[Standards] XEP-0115: invalid example + node in disco results

Peter Saint-Andre stpeter at stpeter.im
Wed Jul 2 18:19:39 UTC 2008

Pedro Melo wrote:
> On Jul 1, 2008, at 11:18 PM, Tobias Markmann wrote:
>> On Tue, Jul 1, 2008 at 11:43 PM, Peter Saint-Andre 
>> <stpeter at stpeter.im> wrote:
>> Tobias Markmann wrote:
>> Hi,
>> First of all kostix from tkabber found an invalid example in XEP-0115 
>> under http://www.xmpp.org/extensions/xep-0115.html#discover . Example 
>> 4 should be:
>>    <iq from='romeo at montague.lit/orchard'       id='disco1'
>>       to='juliet at capulet.lit/balcony'       type='result'>
>>     <query 
>> xmlns='http://jabber.org/protocol/disco#info'>               
>> node='http://code.google.com/p/exodus#QgayPKawpkPSDYmwT/WM94uAlu0='>
>> Currently the query tag is close before node attribute.
>> Typo fixed.
>> The next thing is I'm upgrading pidgins caps support and some question 
>> arise from time to time.
>> Is the node attribute in the query tag required in a disco result 
>> since the XEPs' examples include it but the scheme doesn't tell 
>> anything about it.
>> I think it is recommended, but if the processing application doesn't 
>> receive it in the disco result it needs to process the disco anyway.
>> So if I send a query with node 
>> 'http://code.google.com/p/exodus#QgayPKawpkPSDYmwT/WM94uAlu0=' can i 
>> expect the result includes a node attribute too?
>> If yes I could easily compare the hash inside the node to the self 
>> generated hash of the query contents and cache it on match.
>> Yes that seems best. I think we can make it required if that would be 
>> helpful. However, the client should remember it based on the IQ id.
>> Peter
>> Okay. How should a client respond if it requests disco for a node with 
>> the caps hash of the previous presence though receives a disco result 
>> with a node url including a different hash?

You're not checking the disco NodeID, you're checking the disco#info 
against the caps hash you have on file for that user. Or so it seems to me.

> Did you receive a new presence from that client between the moment you 
> sent your IQ request and you got the IQ reply? If yes, and if the hash 
> in said presence is the same as the response, then I would make it 
> "business as usual". Basically, you accept that the response is 
> consistent with the current caps hash for that client.
> In a general way, I would say:
>  * if the hash matches the payload of the IQ response, then you can 
> cache it for future use;

Agreed, business as usual.

>  * if the hash does not match the payload; you cannot cache it (as per 
> spec), but you should use it to represent the client capabilities until 
> you get a new caps hash.

I think you'd ping someone else in your roster if a problem like that 
persists. I'm not sure what you mean by "represent the client 
capabilities until you get a new caps hash" because hash doesn't match 
the disco#info.


More information about the Standards mailing list