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

[Larry Masinter <[e-mail]>]

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.

Larry
--
https://LarryMasinter.net

 

From: Asmus Freytag (c) <[e-mail]> 
Sent: Friday, December 7, 2018 12:49 AM
To: Patrik Fältström <[e-mail]>; John C Klensin <[e-mail]>
Cc: Larry Masinter <[e-mail]>; [e-mail]; [e-mail]; Paul Hoffman <[e-mail]>
Subject: Re: [I18nrp] Last Call: <draft-faltstrom-unicode11-05.txt> (IDNA2008 and Unicode 11.0.0) to Informational RFC

 

On 12/6/2018 10:16 PM, Patrik Fältström wrote:

On 7 Dec 2018, at 7:12, John C Klensin wrote:
 

But I still believe that, with appropriate qualification, Larry is still correct.

 
I think we dive into the details here.
 
1. I think the ability (for example) copy and paste, respond to, click on, save in bookmarks etc is the most important global requirement
 
2. The ability to type, to enter via a keyboard, read on a bus, etc is secondary and have localization issues so very much different than (1)

A longer reply to this in my prev. note, but I emphatically disagree.

If you are dealing with a foreign language / script to you, then you will be reduced to selecting or perhaps copying; but for your own language and script (and for too many of the modern scripts) there are many possible sequences that so deeply violate the reader's expectation (or the systems' expectations) that they can effectively not be understood (read and remembered) by the users or displayed or processed by the system (or not reliably so across systems).

For many scripts, allowing too much will make labels every bit as unusable as allowing too little.

 
 
My point was that because of this, I think retypable is very very very much different than other, global, requirements, and the latter should not (I think) muddy the waters of the first requirement I list above.

Your item (1) addresses much more the level of implementation of the user presentation of IDNs, and less what should be allowed in IDN labels. Apples and oranges, it seems to me.

Item 1 is what the UASG should be concerned with, Item 2 is what IDNA should be concerned with (at the guidance level).

A./