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/
