On 11/17/14, 2:41 AM, "Martin J. Dürst" wrote:
Hello Peter,
On 2014/11/15 23:09, Peter Saint-Andre - &yet wrote:
On 11/14/14, 11:45 AM, Takahiro Nemoto wrote:
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.
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.
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.
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/
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
