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

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



on 7/4/2002 9:37 AM Erik Nordmark wrote:
>> There are already profiles described for iSCSI names and Kerberos
>> realms.

> Correct me if I am wrong, ut I didn't think they were going to use
> IDNA; neither iSCSI names or kerberos realms are domain names (they
> have different syntactic restrictions as far as I knpw) and IDNA is
> about domain names.

I don't know about iSCSI but Kerberos can be used with a new RR quite
effectively. Google for draft-ietf-krb-wg-krb-dns-locate-02.txt for an
example of how they were using TXT RRs to determine the realm associated
with a domain. Although they use TXT (this was to avoid compression which
would cause case-conversion, and is avoidable through other means) but it
is still a domain name and gets used to seed subsequent lookups.

As to whether or not these are valid domain names, sure they are. A domain
name is any series of labels that can be exchanged in a DNS message
(resulting in either a referral, an answer or an error). Certainly these
are more valid than the pseudo names generated with TKEY and TSIG.

As to your comment that these are not domain names since they are not
defined by nameprep, my position is that nameprep is misdefined. In its
current form, IDNA is about i18n hostnames, and there are other kinds of
domain names which can be exchanged but which cannot be represented with
nameprep (see the TKEY and TSIG logical domain names again).

>> Requiring new codecs for new profiles is all cost and zero benefit.
>> What possible value is there in forcing applications to define new
>> codecs with different outputs for their alternative names?
>
> The "codec" is punycode, right? If not, what is your definition of
> "codec"?

The IDNA codec is punycode with the IDNA prefix identifier. Without the
identifier, the data is not IDNA.

It's really simple: IDNA should just be a codec that generates IDNA label
output from UCS input (and vice-versa) and which supports any Stringprep
profile, while Nameprep should just define the i18n hostname profile. I've
been saying this for two years now.

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