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

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

on 7/4/2002 11:30 AM Erik Nordmark wrote:

>> 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.
>
> The RDATA of the TXT record is a kerberos realm name according to the
> draft.

From what I understand, the realm is sucked out of the TXT RR, and is then
used to generate the SRV lookups.

 | Overview - KDC location information
 |
 |   KDC location information is to be stored using the DNS SRV RR [RFC
 |   2052].  The format of this RR is as follows:
 |
 |   Service.Proto.Realm TTL Class SRV Priority Weight Port Target

 |   The Realm is the Kerberos realm that this record corresponds to.

This is a very problematic design on multiple fronts, but I bring it up to
demonstrate the point that people want to use Kerberos realm names as
domain names. By the same token, people will want to store NetBIOS names
in the DNS as well (see STD19). And so forth.

> The QNAME is clearly a domain name. The RDATA in the text record is not
> - it is a case sensitive realm name. Thus QNAME would be subject to
> nameprep when IDNA is used. TXT records are not domain name slots thus
> IDNA does not apply.

IDNA does not apply to this model *YET*, but if they go to a custom RRtype
that stored the realm then the question of using IDNA would apply.

As for the qname question, note that the STD13 model would preserve the
capitalization on subsequent queries, while the IDNA model will burn the
capitalization during mutation if IDNA always requires nameprep.

Furthermore, see draft-hall-dns-datatypes for an inventory of currently
registered RRs. There are several RRs which do not use hostnames for the
owner name. These kinds of uses have to be allowed for.

>> The IDNA codec is punycode with the IDNA prefix identifier. Without
>> the identifier, the data is not IDNA.
>
> Then I don't understand why you claim that a new codec is needed for
> new profiles. The IDNA prefix and punycode could be used for other
> profiles as well.

> I'm concerned that having a standard which leaves the door completely
> open with "use any stringprep profile" is exactly the type of loose
> definitions that have gotten us into trouble in the past. Specifying
> different profiles for different usage doesn't have this problem.

Under the current wording, only the nameprep profile is allowed.

I am strongly in favor of profiles. What I am specifically arguing against
is the restriction in IDNA which prohibits the use of the codec with
anything other than nameprep:

 |  2. Perform the steps specified in [NAMEPREP] and fail if there is
 |     an error.

 | IDNA requires that implementations process input strings with
 | Nameprep [NAMEPREP], which is a profile of Stringprep [STRINGPREP],
 | and then with Punycode [PUNYCODE].

Nameprep is the only profile which can be used with IDNA.

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