[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] Suggested clarifications of the IDN requirements doc
- To: Harald Tveit Alvestrand <email@example.com>
- Subject: Re: [idn] Suggested clarifications of the IDN requirements doc
- From: RJ Atkinson <firstname.lastname@example.org>
- Date: Wed, 09 Aug 2000 11:12:06 -0400
- Cc: email@example.com
- Delivery-date: Wed, 09 Aug 2000 08:36:17 -0700
- Envelope-to: firstname.lastname@example.org
At 10:34 09/08/00 , Harald Tveit Alvestrand wrote:
> The protocol MUST work for all features of DNS, IPv4, and IPv6.
> The protocol MUST support the following operations:
>- Mapping an IDN to IPv4 addresses
>- Mapping an IDN to IPv6 addresses
>- Mapping an IDN to an MX record
>The protocol SHOULD support the following operations:
>- Mapping an IPv4 address to an IDN
>- Mapping an IPv6 address to an IDN
>The protocol MAY support other operations.
>The protocol MUST NOT allow an IDN to be returned to a requester
>that requests the IP-to-(old)-domain-name mapping service.
>I suggest also that this requirement be moved to be [2.6] - I think it is critical for knowing what solutions can be allowed, and should be early in the document.
The proposed new text above is far too limiting.
For example, it is also important to also be able to map an IDN
to an MB record (for key management reasons; see RFC-2230; RFC-2230
is supported in BIND and in more than 1 IPsec implementation, btw).
For IDN to be really useful, it needs to fully support all
current DNS operations and mappings. If we don't require this,
the net result might be that IDN names are some sort of 2nd-class
component of the overall DNS, whereas we need for IDN names to be normal,
universally supported, 1st class components of the overall DNS.
We should retain the original text, except that it would be
prudent to add to the original text this one sentence from Harald:
"The protocol MUST NOT allow an IDN to be returned to a requestor
that requests the IP-to-(old)-domain-name mapping service."
That one sentence helps clarify the requirement that we don't break
existing deployed systems when IDN is deployed.