RE: [idn] Document Status?

[John C Klensin <klensin@jck.com>]

--On Saturday, 07 September, 2002 16:30 -0400 "Hollenbeck,
Scott" <shollenbeck@verisign.com> wrote:

>> > The only text I recall which has some bearing on this is:
>> >   It is expected that some name-handling bodies, such as
>> >   large zone administrators and groups of affiliated zone
>> >   administrators, ...
>> > I don't see how registries limiting the set of Unicode code
>> > points that can be used in a part of the name space has any 
>> negative impact on
>> > interoperability; registries limit the types of names for 
>> various policy
>> > reasons already (such as only allowing registered companies
>> > in some
>> 
>> I am hoping that I am misunderstanding what you have just 
>> written, Erik.
>> 
>> You are suggesting that the set of valid characters -- leaf 
>> characters?  intermediate node characters? -- will depend 
>> upon the portion 
>> of the DNS tree that the name is under?  This is a 
>> fundamental change to 
>> the DNS.
>> 
>> Since you disagree, please cite an existing example of such a 
>> dependency, 
>> on place in the tree, in the current DNS.
> 
> Jumping in...
> 
> There are some domain name registries that prohibit certain
> combinations of characters in the name spaces they administer.
> The administrator of the .us ccTLD, for example, prohibits use
> of the seven "dirty words" described by the US FCC and George
> Carlin.  While this isn't a restriction on the set of valid
> characters, it _is_ a restriction on how they may be combined.
> I read Erik's note to mean that registries may well prohibit
> certain Unicode code points or combinations of code points for
> various policy or legal reasons, and I'd agree with that
> assessment.
> 
> Please correct me if my interpretation is wrong, Erik.

IMO, if this is the intention, then the document needs to be
made crystal clear -- this is a really bad area in which to say
something circumspect that people can interpret as they will.
And, in particular, it needs to be clear that:

(i) No one can expect a client-side error message on the basis
of any of these excluded characters, labels, or sequences.
I.e., that one must look up a name and, if it isn't present,
return a "nodomain" error and not be expected (or even
permitted) to return "that isn't a valid string in Lower
Slobbovian".

(ii) The _only_ thing a registry (or other form of zone
administrator) is permitted to do is to specify what character
content will not be accepted in labels being registered, or what
specific labels will not be registered.  This does not make any
of those characters or sequences "invalid" as far as the
protocol is concerned, it is just a restriction on registration
in that particular zone or set of zones.  Any notions of local
(or per-zone) interpretation of what particular characters
"mean", or how they are to be interpreted or mapped, are
off-limits and seriously noncomforming -- so seriously so that
the administrator of the parent zone should consider it grounds
for considering redelegation as a threat to global Internet
interoperability.

To use a concrete example from Roman-based scripts, while I
don't think any of us would encourage it, it would be plausible
for the administrator of a particular zone (or subtree) to say
that "1" and "l", and "u" and "v" are just too similar, and
hence that no labels containing "1" or "v" are permitted to be
registered in that zone.  It would _not_ be plausible to thereby
consider a query for "1" to be invalid -- it would just not
match any registered name since no such names would appear in
the zone.  And, more important, it would be completely
unacceptable for that zone administrator to expect that a query
containing "ab1cd" be mapped into, or interpreted as, a query
containing "ablcd", or that information associated with "ablcd"
be returned in response to a query for "ab1cd".

For the record, I'm not sure that is good enough.   If the
relevant zone accepts dynamic updates that can add labels to the
zone, we need to be absolutely sure that there are appropriate
and unambiguous reply states for "that label isn't acceptable
for this zone even though it meets all of the syntax rules".

And, again, whatever is done here, I believe the specification
needs to be made so clear that not even someone who is trying to
misunderstand it can do so and pass even the most minimal of
laugh tests.

     john