[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt
on 6/10/2002 3:05 PM John C Klensin said the following:
>>This doesn't hurt anybody and puts the i18n namespace on equal
>>footing with the STD13 namespace.
>
> Well, if you want to define it on a "per-name/ per-RR" basis,
> which is what both your statement and your examples seem to say,
> I think we are 95% there. We already have per-RR rules (e.g.,
> different name-formation rules for SRV than for A RRs)
Exactly. We already have:
<srvprep> SRV <...> <nameprep>
<nameprep> RP <mboxprep> <txtprep>
<txtprep> TXT <...>
<nameprep> SOA <nameprep> <mboxprep> <...>
Allowing <fooprep> FOO <barprep> isn't any different.
[snip]
> Would that meet your needs? Is that what we are really talking
> about?
I'm not sure I understand the suggestion. Can you rephrase it? I'm not
sure that itemizing the RRs which IDNA can/cannot be used with (as is your
suggestion, I think) will accomplish the ultimate goal, since the whole
idea is to be able to use IDNA for any owner name which requires
conversion, regardless of the profile used with that owner name.
The only change that I think needs to be made is the existing ~"must be
used with nameprep" statement be replaced with ~"this specification is
specifically intended to be used with domain names which have processed
through nameprep, but it may be used with any profile of stringprep which
specifies a domain name". The specific usage rules for profiles and their
IDNA interaction can be detailed in the RR-specific declarations.
AMC and paf seem to be intimating that the IDNA labels may not be
reversible, which may require an additional fixup if so, and if it is
possible. If it isn't possible then the discussion is moot. We might as
well stick with STD13 labels for i18n domain names at that point.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/