Hi John, Asmus,
At 09:55 AM 07-10-2024, 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
Let's take a step back. The document is about updating RFC 5890 and
RFC 5891. There isn't any update to the RFC on "IDNA: Background,
Explanation, and Rationale". The correction/update is to A-labels
and Unicode strings (Section 5).
I found the background information in Section 4 useful to understand
what this was all about. It could be somewhat contentious to write
about that while referring to RFC 1591. I assume that the reason for
that text is the following: "While the IETF rarely gives advice to
those who choose to violate IETF Standards ..."
I would view Section 4 of this document in the light of Section 4.3
of RFC 5981, i.e. policies about label registration. The 2010 view
was that policies were likely informed by local languages and the
scripts that are used to write them. Such polices could result in
undesirable outcomes if they violate economic principles. Some of
those policies are discussed under the umbrella of ICANN. In order
to work around IETF policy limitations, the authors could consider
whether it makes sense to tackle the topic from a label registration
perspective. For example, saying that a particular label causes harm
is not a very convincing argument unless there is some evidence to
support the argument.
Regards,
S. Moonesamy
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
