Comments on draft-ietf-idnabis-defs-10

Wil Tan wil at cloudregistry.net
Tue Sep 1 18:30:08 CEST 2009


On Wed, Sep 2, 2009 at 1:05 AM, Andrew Sullivan <ajs at shinkuro.com> wrote:

> On Wed, Sep 02, 2009 at 12:45:05AM +1000, Wil Tan wrote:
> > 2. If A-labels are not allowed to have uppercase ASCII characters, why do
> we
> > define case-insensitive comparison for them? An invalid A-label should
> not
> > be equivalent to a valid one. It should be as Paul suggested, i.e.
> > "case-preserving" (why not just "case-sensitive" as it's more
> > straightforward?)
>
> This one's easy: we're stuck with what DNS does.  A-labels are all LDH
> labels, and LDH labels compare for equivalence according to the
> case-insensitive matching rules defined as part of DNS (see STD13).
> Attempting to invent special rules for A-label matching will have the
> bizarre result that an IDNA-aware application will not match two
> "identical" DNS labels, even though an IDNA-oblivious application will
> match them.
>
>
Agreed. I'm not actually advocating special rules for A-label matching, just
pointing an inconsistency where label1 is a valid A-label, and is equivalent
to label2 which is an invalid A-label.



> > 3. We are "violating" (may be too strong a term, "contradicting" perhaps)
> > the underlying assumptions that DNS labels are case insensitive. There
> are
> > lots of deployed software that relies on that assumption. Domain names
> are
> > often presented (and perhaps stored) in uppercase by some registries in
> > Whois and EPP. I'm also worried about potential security issues that may
> > arise if the case insensitivity property is not preserved.
>
> Well, we haven't violated that, precisely because no valid A-label
> has, at least, an ASCII capital letter that will remain in the
> translation back to a U-label.  But the upper-cased version (or any
> mixed-case version) of the same A-label will still be DNS equivalent.
> It just won't be an A-label, it seems.
>
>
If the A-label qualification is just a definition, it wouldn't matter much.
But it's how we define registration and lookup behavior where A-label is
concerned that I'm afraid this could cause unintended consequences in
software implementations.

As it is currently defined, IDNA2008 protocol allows a conforming
applications to behave in different ways (even without mapping).


On Wed, Sep 2, 2009 at 1:10 AM, Vint Cerf <vint at google.com> wrote:

> andrew, the problem with that last point is that the two labels will
> match in DNS but produce different U-label on conversion.


One of those U-label is not valid though (since it contains uppercase
characters.)


> I think that
> is not a good outcome.
> downcasing would solve that wouldn't it?
>

I do think it would gives us the best compromise between the U/A-label
symmetry and being compatible with LDH matching rules. That said, I do
recognize that it is a change to the core protocol and that alone warrants
more thorough reviews.

I'm all for a path of least change, even if it is a compromise as long as we
understand the implications and make them clear in the specs.

=wil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20090902/bc740cd8/attachment.htm 


More information about the Idna-update mailing list