[JDEV] Proposals (file transfers and info/query)
patrick at kia.net
Tue Aug 10 17:29:14 CDT 1999
> I'm speaking strictly of file transfers ala the file transfer proposal and
> HTTP, and I think you are talking about the <message></message> packet
> within the Jabber protocol.
> Honestly, I'm quite against adding any sort of MIME layer onto the Jabber
> protocol or <message/> packet itself for lots of reasons. First, instant
> messaging is all about simple instant text messages, not a one-to-one web
> page delivery service. Second, Jabber is all about talking transparently
> to other IM systems, many/most of which do not and could not support MIME
> messages. Third, everything that a client needs to do with MIME can be
> done via file transfers, and in this way be more widely supported even
> across other IM systems. Finally, it would increase the complexity
> significantly of the Jabber protocol.
Regarding simplicitiy: true and true and true. But simple text messages are
in fact not simple any more. Oh, they were easy enough in the sixties I
think (not that I would actually know, mind you) but in the late 90s there
are problems like multiple character sets that deserve to be addressed. I
believe MIME messages solve this problem well.
Regarding transparency to other IM systems: there's no reason transports
can't mangle messages to take easy MIME types - say, text/plain - and put
them into the other transport's expected format (say, ASCII.) In fact, some
IM systems will be expecting a MIME message anyway, and with the current
design a Jabber transport would have to construct a MIME envelope around
outgoing messages and tear away the MIME envelope from incoming messages.
Jabber transports would have no way of knowing whether a Jabber client could
handle complex incoming MIME'd messages, so would either have to pass them
through unchanged - possibly endangering the client - or strip out things it
didn't understand - or possibly refuse the message. None of these are really
Regarding complexity: it does not make the protocol more complex. What it
does is require clients to be more complex (and potentially certain
transports, as well). But it doesn't really do that, either, if you're
careful and say: clients are only required to support the following MIME
types: text/plain, text/very plain, text/very extremely plain.
With a MIME support requirement that light, 'rich' clients would receive
everything in formats which they expect (NB: expect IMPP clients to support
MIME) and slim clients can strip away things they don't like.
> IMHO, messages should be just simple text messages. Jabber is an
> expression of the base and common elements of ALL instant messaging
> systems, not a radically advanced new next generation IM system.
To support the lowest common demoninator would be a boon. To bring Jabber's
future to the lowest common demoninator would be a tragedy.
I'm not going to get hopping mad about this topic either; but I'd like to
see Jer's typically sage comments on these issues, as well as other
More information about the JDev