Re: [I18nrp] draft-faltstrom-unicode11-04.txt

[Nico Williams <[e-mail]>]

On Sun, Oct 07, 2018 at 07:53:51AM +0200, Patrik Fältström wrote:
> Background: As we all know IDNA2008 is an algorithm that applied to
> Unicode gives a subset of code points which are permissible for in
> turn registries and others to create subsets from to be used in their
> respective policies.
> 
> Being the appointed expert for the IANA registry I have flagged for
> IAB changes made to Unicode that I feel must be discussed in IETF, and
> here is the document with my proposal (details are in the draft).
> 
> In short the draft proposes (just like RFC 6452) IETF continue to
> follow Unicode Standard without adding exceptions to the IDNA2008
> algorithm, EVEN IF changes are made that are incompatible to earlier
> versions of Unicode.

+1

We're talking specifically about future incompatible changes in
either case mappings or normalization.  Correct?

And to confirm the IDNA2008 / UTS#46 context:

 - IDNA2008 is hear-no-evil-see-no-evil, says to do no case mappings,
   relies on users entering domainnames in the correct case whatever
   that is

 - UTS#46 says to lower-case first, then apply the rest of IDNA2008

Correct?

> The choices for IETF when things like this happens are:
> 
> 1. Keep IDNA2008 with no exceptions
> 
> 2. Keep IDNA2008 with exceptions
> 
> 3. Stop referring (directly) to Unicode as it is not stable enough

(3) has got to be out as it amounts to hard-forking Unicode.  A fork of
Unicode would be momentous and extraordinary, and not to be undertaken
lightly!  It might be useful to think about how we'd go about forking
Unicode process-wise, but I think any analysis will convince us that we
should not actually do it.

(2) is a light fork of Unicode.

I understand that there have been a few backwards-incompatible changes
in Unicode, but that's just life, and it is their problem (sure, our
users' too, but forking Unicode is not going to be satisfying at the
very very least).

We could do a flavor of (2) that I describe below, but I'd rather not.

For me that leaves (1), which is what I'm for.

We should, however, use our liason to communicate to the UC our
displeasure as to backwards-incompatible changes, and that we'd like the
UC to at least consider adding a stability attribute to every codepoint.
If there were a stability attribute, then we could exclude codepoints
whose stability the UC will not guarantee.

If there were codepoint stability attributes, then filtering out
unstable codepoints would be (2') and likely desirable.

Future codepoint assignments could all begin life as unstable and gain
stability with experience.

We could, perhaps, implement codepoint stability attributes at the IETF
alone if the UC balks.  I would be OK with that provided it was simple
and simple to automate -- I don't think we want to be in the business of
inspecting every new codepoint assignment and guessing a stability level
for it, so nothing much more complicated than time-since-assignment
should be used.

> Probably more choices than these...
> 
> My proposal is [1], together with a more forceful push to strict
> IDNA2008 adoption. No IDNA2003, no UTS#46, no homebrew mixes.

I would much prefer that we adopt UTS#46.

> Including that registries really do a careful conservative selection
> of code points to be used in whatever context it is to be used.

Yes.

> The problem though is that this is *my* view. Sure, a few others have
> randomly and "by pure luck" told me "this is ok".
> 
> But is this a stable informed decision by IETF?

It should be after the standard IETF sturm und drang :)

> This very fast turn into a process issue where IAB have asked for
> progress, and IETF is to deliver.
> 
> And this is where I take a step back, and want IESG and IAB to make up
> their mind. This group was created for I18N issues, we have a charter,
> but then what? Is this where drafts like these should be discussed?

I believe we need IETF consensus on these matters, but the IAB must be
involved.  Any notion of forking Unicode should require buy-in from the
IAB.

Nico
--