Re: Matching and comparison

[Paul Hoffman / IMC <phoffman@imc.org>]

At 12:19 PM 1/20/00 +0900, Martin J. Duerst wrote:
>         Filename        : draft-skwan-utf8-dns-00.txt

Yes, there is an -02 version that is still active.

It blithely ignores any problems it creates, such as destroying Internet 
mail and any program that uses URLs...

> > This wouldn't break the current DNS system if we had different rules for
> > internationalized names than we have for the current all-ASCII names 
> and an
> > easy way for systems to tell the difference between the two. This is 
> what I
> > would propose for a protocol. But there's no need to spell this one out in
> > the requirements, I think.
>
>How would you tell the difference?

By tagging internationalized names. This is now moving from requirements to 
protocol. But it would be easy to do in a backwards compatible way for some 
protocols.

>  And would it really make sense?

Yes. Unless we can definitively specify the transformation (probably during 
normalization) for how to do case-insensitivity, we need to allow 
case-sensitivity. Further, the lack of case sensitivity is a historical 
aberration based on the fact that some input devices couldn't do lower-case 
ASCII. We don't need to carry that forward (although we can certainly chose 
to).

We're trying to open up the DNS to more people. For some of them, it is 
insulting to require a particular case that does not match their naming 
conventions. Unless we can show a need for case-insensitivity *in the 
internationalized characters*, we shouldn't force it.

>Assume I have mycompany.com, which is case-folded, i.e. Mycompany.COM
>gets me to the same place,, and now I create Du"rst.mycompany.com,
>and suddenly Du"rst.Mycompany.COM isn't found anymore?

Wrong question: mycompany.com isn't internationalized. The question should 
by "Does it make sense to have Dürst.com be different than dürst.com?" I 
believe it does if it doesn't affect the case-insensitivity of any 
non-internationalized names.

Again, I believe this is a protocol issue, not a requirements issue. I 
don't see the need for a requirement about casing, other than a requirement 
that however the protocol deals with casing, it cannot break the rule for 
case-insensitivity in current names.

--Paul Hoffman, Director
--Internet Mail Consortium