Subject: Re: [Idna-update] [art] Comments on draft-faltstrom-unicode11-02

From: John C Klensin <[email-masked]>
Date: Mon, 08 Oct 2018 15:58:14 -0400

--On Monday, October 8, 2018 09:06 -0700 Ted Hardie
<[email-masked]> wrote:

> Modulo Erik's comments, I think this is ready for publication.
> The instructions to IANA are clear and the rationale behind
> those instructions is laid out.
> 
> I think we could ask for AD-sponsorship for this, but I also
> believe that the instructions could go to IANA now; at the
> very least, we could ask them to review.

Ted,

I'm sorry, but I disagree.  Patrik has, as far as I can tell,
done the job that the IAB asked him to do in his liaison
capacity to Unicode, but that job involves a number of
assumptions about how to proceed that interact with i18n
documents that the IETF has been unable to process.  If we
follow the precedent of RFC 6452, this document should be
processed as standards track even if it changes nothing.  It
would be wildly inappropriate for it to constrain the
conclusions the IETF could reach about those other documents.

My understanding coming out of the BOF at IETF 102 was that the
ART ADs were going to establish a directorate to determine how
i18n documents were to be handled and to start processing those
documents.  This document would make an entirely reasonable
addition to that directorate's queue.   However, if an progress
has been made on creating that directorate, much less having it
convene and discuss processing of documents, I seem to have
missed the announcement(s).

best,
   john

---

From: Ted Hardie <[email-masked]>
Date: Mon, 8 Oct 2018 13:26:58 -0700

Howdy,

On Mon, Oct 8, 2018 at 12:58 PM John C Klensin <[email-masked]> wrote:

> I infer that you are disagreeing with my suggestion that this get
AD-sponsorship, not with my suggestion that it get at minimum IANA review.
If you disagree with that as well, perhaps you'd care to say why.  My
personal take is that it is useful to get confirmation from IANA that the
instructions are clear as soon as possible.

> As you know doubt recall from RFC 2418, the purpose of a directorate is to
advise an Area Director or a set of Area Directors:

In many areas, the Area Directors have formed an advisory group or
> directorate. These comprise experienced members of the IETF and the
> technical community represented by the area. The specific name and the
> details of the role for each group differ from area to area, but the
> primary intent is that these groups assist the Area Director(s), e.g., with
> the review of specifications produced in the area.
>

I certainly agree that the presence of a fully functional i18n directorate
would be a boon, but I believe that any AD considering sponsorship of this
would do so by consulting, informally, many of the same folks who might
serve on that directorate were it in place.  So I do not, personally, see
any reason to gate on the formality when the ADs can get the same advice
for this one without it.

regards,

Ted Hardie

---

From: Asmus Freytag <[email-masked]>
Date: Mon, 8 Oct 2018 13:34:04 -0700

On 10/8/2018 12:58 PM, John C Klensin wrote:
> capacity to Unicode,

I thought this draft was in Patrik's role as the designated expert for 
the IANA registry.

> but that job involves a number of
> processed as standards track even if it changes nothing.

The relevant difference is that RFC 6452 contained this section:

-------------------

IETF Consensus

    No change to RFC 5892 is needed based on the changes made in
    Unicode 6.0.

    This consensus does not imply that no changes will be made to
    RFC 5892 for all future updates of The Unicode Standard.

    This RFC has been produced because 6.0 is the first version of
    Unicode to be released since IDNA2008 was published.
--------------------

I see no particular reason why such a section couldn't be added
to Patrik's draft, allowing it to be processed like 6452 if that is
felt to be more appropriate.

>   It

I don't see how this would constrain IETF conclusions about other documents,
or even RFC 5892 itself (other than that the consensus is to not add 
exceptions).

There are changes that may be motivated by the general aspects of the 
interaction
between Unicode and IDNA, but the kind of language as quoted above would not
rule those out.

You would need to make a more concrete claim how processing this RFC
interferes with the work of IETF.

> missed the announcement(s).

I don't necessarily see the plan for a new directorate as suspending IETFs
ability to process certain RFCs indefinitely. The goal was to make it 
possible
to process more of them and more consistently, not to provide an additional
hurdle.

