Subject: [I18ndir] Update needed to RFC 8228?

From: Asmus Freytag <[email-masked]>
Date: Tue, 14 Dec 2021 09:53:21 -0800

Since I wrote RFC 8228, ICANN's Root Zone LGR process and the separate 
effort of creating Reference LGRs for the second level have seen many 
RFC 7940-based LGRs added for additional scripts and languages.

By and large, RFC 8228 has aged well; little to none of its 
recommendations have been superseded by new experience or are in need of 
modification. However, complex scripts have shown the need for some 
additional recommendations to make sure some common scenarios regarding 
sequences in these scripts result in well-behaved LGRs.

At the same time, as result of intense discussions among experts in 
these efforts, the understanding of what precisely is meant by an LGR 
that is "well-behaved" in dealing with sequences has been further 
refined and could now be stated with more precision.

Like the guidelines in RFC 8228, these extensions are not concerned with 
formal correctness of an LGR, but with additional conventions that 
ensure an LGR works as intended. At the moment, these additional 
guidelines are documented ad-hoc in various places, but they are simply 
a completion of the set already in RFC 8228, and logically one would 
want to collect them in the same context. Either as a replacement RFC or 
as an "add-on".

Separately there's been a lot of work done implementing variants outside 
the original set of scripts for which they have precursors before RFC 
7940. The issue where we've gained much new experience is with how 
variants defined on the code point level in an LGR result in sets of 
allocatable variant labels -- sometimes an uncomfortably large number of 
them.

While there may always be the need for a registration policy that limits 
how many variants may actually be delegated, the desire has been to 
define mechanisms that can mechanically limit the number of allocatable 
variants where possible to those that are linguistically motivated, 
rather than being random permutations.

Reducing the potential set of allocatable variants enhances the user 
experience by removing linguistically unmotivated variants and making 
the whole set more predictable. Likewise, it creates certainty for 
applicants.

There are several methods that can be used in the RFC 7940 context to 
limit allocatable variant labels by preventing some combinations that 
are not linguistically required. Each of those has different advantages 
and costs, not all of them are obvious and some of them may be unknown 
to anyone not familiar with Chinese IDNs.

Now that the work on the Root Zone LGR is nearing completion, it might 
be useful to capture that experience in an informational RFC, similar to 
RFC 8228.

Like that RFC, the aim would be to bridge the gap from the per-code 
point definition of LGRs as formalized in RFC 7940 to cover the 
guidelines and conventions needed to make such LGRs well-behaved in 
terms of the variant label spaces they produce.

The purpose of this e-mail is to sound out people whether this group 
sees any chance for an additional RFC in this space.

The contents would reflect actual working experience; the concrete 
examples it is based on are all public. In my view, ICANN and others 
would benefit from having such guidelines and best practices documented 
in a forum that is separate from the contents of actual LGRs (such as 
those published by ICANN or additional ones planned to be deposited at 
IANA).

Because IETF "owns" the formal specification of LGRs it would seem to be 
the most suitable forum.

Let me know if you feel that preparing an actual draft would be 
worthwhile or a waste of effort, from your perspective.

A./

---

From: "John Levine" <[email-masked]>
Date: 14 Dec 2021 20:58:49 -0500

>sees any chance for an additional RFC in this space.

Sure.  I'd like to see this in an easy to find place rather than just
folklore.  My personal preference would be an updated 8228bis so it's
one place rather than two.

It also sounds like this would be useful to people at lower levels in the
DNS, to figure out which of a set of possible variants are worth defining.

R's,
John

---

From: Asmus Freytag <[email-masked]>
Date: Wed, 15 Dec 2021 12:59:12 -0800

On 12/14/2021 5:58 PM, John Levine wrote:
> It appears that Asmus Freytag<[email-masked]>  said:

Thank you for the encouraging words.

> DNS, to figure out which of a set of possible variants are worth defining.

Precisely, that's the thought.

A./