Re: [dnsext] does making names the same NEED protocol changes at all?

[Andrew Sullivan <[e-mail]>]

No hat.

On Fri, Feb 25, 2011 at 10:51:48AM -0800, Nicholas Weaver wrote:
> It is ONLY a point of failure for NeW MiXED CasINGs which appear.  Old ones remain cached.
> 

I'm not exactly sure how you decided that mixed case was a problem we
were going to solve anyway, but let me disabuse you of this.  In the
interests of allowing people to think about the issues, I haven't shut
down the case discussion, but maybe I should have.  It's not something
we actually need to solve.

First, remember that we're actually trying to solve problems in the
DNS generally, and not to solve particular linguistic issues, since we
don't have the expertise for that.  (Indeed, that we're wasting time
exploring this rathole is evidence of it, since a large number of the
"variant" cases for which we might need a solution don't have anything
to do with case.  Chinese, to pick the obvious example, isn't even
alphabetic.)

Now, there simply is no problem in English: mixed case already
matches.

The rest of the possible target cases occur under IDNA.  And in IDNA,
there is no problem of case.  IDNA2003 maps all upper case to lower
case, and does the lookup.  Under IDNA2008, upper case is simply
DISALLOWED, so it never gets looked up.  It is presumed (but not
actually part of the protocol) that applications will do
locale-appropriate case conversion prior to lookup.  (Note that there
are important subtleties involved here that I am quickly waving away
as detail, but which matter up in the application layer.  For
instance, downcasing, upcasing, and normalization for comparison might
yield different and, to anglophones, surprising results.)

There are problems which happen to have their expression in the
results of case conversion.  

In Greek, there is one GREEK CAPITAL LETTER SIGMA, but GREEK SMALL
LETTER FINAL SIGMA and GREEK SMALL LETTER SIGMA.  In upper case a
sigma in the final position will be the identical Unicode code point
to an upper case medial form sigma; but when they are downcased, one
of those should become one code point and the other should become
another code point.  This _is_ a problem.  People might try to look up
a label, [GREEKLETTERS][GREEK CAPITAL LETTER SIGMA].  Now you need to
have [greekletters][GREEK SMALL LETTER FINAL SIGMA] and
[greekletters][GREEK SMALL LETTER SIGMA] mapped to one another
transparently, because it is unpredictable what will actually be the
U-label that gets converted to the A-label before it gets looked up
when the application maps [GREEKLETTERS][GREEK CAPITAL LETTER SIGMA].
(Or rather, it might be.  The applications might actually all do this
correctly, for all anyone knows.)

But as you can see, we can discuss all of that without recourse to the
specifics of the language, since the actual issue is that a zone
administrator knows a label to label mapping of the items.

Clearer now?

A

-- 
Andrew Sullivan
[e-mail]
Shinkuro, Inc.
_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext