dizzyd at jabber.org
Sun Jan 18 15:03:40 UTC 2004
-----BEGIN PGP SIGNED MESSAGE-----
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
> on an XML stream, it operates as a series of stanza/full-element
> transactions. It abandons TLS and SASL security layers, and relies
> 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
> support cannot be offered via a separate public proxy and remain
> 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
> I consider JEP-124 harder to implement because the changes in the
> 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
> to support it. JEP-25 requires less changes to existing XML stream
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
> can weigh the options. As it stands, I don't even see anything to
Of course, there is also an introduction on 124 that describes some of
the other rationale for this JEP...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)
-----END PGP SIGNATURE-----
More information about the Standards