[Standards-JIG] JEP-0045 and locking room nicknames
stpeter at jabber.org
Mon Apr 17 17:56:46 UTC 2006
-----BEGIN PGP SIGNED MESSAGE-----
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/>
>> the client sees it isn't already in that room, and enters it with
>> 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.
In fact, the JEP currently recommends just the opposite!
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
Jabber Software Foundation
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards