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

Tobias Markmann tmarkmann at googlemail.com
Wed Jul 2 13:40:52 CDT 2008


On Wed, Jul 2, 2008 at 8:19 PM, Peter Saint-Andre <stpeter at stpeter.im>
wrote:

> 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.
>
> Peter
>

I mean a client gets this presence:

<presence from='romeo at montague.lit/orchard'>
  <c xmlns='http://jabber.org/protocol/caps'
     hash='sha-1'
     node='http://code.google.com/p/exodus'
     ver='QgayPKawpkPSDYmwT/WM94uAlu0='/>

</presence>

Then requests:

<iq from='juliet at capulet.lit/chamber'
    id='disco1'
    to='romeo at montague.lit/orchard'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#info'
         node='http://code.google.com/p/exodus#QgayPKawpkPSDYmwT/WM94uAlu0='/>
</iq>

but gets

<iq from='romeo at montague.lit/orchard'
    id='disco1'
    to='juliet at capulet.lit/chamber'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'
         node='http://code.google.com/p/exodus#SOMEOTHERHASHHERE'>
    <identity category='client' name='Exodus 0.9.1' type='pc'/>
    <feature var='http://jabber.org/protocol/caps'/>
    <feature var='http://jabber.org/protocol/disco#info'/>
    <feature var='http://jabber.org/protocol/disco#items'/>
    <feature var='http://jabber.org/protocol/muc'/>
  </query>
</iq>


Cheers

Tobias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/standards/attachments/20080702/2e18fa3f/attachment.htm 


More information about the Standards mailing list