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

Mridul mridul at sun.com
Wed Apr 12 08:15:28 UTC 2006


Hi all,

   Some comments inline.

Thanks,
Mridul

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

Great !

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


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


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.

>
> Thanks.
>
> Peter
>
> [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




More information about the Standards mailing list