[Council] vote needed from Ian

[Ian Paterson]

BTW I'm +1 on the new protocol version, whether or not my comments 
result in changes.

- Ian


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