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

[Patrik Fältström <[e-mail]>]

> On 11 Oct 2018, at 23:17, Nico Williams <[e-mail]> wrote:
> 
>> 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?

No, we talk about current incompatible changes to the Unicode Standard between version 6.4 and 11.0. Changes that moves code points from DISALLOWED to PVALID.

> 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

No, not at all. IDNA2008 do say that normalization, case mappings and such things are to happen.

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

UTS#46 is something different, and is not what IETF is dealing with.

IDNA2008 is IDNA2008.

>> 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.

Thanks for the information.

> 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.

Noted.

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

Yes.

> 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.

There are so many incompatibilities between IDNA2008 and UTS#46 that it is not possible.

What implementors can do is to implement a mapping scheme and normalization that might be close to what UTS#46 is doing, but what has been discovered in the ICANN context is that what mapping you use is in fact dependent on context so much that it is impossible in reality to specify just one such algorithm. Instead, the important issue is that whenever that initial transformation is done (which the application is responsible for), then strict IDNA2008 is a necessity. Or else the uncertainty is too large which in turn makes it impossible for the application to make a good context dependent mapping.

>> 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.

   Patrik