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

Peter Saint-Andre stpeter at jabber.org
Mon Apr 17 17:56:46 UTC 2006

Hash: SHA1

Etan Reisner wrote:
> 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

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.



- --
Peter Saint-Andre
Jabber Software Foundation

Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060417/84cc9430/attachment.bin>

More information about the Standards mailing list