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

[Suzanne Woolf <[e-mail]>]

Hi,

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

> On Oct 8, 2018, at 4:34 PM, Asmus Freytag <[e-mail]> wrote:
> 
> On 10/8/2018 12:58 PM, John C Klensin wrote:
>> --On Monday, October 8, 2018 09:06 -0700 Ted Hardie
>> <[e-mail]> <mailto:[e-mail]> 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, 
> 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.

>> 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. 
> 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.
> 
> 
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.
>>  It
>> would be wildly inappropriate for it to constrain the
>> conclusions the IETF could reach about those other documents.
> 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.
> 
I admit I don’t see this either. 
>> 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).
> 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.
> 
> 
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