[JDEV] MUC problems
David Sutton
jabber at dsutton.legend.uk.com
Thu Feb 13 19:09:16 CST 2003
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 at localhost/coccinella'
> from='girls at conference.localhost'>
> <conference xmlns='jabber:iq:browse' name='girls' type='public'>
> <ns>http://jabber.org/protocol/muc</ns>
> <user name='mats'
> jid='girls at conference.localhost/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='darkcave at macbeth.shakespeare.lit'
> to='hag66 at shakespeare.lit/pda'
> id='disco4'>
> <query xmlns='http://jabber.org/protocol/disco#items'>
> <item jid='darkcave at macbeth.shakespeare.lit/firstwitch'/>
> <item jid='darkcave at macbeth.shakespeare.lit/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='darkcave at macbeth.shakespeare.lit'
> to='hag66 at shakespeare.lit/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='room at muc.server'>
> > <query xmlns='jabber:iq:browse'/>
> > </iq>
> > READ: <iq type='result' to='user at server/resource' from='room at muc.server'>
> > <conference xmlns='jabber:iq:browse' name='room' type='public'>
> > <ns>http://jabber.org/protocol/muc</ns>
> > <user name='nick1' jid='user2 at 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., 'room at muc.server/nick2').
> >
> > > -----Original Message-----
> > > From: David Sutton [mailto:jabber at dsutton.legend.uk.com]
> > > Sent: Tuesday, February 11, 2003 8:59 AM
> > > To: jdev at jabber.org
> > > 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
> > > 'girls at conference.localhost/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:jabber at dsutton.legend.uk.com]
> > > > > Sent: Monday, February 10, 2003 8:51 PM
> > > > > To: jdev at jabber.org
> > > > > 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
> > > > >
> > > girls at conference.localhost/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='foo at muc.server/nick1'>
> > > > <x xmlns='http://jabber.org/protocol/muc'/>
> > > > </presence>
> > > > READ: <presence from='foo at muc.server/nick1'
> > > to='user at server/resource'>
> > > > <x xmlns='http://jabber.org/protocol/muc#user'>
> > > > <item affiliation='owner' jid='user at server/resource'
> > > > role='moderator'/>
> > > > </x>
> > > > </presence>
> > > >
> > > > Changing the nick (JEP-0045, section 6.4):
> > > >
> > > > SENT: <presence to='foo at muc.server/nick2'/>
> > > > READ: <presence type='unavailable' from='foo at muc.server/nick1'
> > > > to='user at server/resource'>
> > > > <x xmlns='http://jabber.org/protocol/muc#user'>
> > > > <item nick='nick2' affiliation='owner'
> > > > jid='user at server/resource' role='moderator'/>
> > > > <status code='303'/>
> > > > </x>
> > > > </presence>
> > > > <presence from='foo at muc.server/nick2'
> > > to='user at server/resource'>
> > > > <x xmlns='http://jabber.org/protocol/muc#user'>
> > > > <item affiliation='owner' jid='user at 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
> > > > jdev at jabber.org
> > > > http://mailman.jabber.org/listinfo/jdev
> > >
> > > --
> > > David Sutton
> > > Email: dsutton at legend.co.uk
> > > Jabber: peregrine at legend.net.uk
> > >
> > _______________________________________________
> > jdev mailing list
> > jdev at jabber.org
> > http://mailman.jabber.org/listinfo/jdev
> >
>
>
>
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
--
David Sutton
Email: dsutton at legend.co.uk
Jabber: peregrine at legend.net.uk
More information about the JDev
mailing list