On Wed, Jul 2, 2008 at 8:19 PM, Peter Saint-Andre <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> >>> 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='[EMAIL PROTECTED]/orchard' id='disco1' >>> to='[EMAIL PROTECTED]/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='[EMAIL PROTECTED]/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='[EMAIL PROTECTED]/chamber' id='disco1' to='[EMAIL PROTECTED]/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='[EMAIL PROTECTED]/orchard' id='disco1' to='[EMAIL PROTECTED]/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
