-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@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.
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='[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?
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 belowjid. Its used
-----Original Message-----<snip>
From: David Sutton [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 10, 2003 8:51 PM
To: [EMAIL PROTECTED]
Subject: Re: [JDEV] MUC problems
The hex string is actually a SHA1 hash of the users real
[EMAIL PROTECTED]/13c6a01dc31309e331c2b018640b9c03b85to 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
34327 and
compatability toit will show you the true jid. This also helps to keep
the reference, asexisting clients that are used to this form with the
groupchat/conferencing module. The real jid is used as
session, but theya person can keep changing their nick throughout a
specifies howcan't change their real jidThe problem with this is that the MUC standard (JEP-0045)
nicknames are passed along with presence information, andhow they are
changed -- and SHA-hashing isn't the way.to='user@server/resource'>
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'
<x xmlns='http://jabber.org/protocol/muc#user'>to='user@server/resource'>
<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'
<x xmlns='http://jabber.org/protocol/muc#user'>backward-compatible with the
<item affiliation='owner' jid='user@server/resource'
role='moderator'/>
</x>
</presence>
The MUC protocol wasn't designed to be fully
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
_______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
