Subject: [precis] Fwd: New Version Notification for draft-nemoto-precis-alternativenames-00.txt

From: Takahiro Nemoto <[email-masked]>
Date: Thu, 13 Nov 2014 13:51:23 -1000

Dear all,

Although belated, Daniel (new co-author) and I submitted new PRECIS profile document.  
I would greatly appreciate your comments/suggestions. 

Regards,

Nemo

転送されたメッセージ：

> 差出人: [email-masked]
> 件名: New Version Notification for draft-nemoto-precis-alternativenames-00.txt
> 日付: 2014年10月27日 10:28:38 GMT-10
> 宛先: Takahiro Nemoto <[email-masked]>, Daniel Wang <[email-masked]>, "Daniel Wang" <[email-masked]>, "Takahiro Nemoto" <[email-masked]>
> 
> 
> A new version of I-D, draft-nemoto-precis-alternativenames-00.txt
> has been successfully submitted by Takahiro Nemoto and posted to the
> IETF repository.
> 
> Name:		draft-nemoto-precis-alternativenames
> Revision:	00
> Title:		Preparation and Comparison of Customized Alternative Names
> Document date:	2014-10-27
> Group:		Individual Submission
> Pages:		6
> URL:            http://www.ietf.org/internet-drafts/draft-nemoto-precis-alternativenames-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-nemoto-precis-alternativenames/
> Htmlized:       http://tools.ietf.org/html/draft-nemoto-precis-alternativenames-00
> 
> 
> Abstract:
>   This document describes how to prepare and compare Unicode strings
>   representing to customized alternative names for devices, which can
>   be created and accessed by users definition, primarily as used within
>   IoT environment like appliances controlling through home network.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Thu, 13 Nov 2014 18:11:22 -0700

> I would greatly appreciate your comments/suggestions.

As section 5.1 of draft-ietf-precis-framework-19 says, "profiles must 
not be multiplied beyond necessity". Therefore, I wonder why we need 
this profile, because it is very similar to the nickname profile in 
draft-ietf-precis-nickname. The only difference I can see is the use of 
NFKC and therefore no width mapping in the nickname profile (intended to 
reduce the possibility of confusion) vs. the use of NFC and width 
mapping in the alternative names profile.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Takahiro Nemoto <[email-masked]>
Date: Fri, 14 Nov 2014 08:45:50 -1000

Hi, Peter-san

Thank you for your quick reply.
I think that this profile is similar to the nickname profile too.

However, even though NKFC has the benefit of increasing the probability of comparison matching, 
the aggressive normalization may create a problem. Using NKFC on some characters may cause
 changes on the character’s form and byte length that would confuse users. 
For this reason, I chose NFC and width mapping.

Last year, I conducted a research in Singapore (a country that uses English, Chinese, 
and Malay as the official languages) on the names that are attached on hosts by users. 
I found that there were several machines that use special characters as host names. 
Thus, this profile is intended to allow as many characters as possible while increasing 
the probability of comparison matching and I think NFC and width mapping would be 
appropriate for preprocessing of names for aliases of machines that are used on daily basis.

For this reason, I would like to do a little more research to understand the necessity of this profile processing.
Please let me know if you have any questions and concerns. Your comment will be greatly appreciated.

Regards,

Nemo

2014/11/13 15:11、Peter Saint-Andre - &yet <[email-masked]> のメール：

> As section 5.1 of draft-ietf-precis-framework-19 says, "profiles must not be multiplied beyond necessity". Therefore, I wonder why we need this profile, because it is very similar to the nickname profile in draft-ietf-precis-nickname. The only difference I can see is the use of NFKC and therefore no width mapping in the nickname profile (intended to reduce the possibility of confusion) vs. the use of NFC and width mapping in the alternative names profile.
> 
> Peter
> 
> -- 
> Peter Saint-Andre
> https://andyet.com/
> 
> _______________________________________________
> precis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/precis

---

From: Yutaka OIWA <[email-masked]>
Date: Sat, 15 Nov 2014 05:06:38 +0900

Dear Nemoto-san,

could you describe "how" the names will be used?
There are several ways of using an identifier,
with several different levels of requrements for
"canonicalizations": from looser to stricter,

 * Display only
 * List-up and select (e.g. modern messaging applications)
 * Type-in and compare
 * Type-in and compute (cryptographic) (e.g. most cryptography-based
authentications)

Which model will your target appliance's use case falls into?

2014-11-14 8:51 GMT+09:00 Takahiro Nemoto <[email-masked]>:
> 宛先: Takahiro Nemoto <[email-masked]>, Daniel Wang
> <[email-masked]>, "Daniel Wang" <[email-masked]>,
> "Takahiro Nemoto" <[email-masked]>
>
>
> URL:
> http://www.ietf.org/internet-drafts/draft-nemoto-precis-alternativenames-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-nemoto-precis-alternativenames/
> Htmlized:
> http://tools.ietf.org/html/draft-nemoto-precis-alternativenames-00
>
>
> Abstract:

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Sat, 15 Nov 2014 07:09:40 -0700

> For this reason, I chose NFC and width mapping.

I don't see a compelling difference between "NFKC without width mapping" 
and "NFC with width mapping", and I would strongly prefer to avoid 
having two profiles here.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 17 Nov 2014 18:41:12 +0900

Hello Peter,

> having two profiles here.

