On 7 Oct 2024, at 9:55, The IESG wrote: > The IESG has received a request from an individual submitter to consider the > following document: - 'Internationalized Domain Names in Applications (IDNA): > Registry > Restrictions and Recommendations' > <draft-klensin-idna-rfc5891bis-07.txt> as Proposed Standard > > This is a revision to a document that previously went through Last Call in > 2019, but stalled in IESG Evaluation specifically with respect to the content > of Section 4. This new revision modernizes significant portions of the text, > and is now being returned to the community to verify continued consensus and > then progress toward publication. > > 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 > last-call@xxxxxxxx mailing lists by 2024-10-21. Exceptionally, comments may > be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning > of the Subject line to allow automated sorting. This draft should have remained abandoned after the failed IETF Last Call in 2019. This update is not needed, and some of the changes are harmful to this widely-deployed standard. The document shepherd's writeup correctly states "this is a document regarding recommendations to the registry and registrar community that could only be developed by experts on IDNA, of which the IETF has very few." There is no justification that this (or any) IETF document should make recommendations to registries and/or registrars (neither of which can actually be considered organized communities) beyond what is already in RFC 5891. In the years since RFC 5891 and the other documents defining IDNA 2008 were published, the registries and registrars have determined on their own how to implement IDNA2008 without the need for an updated standard. Section 5.1 woefully and deceptively understates the vast changes from RFC 5891. None of the diffs that this document proposed to make to RFC 5891 (closest estimate of changes is <https://author-tools.ietf.org/iddiff?url1=draft-klensin-idna-rfc5891bis-00&url2=draft-klensin-idna-rfc5891bis-07&difftype=--html>) are needed for the standard to be implemented. Worse, some are harmful, such as the ones made in Section 3 where there is a long description of the ICANN maximal string repertoires (MSRs) and label generation rules (LGRs), both of which are still in the process of change. This material has no place in an Internet standard, and if it is needed by those in the ICANN community, ICANN itself can publish that material. There is a great deal of new editorializing in the guise of history presentations, such as the additions in Sections 1 and 2 and 6. These were not needed in RFC 5891 for implementers, and are still not needed now. These changes do not have rough consensus in the IETF, and implementation of the original RFC continues just fine without it, as is evidenced by the long lull since this document failed during the previous IETF Last Call. If the authors want to write an editorial document with historical commentary, they should do so as a stand-alone document in the Independent stream, not as an update to a widely-implemented standard. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
