Waqas, thanks for your feedback. Comments at end. On 1/25/12 2:51 PM, Waqas Hussain wrote: > 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 have another use case here, but that's not essential to this discussion (suffice it to say that nicks might change after joining but without the user requesting a nick 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. Yes, I think that's reasonable. At least, that is how I interpreted your original comments. :) > It may make sense to extend 210 to (2) > and (3). That's the path I took based on your feedback (however, I notice that I didn't add anything about status code 210 to the section on user-requested nick changes, which is another time when the service might modify the user's nick). > 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. Agreed. Peter -- Peter Saint-Andre https://stpeter.im/
