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

["Eric A. Hall" <ehall@ehsco.com>]

on 6/10/2002 1:29 PM John C Klensin said the following:

> Now IDNA (and friends) add a new class of rule, which is to
> permit giving different semantic interpretation to a label based
> on the _content_ of that label, e.g., whether applications are
> expected to map it to or from Unicode based on the presence of a
> prefix.

Actually what it does is require that all domain names be converted into a
lowercase and normalized form, even if the domain name is only supplied as
data in the resource record.

> Suppose Eric said, consistent with the typology above,
> that we should specify that IDNA (and that
> prefix-interpretation, nameprep, etc.) are to be applied only to
> particular RR types within Class=IN, or to all of Class=IN but
> not to Classes as yet undefined.   I'd be sympathetic to that: I
> think tighter and more conservative definitions (that can be
> expanded in the future if needed) tend to serve us well in the
> long term.

What I want to do is define this on a per-name/per-RR basis:

  <nameprep> A <address>

  <nameprep> NS <nameprep>

  <nameprep> MX <pref> <nameprep>

Those rules result in exactly the same usage as the current IDNA model.
I'm not asking to turn everything upside down. What I'm asking for is that
if an application needs to use an uppercase or non-normalized domain name
for some reason, that they be allowed to do so, but only after defining a
strong profile. Eg:

   <fooprep> FOO <barprep>

This doesn't hurt anybody and puts the i18n namespace on equal footing
with the STD13 namespace.

Nobody has yet told me why this won't work.

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