[Council] vote needed from Ian

Ian Paterson ian.paterson at clientside.co.uk
Thu Feb 21 12:54:20 CST 2008


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/

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='*'

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?

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.

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

- Ian



More information about the Council mailing list