Re: [idn] Document Status?

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

--On Sunday, 08 September, 2002 01:06 +0000 "Adam M. Costello"
<idn.amc+0@nicemice.net.RemoveThisWord> wrote:

> John C Klensin <klensin@jck.com> 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.

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