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

Jacques Belissent jacques.belissent at Sun.COM
Wed May 3 23:59:02 UTC 2006


Hi,

It would be nice to get some clarifications on the questions below from 
the JEP authors.

Of particular concern is item 2 below.

Though not a normative requirement, if we are trying to morph this spec 
into a generic xml streaming protocol over http, it would be very 
helpful if some non-xmpp examples and rationales were included.

The spec requires an XMPP server.  It does not require any other 
back-end to handle other xml.  How is the non-xmpp xml going to be 
handled?  Are we assuming that the XMPP server will support more than 
XMPP?  Will the connection manager talk to some other back end?

In any case, it is not realistic to expect the xmpp server or the 
connection manager to handle any random xml.  There should be some kind 
of negotiation between the client and the httpbind component to 
determine which stanza-level non-xmpp namespaces can be used.

In addition, shouldn't the spec require that all stanzas from the client 
have an explicit namespace declaration, at least for non-xmpp stanzas? 
This is currently a SHOULD.

Thanks in advance.
Jacques


Mridul Muralidharan wrote:
> Hi,
> 
>  Couple of issues.
> 1) The value of '9007199254740991' for max value of rid : how was this 
> arrived at ? On what criterion ?
> 2) Why are you allowing arbitrary xml stanza's to be sent through 
> connection manager ?
> I am not sure why we are envisioning jep124 http binding connection 
> manager as a generic xml stream gateway - if specific implementations 
> want to treat it that way , it is fine.
> But the jep as such should conform to xmpp as much as possible imo. At 
> the very least , this should be something which should be something 
> which is explictly negotiated and enabled.
> 
> Thanks,
> Mridul
> 
> Peter Saint-Andre wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> 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
>> application.
>>
>> ******
>>
>>  
>>
>>> 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:
>>
>> http://www.jabber.org/jeps/tmp/jep-0124-1.5.html
>>
>> CVS diff:
>>
>> http://www.jabberstudio.org/cgi-bin/viewcvs.cgi/cvs/jeps/0124/jep-0124.xml?r1=1.62&r2=1.63 
>>
>>
>> /psa
>>
>>
>>  
>>
>>> [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 
>>>
>>>   
>>
>>
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.1 (Darwin)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>>
>> iD8DBQFEURc+NF1RSzyt3NURAuq+AKDFyYDtOpRR14+MXFHPq31+T83XEwCgjblz
>> a2UK4zIsxm2tGhhfUhS57FI=
>> =3ved
>> -----END PGP SIGNATURE-----
>>  
>>
> 



More information about the Standards mailing list