[Standards] XEP-0115: invalid example + node in disco results
melo at simplicidade.org
Thu Jul 3 07:15:57 UTC 2008
On Jul 2, 2008, at 7:19 PM, Peter Saint-Andre 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:
>>> 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.
I meant that the list of features that he got represent the
capabilities of the client, but he cannot associate that feature list
with the hash given.
Compare it with a situation of a client that does support disco#info
but does not support xep-0115: you trust the feature list to match
the capabilities of the client.
XMPP ID: melo at simplicidade.org
More information about the Standards