[Council] vote needed from Ian

Peter Saint-Andre stpeter at stpeter.im
Fri Feb 22 03:50:23 CST 2008

Ian Paterson wrote:
> Hi Earth,
> Sorry for the delay.
> I went through XEP-0115 with a fine tooth comb. Here are my comments and
> questions (the first 4 are typos that can be ignored by all except Peter):
> 1. Typo:
> "must be usable be servers"


> 2. Typo: missng "it" before "MAY"
> "If a connected client determines that its server supports caps
> optimization, MAY "


> 3. Typo: I think this sentence needs tidying up:
> "It is RECOMMENDED for an application to cache associates across
> presence sessions. However, since this obviates the need for extensive
> service discovery requests at the beginning of a session, such caching
> is strongly encouraged, especially in bandwidth-constrained environments."
> If I understood the intention correctly then these three edits might help:
> /associates/associations/
> /. However//
> /, such/. Such/

Ah. The RECOMMENDED there was changed from OPTIONAL so now the "however"
doesn't make sense. Fixed.

> 4. Typo: The "Server Optimization <#optimization>" (#optimization) link
> before Example 7 seems to be broken. I guess it should be "Caps
> Optimization" (#impl-optimize)?


> 5. Could we recommend a really short non-URI 'node' value for apps that
> want to save bandwidth and are happy to rely on the disco <identity/>
> element to identify themselves? For example, node='*'

Presumably such entities would not even send capabilities data, no?

> 6. We might want to define more than one delimiter in Section 5.1
> "Generation Method". For example, in Point 7 the fact that FORM_TYPEs
> vars and values are delimited with the same character as the fields
> means it would be possible, for example, to design two fields that give
> rise to the same string as one field, or three forms that give rise to
> the same string as one form. Features and forms could even be confused.
> These issues would probably almost never happen by accident, and it
> probably wouldn't matter much even when they did. However, do we need to
> take the risk?

Yeah, Joe and I talked about that. At one point I had different
delimiters in there and he convinced me that they didn't add anything to
the protocol, because an entity is not going to parse the string that's

> 7. In Section 5.4, I didn't understand why is it necessary for client
> authors to implement the following tests. (for example, they aren't
> sufficient to prevent caps cache poisoning - which is the hash
> algorithm's job anyway):
> 3.3. If the response includes more than one service discovery identity
> with the same category/type/lang/name, consider the entire response to
> be ill-formed.
> 3.4. If the response includes more than one service discovery feature
> with the same XML character data, consider the entire response to be
> ill-formed.
> 3.5. If the response includes more than one extended service discovery
> information form with the same FORM_TYPE or the FORM_TYPE field contains
> more than one <value/> element with different XML character data,
> consider the entire response to be ill-formed.

I think those are ill-formed from the perspective of Service Discovery,
for example:

<iq from='benvolio at capulet.lit/230193'>
    to='juliet at capulet.lit/chamber'
  <query xmlns='http://jabber.org/protocol/disco#info'
    <identity xml:lang='en' category='client' name='Psi 0.9.1' type='pc'/>
    <identity xml:lang='en' category='client' name='Psi 0.9.1' type='pc'/>
    <feature var='http://jabber.org/protocol/disco#info'/>
    <feature var='http://jabber.org/protocol/disco#info'/>

The point is that it's not clear how a receiving entity should check
such results (does it throw out one of the instances?), so it's better
to consider such results to be invalid and move on to checking the hash
against a better-behaved entity.

> Overall congrats. IMHO this is a very good protocol, especially
> considering that it had to be backwards compatible with v1.3.



Peter Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/council/attachments/20080222/e36ce74c/attachment.bin 

More information about the Council mailing list