Some confusion about policy application and its effects

Erik van der Poel erikv at google.com
Mon Aug 4 23:19:23 CEST 2008


On Mon, Aug 4, 2008 at 8:08 PM, Andrew Sullivan <ajs at commandprompt.com> wrote:
> In IDNA2003 use, we have applications that call for resolution using a
> specially-formatted name that otherwise does not perturb the
> traditional use of DNS at all.  There are restrictions on what may go
> into the DNS, in the sense that there are rules about characters, and
> possibly labels when taken as a whole.  There may also be a number of
> equivalence rules.  All of these restrictions, however, are rules that
> are imposed at the registration side.  Applications still just get a
> result back, and use that.  For convenience and consistency, the
> application may just use Unicode and expect the transformations to be
> supplied by some underlying library that's "bolted onto the front" of
> the traditional resolver.  In some sense, though, we could regard that
> approach as logically equivalent to having the library "bolted onto
> the back" of the application.  The key is that rules about what counts
> as a "legal domain name" under IDNA2003 (and under traditional DNS)
> are applied at the registration end of the DNS.  You get a local error

IDNA2003 seems to say that client applications must check for
prohibited characters and must not use the domain name if ToASCII
fails.

> if you don't have an input label that can be successfully transformed
> according to IDNA2003 rules; but that's not really different from a
> typo where you include a "/" in your ASCII-only domain name.
>
> IDNA2008 takes a different approach, though, because local
> mappings are allowed.  This means that there is policy at the
> registration/DNS side of DNS operation, _but also_ on the client end
> of the transaction.  I understand the motivation for this innovation.
> But I think it probably breaks the "lookup and use" model that
> underlies the way we talk about using the DNS.
>
> In my reading, in traditional ASCII-only DNS resolution, two clients
> C1 and C2 will both get the same result to the same query for a name N
> when querying the same server at the same time.  Under IDNA2003,
> that's also true.  While the scope of N might be different, an
> IDNA2003-compliant client will perform the same transformation to the
> "Unicode labels" each time.  The display of the result will be the
> same, too (as long as both C1 and C2 are both IDNA-aware).  As near as
> I can tell, however, the same is _not_ true for IDNA2008, because
> local mappings may change both the input to the transformation
> function and the displayed output after the answer is returned.  If C1
> and C2 have different policies (different locales, for instance?),
> then at least the meaning of "same query" is not clear to me.

Even though IDNA200X appears to allow local mappings, it would be
unwise to perform them in certain contexts. For example, it would be
bad to apply local mappings to domain names found in "href" attributes
in HTML "a" (anchor) tags. If HTML implementors do not all agree to
use the same mappings, there would be interoperability problems.

Without putting words into Mark's mouth, I believe he is saying that
it would be bad to perform local mappings in any context, because
people often copy text from one place to another. While I can see how
such local mappings could create interoperability problems if the
mappings are applied recklessly, it would probably be OK to apply some
mappings in certain specific contexts, e.g. Turkish dotted/dotless
letter 'i' when the user is known to be expecting Turkish conventions.

Erik

> If I'm right about the above, I wonder whether it is a (new) layering
> violation; and if so, whether it's an acceptable one in the face of
> the alternatives.
>
> A
>
> --
> Andrew Sullivan
> ajs at commandprompt.com
> +1 503 667 4564 x104
> http://www.commandprompt.com/
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>


More information about the Idna-update mailing list