Done:

http://xmpp.org/extensions/tmp/xep-0172-1.1.html

http://xmpp.org/extensions/diff/api/xep/0172/diff/1.0/vs/1.1rc1

On 2/21/12 4:15 PM, Peter Saint-Andre wrote:
> FYI, I plan to update XEP-0172 along these lines.
> 
> -------- Original Message --------
> Subject: Re: [jdev] XEP 0172 in MUCs
> Date: Mon, 20 Feb 2012 01:07:47 +0500
> From: Waqas Hussain <[email protected]>
> Reply-To: Jabber/XMPP software development list <[email protected]>
> To: Jabber/XMPP software development list <[email protected]>
> 
> On Tue, Feb 14, 2012 at 3:54 AM, Peter Saint-Andre <[email protected]>
> wrote:
>> Hallo Thijs,
>>
>> On 1/4/12 10:26 AM, Thijs Alkemade wrote:
>>> Hello,
>>>
>>> As a client developer, I'm a bit confused about how XEP 0172 (User
>>> Nickname) is intended to be used with MUCs. From the XEP:
>>>
>>> "A user MAY specify his or her persistent nickname as well. This may
>>> be desirable because the user's preferred room nickname is already
>>> taken or because the service "locks down" room nicknames."
>>>
>>> So should a client should interpret the XEP-0172 nickname as a
>>> replacement for the MUC-nickname?
>>
>> I think it would be supplemental.
>>
>>> This could lead to confusing
>>> situations with the same nick being used multiple times. If the
>>> service locks down room nicknames, then it supposedly has a good
>>> reason for that, and implementing a way to circumvent that sounds
>>> like a bad idea.
>>
>> I think you're right.
>>
>>> The reason I'm asking this is because Google Talk (the web interface)
>>> uses, for ad-hoc private group chats, random strings as room nicks,
>>> and then sends the user's real name as a <nick> element. I think all
>>> users would rather see the real name instead of the random string,
>>> but I'm worried about the implications of changing this. I've read
>>> the Security Considerations of XEP-0172, but I don't think that
>>> really answers this.
>>
>> I agree with you that it's preferable to allow real roomnicks. We might
>> want to update XEP-0172 to make that clearer, or even deprecate its use
>> in chatrooms...
>>
> 
> I strongly support deprecating its use in chatrooms.
> 
> We've seen this cause issues in the Prosody chatroom. This was on my
> list of things to post on the standard list, but somehow I never did.
> 
> This issue that we saw was different clients showing users different
> nicks for the same user, users auto-completing the wrong nick, and
> conversations getting derailed due to that. A quick survey of the
> participants in that discussion showed that the affected clients had
> no visual indication that the nick being displayed and in the UI
> wasn't the real room nick. This has obvious security implications,
> e.g., it easily allows impersonation.
> 
> --
> Waqas Hussain
> _______________________________________________
> JDev mailing list
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: [email protected]
> _______________________________________________


-- 
Peter Saint-Andre
https://stpeter.im/


Reply via email to