[JDEV] Proposals (file transfers and info/query)

[arh14 at cornell.edu]

I have about 50 messages left to read so bear with me if this has already 
been addressed.

On Tue, 10 Aug 1999, Jeremie wrote:

> > Are you impling that instead of encoding our messages in MIME, that we
> > encode them with some HTTP headers on the top? I'm going to assume not.
> 
> No no, not at all... I think we are talking about two different issues :)
> 
> 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.

I think the arguments on this thread are orthogonal...MIME is not a 
communication protocol...it is simply a convenient mechanism for the 
identification of arbitrary data sent to the client.  HTTP *may* solve 
this by including MIME-like headers, but in this case it is a 
coincidence.  I don't think anybody is arguing for the use of MIME 
*instead* of (as an alternative to) any transfer protocol: that simply 
doesn't make sense since MIME itself is not a transfer protocol.  What I 
am suggesting is that if all data going through the network were wrapped 
in MIME (which is very lightweight), that ALL transfers of data of ANY 
kind could be handled identically at the endpoints.  HOW it gets to the 
endpoint is a trivial question then, because however it does it can be 
treated uniformly there.  The client will handle file transfers the same 
as <message>s, and the same as whatever other CTCP or CTSP delivers to it.
 
> 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.

MIME says nothing about the connection.  There is no requirement for a 
peer-peer connection for the use of MIME (let alone any web page 
specification).  MIME itself is, in my opinion very simple, especially 
considering the clients already have to be able to parse XML...but that's 
just my opinion.

> Second, Jabber is all about talking transparently
> to other IM systems, many/most of which do not and could not support MIME
> messages.

This is where MIME would work lovely.  The transport would convert from 
MIME (the common denominator) to whatever client-specific format was 
needed (ICQ, AOL, whatever).

>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.

This doesn't make sense.  MIME is not an alternative to file transfer.  
MIME is a data wrapper and identifier.  It is not competition or an 
alternative "form" of file transfer.  When talking directly to an unknown 
client, then the assumption for MIME support cannot be made, and the data 
might have to be sent "as-is" with whatever file type specification the 
underlying protocol provides.  All data going through the Jabber network 
itself though could be MIMEd.

> Finally, it would increase the complexity
> significantly of the Jabber protocol.

Hmm...well since it is the endpoint's responsibility to parse the MIME, I 
can't see how it would add any more complexity than the <ext> tag...maybe 
there are wierd XML CDATA complications?

> 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.
[rest chopped]

Scenario:  popular IM client FOO sends messages to other FOO clients in 
Rich Text Format.  How is the Jabber protocol used to transport these 
messages to and from FOO and other clients on the Jabber network?  If not 
using MIME, is a file transfer required just because the data type is not 
plain text?  Is the data stuck in an <ext> tag?  Using MIME, you would 
just slap on a Content-type: text/rtf, and endpoints would "know" what to 
do with it...pass it on to a plugin/viewer, or whatever.

Aaron