Hello all, I've spent some time thinking about this over the evening. 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. > I will review the browse and see if it is possible to return with a result which follows the meaning of the JEP. The existing method was used to provide compatability to the existing conference system running on jabber.org. > > 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. > Until the debate on browse reaches some stability, i've removed the browse code from the MU-Conference cvs. I've already heard from people who feel that it is a bad idea to remove browse, as it already has place in many of the existing clients. Another expressed concern that disco made it more complicated to retrieve the data necessary. What I may do is make browse an optional extra which can be enabled or disabled at the service admins choice. If I do this, then the SHA hash idea (for representing a users true jid, not roster entry) may also be an option. I really perceive this being of use in certain situations, even if others may not yet. > > 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: > I think that the issue is being slightly missed here. the response to disco#items already does report in the syntax given below. The current debate about SHA hash jids is in relation to browsing for a users real jid, not for a room roster. I had already rewritten browse (and disco iirc) so that for the room listings, it reported them in the format roomname@service/nick. Only browsing a user for their true jid in semi-anonymous rooms returned a hash, to provide a form of accountability. Does this make the point I am trying to make clearer?
On the issue of disco, I also recall a debate going on because the exact details of what items were to be returned was not defined. There are several possibilities, such as room roster, member list, moderator list, admin list and so on. Was a decision made on which data should be returned, and if there was a way to return any of the other information via the disco interface? > > 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? > Disco returning an empty list makes sense, although it was this that reminded me of the point I made above regarding different lists. Hope this makes my point a little clearer. > > 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
