[Standards-JIG] JEP-0045 and locking room nicknames

Etan Reisner deryni at eden.rutgers.edu
Sat May 6 01:39:17 UTC 2006


On Mon, 17 Apr 2006, Peter Saint-Andre wrote:

> Etan Reisner wrote:
>> On Tue, 11 Apr 2006, Julien PUYDT wrote:

<snip>

>>> I wrote a basic jabber with basic MUC support. I made it so that the
>>> first presence received from a muc room is the one telling it which
>>> nick is his.
>>>
>>> For example, upon receiving :
>>> <presence from='room at conference.server/mynick'>
>>>     <x xmlns='http://jabber.org/protocol/muc#user'>
>>>         <item whatever/>
>>>     </x>
>>> </presence>
>>>
>>> the client sees it isn't already in that room, and enters it with
>>> 'mynick'.
>>>
>>> The idea was that the presence sent by the client to enter a room was
>>> a request, and the presence sent by the server to enter the room was
>>> the answer.
>>>
>>> I thought it could fly ; was I wrong ?
>>>
>>> Snark on #ekiga
>>
>> That's exactly what I was suggesting, that we have the client not assume
>> that the nickname it requests is the nickname it will actually get.
>> Which is something clients already need to do somewhat to handle
>> nickname change conflicts.
>>
>>     -Etan
>
> In fact, the JEP currently recommends just the opposite!
>
> http://www.jabber.org/jeps/jep-0045.html#enter-pres says:
>
> ***
>
> The order of the presence stanzas sent to the new occupant is important.
> The service MUST first send the complete list of the existing occupants
> to the new occupant and only then send the new occupant's own presence
> to the new occupant. This helps the client know when it has received the
> complete "room roster".
>
> ***
>
> But what you are saying is that if the MUC service modifies the new
> occupant's roomnick then the client won't know when the room roster has
> been received.
>
> Hmm.
>
> Peter
>
> - --
> Peter Saint-Andre
> Jabber Software Foundation
> http://www.jabber.org/people/stpeter.shtml

My idea had nothing to do with the ordering of the presence stanzas, so 
any implication of an order was not my intention. I hadn't recalled that 
presence ordering requirement, nor had I really noticed the 'first' in 
Julien's email. My idea was only and always the idea that the server 
should be free to return to the client any nickname the server chooses, 
in the same way it can modify resources during stream/session startup.

But as you point out that does make that requirement in the JEP rather 
impossible, since the client can only look for the resource they asked 
for and not any others.

Why do we think clients want to know when they have received the entire 
room roster? Why can't they just assume it is complete when they receive 
room history, or the first message? (Can either of those happen before 
the roster is finished?)
For that matter, why do clients need to know when the room roster is 
finished? It isn't as if the roster can't change later or anything.

I was going to suggest that we drop the ordering requirement but that 
doesn't actually help since the user still has no way to know that the 
nickname they receive belongs to them and not to another person in the 
room. Even going by associated jid doesn't help, since it could be 
themselves connected from another client/location.

So, perhaps what we need is to add a status code for 'this is your room 
entrance presence' which solves the problem of how to handle getting a 
different nickname than what you asked for, since the client now has a 
non-nickname associated way to find out their own presence. Once we have 
that we can decide whether we want to keep the ordering requirement 
depending on what use people explain it as having.

 	-Etan



More information about the Standards mailing list