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

["Asmus Freytag (c)" <[e-mail]>]

On 12/9/2018 1:55 PM, Larry Masinter wrote:
>
> I think we’re looking at the problem from different ends of the telescope.
>
Not necessarily.

> I’m concerned with giving guidance to the use of Unicode in other 
> naming contexts, including URLs.
>
I'm interested in that aspect as well, even though my current projects 
is focused on IDN labels for domains.

Many of the considerations I mentioned apply - they are based on the 
nature of the writing systems more than on particularities specific to 
domain names.


> I think we should extend the advice to anyone assigning a “Unicode 
> name” e.g., email addresses social media handles.
>

Agreed.

Here are some potential distinctions between different types of systems 
that handle Unicode names.

1) public vs. single entity

That is, who can create names. If any user can create names, then you'll 
want some protection against malicious registrations (or some other 
means of handling duplicate handles)

For singly entity controlled naming systems, malicious use and 
inadvertent duplication would not be a concern (as long as names are 
truly assigned by that entity and not via pass-through from other data - 
like document titles).

2) registry-based vs. open naming

If there's a list of names maintained in a registry (or database of some 
sort), it's possible to query it and prevent some duplicate names from 
being added -- that allows the addition of script or writing-system 
dependent rules to manage collisions.

Without such a database, inadvertent or malicious duplicates are hard to 
police.

3) exact or permissive lookup

Some name systems perform folding (like punctuation removal for e-mail 
names). Such lookup systems could directly support linguistic and visual 
variants by mapping all of them to a "preferred" form of the label.

Exact lookup systems must mimic that with a support for variant labels. 
Unlike a label folding scheme, the variant mechanism allows more 
fine-grained control over which form(s) of the label will succeed in 
lookup (and registration).

> In particular, the  IRI document RFC3987 needs update to align its 
> recommendations with IDNA and the WHATWG URL “living standard” (which 
> mainly neglects giving any advice at all the those choosing URLs.)
>

OK; looks like there's work to do.

A./


> Larry
>
> --
>
> https://LarryMasinter.net
>
> *From:*i18nRP <[e-mail]> *On Behalf Of *Asmus Freytag (c)
> *Sent:* Saturday, December 8, 2018 1:13 PM
> *To:* Larry Masinter <[e-mail]>; 'John C Klensin' 
> <[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/8/2018 12:00 AM, Larry Masinter wrote:
>
>     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.
>
> The rules are complex even if the basic requirements can be stated simply.
>
> The process of teasing them out for the 28 scripts that make up all 
> but a miniscule fraction of modern use is progressing nicely, but 
> including preparatory phases will probably have taken most of a decade 
> before completion. (I'm referring to the Root Zone LGR program).
>
> The good news is that the result of this effort will be well 
> documented (linking the final design to the underlying details of the 
> scripts and language use) and that it will also be available in a 
> machine-readable format.
>
> That means that for the first time, there would be a well-researched 
> (and well-documented) starting point for anyone trying to create and 
> enforce registry policies for pretty much any writing system used in 
> daily transactions.
>
> Policies for the second level would have to extend this template to 
> allow digits and hyphen - and perhaps relax some other restrictions 
> that are seen as relevant only to the root. This is a much smaller 
> task than starting from scratch, but for some scripts, even that task 
> is not entirely trivial.
>
> Common to the rules for most of the scripts is that they define 
> variant labels and the restrictions applicable to them (never 
> allocatable to unrelated entities and most commonly the first 
> allocated blocks all subsequent registrations of variants). Carefully 
> designed to make indistinguishable or semantically equivalent labels 
> mutually exclusive or reserved for a single applicant, these policies 
> require access to a registry to implement. Only when you know what is 
> allocated already can you evaluate whether a new label is a blocked 
> variant.
>
> Being machine readable should make it easy to integrate these rules 
> into registry operations. Therefore, I'm a bit confused as to what 
> would be gained by somehow distributing this responsibility down the 
> chain - other than surfacing restrictions built into the registry to 
> applicants.
>
> A./
>