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

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

The kerberos client needs know the (case sensitive) realm name to use it
in the kerberos protocol. This must be what drives the requirement that the
RDATA of the TXT not be case folded.
In addition, the kerberos client can use it to form SRV lookups, but if
that was the only use there would be no requirement that the RDATA preserved
case.

Hence the RDATA is a realm name. The realm name can be usd to form a SRV
lookup.

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

It the RDATA in such an RR said it was a domain name, then IDNA would
apply. If the RDATA in such an RR was specified to be a realm name, then IDNA
would not apply. Thus in the latter case (which is what would make sense
due to the sensitivity of the realm names) then the definition of such a record
could choose to whatever it wants (including use realmprep and punycode with
the IDNA prefix; or use realmprepped UTF-8).

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

But IDNA (ToASCII) doesn't always require nameprep; it isn't required for
all-ASCII labels. So I don't understand the point about "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.

Agreed. 
Which ones do not work with IDNA in practise as IDNA is currently defined?
As far as I can tell all textual labels work with IDNA and IDNA explicitly
does not apply to non-textual labels.

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

Perhaps you could suggest alternate wording.
I'd like to understand how you can state something different
without resorting to "anything goes" given that there aren't other 
standardized (or ready to standardize) profiles to which IDNA could have
a normative reference.

   Erik