(Taken to its logical conclusion, such restriction would have to apply 
to all
RFCs that such a directorate might be giving i18n related input on. I don't
see that happening, so I don't see why this draft needs to be singled out).

That said, I would also like to learn what progress is being made.

At some point, people were looking for volunteers, but at that point the
parameters were sufficiently vague for anyone to know what they would
be committing to.

A./

---

From: Suzanne Woolf <[email-masked]>
Date: Mon, 8 Oct 2018 23:29:04 -0400

Hi,

(A little confused over which mailing list is preferred for this particular discussion….)

> On Oct 8, 2018, at 4:34 PM, Asmus Freytag <[email-masked]> wrote:
> 
>> <[email-masked]> <mailto:[email-masked]> wrote:
>> 
> I thought this draft was in Patrik's role as the designated expert for the IANA registry. 
> 

That was also my impression. In March, the IAB said that “The IAB believes that the best current course of action for now is to bring the two [Unicode and the IDNA parameters registry] back into alignment while the IETF continues to work toward consensus on the underlying issues.  We have therefore asked the expert reviewer to bring the IDNA Parameters registry up to date…” The draft (I thought) is documenting the expert's examination of code points that had been added or had properties change in the course of that update, and the rationale for his recommendation about how to handle them in the registry.

> The relevant difference is that RFC 6452 contained this section:
I think that having an RFC for this set of updates, documenting the rationale for the decision to update the registry to Unicode 11 without exceptions for the code points that changed properties, will be valuable for the future— but AFAICT it’s not strictly necessary as part of the action Patrik was asked to take. I’m fine with adding language as Asmus is suggesting, which clarifies the current reasoning without restricting future decisions inappropriately.
> or even RFC 5892 itself (other than that the consensus is to not add exceptions).
> 
> There are changes that may be motivated by the general aspects of the interaction
I admit I don’t see this either. 
> ability to process certain RFCs indefinitely. The goal was to make it possible
At this point, I see three separate issues, any two of which have some interaction, but I don’t see hard dependencies:

1. Updating the IDN parameters registry as the IAB requested. With apologies if I’m missing something, I don’t see the expert saying he can’t update the registry for some reason, or that there’s any ambiguity in what the update should be; it’s his judgment that “the right thing to do” about the code points that changed properties between Unicode 6.3 and Unicode 11 is consistent with what the standard tells him to do. So for the current situation, the standard, including the instructions to the expert, is adequate.

2. Having an RFC about the specifics of updating the registry to Unicode 11. I agree with Patrik that having this document is useful, as an example of how to apply IDNA2008 to changes in Unicode; at the very least, the reasoning can inform future experts. But I see it as Informational— a service to the community— not as a change to the registry policy or an extension to the protocol standard. I don’t see a problem with making it AD-sponsored.

3. Establishing the proposed I18N directorate. I strongly agree that the IETF needs the directorate, or some other mechanism for reviewing i18n aspects of work across the IETF and providing backup for expert review as needed. But that’s also an optimization, to improve future handling of i18n documents.

I think all three of these things are important and useful. But it doesn’t look to me like any of the necessary decisions for these three items are gating on the others, or constraining the options for the others. They can be done more or less in parallel.

Suzanne

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 9 Oct 2018 06:37:23 +0200

> On 9 Oct 2018, at 05:29, Suzanne Woolf <[email-masked]> wrote:
> 

The key thing here is that I do not see myself have the competence in actually ensuring what I propose in the I-D is the correct thing to do. There are other alternatives as well, such as adding an exception to the IDNA2008 rule set.

IAB asked me to bring things forward, and my call is what I call path A:
A.1. Suggest a path forward
A.2. Ask IETF to ensure what I propose is the right thing.

This is btw what was done last time we had an incompatible change like this.

Alternatives could have been:

B. Be passive:
B.1. I ask IETF what to do with the incompatible changes (but do not suggest anything)
B.2. IETF tell me what to do

C. Have IAB make the call
C.1. IAB tell me not only to move things forward, but also “IAB have decided that the changes made in Unicode do not require backward compatible rules in IDNA2008”
C.2. I move things forward based on B.1.

FWIW, I did not interpret what IAB told me was “C” which I read in your note Suz. Maybe I misunderstand you.

Now, IF IAB really told me C, then can you please clarify?

   Patrik

---

From: "Asmus Freytag (c)" <[email-masked]>
Date: Mon, 8 Oct 2018 22:37:01 -0700

> This is btw what was done last time we had an incompatible change like this.

Sounds like a good approach in any case.

 From where I sit, what you did looks fine, so my answer to A.2. would 
be affirmative.

A./

PS: if IAB agrees with your assessment re: rules, the more the better.

> _______________________________________________
> IDNA-UPDATE mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idna-update

---

From: "Jiankang Yao" <[email-masked]>
Date: Tue, 9 Oct 2018 13:40:34 +0800

From: Suzanne Woolf
Date: 2018-10-09 11:29
To: Asmus Freytag
CC: Ted Hardie; i18nrp; nordmark; Patrik Fältström; Applications and Real-Time Area Discussion; John C Klensin; idna-update
Subject: Re: [art] [I18nrp] [Idna-update] Comments on draft-faltstrom-unicode11-02
> That was also my impression. In March, the IAB said that “The IAB believes that the best current course of action for now is to bring the two [Unicode and the IDNA parameters registry] back into alignment 
[Jiankang Yao] >

---

From: "Jiankang Yao" <[email-masked]>
Date: Tue, 9 Oct 2018 13:49:45 +0800

From: Suzanne Woolf
Date: 2018-10-09 11:29
To: Asmus Freytag
> That was also my impression. In March, the IAB said that “The IAB believes that the best current course of action for now is to bring the two [Unicode and the IDNA parameters registry] back into al…

I think that  having a good design registry of [Unicode and the IDNA parameters registry] is a good idea.

Best Regards
Jiankang Yao

---

From: John C Klensin <[email-masked]>
Date: Tue, 09 Oct 2018 03:10:46 -0400

Suzanne, Ted,

Let me build on Patrik's clarification to explain what I'm
concerned about (some other issues have been raised that I'll
come back to later).   I had read Ted's comment about
AD-sponsorship and IANA as implying something close to Patrik's
"C", i.e., the IAB decides it has the authority to just move
forward with this.  I think that would be a bad idea for the
reasons below.   But Ted said he was suggesting only asking
IANA's opinion as to whether the instructions to them were
sufficient and doing so in parallel with starting to advance the
document.   I don't see any problem with that; it would
certainly be consistent with other comments I've made lately
about working together informally to get things done rather than
getting tied up in procedures, throwing things over virtual
walls, and figuring out how and when to do that.

My concern was precisely about heading down the path to Patrik's
"C".  I think what we have learned in the last few years is that
things are more complicated -- and complicated in ways that
affect IDNA (and, btw, PRECIS) -- than the community assumed
when IDNA2008 was adopted.  Those complications include, but are
not just about, the issues that started out with the "Hamza"
discussion that prompted the original IAB statement on that
subject and evolved into what some of us have called the
non-decomposing precomposed character issue.  They also include
some of the issues Asmus has identified about complex scripts
and the requirements they impose as well as, e.g., issues of
registry responsibility and accountability (not only from
IDNA2008 but going back to RFC 1591 and earlier) and other
topics that may be in need of clarification and/or more serious
attention.

If we are either going to change or clarify IDNA2008 to address
those issues or decide to push ahead without addressing them at
all (which, itself, would change or clarify IDNA2008), I think
that must be an IETF consensus position, not done on the basis
of the IAB declaring what it believes (something the IAB is
certainly entitled to do).

best,
    john

--On Tuesday, October 9, 2018 06:37 +0200 Patrik Fältström
<[email-masked]> wrote:

>> 1. Updating the IDN parameters registry as the IAB requested.
>> With apologies if I'm missing something, I don't see the
>> expert saying he can't update the registry for some reason,
>> or that there's any ambiguity in what the update should be;
>> it's his judgment that "the right thing to do" about
>> the code points that changed properties between Unicode 6.3
>> and Unicode 11 is consistent with what the standard tells him
>> to do. So for the current situation, the standard, including
>> the instructions to the expert, is adequate.
> 
> The key thing here is that I do not see myself have the
> competence in actually ensuring what I propose in the I-D is
> the correct thing to do. There are other alternatives as well,
> such as adding an exception to the IDNA2008 rule set.
> 
> IAB asked me to bring things forward, and my call is what I
> call path A: A.1. Suggest a path forward
> B.1. I ask IETF what to do with the incompatible changes (but
> do not suggest anything) B.2. IETF tell me what to do
> 
> C.1. IAB tell me not only to move things forward, but also
> "IAB have decided that the changes made in Unicode do not
> require backward compatible rules in IDNA2008" C.2. I move
> things forward based on B.1.
> 
> FWIW, I did not interpret what IAB told me was "C" which I
> read in your note Suz. Maybe I misunderstand you.
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 9 Oct 2018 12:59:00 -0500

Posting from far outside the level of expertise I'd hope to find in the
archives for this mailing list, but on one particular point.

> walls, and figuring out how and when to do that.

As an AD, I've had more problems when I asked for feedback on schedule and
could reasonably have asked for early feedback, than I've had when asking
for early feedback. I don't have a lot of experience with complex IANA
instructions, but even then, we've asked IANA their opinions a few times,
early in the process.

I'll leave it to others to determine what the right answer is in this
specific case, but I hope John is right.

Spencer

> i18nRP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i18nrp
>