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

Re: [idn] I-D ACTION:draft-ietf-idn-nameprep-07.txt



I wrote:

> There are some code points that are prohibited in host names, but not
> in all textual domain names.

"Eric A. Hall" <ehall@ehsco.com> replied:

> These include the octet values to which I was referring.  Just as a
> domain name can include underscore and period, it can also include the
> codepoint values for NUL, BS, CRLF, or any other value in the range of
> 0x00-0xFF.
>
> Unless you are planning to update STD13, all octet values need to be
> passed for non-hostname domain names.

Let's not confuse code points with octets.  Nameprep does not input or
output octets.  It inputs code points and outputs code points.

STD13 says that domain labels, in the broadest sense, are sequences
of octets, each of which can have any of the 256 possible values for
octets.  Domain labels in this broadest sense may or may not be text;
the octets can, in theory, be used to represent anything.

Depending on what the domain labels are being used for, some of those
256 possible octet values might not get used, even though STD13 allows
them.  For example, when domain labels are used as host labels, only 63
of the possible 256 values get used (the ones corresponding to the LDH
characters).

Similarly, when domain labels are used as IDNA internationalized text
labels, not all 256 octet values get used.  Only the values that can
be output by ToASCII get used.  Clearly, the values 80..FF can never
be output by ToASCII.  Furthermore, because of the prohibitions in
nameprep, the values 7F and 0..20 also cannot be output by ToASCII.

Even though ToASCII never outputs the values 80..FF which are allowed
by STD13, that obviously doesn't mean that ToASCII is broken.  Avoiding
80..FF is the entire point of ToASCII!  Similarly, even though ToASCII
never outputs the values 7F or 0..20 which are allowed by STD13, that
doesn't mean ToASCII (or nameprep) is broken.  IDNA simply doesn't need
those values in order to represent the things it's designed to represent
(internationalized text labels).

If you want to argue that nameprep shouldn't prohibit some of the
code points it's currently prohibiting, you'll need to come up with a
different argument.  Invoking STD13 doesn't help.

AMC