Subject: [Simple] SIMPLE chat: Internationalization and normalization of nicknames

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 1 Mar 2012 22:55:59 +0100

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.

I guess this is what we should do, but if someone has any other opinion, 
please let me know it.

The internationalization and normalization of nicknames will probably 
take a bit of my time until we do it. So, I propose to submit my current 
working copy, that contains all comments from Cullen, Christer, Saul, 
Suresh, etc. This will be version -14.

Comments, please?

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 01 Mar 2012 15:00:24 -0700

> Comments, please?

Hi Miguel,

As an author of 6122bis and the PRECIS framework, I stand ready to help
on this list if you guys have questions.

To be clear, I think you guys don't want to use 6122bis, but you
probably do want to define a separate profile of the PRECIS framework.
Your other options are to define a stringprep profile (which I do not
recommend for various reasons) or to "roll your own" (which has its own
hazards).

Peter

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

---

From: Ben Campbell <[email-masked]>
Date: Thu, 1 Mar 2012 16:12:27 -0600

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:
> 
> So, I got advice from Alexy Melnikov, indicating that we should take a look at the ResourcePrep in:
> 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:
> 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.

2) The 6122bis resource parts live inside URIs, while  simple-chat nicknames are just strings.

I'm not sure that these differences really change the outcome much--they're just things to think about.

> 
> I guess this is what we should do, but if someone has any other opinion, please let me know it.
> 
> The internationalization and normalization of nicknames will probably take a bit of my time until we do it. So, I propose to submit my current working copy, that contains all comments from Cullen, Christer, Saul, Suresh, etc. This will be version -14.

(as draft shepherd) 

Please do so. Hopefully we can get feedback as to whether they are okay with the changes related to their comments in parallel to working out the nickname issue.

Thanks!

Ben.

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 1 Mar 2012 23:13:04 +0100

Thank you Peter,

I am also leaning towards defining a profile of the PRECIS framework. I 
need to study it in detail, and I am sure questions will come, so I will 
get back to you.

Thanks,

     Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 01 Mar 2012 15:19:50 -0700

> need to study it in detail, and I am sure questions will come, so I will

OK, good.

I'd like to make it clear that in XMPP, we would probably define a more
strict subset for nicknames than for resourceparts in general. As a
reminder, in XMPP your nickname is the last part of the JabberID, which
we call a resourcepart:

someroom@service/nick

Some XMPP implementations try to avoid confusion in chatrooms by
prohibiting case variations such as stpeter vs. StPeter (etc.). However,
confusion is nearly impossible to prevent, as we discuss in the
precis-framework document. Internationalization is inherently difficult,
so you'll want to really talk about this in the WG so your assumptions
and goals are clear.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 01 Mar 2012 15:26:00 -0700

On 3/1/12 3:12 PM, Ben Campbell wrote:
>> 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 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: 
>> 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.

> 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/

---

From: Ben Campbell <[email-masked]>
Date: Thu, 1 Mar 2012 16:45:35 -0600

> On 3/1/12 3:12 PM, Ben Campbell wrote:

[...]

> really quite similar in XMPP chatrooms and SIMPLE chatrooms.

My understanding of simple-chat is that the participant that you make policy decisions about would be identified by a bona-fide URI. For example, if we kick someone, we would supply the URI.  The nickname is a data attribute associated with the URI, and really is a display name for most practical purposes. Of course, you might select the nickname in a GUI in order to get you client to do the right thing.

> in XMPP chatrooms (e.g., to send a private message to another occupant).

You are right of course :-) I mean JIDs.

> A common approach might be good.

Agreed. Also, since simple-chat uses the nickname from the XCON common data model, other clients of that data model may have similar issues.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 01 Mar 2012 15:48:55 -0700

On 3/1/12 3:45 PM, Ben Campbell wrote:
>>> 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.
>> 
> 
> My understanding of simple-chat is that the participant that you make
> policy decisions about would be identified by a bona-fide URI. For
> example, if we kick someone, we would supply the URI.  The nickname
> is a data attribute associated with the URI, and really is a display
> name for most practical purposes. Of course, you might select the
> nickname in a GUI in order to get you client to do the right thing.

