[JDEV] EVERYTHING (re: mime/file-xfer/ctcp/etc)

[Jeremie]

> 	I look forward to seeing the file transfer mechanism. That Jabber has to be
> interoperable and be able to exchange files with other IM systems ( I am
> glad this has been brought up again, honestly. It is all too easy to lose
> focus. ) makes the topic extremely interesting.

I'll try to get it put together tonight.  It sounds pretty straight
forward, but when mingling in the other IM systems it can get
complicated quickly :)

> 	Jer, I suggest creating a client to client optional protocol team. If you
> don't want to - it is, indeed, outside the scope of interoperable Jabber -
> then those of us interested, myself included, will form an external working
> group and move our discussions and ultimately implementations there.

I'm not dead-set against it, it's just not part of the way Jabber works
and I haven't seen the critical need for a standard form of client to
client Jabber-specific communications.  The only critical common needs for
it that I can see are streaming and file transfers, and both of those can
be addressed without creating a Jabber-specific connection directly 
between clients.

If someone can express a need for a Jabber-specific client to client
connection that can't be served (or served better) via the server, I'll be
glad to consider adding it to Jabber, *grin*.

> 	Also, I have some more general question regarding extensions: Message
> extensions aren't required to be interoperable, right? So we can create
> extensions which aren't supported by other transport systems?  Transports
> may or may not deal with extensions which they feel they can handle, right?
> 
> 	Any thoughts on the possibility of creating an extensions team?

Actually yes, we need to discuss extensions and how they should be
handled.  The intention of the <ext></ext> field is to be
application-specific, so that any particular application could use Jabber
to talk to another version of itself running for another user, and pass
structured data in the background.  It can also be used for very
specialized server modules talking to custom clients, this might be for a
special service built upon Jabber.

Anything that might be of use or interest across multiple clients,
servers, or transports, I'd like to consider for addition into the main
protocol.  We shouldn't have to resort to using the <ext></ext> field for
common basic functionality.  *But*, if there are lots of "fringe"
features that come up, it might very well be better to create a common set
of extensions :)

Also, extensions should be structured like(this should be included in the
protocol documentation somewhere):
    <ext><app-specific-id>
	app custom data in here
    </app-specific-id></ext>

Jer