You got me confused here. Surely "NFKC without width mapping" and "NFC 
with width mapping" differ quite a bit, namely for all compatibilitity 
formatting tags (for a list, see e.g. 
http://www.sw.it.aoyama.ac.jp/2013/pub/NormEquivTut/#kompabitibily_tags).

If we don't care about compatibility mappings at all, then just doing 
NFC would be the simplest thing to do.

The reason why Takahiro is proposing "NFC with width mapping" is that 
width differences are very well known to be ignored by users entering 
text especially here is Japan. On the other hand, other compatibility 
formatting categories such as <sub>, <super>, <fraction>, <circle>, 
<square> and so on are visually clearly different and and therefore are 
extremely rarely selected by users, if they can be input at all. For 
other cases, such as <isolated>,..., these may exist in legacy 
documents, but aren't produced by current input methods (read 
keyboards,...).

So "NFC with width mapping" makes ample sense to me, whereas "NFKC 
without width mapping" does not make any sense whatsoever in the first 
place, and any profile (or whatever it's called) that used it would be 
seriously flawed in my opinion and should be fixed.

Regards,    Martin.

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 19 Nov 2014 20:45:28 -0700

> seriously flawed in my opinion and should be fixed.

Nemo is proposing a profile for nicknames (with IoT or device use cases 
in mind). We already have a profile for nicknames (with chatroom or chat 
use cases in mind). I am suggesting that we combine the two because 
profiles must not be multiplied beyond necessity.

The point of using NFKC in draft-ietf-precis-nickname was to more 
aggressively find matches and therefore reduce the possibility of 
confusion. This might not apply to petnames for devices, but it 
certainly applies in chatrooms (where spoofing attempts are common).

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 20 Nov 2014 14:26:53 +0900

Hello Peter,

> certainly applies in chatrooms (where spoofing attempts are common).

Okay. I agree that having one profile with "NFC with width mapping" and 
another with NFKC is not needed, because it doesn't hurt to map other 
compatibility formatting categories such as <sub>, <super>, <fraction>, 
<circle>, <square> and so even where such mapping isn't really needed.

What I still don't understand is why you wrote "NFKC without width 
mapping". Width mapping is an integral part of NFKC, and I don't see any 
reason why it would or should be excluded.

Also, we should hear again from Takahiro, because he says that he didn't 
want to use full NFKC because "using NKFC on some characters may cause 
  changes on the character’s form and byte length that would confuse users".

I personally think that "byte length" doesn't have anything to do with 
user confusion, but e.g. mapping "①" (circled 1) or "❶" (black circled 
1) to "1" could well cause user confusion. On the other hand, mapping 
"⑴" or "⒈" should be preferred because otherwise they'd be easily 
confused with "(1)" and "1.". So the question is mainly whether stuff 
like "①" or "❶" are in actual use.

Regards,   Martin.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 20 Nov 2014 00:30:16 -0500

On Wed, Nov 19, 2014 at 08:45:28PM -0700, Peter Saint-Andre - &yet wrote:
> Nemo is proposing a profile for nicknames (with IoT or device use cases in
> mind). We already have a profile for nicknames (with chatroom or chat use
> cases in mind). I am suggesting that we combine the two because profiles
> must not be multiplied beyond necessity.

I agree.  I certainly understand the use case, but we've already seen
that we have some trouble due to the desire for multiple profiles.

I wonder though if we mightn't take a page from IDNA's playbook here.
One of the things IDNA did was to say, "Do some locale-sensitive
mapping before you get to the algorithm."  Couldn't this be a case for
that?  That is, half-width mapped to full width or something _before_
even starting on the string?

A

-- 
Andrew Sullivan
[email-masked]

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Thu, 20 Nov 2014 06:42:25 -0700

> even starting on the string?

Well, that's what the width-mapping rule is supposed to take care of, 
and it's applied first in PRECIS.

But I am thinking of other confusing strings, beyond strings with 
half-width characters.

For example, in a chatroom context, we don't want someone to spoof a 
user HenryIV (with last two characters U+0049 LATIN CAPITAL LETTER I and 
U+0056 LATIN CAPITAL LETTER V) by creating a user HenryⅣ (with last 
character U+2163 ROMAN NUMERAL FOUR).

Similarly, in an IoT context, does a user really need to have separate 
devices named TabletIV and TabletⅣ or whatever? Doesn't that open the 
potential for user confusion and security vulnerabilities? ("Strange, 
TabletIV shows up twice, I'll just choose the first one and log in 
there... oh, this is even stranger, now I can't log into any of my 
tablets...")

Using the FreeformClass enables expressiveness but at the price of 
potential confusion. The nickname profile attempts to reduce that 
confusion. I'm not seeing how Nemo's proposal helps here, but I might be 
missing something.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Thu, 20 Nov 2014 06:45:28 -0700

> reason why it would or should be excluded.

I meant that draft-ietf-precis-nickname includes width mapping by using 
NFKC. It doesn't need a separate width mapping rule, as other profiles 
that use NFC sometimes do. That is, no dedicated width mapping rule is 
needed. See Section 2.2 of draft-ietf-precis-nickname. My apologies for 
the lack of precision.

>   changes on the character’s form and byte length that would confuse

Yes, I would like to understand what he meant by that.

Peter

-- 
Peter Saint-Andre
https://andyet.com/