[standards-jig] JEP-0025

Justin Karneges justin-keyword-jabber.093179 at affinix.com
Sat Jan 17 02:04:00 UTC 2004

I've brought up the issues before, but I'll do it again since you asked.

>From what I can see, JEP-124 brings no improvement over JEP-25 (other than the 
fact that it is standards-track).  In fact, it reduces features and is harder 
to implement.  I'll explain below.

JEP-124 tightly couples HTTP with XMPP, to the point where it basically 
reinvents the xmpp-core login and security procedure.  Instead of operating 
on an XML stream, it operates as a series of stanza/full-element 
transactions.  It abandons TLS and SASL security layers, and relies instead 

I consider this a reduction in features, because HTTPS is certainly not 
preferrable to full XML stream encryption.  For instance, JEP-124 server 
support cannot be offered via a separate public proxy and remain secure.  
Also, HTTPS is known to be costly, especially if many clients are polling at 
once.  XML stream encryption, as defined in section 5 and 6 of 
draft-ietf-xmpp-core, is much more practical and secure.

I consider JEP-124 harder to implement because the changes in the protocol 
fundamentally alter the way we deal with XML streams.  This doesn't mean it 
will be impossible to adapt to, but rather more code will need to be written 
to support it.  JEP-25 requires less changes to existing XML stream code.

Maybe if the authors can explain the improvements JEP-124 intends to bring, we 
can weigh the options.  As it stands, I don't even see anything to weigh.


On Friday 16 January 2004 04:04 pm, Peter Saint-Andre wrote:
> On Fri, Jan 16, 2004 at 02:51:56PM -0800, Justin Karneges wrote:
> > JEP-124 is certainly a different way to perform an HTTP polling
> > connection, but I hope it doesn't qualify as a complete replacement.
> >
> > JEP-25 is nice because it doesn't reinvent xmpp-core.  Not only does this
> > make it very easy to program (developers get to re-use their same
> > xmpp-core code), but it also gives us access to features like TLS and
> > SASL stream encryption, which are absent from JEP-124.
> Please. The point is develop ONE solution that addresses all needs
> (or at least 80% of the needs). If you have problems with JEP-0124,
> please specify them so the JEP authors can adjust the protocol and
> get it right this time.
> Peter

More information about the Standards mailing list