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]/13c6a01dc31309e331c2b018640b9c03b8534327 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]
msg08624/pgp00000.pgp
Description: PGP signature
