[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt




"Adam M. Costello" wrote:

> Maybe you are using the term "domain name" in a more general sense
> than the rest of us, but domain names are compared in a particular way
> (for example, they are case insensitive) and are subject to certain
> constraints (for example, their labels do not exceed 63 bytes).

I don't want to get pedantic about this, but you are incorrect.

Queries treat labels as case-insensitive for comparison purposes but the
data is not case-neutral. Data must be provided in the capitalization it
was entered. There are applications which are picky about case, and this
is supported by STD13. This says nothing about the interpretation of
binary data in the eight-bit range.

Length has not and will not be an issue in the same way as capitalization,
but you are wrong about that as well. The official hostname syntax has at
times defined minimum and maximum lengths which were different from the
domain name restrictions. EG, maximum of 24 characters for hostnames in
RFC 952, even though 63 character domain names were allowed in DNS by RFC
883. These were both synchronized to 63 characters max in RFC1123 although
they still have different minimums.

> If an
> application's identifiers conform to all the rules for domain names,
> they can be called domain names, but if they have their own syntax rules
> that are incompatible with domain names (for example, if they are case
> sensitive or if they contain strings longer than 63 bytes) then they are
> not domain names.

A domain name is any sequence of labels that can be stored in the DNS. An
i18n domain name should be any sequence of labels which can be encoded
with IDNA. Currently, you are recursively defining i18n domain names as
anything which complies with nameprep, even though we already know that
there are applications which will not do so.

> > Under the current wording, all of the applications must use the
> > nameprep rules to use IDNA encoding, even if those rules are not
> > applicable to the application at hand.
> 
> If the email folks want to use something similar to IDNA for email
> address local parts, they can.

At least naming it will be easy: yacm  [yet another codec for mail]

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