IDNAbis spec

[Erik van der Poel]

I was talking about a single DNAME definition, not about other DNAMEs
that might enter the picture at some point. If somebody were to
implement a tool that checks DNAMEs before inserting them into a zone,
that tool could check a *single* DNAME against the IDNAbis bidi rules.

Here is an example from http://tools.ietf.org/html/rfc2672

frobozz.example.  DNAME    frobozz-division.acme.example.

When the tool is about to insert this DNAME into the zone, it can
apply the bidi rules to the full domain name (which consists of
multiple labels, as you can see).

Even if some other DNAMEs were defined later that would allow the
creation of domain names that break the bidi rules, the client can
check the rules at lookup time and at display time.

Erik

On Wed, Nov 4, 2009 at 6:47 AM, Andrew Sullivan <ajs at shinkuro.com> wrote:
> On Wed, Nov 04, 2009 at 05:31:49AM -0800, Erik van der Poel wrote:
>> (2) multi-label DNAME definition time
>
> The problem there is that there is _no way_ to have a rule about this.
> It's not that we never thought about it; it's that you can't possibly
> specify a rule that will solve this problem.
>
> If there are zone cuts, it is _just impossible_ to know what might end
> up lurking on the other side of the cut, not only at the time of
> registration but also later, since a DNAME could be introduced at a
> later date (indeed, that's actually one of the target use cases of
> DNAMEs).
>
> A
>
> --
> Andrew Sullivan
> ajs at shinkuro.com
> Shinkuro, Inc.
>