[JDEV] Proposals (file transfers and info/query)
arh14 at cornell.edu
arh14 at cornell.edu
Wed Aug 11 08:55:09 CDT 1999
I have about 50 messages left to read so bear with me if this has already
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
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.
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.
More information about the JDev