[JDEV] MUC problems
David Waite
mass at akuma.org
Thu Feb 13 19:37:38 CST 2003
Please make sure this is brought up formally in the call for experience,
however.
-David Waite
David Sutton wrote:
>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
>>
>>
>
>
>
More information about the JDev
mailing list