Subject: Re: [idn] naming syntax rules

From: Dan Oscarsson <[email-masked]>
Date: Mon, 10 Dec 2001 12:17:52 +0100

>> >The basic idea here is to declare formal data-types for labels, and
to
>> >incorporate the data-types into syntaxes for applications and
protocols to
>> >use when they need to interact with domain names.
>>
>> While this is good, to make DNS really work the foundamental
>> rules should be the same for all labels. Just like it has been
>> so far.
>
>No, DNS has two rules: octet strings with ASCII, and a hostname subset.

The DNS standard only have one type of label: octet strings with the
code
values 0-127 treated as ASCII during comapring.
The DNS server do not have a hostname subset and may not reject
any name not following it.

For DNS, an A, TXT or SRV record can all contain any octet sequence.

As said in RFC 2929, in practice the labels are text using ASCII even
though
the standard allows any octet value.
Just like the host name rule have been updated several times, the DNS
octet label could now be defined to be just printable text (using UTF-8)

without breaking very many programs. If you add that invalid UTF-8
sequences are treated as just octets even less will break.

>Mailbox names must be case-preserved in order to satisfy protocol
>dependencies, and are not used in lookups so normalization is not
required.

Normalisation is still needed, otherwise may some clients interpret
the name as something else. I could use the ASCII range to encode all
characters I need for Swedish and use that in labels, but you would
not get the right name if you assume they are ASCII.
That is why character data must be normalised.

>Host names have no such dependencies. STD13 defines domain names as
>case-neutral, and enforces this through case-neutral comparison
operations on
>the servers. However, making host names case-neutral will require a new
ACE,
>or will require that every possible case combination be delegated and
managed
>simultaneously. As such, case-neutral comparisons can still be
performed, but
>should be done at the resolver instead of at the server.

Just like some systems have case-sensitive mailboxes, some systems have
case-sensitive host names (Unix is one of them). So you need to retain
case to avoid breaking them.

>The current delegation rules prohibit it. STD13 hostnames are currently
a
>subset of IDN and that should be preserved where possible. Essentially,
this
>change would mean ~"if all of the characters in the delegation are LDH,
then
>the minimum length is 2 characters, otherwise it is one character."

I do not know what you mean by current delegation rules. In .com domain?

Some domains allow 1 character subdomains.

>
>There is no comparison on mailbox names. Mailbox names are not
specified in
>any queries. For RR data, they must be provided in case-sensitive form,
but by
>the same token they must also be non-normalized until the successor to
2822
>says which normalization to use.

RFC 2822 only have ASCII mailboxes.  ASCII is normalised. So there can
be no
non-normalised until we get UCS in mailboxes.

   Dan

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 10 Dec 2001 10:45:57 -0600

Dan Oscarsson wrote:

> code values 0-127 treated as ASCII during comapring.

This is what I meant by my followup message yesterday when I said that we
are probably in agreement here. The proposed syntax rules only define one
"domain name" syntax (non-normalized, non-lowercased, any UCS code), but
there are several application-specific subset definitions.

Note that the subset definitions are either implicitly and explicitly
defined for STD13. For example, the mailbox rules are not defined in STD13
but instead section 8 of RFC1035 kinda sorta delegates the rules to
RFC822. The difference here is that the IDN rules (should) explicitly
declare the mailbox rules as being defined by the local-part definitions
in 2822.

Anyway, I don't think we're in disagreement on this part.

> That is why character data must be normalised.

If an i18n successor to 2822 allows encoded versus unencoded mailbox names
to collide, it will have failed.

Under the current rules, they can only contain US-ASCII, must be
case-preserved, so that is all we should worry about. If/When the mailbox
rules are changed, they should be backwards compatibile. If we enforce our
own biases and rulesets on these names -- even though it is not our area
of responsibility -- we will impose additional considerations on the
successor to 2822. We do not have any authority to do so, have no
technical justification for doing so, and therefore we must not do so.

> case to avoid breaking them.

I want to call out this topic for discussion separately.

> > this change would mean ~"if all of the characters in the delegation
> > are LDH, then the minimum length is 2 characters, otherwise it is
> > one character."
> 

I was looking through ICANN's site for a canonical reference on this point
and cannot find one. However:

  a) you cannot register a.[com|net|org]

  b) some of the new gTLDs have minimum length rules of 3 characters,
     and not just two characters

  c) I haven't ever seen any ccTLD take 1 char delegations but I will
     believe you.

Since those three points are non-normative and no canonical ruleset exists
to reference (that I can find), I would say that we should redefine this
rule to be a minimum of 1 character, with the disclaimer that delegation
rulesets may be different. If com|net|org still only accept 2 chars in
delegations then that will be their issue to deal with.

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

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 10 Dec 2001 11:59:58 -0600

> case to avoid breaking them.

Let's break this down into discernable components (for my benefit at the
very least).

Forward-lookups on hostnames which are stored in the DNS are currently
treated as case-insensitive. This will not change under the proposed
syntax rules; the difference will be that the case-neutral comparison will
be performed by the requesting application, rather than the server.

EG, if the application sees a URL for an IDN equivalent of
<IDN>.eXaMpLe.CoM then it will normalize and lowercase for query
construction purposes to <idn>.example.com, which will match at the
server, and answer data will be returned. The application can still use
<IDN>.eXaMpLe.CoM for the URL, and only had to convert the domain name for
the lookup operation.

The problem scenario arises with hostnames which are provided as data and
which enforce the host label data-type in those rules. In the example
above, it would mean that programmatic generators would be encouraged to
provide the i18n URL as <idn>.example.com (although <IDN>.eXaMpLe.CoM
would still have to be supported because an end-user may type it into a
message that way), and that the HTTP HOST headers would probably need to
use the normalized/lowercased form (assuming it procesed the i18n hostname
in unencoded form).

In the case of DNS, this problem could also appear with RR data with CNAME
or PTR RRs. Another problem data stream is DHCP options (this is probably
the most damaging scenario).

This is pretty much the scope of the problem: does mandatory lowercased
hostnames in these streams break existing systems?

One other point of consideration here is that there is a difference
between legacy hostnames and i18n hostnames. A hostname which is made up
of LDH *MUST* be treated as case-neutral. However, this is not necessarily
required for i18n hostnames. While it would be unfortunate to mandate that
all i18n hostnames MUST be lowercased, it is at least a valid option (it
is the current mechanism anyway). This would introduce another element to
the rule, which is that US-ASCII must NOT be case-converted, while all
other instances of the host label MUST be.

Another option is to figure out a way to make ACE case-neutral.

Comments from the gallery please