[JDEV] MIME, was My evil plans for a client.

[arh14 at cornell.edu]

On Mon, 9 Aug 1999, Thomas D. Charron wrote:

[snip]

>   They talk to the etherx router via the protocol.  What they do with the data afterwards is their own buisness..  When they send data out to jabber users, they need to conform to jabber protocol, but on other ends, they can do whatever they want.  That is why a Jabber<=>SMTP transport could be done..  The transport is what carries the data from one thing into and out of the jabber 'network'.  Etherx is then in charge of routing the packets where they need to go, either to another etherx, or a local transport.
> 
> For instance, if the server recieves a message, 
> >that message should be formatted independant of its destination.  If so, 
> >this message can be transmitted to an arbitrary type of endpoints 
> >(SMTP, IM, pager, whatever).  Is there a distinction between the Jabber 
> >protocol and these "transport" protocols, and if so, why?
> 
>   I'm not quite sure I understand what your asking, but I'll stab at it..  All data is transported via jabber's protocols.  Extra data CAN be appended inside of CDATA segments in the <ext> tags if needed, but I can truely not think of a reason beyond binary data.  All transports need to know how to talk with this protocol to jabber users.  Anything else they want to do is their own buisness..
> 
>   Perfect example would be the really basic Jabber<=>IRC transport.  It talks to IRC as IRC, and any data coming in to IRC is then transfered into jabber.  It can then route the IRC data to ANYTHING that speaks jabber, hence, I COULD have a transport that monitors an IRC channel for nasty words, and send me a jabber message when it detects it..  Then, you see the fun..  Well, wait, I'm offline, Ok, so it looks at an alternate address in my profile..  Could be a alpha numeric cell phone/pager transport..  Sends it there..  COuld have been an Email, sends it there..  Heck, could be the AOL IM interface to send it to my AOL ID..
> 
>   See how it all shapes up, and the entire reason for having transports?

That's how I thought it worked.  Transports are then basically a 
translation layer before and after the message is routed through the 
Jabber network.  They are not in and of themselves the way the data is 
"transported" (I was confused for a second).  The Jabber protocol handles 
the transportation, and the transports ensure that data can get into the 
Jabber protocol and out of it into the form it needs to be in at the 
destination.


> >?? Would that mean every Jabber client would have to be an HTTP server?  
> >Or that the Jabber server would have to be an HTTP server?  Is there a 
> >reason the Jabber protocol itself cannot handle messages that contain 
> >files, and must rely on a separate protocol?
> 
>   Both ways work, merely an idea that was put forth.  Wouldn;t be a full fledged HTTP server, merely something that would say 'Ok, I'm listening for connection here, go ahead and do an HTTP get there, and I'll send it' in laymens terms..  I personally like the idea of embeding the data into message packets, but it DEFINATLY has it's cons..

Yes, I liked the idea of embedding data into the messages itself.  That is 
where I started off talking about MIME to enable the embedding of 
arbitrary types of data in a message.

> 
> >This was my view also.  Client to client would be no different from 
> >client to server.  No need to use application(client)-specific protocols.
> 
>   Darned good idea of how to do it..  As long as it conformed, the only thing you would have to do it come up of a way to securely start the connection..  Once (if) moddigisign ever get's finished, it'd be a way to do it..

>From perusing the Jabber docs, it looked like after the initial 
"sign-on"/negotiation stage, that client-client was identical to 
client-server - just passing of <message>s.


> >So then the Jabber protocol should support the transport of heterogenous 
> >data in some generic way.  I was seeing embedded MIME as the way to do 
> >this.  That would obviate the need for any other protocols (HTTP, FTP, 
> >client-specific, whatever).  If the client could parse MIME it could 
> >automatically recieve data of any type...no need to even open separate 
> >ports talking different protocols.
> 
>   I would as well..  This is what the <ext> flags are for...  I think we should support SEVERAL ways to transfer files, IMHO, and let the user choose, with the most proven method being the default..  Then of course, do you split up the messages, or send as one HUGE mime message?

Splitting of the message was the conceptual stumbling block.  The least 
troublesome would be at content-type boundaries.  This is a rather high 
granularity though.  Media-streaming would not be practical through 
MIME, and would have to rely clients negotiating some other protocol, as 
Patrick indicated.

Aaron
(I know I quoted a lot...but it's getting hard to chop out too much)