[Standards-JIG] JEP-0124: comments on proposed version 1.5
stpeter at jabber.org
Tue Apr 11 22:56:53 UTC 2006
-----BEGIN PGP SIGNED MESSAGE-----
In today's Jabber Council meeting , we discussed the proposed
revisions to JEP-0124.   I promised to provide some comments. Here
they are. :-)
1. In a prior thread  we discussed some possible security issues
related to JEP-0124. I don't think the proposed text addresses point 3
of my initial email in that thread:
We need to specify whether it's OK to set up a SASL encryption layer
(as some SASL mechanisms allow you to do). If so, what do you send in
the XML? If not, then we need to say that.
The list consensus seemed to be that we would not allow this.
2. I don't think the proposed text addresses point 4 of my initial email
in that thread, either:
Since request IDs may affect security, we probably need to say what
to do if the Request ID hits the upper limit. Do you "wrap" back to
some smaller value? If so, what?
I don't think there was any list discussion of that point.
3. As far as I can see, the point raised by Peter Millard  regarding
the purpose of the multiple streams support is still not fully clear in
the text. In a related matter, please move notes 19 and 20 at
http://www.jabber.org/jeps/tmp/jep-0124-1.5.html#multi into the body of
the text. In general, I think the introduction could be clearer and if
desired I would be happy to propose alternate text to move us along.
4. I would like to make it explicit that the multi-stream feature is
backwards compatible, and exactly how it is. E.g., we could add some
text about this to the end of the following sentence in Section 14.3:
If the connection manager did not indicate its support for
multiple streams at the start of the session then it MUST
ignore the extra attributes and treat the request as a normal
empty request for stanzas (see Sending and Receiving XML
For example, add a clause to the effect that "this helps ensure
backwards compatibility" (it may not be obvious to people).
If this feature is completely backwards compatible then I'm fine with
it. Even though it adds complexity, that complexity is optional. :-)
5. In section 14.2 (discovery of multi-streams support), I think we mean
to say that if a connection manager supports this (optional) feature, it
MUST include a 'stream' attribute in its session creation response
(though naturally it MAY support the feature). Also I think we need to
say that if a client does not receive that 'stream' attribute then it
MUST assume that the connection manager does not support the feature.
6. In today's meeting I complained  about the schema changes.  I'm
still not convinced that we want to allow *any* attribute on the <body/>
element or *any* child in the <body/> element. For instance, this seems
just wrong to me:
... image data here ...
Allowing *any* XML content sure is flexible. But why do we need that
flexibility? Ian argued that if XMPP 1.1 is ever released and it
specifies different stanzas or whatever, we won't have to update the
JEP-0124 schemas if we make them really flexible now. Well, if the IETF
ever releases XMPP 1.1, I expect that a lot of things will need to
change. Making some edits to the JEP-0124 schema will be the least of
our worries. Indeed I'd prefer to revisit things like JEP-0124 if XMPP
1.1 is ever released (which, I think, will never happen; at least it
won't happen on my watch).
The point of JEP-0124 is to be an HTTP Binding for XMPP, not an HTTP
Binding for any random XML. Allowing literally any XML content in the
<body/> element strikes me as unnecessarily flexible. Unless someone can
make a good argument that the flexibility is needed to handle XMPP 1.0,
I would strongly prefer to keep the HTTP Binding of XMPP well-specified.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards