Re: [Standards] XEP-0115: invalid example + node in disco results
Hi, 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 <[EMAIL PROTECTED]> 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. Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP!
Re: [Standards] XEP-0115: invalid example + node in disco results
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: >>> >>> >> to='[EMAIL PROTECTED]/balcony' type='result'> >>> >>> 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: Then requests: but gets Cheers Tobias
Re: [Standards] XEP-0115: invalid example + node in disco results
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: 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
Re: [Standards] XEP-0115: invalid example + node in disco results
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: 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? 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? Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP!
Re: [Standards] XEP-0115: invalid example + node in disco results
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: >> >>> to='[EMAIL PROTECTED]/balcony' type='result'> >> >> 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? Cheers, Tobias
Re: [Standards] XEP-0115: invalid example + node in disco results
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: id='disco1' to='[EMAIL PROTECTED]/balcony' type='result'> 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
[Standards] XEP-0115: invalid example + node in disco results
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: node='http://code.google.com/p/exodus#QgayPKawpkPSDYmwT/WM94uAlu0='> Currently the query tag is close before node attribute. 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. 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. Cheers, Tobias