[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[idn] lowercased hostnames (was: naming syntax rules)
Dan Oscarsson wrote:
> 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.
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
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/