[JDEV] JEPs and Jabber Adoption

Paul Curtis pcurtis at terrapin.com
Thu Jun 26 20:45:41 CDT 2003


I normally avoid all of the conflicts surrounding JEPs, as I am rather 
content to implement than to propose. However, in my one year of active 
participation in the Jabber community, I have watched as proposals for 
much needed features have been sidelined, retracted, or left for dead 
because of lack of community concensus.

The point of a community is community, and not competition. In addition, 
the JEP process, and the XMPP protocol itself, makes it easy to 
implement a feature and extend it later. Isn't that one of the 
touchstones of the protocol itself? "Extensible" is part of the name ... 
it's not just a word or phrase, but rather a methodology for this protocol.

So, where am I going with this? I have watched a single, much needed, 
and frequently requested feature get "reinvented" three times in the 
space of a year. Rather than trying to make it perfect from the start, 
let the community agree on the current proposed enhancements as a 
starting point. This will give the client developers and the users 
something that works, while not perfect for every need, will meet the 
needs of 90% of the user base.

I stand in an untenable position: having promoted Jabber and XMPP 
internally to my company, I have to explain that a fundamental feature 
that every legacy IM system has is absent in Jabber and XMPP. The 
community needs to support this feature to even be on the same playing 
field as the "competition" that is already out there.

What is this feature? File transfer. Currently, the community needs to 
find any major flaw with the existing JEPs mentioned below, and forward 
them all as a group to last call. These four JEPs will give the 
Jabber/XMPP users what they really want.

Now, are these JEPs perfect? Probably not. But, then again, neither was 
SMTP (RFC 822 & 2822). There are many extension RFCs to SMTP to enhance 
its usability and to add features that are not necessarily used by many 
systems in the "mainstream". The JEPs I'm speaking about are:
   * JEP-0042 Inband Bytestreams (the lowest common denominator for file 
transfers)
   * JEP-0065 SOCKS bytestreams
   * JEP-0096 Stream Initiation
   * JEP-0096 File Transfer Initiation

With these four, the Jabber community can cover that 90% of the user 
base. Without them, I'll have to wait out yet another file transfer JEP 
(or JEPs) to be dissected and argued over. If that is the case, then I 
can't continue to be a proponent of the Jabber community, because the 
community is not acting in its best interest.

We, as a community, have lost active participants over the course of the 
year because of petty arguing. We, as a community, cannot afford to lose 
any more (or anyone at all) at this point. XMPP stands to take over as a 
"standard" IM protocol. We need to have this capability ironed out and 
solid when that happens.

Let's take these four JEPs, remove any major flaws, add any major 
omissions, and finalize them now. I can't stand to wait for another 
complete restart on file transfer, and I'm getting less and less willing 
to extoll the virtues of the protocol and community when something like 
this cannot be agreed upon.

paul




More information about the JDev mailing list