Re: [Idna-update] Expiration impending: <draft-klensin-idna-rfc5891bis-01.txt>

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

--On Thursday, March 8, 2018 14:37 -0500 Andrew Sullivan
<[e-mail]> wrote:

> On Thu, Mar 08, 2018 at 02:11:21PM -0500, John C Klensin wrote:
>> 
>> On the other hand, the same kind of thinking  that argues for
>> a "troublesome characters" list (at least as I've understood
>> it) -- more "you SHOULD NOT use these unless you are
>> extra-sure you know what you are doing and what the
>> implications might be" than any sort of absolute prohibition
>> -- might imply a similar statement about combining sequences.
> 
> That actually doesn't seem like a terrible idea to me.  Of
> course, that was _supposed_ to be the point of the general
> exhortation to have a clue about the code points you were
> putting in a zone.  And that doesn't seem to have panned out
> :-/

Well, and this may apply to Asmus's recent notes (including a
more nuanced view of combining sequences) too, I'm trying to
think in terms of, and maybe adjust, a distinction that goes
back to at least the earliest discussions of IDNs and IDN
policies.   The distinction is arguably closely related to the
difference between RFCs 1034/1035 and a number of subsequent
"this is how we are actually going to do this" statements, of
which RFC 1591 may be a high point.   The version that might be
relevant today is that there are three (or four) levels or
layers of IDNA-related rules affecting what domain names can be
registered:

(0) Nothing gets to violate the fundamental architecture of the
DNS, e.g., one doesn't get to have two labels that compare equal
in the same zone and it really is a tree.   By and large, we
expect this set of rules to be self-enforcing: it is hard to
even think about ways to break those rules and still have
anything work (although we've seen some speculation and wishful
thinking about aliases that would interleave branches of the
tree and that would therefore come close).

(1) The IDNA protocol collection specifies what is and is not
allowed and what operations work and how, and what is and is not
valid, at a fundamental level.  That isn't just
registration-time requirements.  IDNA2008 specifies checks to be
done at lookup time and we expect systems looking up names to
reject at least a subset of invalid strings before looking them
up.   There is some implementation flexibility there: while we
don't require, e.g., contextual checks at lookup time, I don't
imagine anyone would severely criticize an implementation for
rejecting a string outright that didn't conform to those rules
because, if lookup succeeded, the application would be safe in
concluding that either something was broken or that it was
likely that something malicious was going on.  That is true even
of IDNA2003, which effectively has no lookup-time requirements:
to take an extreme example, if an implementation were given
something in ACE (aka presumably "Puncode encoded") form;
decided to convert it back to native characters to be sure it
could generate native-character error messages if needed;
discovered it wouldn't convert or converted to something that
required mapping; and then generated an error message rather
than trying to look the thing up, I don't imagine anyone would
complain (other than perhaps a registrant who had bought such a
string in its Punycode encoded from -- something many registries
won't allow).  

The important thing about these protocol requirements is that no
sane person should expect the problem domain name or label to
actually work, or work predictably, for what we normally
consider DNS functions such as doing name to address
translation.  If someone were buying labels as trophies in the
hope that their trophy-value would increases over time that
would be another matter but I'm not sure that, from a protocol
standpoint, we really need to care.

(2) Advice, guidelines, or policy requirements applicable to a
broad variety of domains.  Unless we are going to have chaos,
such guidelines must allow only a subset of what is allowed
under the protocol limitations above.  For zones that are well
and carefully run, with name use and the best interests of
Internet users in mind, it is reasonable to expect that
well-designed guidelines will be followed, as least unless the
zone administrators understand things well enough to carefully
allow exceptions.   The meta-rule that zones are required to
understand what they are doing is one such guideline and, at
least to a first approximation, I think most registries
(including zones below the second level that are using IDNs)
try.   For those who are not inclined (for business or other
reasons), to follow such guidelines, the guidelines are only as
good as the existence of someone who is willing and able to
enforce them or otherwise discourage bad behavior.  

What has not panned out is the assumption that ICANN would make
at least some serious effort to either persuade or induce
registries, even second-level entities under contracted TLD
registries, to follow those guidelines, especially with
regard to taking active responsibility for what they are doing.
But that doesn't make establishing the guidelines a bad idea.
I'm not aware of it having happened yet with IDNs, but there is
precedent for people who are harmed by someone else's bad
behavior to cite violation of widely-accepted guidelines as
evidence that the behavior was bad or negligent.

(3) The rules that are used by the operator/ administrator of a
particular registry to determine what can or will be allowed in
that zone.  Noting that the rules for the root (including the
LGR rules but not limited to them, at least yet) are just a
special case of this category, all that is necessary to
application and enforcement of the rules is that the registry
decide to do so... and that the rules that are chosen be
sufficiently acceptable to whatever community(ies) are in a
position to hold the registry accountable that they don't either
turn into a source of never-ending strife or change often enough
to cause perceived instability.  

I think some of our discussions have confused the first two and
last two categories and then gone on to confuse the third
(general guidelines for the second level and below) and fourth
(registry-specific rules), assuming, for example, that what is
suitable for one registry should be applicable, either as a
guideline or as a protocol changes, to the others.

best,
   john