[Standards] XEP-0115: invalid example + node in disco results
melo at simplicidade.org
Wed Jul 2 10:32:31 UTC 2008
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:
> 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/
> 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.
> 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?
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;
* 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.
It this reasonable?
XMPP ID: melo at simplicidade.org
More information about the Standards