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

[Larry Masinter <[e-mail]>]

We were discussing Patrik’s document and what advice or rules to give to Registrars about being conservative,

And some questions about the motivation or intelligence of Registrars and their Clients.

 

It would help if the Registrars could pass off responsibility to their Clients; the only reason not to do so would be that the clients shouldn’t be expected to know the complex rules.

 

The transcription problem is relatively easy to explain and understand, and covers most other ways in which a name could be “bad”. 

These names don’t fall from the sky. Someone chooses them. Give them a clear motivation.

 

From: i18nRP <[e-mail]> On Behalf Of Asmus Freytag (c)
Sent: Friday, December 7, 2018 12:36 PM
To: John C Klensin <[e-mail]>; Larry Masinter <[e-mail]>; 'Patrik Fältström' <paf=[e-mail]>
Cc: [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/7/2018 12:02 PM, John C Klensin wrote:

 
 
--On Friday, December 7, 2018 11:28 -0800 Larry Masinter
 <mailto:[e-mail]> <[e-mail]> wrote:
 

...
The reason for emphasizing transcription is not that there
aren't other operations that are possibly more frequent
(copy/paste a URL from one context to another, remember on a
bookmark list) but rather that transcription is the most
stringent requirement – if a user can transcribe a name
resulting in the same sequence of Unicode codepoints, then
they can display the name, distinguish the name from other
(transcribable) names. 

 
Larry, I hope Asmus will respond further to this because he is
far more expert on relevant issues across a very wide range of
scripts and writing systems than I am, but I don't believe what
you write above is true. 

Globalization is often misunderstood - it's neither the magic bullet that
makes everything equally accessible to everyone, nor is it exclusively
about presenting everything to every user in their native context.

Instead, it's an interesting mixture of both.

For IDNs the goal is to allow full native support of mnemonic identifiers
in the context of the language/script native to the user - for all such
combinations of languages and scripts so that, in principle all users
can be supported.

But it's also about enabling the accessing of resources outside your
native bubble - Unicode is a big step in that direction, because before it
you were often locked into a native character set baked into your system.

However, a label in a foreign script will not be "mnemonic" for you, 
and there's nothing we can do about that in this context. However,
we should expect that labels in your script (and where relevant your
language) are indeed able to be mnemonic.

Otherwise, why not use digits like telephone numbers?

I think that is ultimately what Larry has in mind and what I cover by
"typable". You should be able to read a label, understand it, and 
reproduce it by typing, or be able to tell someone about it.

For the Latin script (because of the features that you are attempting
to outline below) even arbitrary sequences of code points do not
generally compromise the ability for a label to be mnemonic and to
support dealing with it other than by clicking/pasting.
(The above is strictly true only for ASCII, once you add the full range
including combining marks a bit more care must be taken - as will
be evident when the draft for the Latin Root Zone LGR becomes
available, until then, I'll spare myself the digression into details)

For other scripts, there's a wide variety of issues.

One example from Arabic: Quite a few letters in Arabic share positional
forms, that is, they are only distinct if, for example, at the end of a word.

Also, some languages using the Arabic script support keyboards that
only have one of these letters, but not the "standard" Arabic-language
one. As a result, while users can "read" an Arabic-language name,
a geographical name, for example, they could not type that name.
If they did, it may even look right, but be different.

Therefore, a registry that attempts to support both languages in
the Arabic script, but does not support variants, will have a fraction
of its labels that are de-facto unusable for some users.

Understood in that sense, "typable for a native user" is a valid goal
that informs necessary features of label generation rules (registry
policies) that enable the use of labels as mnemonic, in the same
way we take for granted for non-IDN labels.

A./

 Some scripts --of which the Roman
Script (Basic Latin of some millennia ago) is a good example--
simply have characters that are more easily distinguishable from
either other by people who cannot actually read the script or
associated language(s) that others.  Put a hypothetical person
who has never seen either before in front of a short string of
characters in that script and in front of a script written with
connected characters, complex use of ligatures, and subtle
distinctions among characters (look at Arabic digits for two and
three for an example of what I mean by "subtle" ... or look at
"O" and, in many contemporary type designs, "Q").  Then supply
that person with character pickers for the two scripts.  You
would almost certainly get accurate transcription of the Roman
characters and probably would not get it with the other script.
In neither case would be ability to transcribe imply the ability
to render and display (I'd encourage observation of five and six
year olds learning to write), nor would it imply that ability to
accurately copy and paste.
 
So, ability to transcribe may be a useful goal, but it isn't,
IMO, close to Patrik's global requirements list.  
 
best,
   john