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

Mridul Muralidharan mridul at sun.com
Fri Apr 28 19:37:34 UTC 2006


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