Hi, > On Feb 5, 2019, at 9:31 AM, The IESG <iesg-secretary@xxxxxxxx> 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 > ietf@xxxxxxxx mailing lists by 2019-03-05. Exceptionally, comments may be > sent to iesg@xxxxxxxx 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
