Re: [Standards] Reg MUC Roomname
Hi, Thank u very much for the reply. One more query, whether the id attribute in xmpp stanzas is case sensitive or not. Please clarify my doubt. Regards Thanik On Wed, Jul 2, 2008 at 3:40 AM, Peter Saint-Andre [EMAIL PROTECTED] wrote: Michal 'vorner' Vaner wrote: Hello On Mon, Jun 30, 2008 at 09:29:03PM +0530, Thanik wrote: Can someone clarify whether the roomname in MUC is case sensitive or not? The concept of case sensitive applies only to US-ASCII -- or at least it does not apply to all UTF-8 characters. Stringprep uses the concept of case folding instead. Also clarify whether the following attributes are case sensitive or not? 1) Transaction ID (TID) Where's that thing from? Maybe the 'id' attribute? 2) Username in JID Case insensitive (see nodeprep profile). Or, it is close-to case insensitive, it also considers other similar-looking characters as the same (like roman number four and IV). Right, but even stringprep doesn't help you with that AFAIK. 3) Room User Nickname Case sensitive, as it is JID resource, it goes trough resourceprep. Correct. Some people find that confusing, though, because vorner is a different person than Vorner (etc.). 4) Room Name Case insensitive ‒ it is node part (username) of JID. Correct. 5) PrivacyList Name Unspecified. :( I think we'd apply resourceprep to determine matching. But that needs to be added to XEP-0016. 6) Group Name of a Roster Item. According to section 2.3.2 of draft-saintandre-rfc3921bis, duplicate groups are determined using the Resourceprep profile of stringprep. I think that could be called out more prominently in the spec, so I'll fix that in the next version. I don't know, try looking which stringpreps and rules apply to them (in XMPP-IM). In specification they have not mentioned anything about this. They do, it is just well hidden ;-) :) Peter -- Keep away from small people who try to belittle your ambitions. Small people always do that, but the really great make you feel that you, too, can become great. *Mark Twain
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
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: 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
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: collection node= 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
