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

Paul Hoffman phoffman at imc.org
Sat Mar 11 23:28:40 CET 2017

On 11 Mar 2017, at 13:05, John C Klensin wrote:

>> 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.

Fair enough.

> 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.

Instead, I would not say "it does not alter" at all. It does alter the 
spec for everyone who interpreted it differently than you expected them 
to. If you want this to be a standard updating a standard, admitting 
that the first standard was not clear is a good thing.

>>> 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.

I still disagree about this, but if others want some clarifications 
without dealing with the bigger messes from IDNA2008, so be it.

>> 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.

A mailing list not run by the IETF, barely visible to the outside world, 
is still a private mailing list even if it was the WG mailing list. 
Please strongly consider getting one managed by the IETF, archived by 
the IETF, and much more visible than this list.

--Paul Hoffman

More information about the Idna-update mailing list