--On Tuesday, October 8, 2024 05:32 -0700 S Moonesamy
<sm+ietf@xxxxxxxxxxxx> wrote:
> 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 bear full responsibility for that sentence -- don't blame Asmus.
The sentence became controversial in the IESG review after the prior
Last Call and is, I believe, factually correct. I have thought about
less forceful (more wimpy?) language but the underlying issue goes
back to language of BCP 14.
I can't explain without going off-topic but, because this came up the
last time, maybe it is worth doing so. In most standards bodies (and
with other makers of rules), the language is, more or less, "do it
this way or you do not conform", i.e., you violate the specification.
In BCP 14-speak, that is the "absolute requirement" described as
"MUST do this" or "MUST NOT do that". But SHOULD is unusual and is
far more fuzzy with "may exist valid reasons in particular
circumstances to ignore ..., but the full implications must be
understood and carefully weighed before choosing a different course".
We have never required that a specification supplement "SHOULD do X"
with a discussion of what the circumstances might be that would
justify not doing that, nor that they include an "if you are going to
ignore that, you SHOULD (or MUST) do Y. There are many reasons for
not requiring such an explanation but we have never prohibited it (or
either part of it) either. Now, suppose a document says "you SHOULD
do X but, if you conclude that circumstances require that you don't,
best do Y" (or even "...don't, you MUST do Y" or "...don't, you
SHOULD do Y"). That is the situation to which the sentence partially
quoted above refers and it is true: we rarely give such advice, but
it is certainly not unprecedented.
Now, I (and several others with whom it was discussed in 2017- 2019)
decided a forceful word was needed, and I therefore selected
"violate". Maybe I've mellowed or gotten jaded during the last five
years but, if there is agreement that section of the document is
problematic with "violate" but would be ok with "disregard",
"ignore", or some other term, then let's agree on which term, change
the word in the I-D, and move on. And, maybe, if BCP 14 is ever
updated again, we should have a discussion of whether a specification
that uses SHOULD ought to provide an explanation of conditions for
violating (sic) a SHOULD and/or what should be done instead if those
conditions and alternatives are known.
> 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.
I would have stated that differently, starting with replacing
"likely" with "SHOULD be" and some words about appropriate context,
but yes.
> Such polices could result
> in undesirable outcomes if they violate economic principles.
Let me say that differently and hope we agree. If the core policy
for the domain is to serve a community, or set of communities, that
are homogeneous with regard to a relatively small number of languages
or scripts, then tuning requirements to reflect those languages,
scripts, and local usage (and any possible interactions among them
including homograph issues) is appropriate. The necessary specific
knowledge should fall with the range of knowledge readily available
to the policy makers and policy development should be fairly easy.
On the other hand, if the core policy for the domain is, e.g., to
register as many names as possible for whatever reason -- even to
accommodate an extremely diverse collection of registrants and names
whether the reasons for that are economic or not (although I can't
think of other compelling reasons) -- then the implications of
registering names without regard to global language or script issues
should at least be understood.
To prohibit such decisions or to declare that the risks and tradeoffs
be evaluated in one particular way, lies outside the IETF's scope.
If we pushed that boundary, we would rapidly find ourselves in the
space between "voluntary standards" and frequent appeals to the
Protocol Police. However, it seems reasonable and appropriate for
us to say something equivalent to "down that path lie dragons and you
SHOULD understand the possible consequences of your decisions" and to
do so as explanation and general guidance, not by altering the core
IDNA2008 specifications or their application.
> 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.
I don't understand what you are suggesting. The policies themselves
fall under ICANN's umbrella (at least for the root, maybe for the
second level (or first level below a "public domain"), less further
down in the tree. Beyond "know what you are doing and what problems
it might lead into", avoiding the assumption that allowing any string
to be registered that conforms narrowly to the IDNA2008 specs is
appropriate for registration, and suggesting that, if the registry
for a particular zone has made decisions that preempt actually
knowing what it is doing, that it is appropriate and desirable to
look elsewhere for at least partial guidance is what this document is
all about.
Again, suggestions about how to make any of that more clear would be
welcome.
best,
john
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
