Subject: Re: Last Call: <draft-faltstrom-unicode11-07.txt> (IDNA2008 and Unicode 11.0.0) to Proposed Standard

From: Suzanne Woolf <[email-masked]>
Date: Thu, 14 Feb 2019 09:53:56 -0500

Hi,

> On Feb 5, 2019, at 9:31 AM, The IESG <[email-masked]> wrote:
> 
> 
> The IESG has received a request from an individual submitter to consider the
> following document: - 'IDNA2008 and Unicode 11.0.0'
>  <draft-faltstrom-unicode11-07.txt> as Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2019-03-05. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the beginning of
> the Subject line to allow automated sorting.

I support publication of this document as an RFC. It provides useful information on how implementation and deployment of the IDNA standard is working out in the real world, and adds transparency to the expert review process.

I sent the following to the draft authors and the AD, but it should probably be on the record as an LC comment:

I’m a little confused about the status of this document.

The datatracker and the document say it’s standards track, but the shepherd’s writeup says Informational.

I was involved in some amount of discussion about the motivation for this document, since it’s not required by the standard or by any procedure imposed on the designated expert, but it seemed like a good idea to record the expert’s thinking on the situation that had developed. I also recall some consideration of whether it needed to be standards track because it sets something of a precedent— it advises specifically against updating 5892, but could be argued to provide future guidance to the designated expert on how to handle changes in derived properties for a code point between Unicode versions.

If this document is intended to establish a precedent— a “soft” change to the procedure expected of the designated expert in future cases, along the lines of “you probably don’t want to try to update 5892, but here’s what you should consider"— PS makes sense to me as the status, as it’s explicitly not a change in the protocol but seems to be a refinement to the registry policy specified in the IDNA documents.

However, if it’s simply intended to provide information about how the designated expert resolved this specific case (which includes a leap over several Unicode versions), shouldn’t it be Informational? 

In either case, I’d suggest briefly explaining the status and the rationale somewhere in the document. It’s way too easy to get into lawyering the difference between Informational and PS in a case like this, so I’m not suggesting you should, but IDNA issues commonly suffer from exactly this kind of confusion: Is this specific decision a matter of protocol compliance, or a judgment call? 

Suzanne

---

From: Ted Hardie <[email-masked]>
Date: Tue, 19 Feb 2019 08:41:56 -0800

I write to support the publication of this document, though I do not
personally believe it needs to be at Proposed Standard, so I would also
support its publication as Informational.

Making a concise summary of the history that led to this document is beyond
my powers of summarization, but a part of that history was a request to the
author, as the Designated Expert for an IANA registry, to review the
updates to the Unicode Code Points in the releases between Unicode 6.3 and
Unicode 11.  It was his decision as the expert to seek public comments on
that review by publishing that document and seeking consensus for it.  I
believe the document does a good job of describing the changes and
reflecting the reasoning behind his decisions as expert.  I also believe
the result, the updating of the tables to Unicode 11, is appropriate at
this time based on the existing documents in the IDNA 2008 set, the IAB
stream principles document, and the Unicode releases.

There are, obviously, a lot of the things that want doing in this realm,
and it is clear that this document does not solve all the problems which
were pointed out in LUCID or other reflections on the IETF
internationalization efforts.  Holding it responsible for that, however,
would be a misreading of the scope of both the document and the work of the
expert.  I encourage the Area Directors to continue to work on the larger
problem, but to do so through other means than updates to this specific
documents.

regards,

Ted Hardie
(no hats)

On Tue, Feb 5, 2019 at 6:31 AM The IESG <[email-masked]> wrote:

> Abstract
>    This document describes the changes between Unicode 6.3.0 and Unicode
>    11.0.0 in the context of IDNA2008.  It further suggests a path
>    forward for the IETF to ensure IDNA2008 follows the evolution of the
>    Unicode Standard.
>
>    Some changes have been made in the Unicode Standard related to the
>    algorithm IDNA2008 specifies.  IDNA2008 allows adding exceptions to
>    the algorithm for backward compatibility; however, this document
>    makes no such changes.  Thus this document requests that IANA update
>    the tables to Unicode 11.
>
>    The document also recomments that all DNS registries continue the
>    practice of calculating a repertoire using conservatism and inclusion
>    principles.
>
>    TO BE REMOVED AT TIME OF PUBLICATION AS AN RFC:
>
>    This document is discussed on the [email-masked] mailing list of the
>    IETF.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-faltstrom-unicode11/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-faltstrom-unicode11/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
> The document contains these normative downward references.
> See RFC 3967 for additional information:
>     rfc6912: Principles for Unicode Code Point Inclusion in Labels in the
> DNS (Informational - IAB stream)
>     draft-freytag-troublesome-characters: Those Troublesome Characters: A
> Registry of Unicode Code Points Needing Special Consideration When Used in
> Network Identifiers (None - )
>     rfc5894: Internationalized Domain Names for Applications (IDNA):
> Background, Explanation, and Rationale (Informational - IETF stream)
>     rfc5895: Mapping Characters for Internationalized Domain Names in
> Applications (IDNA) 2008 (Informational - Independent Submission Editor
> stream)
>
>
>
>

---

From: S Moonesamy <[email-masked]>
Date: Tue, 19 Feb 2019 10:00:40 -0800

Hello,
>comments on this action. Please send substantive comments to the

There is the following in Section 5: "All DNS registries (and other 
organizatios) SHOULD calculate a repertoire using the conservatism 
and inclusion principles ..."  There is a typo for 
"organizations".  The sentence sounds like the IETF telling DNS 
registries what to do.  I'll leave it to the author to see whether 
that can be phrased as a recommendation.  Why is SAC-084 not an 
normative reference?

Regards,
S. Moonesamy