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

Etan Reisner deryni at eden.rutgers.edu
Tue Apr 11 03:34:47 UTC 2006

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

> Peter Saint-Andre wrote:
>> On Tue, Mar 28, 2006 at 01:12:34AM -0500, Etan Reisner wrote:
>>> Let me start by saying that I tried to look up any previous discussion
>>> of this topic on this list as well as on the jabberd list (I was pretty
>>> sure I rememberd there being some) but I couldn't find it. So apologies
>>> in advance if I missed it.
>>> For our jabber server at work we are forcing all room nicknames to be
>>> the same as the user portion of their JIDs. Optionally, with '-foo'
>>> appended. (I mentioned this system in a recent email regarding
>>> JEP-0172.) Our current code returns the following presence error if you
>>> attempt to change nicknames while in the room to an invalid nickname.
>>> <presence type='error'><error code='406' type='modify'><not-acceptable
>>> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/></error></presence>
>>> Is this a correct error for this scenario? I'm asking because it is
>>> causing us some problems, it confuses the clients I have tested it
>>> against.
>> Yes, that seems appropriate. Clients may not handle it well because it's
>> not specified in JEP-0045, but I'll add that flow to my todo list for
>> revisions.
> I've added this to my working copy.
> How do you handle room joins? Presumably you modify the requested
> roomnick on entry. It would be good to add that flow to the JEP as well.
> Peter

Actually I currently return a <forbidden> stanza, that seemed the most 
appropriate error to me at the time. Though that makes more sense with 
the '-foo' allowed locking than with the absolute locking. So I'll 
probably modify my code to do the right thing depending on which locking 
is in place. (And perhaps <not-acceptable> is more correct than 
<forbidden> in the first place?)

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).


More information about the Standards mailing list