[Council] vote needed from Ian

Peter Saint-Andre stpeter at stpeter.im
Sat Feb 23 08:34:13 CST 2008


Seeing no further objections, I'll add this to the agenda of the Council
meeting on Monday for a final sanity check and then push out 1.5.

Peter Saint-Andre wrote:
> 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"
> 
> Fixed.
> 
>> 2. Typo: missng "it" before "MAY"
>> "If a connected client determines that its server supports caps
>> optimization, MAY "
> 
> Fixed.
> 
>> 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)?
> 
> Fixed.
> 
>> 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
> hashed.
> 
>> 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'>
>     id='disco1'
>     to='juliet at capulet.lit/chamber'
>     type='result'>
>   <query xmlns='http://jabber.org/protocol/disco#info'
>          node='http://psi-im.org#8lu+88MRxmKM7yO3MEzY7YmTsWs='>
>     <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'/>
>   </query>
> </iq>
> 
> 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.
> 
> Thanks!
> 
> Peter
> 

-------------- 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/20080223/7e294c88/attachment.bin 


More information about the Council mailing list