I-D Action: draft-klensin-idna-rfc5891bis-00.txt

[John C Klensin]

--On Saturday, March 11, 2017 12:10 -0800 Paul Hoffman
<phoffman at imc.org> wrote:

> On 11 Mar 2017, at 8:52, John C Klensin wrote:
> 
>> Asmus Freytag and I have started to put together a draft that
>> addresses a problem with the IDNA2008 specs, specifically that
>> we failed to make the responsibility of registries to define
>> code point and label acceptability rules that were
>> considerably more narrow (and better understood by them) than
>> the full set of labels allowed by RFC 5891-5893.  It doesn't
>> actually change anything because that requirement is in the
>> existing specs; it just makes (or tries to make) the
>> requirements painfully clear to those who have been missing
>> or misreading them.
>> 
>> It also provides an explicit link between IDNA2008
>> requirements and ICANN work on repertoires and label
>> generation rules without endorsing that work as more than one
>> thoughtful approach that might be examined for either
>> reference or inspiration.
>> 
>> Comments (obviously) welcome.
> 
> Can you explain why this document is meant to be on Standards
> Track? That is, if it is just a hopefully-better explanation
> of what is in RFC 5891-5893, wouldn't it be informational? The
> abstract says "It does not alter the protocols and rules
> themselves in any way."

Paul, as you must know, this whole area has been extremely
controversial, with a regular pattern of people citing documents
as supporting things that their authors didn't intend and
reading and stretching language that was intended to be clear as
ambiguous.  So, the first part of the answer is that, if someone
thinks the current text is unclear, it makes it clear.  To do
that, the draft needs to offer an authoritative interpretation,
not an author's point of view, and that can be done only with a
standards track document that updates the base standards
(remembering, too, that the IESG has taken the position that
simply putting "updates NNNN" in the upper left of a document
requires that the new document be standards track if the old one
is.

Would it help if that sentence said "in the opinion of the
authors and those authors of RFC 5891-5893 who were polled, it
does not alter..."?   I'd hate to clutter the abstract (which is
already pushing length limits) with that level of detail, but I
imagine I could track down the relevant authors and get their
consent and put something to that effect in the document body.
Suggestions as to then how to tune the abstract text would be
welcome.

>> For anyone who might wonder, this document avoids the more
>> controversial IDNA2008 issues including:
>> . . .
> 
> If you're going to open the box of updating the IDNA2008
> standard, it feels like it should be really open. If you're
> really just trying to clarify one bit of it, great, but then
> consider making that just informational.

See above and my note about why I don't want to open the entire
box/ can of worms.

> FWIW, I consider this to be far from trivial. If you mean to
> clarify this standard, the discussion should have a IETF
> mailing list associated with it, not done on a private mailing
> list that is barely alive. And if you mean to open the
> standard (even a little), it should be done in an IETF WG
> under IETF consensus rules. Yes, I remember how hard it was to
> get consensus the last time, but the result of that was the
> lack of clarity that you are trying to fix now.

I have never intended that it be discussed on a private mailing
list and have written Alexey asking how he wants to handle it
and where he wanted it discussed (and, btw, suggesting that, if
the answer was this one, that it be moved to IETF equipment).
I apologize for not realizing I hadn't done that until this
weekend, but I do expect to fix it in -01, which I will get
posted as soon after I hear from him as possible.  In the
interim, this is not a "private mailing list", it is the mailing
list from an IETF WG that has closed, a perfectly orderly place
to have this type of discussion.

best,
   john