No case change in DNS (was: Re: Mapping and Variants)

[Martin Duerst]

At 03:27 09/03/07, Andrew Sullivan wrote:

Hello Andrew,

Can you shed some light on the "don't change case"
provision in RFC 1034?

In my understanding, it would make very much sense during
registration. It could also make sense for the eventuality
that some parts of the DNS don't do case-equivalent lookup.
(Don't know whether there is currently such a case.)

[it seems that was the original motivation; RFC 1034,
on page 8, says:
                                      The rationale for this choice is
that we may someday need to add full binary domain names for new
services; existing services would not be changed.
]

However, it definitely does not make sense, and isn't
respected, e.g. in a Web context. I just typed in
http://wWw.W3.OrG/ into my browser, and after a return,
I got back the page, and http://wWw.W3.OrG/ was changed
to http://www.w3.org/. After all, the point of entering
(for non-IDN domain names) the case variant preferred
the registrant into the domain name system is just so that
this can be shown to an end user after lookup, or not?

Also, similar mappings are done over and over by Web caches
and spiders even without any resolving activity. It increases
efficiency too much to not be done, even if it would be
prohibited in some RFC.

In the context of the present discussion, wouldn't the only
thing that would be happening, even if we went for "lowercase
when you can" rather than just the "strongly discourage
upper case" as proposed by John, be that what happened
above on resolution was just 'pre-applied' in a Web
context, where (ASCII) case equivalence is baked into the
specs, see e.g. Section 3.2.3 of RFC 2616 (HTTP) and 3.2.2
of RFC 3986 (URIs).

Regards,    Martin.


>On Fri, Mar 06, 2009 at 12:13:35PM -0500, John C Klensin wrote:
>
>> Well... A different way to look at this is that you can have all
>> of the case sensitivity, case-independent matching, and case
>> preservation you like in A-labels (as well as all other labels
>> that contain ASCII characters and maybe some others).  IDNA does
>> not change the DNS.
>> 
>> A different way to state Erik's observation/suggestion would be
>> that, in IDNA-aware "slots" use (on registration, lookup,
>> storage in files, etc.) of anything but lower case needs to be
>> really strongly discouraged.   That would imply that, in a given
>> "slot", the decision that IDNA can be used is a decision that
>> upper case is discouraged and violence may be done to it if it
>> appears.  That is an application-layer design tradeoff, not a
>> statement about the DNS or a problem for 1034.
>
>Actually, putting something like those two paragraphs together might
>make this idea rather more palatable.  The more I think about this the
>more I think it has a certain appeal.  It has slightly odd effects,
>because the traditional DNS case-preservation does go all the way
>through an IDNA-unaware application, and does _not_ go all the way
>through an IDNA-aware application.  I am going to post a note to
>various dns weenies I know to try to get review of exactly this
>suggestion, because it does seem to be a way forward.
> 
>> FWIW, 1034 could easily have contained a statement to the effect
>> that one MUST NOT take a label that one receives, map it through
>> a local (as in client-side) aliasing process and then look the
>> result up as if it were the original label.   Presumably it was
>> omitted because, at the time, everyone thought it was obvious
>> (and they probably still do).  But, if 1034 prohibits a strong
>> application and registration preference for lower-case native
>> character strings in IDNA, that implicit statement would
>> prohibit any IDNA mapping at all.
>
>True.




#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst at it.aoyama.ac.jp