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

Etan Reisner deryni at eden.rutgers.edu
Tue Apr 11 06:04:29 UTC 2006


On Tue, 11 Apr 2006, Julien PUYDT wrote:

> Etan Reisner a écrit :
>> As to modifying the roomnick on entry, is there reason given the current 
>> protocol/JEP for the client to assume that the name it requests is always 
>> the name it will get? Or does it function more like resources?
>> 
>> If it isn't currently clear than I would say it probably makes sense to 
>> treat roomnicks like resources and then the semantics of getting a 
>> different roomnick than you requested should be simple to deal with, unless 
>> we think that complicates things too much (there are more semantics with 
>> resources than I am aware of).
>
> 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


More information about the Standards mailing list