Re: [idn] Document Status?

["Adam M. Costello" <idn.amc+0@nicemice.net.RemoveThisWord>]

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

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