OK. It seems that you might also be making some authorization decisions
based on the nickname, e.g., if you've reserved a nickname then I can't
get that nickname (can I join the chatroom but just not with that
nickname?).

Peter

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

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Thu, 1 Mar 2012 23:54:22 +0100

Hi,

> in XMPP chatrooms (e.g., to send a private message to another occupant).

My understanding is that a full JID is comparable with a SIP GRUU, at least from the routing perspective. I'm working on a SIP-XMPP gateway at the moment and this is the translation I'm currently applying :-)

Regards,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Ben Campbell <[email-masked]>
Date: Thu, 1 Mar 2012 16:54:39 -0600

> get that nickname (can I join the chatroom but just not with that

Yes, that is true. We do need an equality operator in some sense. (And yes, assuming no other policy issue was blocking you, you could still use a different nickname)

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 01 Mar 2012 15:57:57 -0700

> Yes, that is true. We do need an equality operator in some sense. (And yes, assuming no other policy issue was blocking you, you could still use a different nickname)

If it were just a pretty display thing, life would be easier. So we'll
need to get into issues of comparison and equality. This could be fun.

Peter

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 02 Mar 2012 11:39:23 -0500

> Yes, that is true. We do need an equality operator in some sense. (And yes, assuming no other policy issue was blocking you, you could still use a different nickname)

And this presumably needs some notion of canonicalization, so that you 
can't get two nicknames that compare as different but *look* the same.

	Thanks,
	Paul

---

From: Ben Campbell <[email-masked]>
Date: Fri, 2 Mar 2012 13:08:17 -0600

On Mar 2, 2012, at 10:39 AM, Paul Kyzivat wrote:

> And this presumably needs some notion of canonicalization, so that you can't get two nicknames that compare as different but *look* the same.

That's going to be a very hard problem to solve. I suspect we will end up with text that points out that this can happen, but leave it up to implementors to figure out what to do about it.

(Peter: Do you have your Cherokee example handy?)

> 
> 	Thanks,
> 	Paul
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/simple

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 02 Mar 2012 14:23:45 -0700

On 3/2/12 12:08 PM, Ben Campbell wrote:
>>>> OK. It seems that you might also be making some authorization
>>>> decisions based on the nickname, e.g., if you've reserved a
>>>> nickname then I can't get that nickname (can I join the
>>>> chatroom but just not with that nickname?).
>>>> 
>>> 
>>> Yes, that is true. We do need an equality operator in some sense.
>>> (And yes, assuming no other policy issue was blocking you, you
>>> could still use a different nickname)
>> 
>> And this presumably needs some notion of canonicalization, so that
>> you can't get two nicknames that compare as different but *look*
>> the same.
> 
> That's going to be a very hard problem to solve. I suspect we will
> end up with text that points out that this can happen, but leave it
> up to implementors to figure out what to do about it.

The problem of so-called confusable characters is impossible to solve.
See for instance:

http://tools.ietf.org/html/draft-ietf-precis-framework-01#section-10.3

The Unicode Consortium has gone a bit farther:

http://unicode.org/reports/tr39/#Confusable_Detection

You can nibble around the edges here, but foolproof solutions cannot be
had (in large measure because humans are so easily fooled).

> (Peter: Do you have your Cherokee example handy?)

http://stpeter.im/journal/1420.html

That is: ᏚᎢᎵᏋᎢᏋᏒ != STPETER (and Cherokee Letter Quv = Ꮛ is not defined
by the Unicode standard as confusable with, mapped to, or otherwise
equivalent to Latin Uppercase E despite their surface similarity).

Peter

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 02 Mar 2012 21:44:23 -0500

OK, you guys have obviously gone down this path before.
I'm happy to have you suggest what is reasonable and what is not.

	Thanks,
	Paul

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 05 Mar 2012 10:26:19 -0700

> I'm happy to have you suggest what is reasonable and what is not.

BTW I am pushing to submit version 00 of a precis-nickname I-D today,
which should provide a starting point for discussion.

Peter

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