I defer to the JEP author, and will remove the hash representation. On Thu, Feb 13, 2003 at 03:01:33PM -0600, Peter Saint-Andre wrote: > First of all, the question here is related more to browse implementation > than MUC implementation. Unfortunately, the browse specification is not > consistent with usage such as this: > > <iq > type='result' > id='1011' > to='xxx@localhost/coccinella' > from='[EMAIL PROTECTED]'> > <conference xmlns='jabber:iq:browse' name='girls' type='public'> > <ns>http://jabber.org/protocol/muc</ns> > <user name='mats' > jid='[EMAIL PROTECTED]/13c6a01dc31309e331c2b018640b9c03b8534327'/> > </conference> > </iq> > > The browse JEP (which is incomplete) does not seem to allow <conference/> > as a root element for the jabber:iq:browse namespace (there is no DTD or > schema so we can't be sure, but it appears that <item/> is the root > element and as we know only one root element should be allowed). In > addition, it does not define <user/> as a child element of the root > element. So I would say that the above stanza is questionable from the > perspective of browse. > > Second, given the ambiguities involved in browse, it may behoove the > author of JEP-0045 to remove all references to browse and require support > for disco only. However, I am loath to do so until disco goes to Draft, so > it is possible I will hold off on submitting JEP-0045 to the Council until > disco is advanced to Draft. > > Third, I would agree with Constantin that the hashed resource in the 'jid' > attribute in the stanza shown above is inconsistent with the spirit of > MUC. Note example 10 in version 1.3 of JEP-0045: > > Example 10. Room Returns Disco Item Results (Items are Public) > > <iq > type='result' > from='[EMAIL PROTECTED]' > to='[EMAIL PROTECTED]/pda' > id='disco4'> > <query xmlns='http://jabber.org/protocol/disco#items'> > <item jid='[EMAIL PROTECTED]/firstwitch'/> > <item jid='[EMAIL PROTECTED]/secondwitch'/> > </query> > </iq> > > In this instance, the user information is public and the implementation > returns each user's room JID (not a hash). > > If user information is *not* public, then the implementation SHOULD return > empty results, not hashed information, as in Example 11: > > Example 11. Room Returns Empty Disco Item Results (Items are Private) > > <iq > type='result' > from='[EMAIL PROTECTED]' > to='[EMAIL PROTECTED]/pda' > id='disco4'> > <query xmlns='http://jabber.org/protocol/disco#items'/> > </iq> > > Or at least so it seems to me. Thoughts? > > Peter > > -- > Peter Saint-Andre > Jabber Software Foundation > http://www.jabber.org/people/stpeter.php > > On Tue, 11 Feb 2003, Constantin Nickonov wrote: > > > I understand what you're trying to do. The problem is that your methods > > conflict with the intent of JEP-0045, which will eventually result in > > fragmentation of the standard, i.e., when two or more implementations of MUC > > accomplish the same thing in incompatible ways. Perhaps the JEP should be > > more specific when it comes to laying out the 'jabber:iq:browse' > > capabilities (which are being phased out in favor of disco), but it seems to > > me the re-introduction of SHA-hashing for this purpose is not a good thing. > > > > Sure, you can talk about race conditions, like when I browse to get a list > > of users and one of them chooses that moment to change his nick, making my > > subsequent user-level browse requests invalid. But why not just return the > > real JID (if it's allowed by the room) in the room-level browse result? > > Something like this: > > > > SENT: <iq type='get' to='[EMAIL PROTECTED]'> > > <query xmlns='jabber:iq:browse'/> > > </iq> > > READ: <iq type='result' to='user@server/resource' from='[EMAIL PROTECTED]'> > > <conference xmlns='jabber:iq:browse' name='room' type='public'> > > <ns>http://jabber.org/protocol/muc</ns> > > <user name='nick1' jid='user2@server/resource'/> > > </conference> > > </iq> > > > > In the case of an anonymous room, the 'jid' attribute could be omitted (or > > contain the in-room JID for that user, i.e., '[EMAIL PROTECTED]/nick2'). > > > > > -----Original Message----- > > > From: David Sutton [mailto:[EMAIL PROTECTED]] > > > Sent: Tuesday, February 11, 2003 8:59 AM > > > To: [EMAIL PROTECTED] > > > Subject: Re: [JDEV] MUC problems > > > > > > > > > Hello there, > > > > > > We are both correct in this situation. The JEP does define > > > how the jid > > > is to be handled for a presence packet, and MU-Conference follows > > > that. You will never see the SHA1 string in a presence packet. > > > > > > On the other hand, the system of using an iq request, xmlns > > > jabber:iq:browse, to discover the room roster is not covered by the > > > JEP. In order to maintain sanity, I have opted to continue using the > > > existing methods. If you require to see the real jid, and you are > > > allowed, then browsing the SHA1 resource will reveal the true jid. I > > > have to use the sha1, since it allows you to track the user more > > > consistantly - as I tried to explain before, I could use > > > '[EMAIL PROTECTED]/NICK' for the nickname reported > > > by browse, > > > the problem is that if users swap nicknames, I have no way > > > of knowing > > > that is what happened. The SHA1 string is unique to that user. > > > > > > Regards, > > > > > > David > > > > > > On Tue, Feb 11, 2003 at 08:12:16AM -0700, Constantin Nickonov wrote: > > > > see below > > > > > > > > > -----Original Message----- > > > > > From: David Sutton [mailto:[EMAIL PROTECTED]] > > > > > Sent: Monday, February 10, 2003 8:51 PM > > > > > To: [EMAIL PROTECTED] > > > > > Subject: Re: [JDEV] MUC problems > > > > > > > > <snip> > > > > > > > > > The hex string is actually a SHA1 hash of the users real > > > jid. Its used > > > > > to reference a user, but not reveal the true jid. If the room > > > > > is set up to allow people to see the real jid, then just browse > > > > > > > > [EMAIL PROTECTED]/13c6a01dc31309e331c2b018640b9c03b85 > > > 34327 and > > > > > it will show you the true jid. This also helps to keep > > > compatability to > > > > > existing clients that are used to this form with the > > > > > groupchat/conferencing module. The real jid is used as > > > the reference, as > > > > > a person can keep changing their nick throughout a > > > session, but they > > > > > can't change their real jid > > > > > > > > The problem with this is that the MUC standard (JEP-0045) > > > specifies how > > > > nicknames are passed along with presence information, and > > > how they are > > > > changed -- and SHA-hashing isn't the way. > > > > > > > > Entering a room (JEP-0045, section 6.2): > > > > > > > > SENT: <presence to='[EMAIL PROTECTED]/nick1'> > > > > <x xmlns='http://jabber.org/protocol/muc'/> > > > > </presence> > > > > READ: <presence from='[EMAIL PROTECTED]/nick1' > > > to='user@server/resource'> > > > > <x xmlns='http://jabber.org/protocol/muc#user'> > > > > <item affiliation='owner' jid='user@server/resource' > > > > role='moderator'/> > > > > </x> > > > > </presence> > > > > > > > > Changing the nick (JEP-0045, section 6.4): > > > > > > > > SENT: <presence to='[EMAIL PROTECTED]/nick2'/> > > > > READ: <presence type='unavailable' from='[EMAIL PROTECTED]/nick1' > > > > to='user@server/resource'> > > > > <x xmlns='http://jabber.org/protocol/muc#user'> > > > > <item nick='nick2' affiliation='owner' > > > > jid='user@server/resource' role='moderator'/> > > > > <status code='303'/> > > > > </x> > > > > </presence> > > > > <presence from='[EMAIL PROTECTED]/nick2' > > > to='user@server/resource'> > > > > <x xmlns='http://jabber.org/protocol/muc#user'> > > > > <item affiliation='owner' jid='user@server/resource' > > > > role='moderator'/> > > > > </x> > > > > </presence> > > > > > > > > The MUC protocol wasn't designed to be fully > > > backward-compatible with the > > > > JCF draft. > > > > > > > > Constantin > > > > _______________________________________________ > > > > jdev mailing list > > > > [EMAIL PROTECTED] > > > > http://mailman.jabber.org/listinfo/jdev > > > > > > -- > > > David Sutton > > > Email: [EMAIL PROTECTED] > > > Jabber: [EMAIL PROTECTED] > > > > > _______________________________________________ > > jdev mailing list > > [EMAIL PROTECTED] > > http://mailman.jabber.org/listinfo/jdev > > > > > > _______________________________________________ > jdev mailing list > [EMAIL PROTECTED] > http://mailman.jabber.org/listinfo/jdev
-- David Sutton Email: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
