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

[arh14 at cornell.edu]

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

> >This sort of brings me back to my peer-peer question.  File transfer is 
> >really a high bandwidth, client-side, endpoint-endpoint operation.  There 
> >really is no reason it needs to go through the server right?
> 
>   Wrong..  Jabber's modularity in is the way it can route the data from point A to point B.  One client can be anything, and another can be something completely different..   Example:  167289 at mobilecomm.jabber.org would be a pager number.  someone.someaddy at smtptransport.jabber.org could be someone mailbox..  That is also one of the reasons for JNX existing..

Ok. I didn't know that Jabber's scope was that large.  Then it is 
entirely desirable to route all messages through the server which can 
then decide where they should actually end up.  In this scheme are the 
"transport"s tied to their endpoint protocol?  And if so, is there a 
reason they need to be?  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?
 
> > Everybody 
> >else shouldn't be loaded down when somebody sends their video files to 
> >each other.  So, is there any reason against allowing (even requiring) 
> >clients to set up their own peer-peer connections for this type of activity?>
> 
>   This is the hurdle we need to decide on..  How to
> transfer data..  So far the best I've heard so far
> is using HTTP for file transfers.  This would also
> allow many current streaming technologies to be used
> by jabber, in the same way that a browser currently
> does.

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

 
> >The only issue I can see is security.  Were there any plans on 
> >introducing security to Jabber?  If not, what else is preventing 
> >client-client connections.  If so, can't it then be extended to 
> >client-client?
> 
>   Nothing is preventing someone from creating a peer to peer connection.  But, once again, we need feature
> negotionation.  In the meantime, anyone could plunk
> in some sort of peer to peer networking.  I'd just
> advise anyone looking at it try to stick to the
> standard Jabber protocols, but merely allow them to go
> direct to the client.

This was my view also.  Client to client would be no different from 
client to server.  No need to use application(client)-specific protocols.

> > I have always seen the messaging "server" as simply a 
> >router, or DNS server.  Once you know "where" your buddies are, you can 
> >talk to them directly instead of going through the server.  This 
> >increases messaging speed and unburdens the server.  
> 
>   That's one way to look at it, but Jabber's power is
> in the fact that it ISN'T just a 'Buddy is Online'
> system.  It's a way to route data from point A to
> point B in a extendable manner.  That's what the transports
> do.  In this, the server DOES DO MORE.  This is not a bug, it's a feature..

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.

> > In my view, the 
> >messaging server should really be an event notification server (buddy is 
> >online, buddy is offline, buddy moved here, etc.).  This doesn't really 
> >burden the client, since the protocol for client-server is the same as 
> >for client-client.
> 
>   Then use the server to relay this data, and implement
> a client to client protocol.  Easy enough..  I tend
> to think that this ends up ruining the point, as you
> are now locked thru a comm channel, and can't automagically
> route packets somewhere else, without doing some sort of
> hack..

Yes, I hadn't realized the scope of Jabber extended to non-IM clients.  
For non-IM messages, one would have to go through the server.

> 
>   It's all a pmatter of opinion, I guess.  I'm not trying to put your down, I just happen not to like it..
> 

Yup, I just wasn't aware of Jabber's scope.

Aaron

> ---
> Thomas Charron