Re: [Idna-update] Last Call: <draft-klensin-idna-rfc5891bis-04.txt> (Internationalized Domain Names in Applications (IDNA): Registry Restrictions and Recommendations) to Proposed Standard

[John C Klensin <[e-mail]>]

(sdding the IDNA-update and directorate lists back in because I
know there are people on both who are critical parts of this
conversation but who are not on the IETF list.)

--On Tuesday, August 6, 2019 01:14 -0400 John Levine
<[e-mail]> wrote:

> In article
> <[e-mail].c
> om> you write:
>> 
>> 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-04.txt> as Proposed Standard
> 
> This document fills a longstanding need and definitely needs
> to be published.  But I have a few suggestions.
> 
> Section 4 on "For-Profit Domains" contrasts normal zones which
> have names that are of use to the zone's owner, and commercial
> zones where more names mean more money and says (I
> paraphrase), hey you greedy slobs, don't register junk names.
> While I certainly agree with the sentiment, in its current
> form I don't think the intended audience is likely to take the
> hint.  I would shrink the section and just note that zones are
> managed in different ways and the ones which have a financial
> or other incentive to maximize the number of names present a
> potential quality problem.  Then say something like that zones
> and registries have reputations, and zones with poor quality
> names tend to earn poor reputations, which has led to
> resolution issues as client systems block them in self-defense.

I'll think about this and discuss it with Asmus and others but,
as you will see below, there more I've though about the change
you suggest the less I think it is desirable

As discussed in other notes, part of the problem is that I/we
wanted to avoid getting into "public domain" terminology,
especially because there are some ccTLDs and maybe still some
gTLDs who behave in an exemplary way. There have certainly been
corporate and academic domains whose naming rules have been
dominated by a dangerous excess of cuteness and cleverness.
Borrowing from your paragraph above, it would be nice to say "if
you are inclined to behave like a greedy slob, then ..." but
that definitely would not fly.

I am also concerned that Getting this perfectly (or even nearly
so) right would require much more text and that more text would
reduce the number of readers.

Possibly more important, your assumption about the intended
audience may be a little bit different from mine.  Based on
watching different subsets of the groups of people whom you
describe as greedy (I'll skip having an opinion about the "slob"
part) ignore DNS identifier issues in favor selling more names,
ignore ICANN Board resolutions and other advice, ignore SSAC
advice, ignore IAB advice, ignore 1591, market names using fear
or extortionist tactics, and so on, I'd assume that the odds of
their paying any attention to anything this document says that
would inconvenience them --wherever it falls between a hint and
rude and explicit language and loud screaming-- is about zero. 

Instead, I think one audience for that and some other sections
of the document is actually those commercial (sic) zone
operators who are trying, hard, to find a good balance between
being profitable and being responsible to the Internet.  Some of
their staff and Board members will read this document and try to
understand it ("hints" or not) and maybe it will leverage
continuing good or improved behavior.  If the document did
nothing else, that would be worthwhile.  

There is also another audience.  As you know from other
contexts, I believe the whole domain names market is looking
more and more like a house of cards and that, sooner or later,
there will be incidents, probably ones in which someone is
harmed, that get enough public attention that people or groups
with authority feel compelled to Do Something.  Whether the
relevant groups are ICANN leadership, government regulators in
one or more countries, or something else, careful and reasoned
explanations about which behaviors are reasonable and which ones
are not are the Internet's best protections against damaging
overreactions.
 
> Section 5 refers to draft-klensin-idna-unicode-review which
> updates RFC 5892.  It is also in last call so I'd suggest
> treating the two drafts as a bundle and replace the paragraph
> with a reference to the RFC.

Under any normal circumstances, great (and obvious) idea.  When
the recent history of IDNA documents (and i18n documents more
generally), including the first draft of this one being posted
early in 2017 and its taking until now to get serious review and
a Last Call, is considered, I think it is better to keep them
formally separate.  If they go through the works together, we
will certainly fix the references.  But, if something ties one
of them up, whether to hold the other one up as a result --
despite the reference, they really are independent -- should be
a substantive decision by the IESG with community input rather
than a decisions the RFC Production Center makes on a procedural
basis.

> Section 5.1 updates RFC 5890 section 4.2 to say in part "A 63
> octet A-label cannot represent more than 58 Unicode code
> points ..." which is true, but is easy to miss the point that
> the UTF-8 version is likely to be a lot more than 58 octets.
> I'd change it to something like "A 63 octet A-label can
> represent up to 58 Unicode code points, each of whose UTF-8
> encoding can take up to four octets..."

Thought about doing something like that, but (i) there is
--quite deliberately and after discussion in the WG-- no UTF-8
dependency or requirement in the IDNA specs.  Use of UTF-8,
rather than some other encoding form, is probably a good
recommendation or requirement, but not in IDNA itself, so
getting significantly into that here would require considerable
foundation that does not now exist.   Also note that, while the
code points far enough out in  the Unicode range to require four
octets each a label consisting entirely of code points from the
ASCII repertoire other than a single "extended Latin" one is
actually shorter in UTF-8 than in A-label form.   Unless you see
reasons I don't, let's not go there.

thanks for the review,
best,
    john