[Council] vote needed from Ian
ian.paterson at clientside.co.uk
Thu Feb 21 12:54:20 CST 2008
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):
"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:
/, such/. Such/
4. Typo: The "Server Optimization <#optimization>" (#optimization) link
before Example 7 seems to be broken. I guess it should be "Caps
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
3.4. If the response includes more than one service discovery feature
with the same XML character data, consider the entire response to be
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.
More information about the Council