On Wed, Jan 25, 2012 at 2:26 AM, Peter Saint-Andre <stpe...@stpeter.im> wrote: > On 1/24/12 11:14 AM, Peter Saint-Andre wrote: > > After jabbering with Kev for a bit, here's a follow-up on the status > code 210 issue (originally raised by Waqas Hussain). > >>>>> "If the user's nickname is modified by the service as a result of >>>>> registration and the user is in the room, the service SHOULD include >>>>> status code "210" in the updated presence notification that it sends >>>>> to all users." - this is new, I think, couldn't it break things? *** >>>> >>>> In what way does that break things? >>> >>> Prior to this change, 210 could only be received on 'your own' >>> stanzas, so it's been reasonable for clients/libs to assume any time >>> it sees 210 it's receiving its own stanza (and, given that servers >>> tend to only send one status code at a time (to work around buggy >>> clients), this is probably a sensible thing to do). If clients start >>> receiving 210 from other people, I think it's entirely likely that >>> things will break. >> >> But we have a separate status code (110) for self-presence. > > First, I found the original message from Waqas: > > http://mail.jabber.org/pipermail/standards/2011-September/025183.html > > He wrote: > > ### > > 3. Service changing room nick > > I'd like some text stating that a service can change the occupant's > nick at any time, including room join. An occupant MUST listen for > status code=100 in available presence for their current nick. > > ### > > I think Waqas meant that the client needs to listen for status code > "110" (self-presence) plus "210" (nick changed) but I'm not sure. Waqas, > please confirm. > > Via IM, Kev pointed out that this should be for self-presence only. I > think he's right about that, so one of the paragraphs currently in the > working version is wrong (right after Example 76): > > If the user's nickname is modified by the service as a result of > registration and the user is in the room, the service SHOULD include > status code "210" in the updated presence notification that it sends > to all users. > > I think the other instances are correct (after Examples 23 and 50 > respectively): > > If the user has connected using a MUC client (as indicated on > joining the room by inclusino of the MUC extension), then the > service MUST include a status code of "210" in the presence > broadcast that it sends to the new occupant. > > and: > > If the service modifies the user's nickname in accordance with local > service policies, it MUST include a MUC status code of 210 in the > presence stanza sent to the user. An example follows (here the > service changes the nickname to all lowercase). > > See Example 51: > > Example 51. Occupant Changes Nickname, Modified by Service > > <presence > from='ha...@shakespeare.lit/pda' > id='nx6z2v5' > to='co...@chat.shakespeare.lit/OldHag'/> > > <presence > from='co...@chat.shakespeare.lit/oldhag' > id='D0E2B666-3373-42C9-B726-D52C40A48383' > to='ha...@shakespeare.lit/pda'> > <x xmlns='http://jabber.org/protocol/muc#user'> > <item affiliation='member' > jid='ha...@shakespeare.lit/pda' > role='participant'/> > <status code='110'/> > <status code='210'/> > </x> > </presence> > > So I propose that we fix the text after Example 76: > > OLD > If the user's nickname is modified by the service as a result of > registration and the user is in the room, the service SHOULD include > status code "210" in the updated presence notification that it sends > to all users. > > NEW > If the user's nickname is modified by the service as a result of > registration and the user is in the room, the service SHOULD include > status code "210" in the updated presence notification that it sends > to the user. > > Now, Kev raised another issue, which is that some clients don't properly > handle presence updates with more than one status code (e.g., they might > read only the first status code). My reply to that is: fix your client > or file a bug report. > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > >
Yes, I did mean 110, not 100. There are three cases in which a service might rewrite a nick: 1. on room join (status codes 110 and 210) 2. on user initiating a nick change (status codes 110 and 303) 3. at some point after join, without the user requesting a normal nick change (e.g., after nick registration, or service policy change) I don't think (1) and (2) really need any extra status codes than what get sent normally, while (3) can be treated exactly like (2), as if the user requested the change. It may make sense to extend 210 to (2) and (3). The question is, how should clients use these status codes? In my opinion, simply assuming your current nick is the last one with a 110 works in all cases for maintaining internal client state, while 303 and 210 could be used to generate user notifications if required about server modification of nick. -- Waqas Hussain
