Re: [Idna-update] [I18nrp] Last Call: <draft-faltstrom-unicode11-05.txt> (IDNA2008 and Unicode 11.0.0) to Informational RFC

[Martin J. Dürst <[e-mail]>]

On 2018/12/08 03:23, Larry Masinter wrote:
> Look at RFC1736 , Functional Recommendations for Internet Resource Locators”, section 4.6: Locators are human transcribable
> 
> https://tools.ietf.org/html/rfc1736#section-4.6
> 
>     Users can copy Internet locators from one medium to another (such as
> 
>     voice to paper, or paper to keyboard) without loss or corruption of
> 
>     information.  This process is not required to be comfortable.
> 
> Changing Internet locators to allow for Internationalization need not necessarily eliminate this valuable property.

And it doesn't. People get confused because they think differently about 
scripts they are not familiar with (where they often assume the worst, 
and are explicit about it) than about scripts they are familiar with 
(where they make the right assumptions implicitly, often without even 
being able to say what these assumptions are).

I have just searched through all of RFC 3986, but I have nowhere found 
anything telling people not familiar with ASCII that they should be 
careful not to create domain labels such as "L0CAT0R". That's because 
writers of RFC 3986 assumed that it would be quite obvious that letters 
and (more-or-less) lookalike digits shouldn't be mixed needlessly. And 
even more, nowhere in RFC 3986 does it say to be careful not to confuse 
'b', 'd', 'p', and 'q', even if these characters look quite the same up 
to only a rotation/reflection. (I remembered being confused about these 
for a while in primary school.)

The same is true for other scripts. Users of Japanese know to not mix up 
Kanji, Hiragana, and Katakana needlessly (*). Users of any script know 
where the potential confusables are, and how to deal with them in daily 
life. There is no need to tell them about the details.

What is desirable are restrictions such as those that Asmus has 
described, on the registry level, to help avoid inadvertent or malicious 
collisions, and to buffer for cases where repertoire-only limitations 
are not enough.

But these are separate from the draft under discussion now.

Regards,   Martin.