[Standards-JIG] JEP-0124: comments on proposed version 1.5
mridul at sun.com
Wed Apr 12 08:15:28 UTC 2006
Some comments inline.
Peter Saint-Andre wrote:
> 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.
Interesting point - something I did not consider happening ...
In our impl , we make sure that initial rid (31 bits) < max_int / 4 -
would require an exceptionally lot of packets to hit this limit - but
this is a possibility.
Why not do something similar to key : as in key/newkey approach ?
> 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:
> <body rid='SomeRID'
> <svg xmlns='http://www.w3.org/2000/svg'>
> ... 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.
I am also in favor of enforcing XMPP only stanza's within the body element.
A later XMPP spec requiring additional top level xml content change will
anyway require changes to HTTPBind gateway's to be compliant.
The only requirement for this would be that , any 1.0+ support should be
explicitly flagged in the initial body response from the gateway.
>  http://www.jabber.org/council/meetings/agendas/2006-04-11.html
>  http://www.jabber.org/jeps/tmp/jep-0124-1.5.html
>  http://mail.jabber.org/pipermail/standards-jig/2006-March/010249.html
>  http://mail.jabber.org/pipermail/council/2006-March/001824.html
More information about the Standards