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

[Erik Nordmark <Erik.Nordmark@sun.com>]

> 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. 

Thanks for the pointer - I could only find draft-ietf-ips-iscsi-string-prep

> 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.
 
> 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.

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.

[Note that I don't think that the use of _kerberos.<domain> names and txt
records have been discussed on namedroppers, and nothing in this email
should be construed as I think this is a good idea.]

Thus the kerberos folks can choose to standardize I18N realm names
and define a new stringprep profile (or use an existing one) and specify
that this applies to their TXT records at _kerberos.<domain>
I wouldn't be surprised if they wanted a profile of stringprep that does not
do case folding.

> As to your comment that these are not domain names since they are not

What does "these" refer to? The NAME or the content of the TXT RDATA?

> 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).

SRV is a better example since it explicitly violates the STD3 host name rules
with the leading underscore. TKEY and TSIG doesn't require domain names
to be outside the host name rules, nor does it require that they follow the
host name rules.

> >> 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.

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.

> 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.

While I understand the need for different profiles of stringprep for different
types of names, identifiers, and protocol elements, I still don't see a clear
case where a different profile would be required for *textual domain names*.

The textual domain names that do not conform to the STD3 host name syntax
rules (such as the NAME for SRV records) can be accomodated by not
setting the UseSTD3ASCIIRules in IDNA.

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.

  Erik