Comments on draft-ietf-idnabis-defs-10

Wil Tan wil at cloudregistry.net
Tue Sep 1 16:45:05 CEST 2009


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

> On Mon, Aug 31, 2009 at 11:00:40AM -0400, John C Klensin wrote:
>
> > Without these changes, the definition of U-label is clear, the
> > definition of A-label is clear, the two are obviously symmetric,
> > and we don't have issues of
> > U-label-except-with-some-upper-case-characters.  Encouraging the
> > latter muddies, and will probably require review, of the other
> > definitions.
>
> Then see the part of my mail that you cut out: since a valid U-label
> can never have upper case ascii characters in it anyway, what's the
> worry?  We've already defined the problem away, it would seem.
>
>
Yes, that's what I perceive from reading the drafts too but several
ambiguities exist in my mind (see below.)



> I think the problem Wil is identifying is that we haven't really
> defined this away, because implementations may choose not to do all
> the validation steps, and therefore lookups will be allowed that in
> some cases will sometimes succeed, even though they shouldn't.  Right?
>
>
Yes, this is one of the issues I'm trying to raise:

1. Consistency of lookup behavior when input appears to be an A-label:
different applications can be conforming to IDNA2008 and yet produce
different results due to the optional punycode decoding step in
idnabis-protocol, 5.3.


Other perhaps more subtle points:

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?)

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.

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


More information about the Idna-update mailing list