Subject: RE: [idn] Document Status?

From: "Hollenbeck, Scott" <[email-masked]>
Date: Sat, 7 Sep 2002 16:30:28 -0400

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

-Scott-

---

From: John C Klensin <[email-masked]>
Date: Sat, 07 Sep 2002 20:25:05 -0400

--On Saturday, 07 September, 2002 16:30 -0400 "Hollenbeck,
Scott" <[email-masked]> wrote:

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

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

---

From: "Adam M. Costello" <[email-masked]>
Date: Sun, 8 Sep 2002 01:06:55 +0000

John C Klensin <[email-masked]> wrote:

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

Yes.

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

Not even if the registry told everyone up front that this is how it
would operate?  As long as registrants understand that the resource
records they associate with ablcd will be automatically mirrored
under ab1cd, what's the problem?  Registrants who don't want this
auto-mirroring (like me) can go to a different registry.

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

This is not an IDN issue; per-zone acceptable-name policies and dynamic
updates both existed before IDN.  If anything, this is an issue for the
dynamic DNS update spec, not the IDN spec.

AMC

---

From: Soobok Lee <[email-masked]>
Date: Sun, 8 Sep 2002 11:12:49 +0900

> dynamic DNS update spec, not the IDN spec.

I think the issue is not only for Dynamic DNS spec, but also for all other
thousands of RFCs which use hostnames in their protocols. Since IDN spec
contains hostnames extension spec, that affects all RFCs. Sweeping.

From conservative security viewpoints, ACE-encoded IDNs are different
than LDH ones in that they have amplified ambiguity/security problems 
behind the merits of backward compatibilty in networking. I cannot
accept even comparing IDN ambiguity problems with '1' and 'l' problems.
ASCII-tunneling accompanies unwarranted/improper trust by all parties. 

Going further, i think per-zone iDN registration policy is not enough,
it is just about how to control the "source" of the problem.
Receiving applications cannot detect IDNs from loosely-controlled-zone 
which policies and management the receiving sides may not accept or not
be satisfied with if they happen to know that, even though those controls 
are correct and acceptable in the source side. Old Receiving applications
can't do anything to ban "alien" improper IDNs.

In short, IDN should be controlled, but it can't because it is ASCII
tunneled. It seems sweeping on all RFC specs ,as you partly suggest.

---

From: John C Klensin <[email-masked]>
Date: Sun, 08 Sep 2002 11:13:26 -0400

--On Sunday, 08 September, 2002 01:06 +0000 "Adam M. Costello"
<[email-masked]> wrote:

>> 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.
> 
> Yes.
> 
>> 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".
> 
> Not even if the registry told everyone up front that this is
> how it would operate?  As long as registrants understand that
> the resource records they associate with ablcd will be
> automatically mirrored under ab1cd, what's the problem?
> Registrants who don't want this auto-mirroring (like me) can
> go to a different registry.

I don't want to go back into an area in which the dead horse has
already been kicked into an unrecognizable pulp, but, no, your
exceptions don't work.  From a technical standpoint, if a
registry wants to implement that mirroring by automatically
registering 
   ablcd IN CNAME ab1cd
whenever they get a registration for "ab1cd" and refusing to
accept registrations for "ablcd", then nothing prevents that
(but the combinatorics, which would, IMO, rapidly kill the idea,
and even more quickly in IDN-space).  Such registrations don't
change the DNS protocols or algorithms.  

But if the registry starts doing protocol-variations, and
"telling everyone up front", it means that every caching server
has to know _all_ of the per-zone rules.  And, remember, nothing
makes a TLD or SLD sacred -- if we can have different
resolution/matching rules for KR than for COM, then we can have
different matching rules for the one subdomain/zone in TV (if it
exists) that is reserved for domestic registrations than we have
for all of the foreign-sales ones.  And I can have different
rules for the i-klingon.jck.com zone relative to the
zh-wuu.jck.com zone, and still other rules for the jck.com
default (and no one can constrain me to name them that way and
thereby give hints).

>> 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".
> 
> This is not an IDN issue; per-zone acceptable-name policies
> and dynamic updates both existed before IDN.  If anything,
> this is an issue for the dynamic DNS update spec, not the IDN
> spec.

Here we may rather seriously disagree.  The IDN WG has a fairly
explicit mandate to not do anything that would wreck the DNS.
Taking this as an example, to the extent that "dynamic updates
... existed before IDN", then it is _someone's_ responsibility
to be sure that IDN side-effects don't foul it up, or that there
are enough normative crossreferences to be sure that IDN specs
are not published onto the Standards Track until after dynamic
DNS is updated sufficiently to resolve any problems.  If the WG
isn't going to, or cannot, take responsibility for doing that,
it falls onto the IESG to do the necessary coordination.  But,
at least in my opinion, if anything the IDN WG produces moves
onto the standards track that creates identifiable risk to
existing standards (or even well-established practices), without
documenting and attempting to resolve those issues on the
"someone else's problem" theory, then it is a process violation
as well as a Really Bad Idea.

     john

