Mapping and Variants

[John C Klensin]

--On Friday, March 06, 2009 08:57 -0500 Andrew Sullivan
<ajs at shinkuro.com> wrote:

> On Thu, Mar 05, 2009 at 02:48:09PM -0800, Erik van der Poel
> wrote:
>> them. One is to always display domain names in lower-case.
>> Some organizations may not like this because they like to
>> advertise their domain names with certain letters capitalized.
> 
> Well, it's not just that "they may not like this".  It may be a
> violation of STD0013 -- specifically, the sentence in RFC1034,
> "When you receive a domain name or label, you should preserve
> its case." 1034 was before 2119, and that 'should' has always
> been interpreted as much stronger than SHOULD -- effectively,
> MUST.  So such a plan would require, I think, an explicit
> update of RFC 1034.

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.

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.

That view doesn't make the idea any more (or less) attractive --
please see my recent note where I suggested that we are down to
looking for the least stinky solution for transitions -- but I
don't think 1034 has much to do with the answer.

And, bluntly, some of the reason we are in this situation today
is that the DNS community largely took a "not our problem,
doesn't affect us" position when IDNA was being developed.
Some of the complaints from them today are ultimately about
consequences of that position.   That doesn't make the
complaints less legitimate, but it does impose some moral
obligation to get into the muck with us and try to help us work
out solutions, not just to point out problems.  You are really
the only one from that community who is trying to do that and,
while I very much appreciate it, the absence of the others
except as occasional complainers and distant threats on the Last
Call horizon is not a good sign.

> I appreciate, however, that what you're suggesting is not
> strictly a change to the DNS protocol -- it's really an
> operational convention for things before they go into the DNS,
> or after they come out.

Yes.  That is a different form of my observation above.

>  But to me, that just moves the
> problem around.  We're already running into this problem with
> IDNA, where I've been arguing both (1) that we need to be
> perfectly clear which parts of the protocol are about
> resolution as such (i.e. "none") and (2) that naïve users are
> going to treat several of the cases we know are _not_ matters
> of resolution as though they _are_ opportunities for
> resolution (this is the idea behind the term "resolution
> context".  But I hate the term).  Your proposal just moves the
> stakes around that problem, without attacking it head on.

We are doing a lot of that lately (Erik is certainly not the
only one).

    john