[standards-jig] JEP-0025

Dave Smith dizzyd at jabber.org
Sun Jan 18 15:03:40 UTC 2004


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Jan 16, 2004, at 7:04 PM, Justin Karneges wrote:

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

The whole point of 124 is to formally define the binding (what you 
referred to as "coupling") of HTTP and XMPP.  It's SUPPOSED to tightly 
couple HTTP w/ XMPP. As such, it uses HTTPs standard mechanisms for 
transport security (i.e. HTTPS), since that's what a well-behaved HTTP 
application would do.

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

Well, while I agree that HTTPS is not preferable to full XML stream 
encryption (certainly from an efficiency standpoint), it's what the 
HTTP community _uses_ on a daily basis. This is not a question of which 
transport-layer security WE (the Jabber community) like better, this is 
a question of what the HTTP community uses, and expects from a 
HTTP-based protocol.

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

Herein lies the fundamental problem with your arguments -- you're 
approaching this as a traditional XMPP over TCP developer, not a XMPP 
over HTTP developer. This protocol is meant to be easy for developers 
with experience using HTTP, hence the abandonment of the "XML Stream" 
concept, and our customized SASL/TLS negotiation and management 
protocols. Arguing that this JEP is more difficult for _you_ to 
implement, given your XMPP-centric toolbox isn't really a concern to 
me, since you are only marginally the intended audience. The idea is to 
make it easy for non-traditional XMPP developers (i.e. people who 
haven't had a chance to enjoy a persistent TCP connection, etc.) to use 
XMPP in their native environments.

I would also note, that given the intended audience of this protocol, I 
have had good feedback from a couple of HTTP developers.


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

Of course, there is also an introduction on 124 that describes some of 
the other rationale for this JEP...

D.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iD8DBQFACqBMYNE3chVHHsMRAn2sAKD1YULFGrlsS8GQzXnUiR94Q73cmACgtVl9
iU164yOEpQx5Y0Jqooq0sEg=
=S7p6
-----END PGP SIGNATURE-----




More information about the Standards mailing list