[standards-jig] JEPs and Jabber Adoption

Tijl Houtbeckers thoutbeckers at splendo.com
Sat Jun 28 15:14:43 UTC 2003


Paul Curtis <pcurtis at terrapin.com> wrote on 27-6-2003 3:45:41:

[about the JEPs named below]
>Now, are these JEPs perfect? Probably not. 

We've had filetransfer in the form of DTCP+JidLink+IBB(the old 
one)+filetransfer(the olde one). They've all been replaced with 
different proposals. Technically, these are not all that much superiour 
to the mechanism above. Nor are they much better from a practical "real 
world" standpoint (quite the opposite even). In fact, most are rather 
the result of different viewpoints in "protocol-philosophy" (and that 
explains the lack of concensus) 

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

The answer to why this hasn't been happening is the same answer as to 
why the orginal 4 JEPs I named above have not been put through. So 
perhaps is makes sense to ask that question too. 

>From what I remember it's been something things like:
DTCP: no we should an adaption of an IETF standard (SOCKS5)
Jidlink: no that's one IQ exhange too much.
IBB: no we should use <message/>. Doesn't matter if it's ready for that 
or not. 

Only one council member has to pick up on that, and the JEP is 
effectivly blocked. 

Rather than letting a sizeable part of the community that comes up with 
a decent standard go ahead with anything further then highly 
experimental implementation and iron out the bugs if necissary, the JEP 
process blocks this till everyone, well especially everyone with 
influence in the council, is close to 100% happy. 

I honestly doubt we would have had much problems with filetransfer if 
we went ahead with the "old" JEPs. They surthenly would have matured by 
now, wich is not at all the case for the "new" JEPs we have now that 
you want to move forward. I'm not saying the new JEPs won't give us 
something that's slighty better than the old ones, but we would have 
had filetransfer by now. 

Ofcourse, this way of working has it's advantages. We end up with 
something for wich, after a long long while there is probably more 
concensus on than any other protocol that would have come out in a 
different process. We can also be sure that from a technical point of 
view it's ok. But do these advantages weigh up disavantages: the 
immensly slower pace of innovation, the immensly longer time-consuming 
discussions. 

Perhaps the council's role should be more to let through different 
competing solutions, rather than searching for the holy grail of 
protocols. Should more competing protocol be let through to the next 
stage of the JEP process? If you're the first to come up with a decent 
protocol that does the job is it fair you have to fight on SJIG for 
many months or even years before your protocol even advances to draft? 

I'm not trying to promote here that we go back to those old JEPs for 
filetranfer (perhaps with the exception of Jidlink ;). That ship has 
sailed.. 

Just that we ask ourselves the questions, do the advantages of this 
lenghty process weigh up against the disavantages? I honestly believe 
we could have had decent filetransfer by now. Even if some in the 
community would have rather seen it implemented slighty different, I 
doubt they'd have any serious issues  working with it. 

Do we want to repeat this for future protocol enhancments? (I dunno, 
VoIP?) 

I'm just saying, having endless discussion on SJIG in the experimental 
fase is not necisarly the best way to pick a protocol for something. I 
think we should seriously consider an alternative way of working. (and 
thus effectivly, the role of the Council in the community) 

-- 
Tijl Houtbeckers
Software Engineer @ Splendo
The Netherlands




More information about the Standards mailing list