---

From: Ted Hardie <[email-masked]>
Date: Sun, 8 Sep 2002 11:49:54 -0700 (PDT)

Since John buried this very important point a few
paragraphs into his message, I'd like to bring it
forward and reinforce it a bit.

> default (and no one can constrain me to name them that way and

I believe many of those who have proposed registration-based
restrictions have assumed that a restriction on, say, registrations in
.ie. to use only characters which are valid in Irish would somehow
apply to the characters allowed in hostnames under .example.ie.  As
John's point makes clear, this isn't true.  Ensuring that folks
outside this group understand this point may be critical to getting
reasonable deployment once IDN is in the wild.

				regards,
					Ted Hardie

---

From: Ted Hardie <[email-masked]>
Date: Sun, 8 Sep 2002 16:40:05 -0700 (PDT)

> reasonable deployment once IDN is in the wild.

It's been pointed out to me that a registry can, of course, refuse
to delegate to those who do not agree to impose the same restrictions
on their registrations as on the parent.   I think this actually
highlights the problem:  any restriction is administrative and
exists *only as policy*.  To put it more bluntly:

The protocol doesn't care.

For those who are helping registries understand the impact of all of
this, it may be useful to repeat this mantra at frequent intervals, so
that they understand that their restrictions, desires, and preferred
mappings simply do not exist at the protocol level.  Any attempts to
restrict, to establish mappings or otherwise satisfy their desires
should not rely on protocol action.  

			regards,
				Ted Hardie

---

From: "Adam M. Costello" <[email-masked]>
Date: Mon, 9 Sep 2002 02:01:50 +0000

John C Klensin <[email-masked]> wrote:

> From a technical standpoint, if a registry wants to implement that
> mirroring by automatically registering
>
>    ablcd IN CNAME ab1cd
>
> whenever they get a registration for "ab1cd" and refusing to accept
> registrations for "ablcd", then nothing prevents that (but the
> combinatorics, which would, IMO, rapidly kill the idea, and even
> more quickly in IDN-space).  Such registrations don't change the DNS
> protocols or algorithms.

Okay.  Now suppose that instead of automatically generating a CNAME, the
registry automatically copies the resource record.  So when you insert

    ablcd A  127.5.5.5
          MX mail.example.org 10

the registry automatically copies it to

    ab1cd A  127.5.5.5
          MX mail.example.org 10

and whenever you alter the one, the registry automatically re-copies
it to the other.  Like the CNAME approach, this approach still doesn't
change the DNS protocol.

Now suppose the server uses a compressed database format, so that the
two records share the same storage, and copying the record is actually a
zero-cost operation.  The DNS standard explicitly abstains from defining
the database format, so this is just a private internal optimization.
We still haven't changed the protocol.

We have now arrived at exactly the scenario you described as "completely
unacceptable", but it is not materially different from your tolerable
scenario above.

> But if the registry starts doing protocol-variations, and "telling
> everyone up front"

That would be bad.  I'm not endorsing protocol variations.  I don't see
how the IDNA spec could be construed as endorsing protocol variations.
The principle at the very heart of IDNA is "no changes to the DNS
protocol".

> > > 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".
> >
> > This is not an IDN issue; per-zone acceptable-name policies and
> > dynamic updates both existed before IDN.  If anything, this is an
> > issue for the dynamic DNS update spec, not the IDN spec.
>
> explicit mandate to not do anything that would wreck the DNS.  Taking
> this as an example, to the extent that "dynamic updates ... existed
> before IDN", then it is _someone's_ responsibility to be sure that
> IDN side-effects don't foul it up, or that there are enough normative
> crossreferences to be sure that IDN specs are not published onto the
> Standards Track until after dynamic DNS is updated sufficiently to
> resolve any problems.

What IDN side-effects?  Registries already prohibit some syntactically
valid labels.  IDN doesn't change anything in that regard.

The concern you raise may be a valid concern, but if so it is something
that the dynamic DNS spec needs to take care of even if IDN is never
introduced.

AMC

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 9 Sep 2002 10:53:51 +0200 (CEST)

> Please correct me if my interpretation is wrong, Erik.

Our interpretation is correct.

The "dirty words" was one type of restriction I had in the back of my head.

Another type of restriction is the one I've vaguely heard about .se
(and I don't know the actual policy rules so I'll be vague) which
is that in order to be able to register a name in .se there has to
be a corresponding (approximate?) legal company name being registered
with Patent och Registreringsverket in Sweden.
Just like the "dirty words" this is not a limitation in code points
but a restriction that applies to the whole label.

Another type of restriction might appear with the introduction of IDN
is a "go slow" approach for allowing Uncode code points. For instance, a ccTLD
registry might initially limit the IDNs that can be registered to
use LDH plus additional code points used in the language(s) in that country.

I don't see how any of these would cause interoperability problems,
even though users might be inconvinienced by not being able to register
arbitrary names in arbitrary TLDs.

  Erik