[standards-jig] JEPs and Jabber Adoption
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,
> 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
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
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