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

RE: [idn] draft-ietf-idn-requirements-04.txt



==========================
OLD:

> The form specified for most protocols using the DNS is a 
> limited form of
> the master file format domain name. This limited form is defined in
> [RFC1034] Section 3.5 and [RFC1123]. In most implementations of
> applications today, domain names in the Internet have been limited to
> the much more restricted forms used, e.g., in email.   Those names are
> limited to the ASCII upper and lower-case characters (interpreted in a
> case-independent fashion), the digits, and the hyphen.

-------------------------------
SUGGESTED NEW:

> The form specified for most protocols using the DNS is a 
> limited form of
> the master file format domain name. This limited form is defined in
> [RFC1034] Section 3.5 and [RFC1123]. In most implementations of
> applications today, domain names in the Internet have been limited to
> the much more restricted forms used, e.g., in email.  Those names are
> limited to the upper- and lower-case letters a-z (interpreted in a
> case-independent fashion), the digits, and the hyphen-minus, all
> in ASCII.

--------------------
REASON:
There is no "hyphen" in ASCII, but there is a hyphen-minus (but there
is a hyphen in Unicode: U+2010). Further, "the digits" here refers
to the digits in ASCII (there are lots more digits in Unicode).

==================================


> [11] Internationalized characters MUST be allowed to be 
> represented and
> used in DNS names and records. The protocol MUST specify what 
> charset is
> used when resolving domain names and how characters are encoded in DNS
> records.

I have no idea what "internationalised characters" are!  Is that
characters that have gone through an internationalisation reform
school?? ;-)  Suggestion: write "letters (and digits) used in
orthographies around the world" instead, or some other even better
formulation.

=================================

> [14] The protocol SHOULD NOT invent a new CCS for the purpose of IDN
> only and SHOULD use existing CES. The charset(s) chosen SHOULD also be
> non-ambiguous.

??? "charset(s) chosen SHOULD also be non-ambiguous"; what is meant by that?

Do you mean: "each of the charsets chosen MUST be unambiguous, and
which charset is in use MUST also be unambiguous for a given IDN"?
Otherwise I can't make sense of the requirement.

=================================

> The DNS has to match a host name in a request with a host name held
> in one or more zones. It also needs to sort names into order. It is
> expected that some sort of canonicalization algorithm will be used as
> the first step of this process. 

For the purpose of sorting (domain) names, for human consumption,
UTS 10 (Unicode Technical Standard 10) should be used.

But I guess a sorting that is not for human consumption is intended,
and then I guess any specific deterministic sorting can be applied
(like "binary" (code point) ordering after 'canonicalisation').  That
is, however, not clear from the requirements text.

=================================

		/Kent Karlsson