Subject: Re: [idn] Charter, refocus

From: Dan Oscarsson <[email-masked]>
Date: Sat, 24 Nov 2001 13:13:25 +0100

>
>I am trying to get an update on the proposed charter. Note that I am not
>disagreeing with you, but just trying to find out the differences
>between your RFC vs our proposed Action Item(s).
>
>> So what I see we need for DNS is:
>>
>> 1) An RFC stating the standard normalisation of domain names.
>>
>> 2) An RFC defining how domain names must be matched. As a minimum
>>    it must require case-insentive matching for characters with case.
>
>What is differences between your (1) & (2) vs
>
>"4. A standard track specification on normalization of domain name
>identifiers for the purpose of string comparisons. This document may
>include case folding, map outs, and prohibited characters."

The above may mean the same as my (1) & (2).
I wanted to make it clear that we should have one normalised format
for all domain names (both host names, and all other types).
This is to have a simple foundation for all software handling
text strings. Normalisation may not do case folding.
(1) is not only for comparisons of names, it is also for
easy character handling and analysis.

And the second should define how names are matched. That is how
what rules define which names match as equal.
For example: Abc.com and ABC.com match as equal.
This is done on top of the (1) normalised strings, when you need
to check if two domain names represent the same name.
The character manipulation you may do to compare names, may change
the name into something different than the "original" normalised
form.

>
>
>> When that is done, we can add:
>> 3) An RFC for ACE so we have a standard way to encode domain names
>>    in ASCII,  complying with the legacy "host name" character
>> restriction.
>
>What is differences
>
>"3. A standard track specification on an ASCII Compatible Encoding
>(ACE), to be used in the standard track specification on permitting
>international characters in domain names."

No difference. I just included all things to have all in there.

>
>> 4) An RFC updating what applications should accept as "host names".
>
>Hmm, how about modify Action Item 4 to
>
>"A standard track specification on normalization of domain name
>identifiers for the purpose of string comparisons. This document(s) may
>include case folding, map outs, and prohibited characters, and what is
>acceptable as host names."

You could, but I prefer to have the items as three different things.

1) is for how character data should be normalised everywhere.

2) is how compare domain names to see who are equal.

4) is what applications accept as a "host name".

In many parts of DNS only 1) is needed.
2) is used when comparing names.
4) is used by applications restricting character allowed for
"host names".

With the combined text above, it might result in one document
most see as only specifying host names instead of many things
common for all parts of DNS.

>
>> 5) An RFC how to layer ACE on top of the current DNS protocol to allow
>>    legacy software to handle new domain names (for example IDNA).
>>
>> 6) An RFC defining how DNS itself can handle UCS based domain names
>>    using UTF-8.
>
>Yours is a more specific action to
>
>"2.  A standard track specification on permitting international
>characters in domain names, including specifying any transition issues."

Yes, I wanted to be specific to make things clear and to avoid
missing something.

I have felt that we have had to much focus on just "host names".
Especially with my 1) and 2) I wanted a common base for
DNS to stand on, before going to specific issues like
what characters are allowed in host names.

   Dan

---

From: "Eric A. Hall" <[email-masked]>
Date: Sat, 24 Nov 2001 10:04:33 -0600

> to check if two domain names represent the same name.

Let's pursue this approach for a while and see where we end up. I see at
least two issues with this tactic:

First of all, not all domain names can be normalized.

STD13 allows octet codepoints to be specified, and for RRs like TXT or RP
or something similar, it is feasible to imagine that an RR exists with a
parent domain name that is using the eight-bit codepoints. These are
manageble via the \esc processing, but only if they exist as exceptions to
normalization. The codepoints MUST NOT be interpreted as character data
and normalized as such.

A different version of the above is using non-normalized IDNs for TXT and
other RRs which do not represent IHNs explicitly, which SHOULD be allowed
to use any UCS character code (even unassigned characters). However, this
isn't something people can do today, so not letting them do it in the
future is at least a legitimate option and possibly even a valid tradeoff
(EG, all RRs with IDN parents MUST use normalized IDNs; if you need
specific values, specify the octets with \esc). I do not like such
mandates (more precisely, I know that others will not like such mandates,
and I don't want to defend it).

Another example is email addresses, which some future rev of 2822 MAY
allow to be non-normalized. In theory, a normalized version of email
addresses should be supported but who knows what will happen. It seems to
me that the proper way to handle this data-type is to defer ownership to
RFC 2822 and its successors, rather than attempting to treat it as DNS
data (it isn't).

In the cases above, an RR of TXT (or some other type with a "binary"
usage) is created with a parent IDN in non-normalized form, so that entry
SHOULD match in its non-normalized form, and the normalized form SHOULD
NOT match since they are different sequences. Forcing normalization on
these entries will be wrong.

As for case-neutral comparisons, the biggest problem is with ACE, which
requires downcasing in order for the encoded representation to be
consistently matched in legacy systems. A query for Ex'AmPlE.com encoded
as zz-12345 will have a different representation than ex'ample.com at
zz-54321, which will be different from EX'AMPLE.com at zz--15243, etc. It
seems to me that downcasing is required and non-optional for delegation
entries and all other IHNs.

For the "binary" IDNs described above, case-neutral is forbidden anyway,
so we couldn't do it for those.

I just don't think that case-neutral comparison is an option, unless every
system decodes the values for comparison, which we know won't happen.
Legacy systems will not decode ACE.

What are your thoughts on the above? It seems that we cannot normalize
everything, and that we can't do case-neutral comparison on the IHNs that
are normalized. Am I missing something? I agree with the spirit of your
objectives, but I don't see any easy way to do it cleanly.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: "James Seng/Personal" <[email-masked]>
Date: Sun, 25 Nov 2001 14:46:32 +0800

Hi Dan,

Thanks. In other words, we are in agreement with the Action Items, each
one could have more than one RFCs. What you want is an detailed RFCs for
each Action Items. IMHO, we can put each RFCs into the goal & milestone
sections if and when we have those RFCs.

-James Seng