[Standards] Fwd: Re: [Simple] SIMPLE chat: Internationalization and normalization of nicknames
Peter Saint-Andre
internationalization of nicknames in chatrooms. There might be value in
pursuing a common approach. Please follow up on the sim...@ietf.org list:
https://www.ietf.org/mailman/listinfo/simple
-------- Original Message --------
Subject: Re: [Simple] SIMPLE chat: Internationalization and
normalization of nicknames
Date: Thu, 01 Mar 2012 15:26:00 -0700
From: Peter Saint-Andre <stp...@stpeter.im>
To: Ben Campbell <b...@nostrum.com>
CC: Simple WG <sim...@ietf.org>
On 3/1/12 3:12 PM, Ben Campbell wrote:
>
> On Mar 1, 2012, at 3:55 PM, Miguel A. Garcia wrote:
>
>> Dear all:
>>
>> I am trying to address the last known issue of the SIMPLE chat
>> draft. This came through Enrico Marocco's Appsdir review, and the
>> comment was:
>>
>> The document doesn't describe allowed characters in Nicks and any
>> normalization that needs to be applied.
>>
>> So, I got advice from Alexy Melnikov, indicating that we should
>> take a look at the ResourcePrep in:
>> http://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/
>>
>> The idea is to inspire on the ResourcePrep and adapted to Nicknames
>> in SIMPLE chat. However, there is a dependency on the completion of
>> the Precis Framework:
>> https://datatracker.ietf.org/doc/draft-ietf-precis-framework/
>>
>> This means that SIMPLE chat will need to add a normative dependency
>> to the Precis Framework, and if SIMPLE chat is approved and arrives
>> to the RFC Editor before the Precis Framework, it will stay there
>> until the framework reaches the RFC editor.
>
> (as individual)
>
> I concur with this approach in general, although I think we will find
> some differences between the Resource parts in 6122/6122bis and the
> use of nicknames in simple-chat. In particular:
>
> 1) A resource part identifies something. That makes uniqueness and
> comparisons fairly important. OTOH, a nickname is really for human
> display purposes. We still need to be able to compare them for
> reservations to work. And the human readability part means we should
> at least mention character confusion issues.
In the chatroom context, XMPP resourceparts are mostly used for display
purposes but also for some authorization decisions (e.g., we can kick
people based on their nickname). As far as I understand it, the uses are
really quite similar in XMPP chatrooms and SIMPLE chatrooms.
> 2) The 6122bis resource parts live inside URIs, while simple-chat
> nicknames are just strings.
Well, we don't really use URIs in XMPP. Probably you mean JIDs
(JabberIDs). In that case, yes, they are used sometimes for addressing
in XMPP chatrooms (e.g., to send a private message to another occupant).
> I'm not sure that these differences really change the outcome
> much--they're just things to think about.
Although I think that XMPP resourceparts *as they are used in chatrooms*
are quite similar to SIMPLE nicknames, resourceparts are used in other
contexts (e.g., as device/connection identifiers) so the resourceprep
replacement that's developed in the XMPP WG won't be quite what you need
anyway. However, there probably is value in thinking about nicks in
general, because it's possible that we could define the same PRECIS
profile for use in both XMPP chatrooms (XEP-0045) and SIMPLE chatrooms.
A common approach might be good.
Peter
--
Peter Saint-Andre
https://stpeter.im/
_______________________________________________
Simple mailing list
Sim...@ietf.org
https://www.ietf.org/mailman/listinfo/simple
Dave Cridland
> FYI, there's discussion happening on the SIMPLE WG list about
> internationalization of nicknames in chatrooms. There might be
> value in
> pursuing a common approach. Please follow up on the sim...@ietf.org
> list:
I've long since dropped off the simple list, but feel free to forward
this note as appropriate - I'm mostly raising this point now since it
happens to have come up.
I do think our use of resourceprep is often a little silly.
Consider:
1) Actual resource parts are basically opaque identifiers, and
comparing them as octet strings without normalization would (and, as
far as I can tell, does) work just fine. If people are actually
typing these things in - where you'd need resourceprep to normalize -
then they're probably doing something wrong.
2) When they're used as chatroom nicknames, on the other hand,
resourceprep is nothing like enough.
As things stand, if a user joins as "dwd", another can join as "Dwd"
- which is mildly confusing - or "dwd " - which is downright nasty. I
think it would be sensible for a XEP-0045 implementation to reject
(with a conflict) or change (by adding "~1" or similar) the nickname
in these cases.
Arguably, the ability to closely mimic other chatroom occupants
without even recourse to Cherokee is a security flaw in XEP-0045, but
luckily it's not one that requires a single interoperable solution -
the key is that an implementation should be able to normalize (or
rationalize, if you prefer) nicknames in any way it sees fit, by
overriding the nickname on join (or change).
Dave.
--
Dave Cridland - mailto:da...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Peter Saint-Andre
> Consider:
That's why I'm saying we might want a separate PRECIS profile for nicks.
Dave Cridland
> On 3/1/12 3:48 PM, Dave Cridland wrote:
>
> > Consider:
>
> That's why I'm saying we might want a separate PRECIS profile for
> nicks.
Right, but I'm saying we don't need a rock-solid profile - just some
sensible guidelines will do just as well.
That is, we don't need to worry that nicknames compare consistently
between servers for interoperability, we just need to recommend that
servers handle the security implications of nicknames.