[Standards-JIG] Re: JEP-0124: comments on proposed version 1.5

Peter Saint-Andre stpeter at jabber.org
Thu Apr 27 19:10:54 UTC 2006

Hash: SHA1

Ian Paterson and I discussed these items off-list. I modify my questions
and comments as follows...

Peter Saint-Andre wrote:
> In today's Jabber Council meeting [1], we discussed the proposed
> revisions to JEP-0124. [2] [3] I promised to provide some comments. Here
> they are. :-)
> 1. In a prior thread [4] 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.

Ian convinced me that this is covered by the existing text.

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

The current text says that "The client SHOULD take care to choose an
initial 'rid' that will never be incremented above 9007199254740991 [10]
within the session." I propose that we change SHOULD to MUST. Also I
have added the following sentence to the note: "In practice, a session
would have to be extraordinarily long (or involve the exchange of an
extraordinary number of packets) to exceed the defined limit." Finally I
have moved the text regarding the syntax of the Request ID to a new
subsection of Section 12 (Request IDs).

> 3. As far as I can see, the point raised by Peter Millard [5] 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.

I propose the following text for the introduction:


The OPTIONAL feature described in this section enables multiple XMPP
streams to be contained within a single session. This is helpful for
several reasons:

    *Some runtime environments constrain the number of simultaneous HTTP
requests a client may make to each connection manager; if such clients
need to connect using more than one account at the same time, then
support for multi-stream sessions is essential.

    * While XMPP does not allow two sessions with the same full JID to
be open at the same time, it does use one stream in each direction for
client-to-server connections; support for multiple streams enables
clients that connect via the HTTP Binding to emulate that behavior and
thereby reduce network traffic.


> 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
>    Stanzas above).
> For example, add a clause to the effect that "this helps ensure
> backwards compatibility" (it may not be obvious to people).

I added a footnote about this.

> If this feature is completely backwards compatible then I'm fine with
> it. Even though it adds complexity, that complexity is optional. :-)

This feature is, I think, completely backwards-compatible.

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

I have changed the first paragraph of section 14.2 to read:


If a connection manager supports the multi-streams feature, it MUST
include a 'stream' attribute in its session creation response. If a
client does not receive the 'stream' attribute then it MUST assume that
the connection manager does not support the feature. The 'stream'
attribute identifies the first stream to be opened for the session. The
value of each 'stream' attribute MUST be an opaque and unpredictable
name that is unique within the context of the connection manager


> 6. In today's meeting I complained [6] about the schema changes. [7] 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:
> <body rid='SomeRID'
>       sid='SomeSID'
>       randomAttribute='foobarcity'
>       xmlns='http://jabber.org/protocol/httpbind'>
>   <svg xmlns='http://www.w3.org/2000/svg'>
>     ... image data here ...
>   </svg>
> </body>
> 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.

Ian has convinced me that there are other possible applications for the
HTTP Binding and that in general a JEP-0124-compatible connection
manager will simply act as a pass-through mechanism for XML. Therefore I
have added the following implementation note:


While it is currently envisioned that implementations of the protocol
specified herein will mostly be used as connection managers for XMPP
servers, management of connections to non-XMPP implementations is also
possible. Furthermore, a connection manager that implements the HTTP
Binding will simply act as a pass-through mechanism for XML (not
necessarily XML that conforms to the schemas for the 'jabber:client' and
'jabber:server' namespaces as specified in RFC 3920 and RFC 3921).
Therefore, the XML schemas defined herein are explicitly not limited to
XMPP. Any error handling for non-XMPP elements and attributes is the
responsibility of the application using such a connection manager, not
the connection manager itself.


I have also cleaned up the schemas accordingly.

My changes are here:


CVS diff:



> [1] http://www.jabber.org/council/meetings/agendas/2006-04-11.html
> [2] http://www.jabber.org/jeps/tmp/jep-0124-1.5.html
> [3]
> http://www.jabberstudio.org/cgi-bin/viewcvs.cgi/cvs/jeps/0124/jep-0124.xml?r1=1.47&r2=1.62
> [4] http://mail.jabber.org/pipermail/standards-jig/2006-March/010249.html
> [5] http://mail.jabber.org/pipermail/council/2006-March/001824.html
> [6]
> http://www.jabber.org/muc-logs/council@conference.jabber.org/2006-04-11.html
> [7]
> http://www.jabberstudio.org/cgi-bin/viewcvs.cgi/cvs/jeps/0124/jep-0124.xml?r1=1.61&r2=1.62

Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060427/d2133d1e/attachment.bin>

More information about the Standards mailing list