[standards-jig] JEPs and Jabber Adoption

Sebastiaan Deckers cbas at screaming3d.com
Sun Jun 29 22:49:58 UTC 2003

Paul Curtis wrote:

> Justin Karneges wrote:
>> True, there quite a few JEPs setting around and doing nothing.  
>> However, what about the JEPs that aren't abandoned, but instead are 
>> endlessly discussed?  That's what this thread was originally about, 
>> anyway.
> Actually, the original thread was about getting a set of JEPs covering 
> file transfer in place. My intention was not to start a far-reaching 
> discussion of how JEPs are handled, but rather a wake up call on a 
> single feature that is the single most requested item.
> I guess I need to be a bit more forceful .... we need to have file 
> transfer in as many Jabber clients as quickly as possible. And they 
> all need to use the same protocols to do it. To acheive that end, I 
> made specific recommendations for the forwarding of four JEPs (one is 
> already draft) to the Council for last call.

Don't most clients already support file transfer using iq:oob?  These 
controversial JEPs are about generic datastreams, and filetransfer is 
just sort of tacked on to that.
Maybe it's just me, and maybe it's way too late to say this, but why 
don't we just extend iq:oob?  You see, (1) HTTP is capable of sending 
files with encryption/resuming/authentication/etc, (2) there is an 
existing infrastructure of proxy servers, and (3) most clients already 
support HTTP GET.  How about just adding support for HTTP POST, in case 
the sender is firewalled, and something like PASS, in case both parties 
are firewalled?
This can be deployed in a minimum of time.
Iq:oob + HTTP has other advantages such as sending files to people 
behind a transport.  Has this compatibility been considered by the 
authors of the various generic datastream JEPs?
Even phones have HTTP support.  Although the iMode devices I have seen 
did not support HTTP POST, only GET.  Maybe someone can shed some light 
on this?

Generic datastreams are an answer to a question no one is asking.  We 
have wonderful protocols for VoIP, file transfers, even online chess 
(Justin ;-) ).
The reason it has taken years and dozens of proposals and modifications, 
is because the goal is not filetransfers.  The goal is a protocol for 
"generic datastreams of which filetransfers is one application".  There 
is no way a consensus can be formed based on that goal -- it is too vague.

Now as Paul just said, we need file transfers ASAP.  Users demand file 
transfer support that works out-of-the-box with any client or device and 
any firewall configuration.
Instead of dragging this generic crap on for another couple of months in 
endless discussions, let's build on what is already out there: HTTP and 


More information about the Standards mailing list