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
