Re: [Standards] Collection Oversights in XEP-0060
At http://mail.jabber.org/pipermail/standards/2008-June/019234.html (sorry, I lost the original message) Nathan Fritz wrote: > Examples 216 and 219, the notification of disassociation/association > are neither a followup of the example that they show, nor does the > collection have a node reference. The attribute "id" is mentioned as > being in the associate/disassociate element, when in fact "node" is > used. Fixed: http://is.gd/KJH > In short, the example doesn't match the text (nor does it flow with > the previous examples), and the receiving entity has no idea which > collection node is being updated just based on this notification. > > Section 9.2 has a similar inconsistency between the "id" attribute > being mentioned in the text and the "node" attribute being used in > the example, however the lack "node" attribute in the collection > attribute is understandable for the root collection. Ralph and I agreed that if we're talking about the root collection node, the value of the NodeID needs to be empty, that is: > Section 9.7 is not clear whether this item subscription is recursive. > Will it update me of collections within collections within > collections? If an item is published to a (leaf) node, anyone who is subscribed to a collection that aggregates that leaf node will receive the item, even if there are other intermediate collections between the leaf node and the subscribed collection. Or at least that's how things work today. This enables you to have multiple aggregation points within the pubsub system. See also this: http://www.xmpp.org/extensions/tmp/xep-0060-1.12.html#collections-models I may add pictures for all those different models so that people can understand it more easily. :) Peter smime.p7s Description: S/MIME Cryptographic Signature
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] Reg MUC Roomname
Michal 'vorner' Vaner wrote: Hello On Wed, Jul 02, 2008 at 12:03:33PM +0530, Thanik wrote: One more query, whether the id attribute in xmpp stanzas is case sensitive or not. You do not need to distinguish, you get it back as is and it depends on you, what IDs you generate. Right. So I think you would perform exact string matching on the id. /psa
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] Reg MUC Roomname
Hello On Wed, Jul 02, 2008 at 12:03:33PM +0530, Thanik wrote: > One more query, whether the id attribute in xmpp stanzas is case sensitive > or not. You do not need to distinguish, you get it back as is and it depends on you, what IDs you generate. Have a nice day -- This is a terroristic email. It will explode in 10 minutes, if you do not close it in the meantime. Michal 'vorner' Vaner pgpiVX5GjOiu1.pgp Description: PGP signature
