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

From: John C Klensin <[email-masked]>
Date: Mon, 03 Jun 2002 08:31:42 -0400

--On Thursday, 30 May, 2002 11:01 -0500 "Eric A. Hall"
<[email-masked]> wrote:

> John C Klensin wrote:
>> 
>> The disagreement between kre and myself about how to read  the
>> spec is, indeed, I think the key to this issue.  It should be
>> noted that we disagree about two things, which are separate:
>> 
>> (i) Whether the correct reading on the DNS specs is that
>> "ASCII" versus "binary" is a function of RR type, or a
>> function of the bits in the octets. I take the text to
>> suggest that _only_ ASCII (note, ASCII, not LDH) is permitted
>> in RR types defined in or by 1034/1035, but that "future" RR
>> types (and Classes) can be defined to have binary labels.
>> Robert takes it as permitted characters outside the ASCII
>> range, with case handling undefined for those characters.
> 
> You are both correct, but Robert is more correct. Note that
> Robert didn't disagree with you "future" use. Essentially this
> boils down to having biblical scholars arguing over how MUCH
> they should love their neighbor.

Well, I'm not sure, partially because I am not convinced that
1034/1035 permit (or require) an octet-by-octet interpretation.
See below.  Also, in the robustness principle, we have a rule,
applicable to the DNS as to other Internet protocols, that
governs the model for loving one's neighbor especially in cases
of ambiguity.

> There are three elements here:
> 
>   1) The lower seven-bit range is definitely interpreted as
> ASCII.

For RRs whose labels are character strings, yes, certainly.

>   2) The upper eight-bit range is definitely undefined for
> those RRs      and classes which do not have an
> interpretation. While some new      RR and/or class could
> define an interpretation for the eight-bit      range, the
> existing RRs in the IN class treat this range as
> undefined values.

Yes.

>   3) STD13 is quite clear that queries may contain eight-bit
> codes.

Yes.  The question is whether this is appropriate (given both
STD13 and the robustness principle) for RRs with character
labels (i.e., the "existing" RRs in Class IN) for for an query.
Or, put differently, while it is clear that eight-bit codes can
be sent in a query (given the query structure and the ability to
specify "ANY" as a query type, any other conclusion would lead
to contradictions), it is not clear how a server should
interpret such a query when it would match an RR with a
character label.

> So, taking all of the above into consideration, how do you
> treat the eight-bit codes for existing RRs in the IN class,
> where an interpretation has not been defined? You have to
> treat them as undefined. Since they are undefined, they are
> not alphabetic, and the non-alphabetic comparison rule kicks
> in.

As has been pointed out, "undefined" means "undefined" and,
given interoperability and the robustness principle, something
that should not be (attempted to be) used.  It doesn't mean
"non-alphabetic" -- that constitutes defining it.  I believe
that loving my neighbor, under the robustness principle, implies
that I don't send that neighbor stuff that is undefined.  And I
believe that, under robustness principle, that neighbor should
_accept_ anything I send it, but that its responses should avoid
returning as a match anything that might not actually be a
match, i.e., that something that is "undefined" doesn't match at
all, regardless of the bit patterns.

> Whether or not any of these RRs allow eight-bit codes to be
> defined is a totally different question, but one which was
> answered in the affirmative by RFC 2181.

Yes.  But in language that, given the matching rules and the
above interpretation of "undefined" (which I would claim is our
historic one), becomes almost as unclear as that in 1034/1035.

> So, unless a new RR or class (or EDNS tag, or whatever)
> defines some specific interpretation, the eight-bit codes are
> to be treated as undefined codes, and must match exactly.

Or, with equal or greater justification, "... to be treated as
undefined codes, and not matched at all".

      john

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 03 Jun 2002 10:41:02 -0500

John C Klensin wrote:

> "non-alphabetic" -- that constitutes defining it.

They are "undefined" for interpretation, but they are "defined" as
eight-bit code values for the purposes of storage and transfer.

Consider the lowly cache. What if a client and server exchange eight-bit
domain names linked with an expiremental RR which the cache knows
absolutely nothing about? What if eight-bit owner names are explicitly
interpreted for that RR? Clearly there is only one interpretation that
works in the distributed model.

I suppose you could argue that the ~standard RRs from STD13 are special
and do not have any such meaning, although I would argue against it. You
could also argue that sending eight-bit codes with the ~standard RRs from
STD13 is a bad idea but not prohibited and I would agree with you.

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

---

From: John C Klensin <[email-masked]>
Date: Mon, 03 Jun 2002 15:38:31 -0400

--On Monday, 03 June, 2002 10:41 -0500 "Eric A. Hall"
<[email-masked]> wrote:

> They are "undefined" for interpretation, but they are
> "defined" as eight-bit code values for the purposes of storage
> and transfer.

ok

> Consider the lowly cache. What if a client and server exchange
> eight-bit domain names linked with an expiremental RR which
> the cache knows absolutely nothing about? What if eight-bit
> owner names are explicitly interpreted for that RR? Clearly
> there is only one interpretation that works in the distributed
> model.

No, there are two.  One is your interpretation, i.e., that all
labels are to be construed as character strings, with ASCII and
case mapping behavior in 0x00-0x7F and exact matching otherwise.
The other is that true binary labels are permitted by the DNS
spec: if they are, then 0x00-0x7F had better not be case-mapped
and a cache must know how to interpret an RR in order to answer
a query on that RR.

I.e., my reading of RFC 1035, section 2.3.3, "Character Case",...

		For all parts of the DNS that are part of the official
		protocol, all comparisons between character strings
		(e.g., labels, domain names, etc.) are done in a
		case-insensitive manner.  At present, this rule is in
		force throughout the domain system without exception.
		However, future additions beyond current usage may need
		to use the full binary octet capabilities in names,
		[...]

is that "full binary octet capability" implies not only that
those bits might be turned on, but that comparisons might be
required to be binary (i.e., exact) ones, even within the
0x00-0x7F range.

> I suppose you could argue that the  ~standard RRs from STD13
> are special and do not have any such meaning, although I would
> argue against it.

And we would certainly continue to disagree, since I read "all
parts... that are part of the official protocol" and "at
present... However, future additions beyond current usage..." as
saying exactly that.  This is reinforced, for me, by section 3.1
of RFC 1034, which says, in part

		but domain name comparisons for all present domain
		functions are done in a case-insensitive manner,
		assuming an ASCII character set, and a high order zero
		bit. 

and

		The rationale for this choice is that we may someday
		need to add full binary domain names for new services;
		existing services would not be changed.

which appears, to me, to constrain those "existing services"
(which I take to be those "standard" RRs in Class IN) to ASCII.
That interpretation makes non-ASCII octets in _their_ labels a
protocol violation, not merely an "undefined" state -- see below.

Now a slightly different reading of 1035 -- and, in particular,
its syntax references to "character strings" -- globally
prohibits binary labels (e.g., numbers with values > 255) as
distinct from octet strings which might have the high bit of
such octets set.  That would, I think, be an unfortunate
restriction on future extensibility, but it makes things a bit
less complicated.  But I can't get from "they are all
characters" to "case-map ASCII graphics only, and exact-match
everything else" -- it appears to me that matching rules for the
above 0x7F range would then be strictly undefined until rules
are standardized for their interpretation (in the existing RRs
or otherwise).  The advantage of that "character string" reading
is that it would be possible to write RFCs that specify how
those "high bit" octets should be processed.  If "full binary"
is permitted, then I think such octets are prohibited forever in
the vintage-1035 "standard"  RRs.

> You could also argue that sending eight-bit
> codes with the ~standard RRs from STD13 is a bad idea but not
> prohibited and I would agree with you.

I would accept that argument and then note that the robustness
principle slides [generally] "sending [is a] bad idea" into
"prohibited" rather quickly.

   john

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 03 Jun 2002 15:15:40 -0500

> The other is that true binary labels are permitted by the DNS

There is no such thing as a true binary label as far as the DNS transfer
protocol and/or storage subsystem is concerned. Where there is a mapping,
it occurs within the realm of the application that is using DNS, and not
within the DNS network service itself.

That is the only way which allows *any* new usages to be defined.
Otherwise, no systems could ever tell what format *any* domain name was
stored in. Not only would this include interpretations of eight-bit
characters, but it would also include any case-specific ASCII alphabetic
mappings which might be required for a given RR.

For example, NB that RFC 1035 defined case-specific owner names for MB,
MG, etc, but even those are compared using the simple rules. If we had
different storage rules for "binary" then those RRs would have to be
treated special, but they are treated the same as every other RR.

Furthermore, nothing like those RRs could _ever_ be defined and deployed
again unless the entire Internet architecture were upgraded to support
that specific RR. Also keep in mind that caches are not the only
transparent boxes on the network. Many DNS servers also allow new opaque
RRs to be defined as simple octet streams. Deployment of new RRs
practically depends upon this feature.

The notion that there is such a thing as a special "binary" label is
partly the fault of the DNS community since this term is frequently used
to describe names which are "not hostnames", but really there is no such
thing. The "binary" name you describe is the default domain name, and
hostnames are a special octet-restricted subset of those names. They all
share the same storage/transfer/mapping rules, however, which is octet
maps with case insensitive comparison for ASCII letters. The
infrastructure would not function otherwise.

> And we would certainly continue to disagree, since I read "all

I can't do this anymore. I would encourage you to take this to
namedroppers where it can be debated to your satisfaction. IMO, the
recommendations for hostname-compatible names are only suggestions, and
not requirements.

---

From: "Adam M. Costello" <[email-masked]>
Date: Wed, 5 Jun 2002 21:06:39 +0000

[Another copy of this message accidentally got stuck in the pipe
somewhere; I apologize in advance if it eventually comes through.]

"Eric A. Hall" <[email-masked]> wrote:

> eight-bit domain names linked with an expiremental RR which the cache
> knows absolutely nothing about?  What if eight-bit owner names are
> explicitly interpreted for that RR?

Excellent thought experiment.

One option that is always open to a cache is to not cache something.
Even if all caching DNS servers stopped caching everything, the DNS
would still work, it would just take a performance hit.

If the caching server receives a record with a name containing 80..FF,
and the caching server is unaware of the semantics of 80..FF for that
record, then the safest and simplest thing to do is not cache it.

However, it could be a little more intelligent.  Surely, if two byte
strings match exactly, then they match in every other way too.  So the
caching server could cache the record and do exact comparisons between
it and queries, and return the record if they match exactly, and let
the query fall through to the authoritative server if they don't match
exactly.

Furthermore, if the caching server knows that 0..7F are ASCII, and is
unsure of only 80..FF, then it can do case-insensitive matching on
0..7F, and exact matching on 80..FF.

Now I finally see an argument for why DNS servers in practice do
comparisons that way.  It's not because RFC 1035 requires it, but
because it's the best effort they can make given 1035's silence on the
issue.

But how does the caching server know that 0..7F are ASCII in domain
names attached to unknown RR types or unknown classes?  We know that
0..7F are ASCII in all character strings, but are all domain labels
necessarily character strings for all future RR types and classes?  Or
can future RR types and classes use non-text domain names?  RFC 1035 is
unclear.  These sentences suggest that domain names are always text:

    For all parts of the DNS that are part of the official protocol, all
    comparisons between character strings (e.g., labels, domain names,
    etc.) are done in a case-insensitive manner.

    The labels in the domain name are expressed as character strings and
    separated by dots.

    \DDD where each D is a digit is the octet corresponding to the
    decimal number described by DDD.  The resulting octet is assumed to
    be text and is not checked for special meaning.

But what does this mean:

    However, future additions beyond current usage may need to use the
    full binary octet capabilities in names,

Does "full binary octet capabilities in names" mean non-text names?  Or
does it merely mean text names that use 80..FF to represent non-ASCII
characters?

Although RFC 1035 is not clear, I think the only sane design is that
all domain names are text regardless of RR types and class.  The data
attached to a name might be non-text, but the name itself is text; 0..7F
are ASCII and 80..FF are text in an unspecified format.  The only safe
way to add non-text names would be via an extension to the protocol that
prevents old servers from participating, like EDNS.

AMC

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 05 Jun 2002 19:09:56 -0500

"Adam M. Costello" wrote:

> comparisons that way.

Great. Can we make IDNA a dumb codec now?

---

From: "Adam M. Costello" <[email-masked]>
Date: Thu, 6 Jun 2002 00:48:28 +0000

> Great.  Can we make IDNA a dumb codec now?

I can't tell if that's a deliberate non sequitur (meaning "Okay, can we
drop this topic and get back to a more important one?"), or if you see a
connection between my statement and your suggestion (I don't).

AMC

---

From: "Adam M. Costello" <[email-masked]>
Date: Tue, 4 Jun 2002 03:59:03 +0000

But what does this mean:

AMC

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 06 Jun 2002 00:39:49 -0500

> connection between my statement and your suggestion (I don't).

I forgot the smiley, but I am serious.

Now that we are all a big happy family and agree that all labels are
treated the same, we need to agree that all i18n labels will *ALSO* be
treated this way. IOW, IDNA applies to any domain name defined as a
profile of stringprep, and is not dependant on nameprep.

This means that IDNA takes i18n labels as input and gives ACE as output
(and vice-versa). IE, just one codec. No new codecs for localpart or for
NetBIOS or for KERBEROS or anything else.

This is required for IDNA to be useful, but it is also necessary for
coordinating EDNS and IDNA. A system faced with an i18n domain name on
input shouldn't have to say "well I can send it straight through in EDNS,
but I'm afraid you'll have to do something else with it if you want STD13
because it isn't nameprep".

---

From: "Adam M. Costello" <[email-masked]>
Date: Fri, 7 Jun 2002 06:27:26 +0000

"Eric A. Hall" <[email-masked]> wrote:

> IDNA applies to any domain name defined as a profile of stringprep,
> and is not dependent on nameprep.

Nameprep is essential to any IDN solution (IDNA or any other).  In order
to avoid chaos, we need everyone (not just DNS servers, but applications
and everything else) to agree on whether two domain names are the same
or not.

We already have this property for ASCII domain names--everyone uses a
case-insensitive ASCII comparison, which is equivalent to performing
ToLower and then doing an exact comparision (which is how it's usually
implemented).

In order for everyone to agree on whether two IDNs are the same, we
need to extend ToLower to work on non-ASCII strings.  There needs to
be a single precise transformation that everyone agrees on.  That
transformation has been decided--it's NFKC followed by the mapping step
defined in Nameprep.  Anything that compares non-ASCII domain names
must know that transformation (or must be promised that its inputs have
already had it applied).

Nameprep is an inseparable part of IDNA.

> This means that IDNA takes i18n labels as input and gives ACE as
> output (and vice-versa).  IE, just one codec.  No new codecs for
> localpart or for NetBIOS or for KERBEROS or anything else.

Agreed, there is only one codec for converting between ASCII domain
labels and non-ASCII domain labels.  Nameprep is an integral part of it.

For email address local parts, there is currently no interaction with
IDNA, because local parts are ASCII only, according to RFC 2822.
The procedure for mapping an email address onto a domain name is to
trivially encode the local part as a single label prepended to the
domain name.  That procedure applies to ASCII local parts, because all
local parts are ASCII.

Presumably someday soon someone will define non-ASCII local parts.  You
could imagine two ways of mapping a non-ASCII email address onto an
ASCII domain name.  (1) You could extend the old precedure to work on
non-ASCII email addresses, that is, trivially encode the local part as
a single internationalized label prepended to the domain name, and then
use IDNA to convert the domain name to ASCII.  (2) You could convert
the local part and the domain name to ASCII separately (using IDNA for
the domain name and something else for the local part), and now you've
reduced the problem to the old problem for ASCII email addresses.

It will be up to the email folks to decide which approach to take.
Local parts are *not* domain labels (even though they are sometimes
*mapped* onto domain labels), so IDNA does not automatically apply
to them.  The mapping from internationalized local parts to domain
labels might or might not be as trivial as it was for ASCII local parts.
That's something for another working group to decide.

As for NetBIOS and Kerberos, I'm not familiar with the issues there.

AMC

---

From: "Adam M. Costello" <[email-masked]>
Date: Fri, 7 Jun 2002 06:39:45 +0000

I wrote:

> That transformation has been decided--it's NFKC followed by the
> mapping step defined in Nameprep.

Doh, I always get that backwards.  First map, then normalize.

AMC

---

From: "Eric A. Hall" <[email-masked]>
Date: Fri, 07 Jun 2002 11:37:15 -0500

"Adam M. Costello" wrote:
> Nameprep is essential to any IDN solution (IDNA or any other).

Nameprep is only essential to the creation and intepretation of the domain
names used with *specific* resource records. Storing, transferring and
converting the data does not require this knowledge.

For example, the authoritative master for a zone needs to know that
nameprep applies to the owner name of an i18n A RR, so that these rules
can be enforced when the RR is created. Similarly, an application which
can create and/or read i18n A RRs from EDNS messages needs to know that
nameprep applies so that it can validate the domain name.

However, a cache inbetween an EDNS client and server does not need to know
these rules, since it will only work with data which has already been
properly formatted by the client or server. Furthermore, a cache which
converts a UTF-8 i18n A RR into ACE does not need to know the rules,
because the input data will have already been formatted properly. This is
also true for replication servers within the zone; they can assume that
the original data is properly formatted, with no knownledge of the rules
used to generate that data.

This same reasoning applies to all RRs regardless of the stringprep
profile they use. If an i18n RP RR contains an i18n email address, the
i18n localpart rules would only apply to the creation of the RR data. The
infrastructure can be relatively ignorant about these rules.

Consider another example, where a specific application requires the use of
an i18n RR which does not conform to nameprep. It is feasible that a FOO
RR will need to define it's own rules, perhaps because the application
requires all-uppercase, or because the RR data is storing raw text which
must not be normalized.

If the infrastructure is opaque, then these RRs can be defined at the
authoritative master for the zone and within the application that uses
these RRs, while the infrastructure can be completely ignorant of the
rules. Caches can even perform conversion because the rules say (or they
*SHOULD* say) that the inputs and outputs are simple octet streams.

That is the same model used today and we need to stick with it.

> In order

Is IDNA capable of producing identical output for two different inputs
(setting aside the issue of normalizations)? That is the only real
question as to whether or not the separation can occur.

---

From: "Adam M. Costello" <[email-masked]>
Date: Sat, 8 Jun 2002 04:48:48 +0000

"Eric A. Hall" <[email-masked]> wrote:

> Nameprep is only essential to the creation and interpretation of the
> domain names used with *specific* resource records.

Nameprep is at the heart of the definition of equivalent labels.

In today's domain name system, you cannot have foo and Foo and FOO as
three separate entries in the same zone.  No matter which one you ask
for, you'll get the same records back, because they are equivalent
labels.

This will still be true for IDNs.  No matter whether you ask for
föo, Föo, or FÖO, you'll get the same records back.  (For the
Latin-1-impaired, the non-ASCII characters are o with umlaut.)

You seem to be proposing a model in which there might be special kinds
of labels that use different Stringprep profiles that don't do case
folding.  But then queries for föo, Föo, and FÖO could return three
different results.  That would be a fundamental departure from today's
model.

Nameprep is inseparable from IDNA not only for names of resource records
but also for domain names appearing inside resource records, because you
never know when or why or by whom domain names will get compared.

Let's examine how föo and FÖO can get compared.  The ACE form of both
is xx--fo-fka.  But if we were to skip Nameprep when converting FÖO, we
would get xx--FO-ohA.

Now consider an entity that knows that föo and FÖO and xx--fo-fka and
xx--FO-ohA are domain labels, but does not know that they are special
labels that don't use Nameprep.

Will this entity consider föo and FÖO to be equivalent?  Yes, because
domain labels are case-insensitive.  Will it consider föo and xx--fo-fka
to be equivalent?  Yes, because the latter is the ACE encoding of
the former.  Will it consider labels xx--fo-fka and xx--FO-ohA to be
equivalent?  No, because they are ASCII labels and the usual ASCII
comparison rules apply.  Therefore, by transitivity of equivalence, this
entity cannot consider FÖO and xx--FO-ohA to be equivalent.

That's an important result.  An entity that doesn't know about special
non-nameprepped labels cannot convert between the non-nameprepped-ACE
form and the Unicode form (because it doesn't consider the two forms to
be equivalent).  Only an entity that knows the special nature of such
labels can do the conversion.

Therefore, we might as well not overload the IDNA prefix for such
purposes, but instead use a different prefix associated with a
different Stringprep profile.  If an entity knows about the special
non-nameprepped labels, it can easily look for the other prefix.  If
an entity doesn't know about the special non-nameprepped labels, it
couldn't do the conversion anyway, so it doesn't matter that it doesn't
know the prefix.  Having different prefixes for different profiles would
help avoid confusion and mistakes.

I think these special non-nameprepped labels that you envision tend
to be the result of mapping non-domain-label data onto domain labels
(like email address local parts).  Domain labels have their own matching
rules, and those rules apply to all domain labels, and Nameprep is an
integral part of those matching rules (for IDN labels).  If you want
to map some other data type onto domain labels, then it's up to you to
define a mapping that copes with any differences between the domain
label matching rules and the matching rules of the other data type.

IDNA is designed to convert domain labels to other domain labels, and
to compare domain labels.  It is not designed to convert between domain
labels and other data types.  If you want to define such conversions,
you are free to immitate IDNA.  Maybe you will end up with something
just like IDNA except that it uses a different Stringprep profile and a
different ACE prefix.

(But if the other data type has such different matching rules, it might
be easier not to try to map it onto a domain name at all, but instead
just let it be its own data type.  There's no law that says everything
needs to be represented as a domain name.  Resource records can define
arbitrary data formats.)

> (setting aside the issue of normalizations)?

I'm not sure what you mean.  Nameprep can of course produce identical
output for two distinct inputs.  But for two distinct outputs of
Nameprep, ToASCII cannot produce the same output.

AMC

---

From: "Eric A. Hall" <[email-masked]>
Date: Sat, 08 Jun 2002 01:29:10 -0500

on 6/7/2002 11:48 PM Adam M. Costello said the following:

> föo, Föo, or FÖO, you'll get the same records back.

Important footnote clarification. The i18n namespace is case-sensitive 
because of the AMC-Z encoding, not because of nameprep. The original 
capitalization has to be burned to suit the encoding.

As a result, all i18n domain names (unencoded) must be compared as 
case-specific data, by requirement of the codec.

This applies to every domain name which can be encoded with IDNA 
regardless of whether or not nameprep is used.

> folding.

Absolutely. If somebody needs an RR that preserves case, there's no reason 
they shouldn't be able to do so. It's a choice between:

   1) do I store the data in case-specific form and require
      case-specific comparisons

or

   2) do I burn character case on creation through mandatory
      lowercasing and also require case-specific comparisons

There is no reason to require #2, just as there is no reason to always 
require normalization. Furthermore, there are already well-known 
data-types that require #1.

> But then queries for föo, Föo, and FÖO could return three

We just finished this argument. Labels are currently stored, transferred 
and compared as octet-streams, with the exception being that ASCII A-z is 
compared as case-insensitive. The difference here is that ASCII A-z will 
always be case-specific for i18n domain names (a requirement of the 
codec). Otherwise, the behavior I am arguing for is *IDENTICAL* to the 
current model, while you are arguing for mandatory lowercasing for storage 
and transfer in addition to comparison.

> labels that don't use Nameprep.

Why would it ask for a special RR that it doesn't know how to read? There 
are loads of RRs out there that applications cannot parse. ping can't 
process SOA RRs, why would it be expected to read the FOO RR?

People can already write RRs that suit specific application requirements, 
and I'm asking that you consider this continued requirement. They are the 
only users of those RRs, so what do we care what they do? Moreover, why do 
we need an arbitrary rule that prohibits current practice?

> Nameprep, ToASCII cannot produce the same output.

Is the encoding form guranteed to always be reversible to the original 
capitalization?

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sat, 8 Jun 2002 08:33:10 -0700

Eric, at one point you offered to take this discussion to the DNSEXT 
Working Group. That seemed like a good offer because you are talking 
about features that are not in the expertise set of this WG. If the 
DNSEXT Working Group thinks that a change needs to be made in IDNA 
for resource records, they will certainly tell the Area Directors and 
probably this WG.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "Eric A. Hall" <[email-masked]>
Date: Sat, 08 Jun 2002 11:38:13 -0500

on 6/8/2002 10:33 AM Paul Hoffman / IMC said the following:

> about features that are not in the expertise set of this WG.

Case and normalization certainly should be in the expertise set of this
WG. I mean, you seem to know enough to mandate arbitrary uses of it. If
you want to plead ignorance, don't impose a rule you don't understand.

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sat, 8 Jun 2002 09:51:20 -0700

At 11:38 AM -0500 6/8/02, Eric A. Hall wrote:
>WG.

Right, but that's not what you are arguing about. You are saying that 
we shouldn't impose them on all DNS RRs. The decision of what DNS RRs 
should be internationalized is for the DNSEXT WG.

--Paul Hoffman, Director

---

From: "Eric A. Hall" <[email-masked]>
Date: Sat, 08 Jun 2002 12:08:12 -0500

> should be internationalized is for the DNSEXT WG.

Paul, I am arguing against an arbitry architectural decision which
prohibits alternative RRs and domain names from ever being used. Arguing
over the RRs themselves is not going to be productive if the architecture
won't support them.

So yes, I am arguing against the mandatory and unnecessary case and
normalization rules which are embedded into the architecture.

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sat, 8 Jun 2002 10:17:20 -0700

At 12:08 PM -0500 6/8/02, Eric A. Hall wrote:
>prohibits alternative RRs and domain names from ever being used.

And if the DNS folks believe your view of reality, they will will 
certainly speak up. If they don't believe your view of reality, well 
that says something.

--Paul Hoffman, Director

---

From: "Eric A. Hall" <[email-masked]>
Date: Sat, 08 Jun 2002 12:30:32 -0500

on 6/8/2002 12:17 PM Paul Hoffman / IMC said the following:

> certainly speak up.

The ones that are here have done so. On the other hand, there is no
support for your capricious choices in the record. In fact, the record
shows that they are based on factually incorrect interpretations of DNS
technology and practices.

Again, I have no expectation that the IDNA team will fix the problems that
have been pointed out.

---

From: "Adam M. Costello" <[email-masked]>
Date: Sun, 9 Jun 2002 20:51:02 +0000

"Eric A. Hall" <[email-masked]> wrote:

> The i18n namespace is case-sensitive because of the AMC-Z encoding,
> not because of nameprep.  The original capitalization has to be burned
> to suit the encoding.
>

You have totally lost me.  First, what does "case-specific" mean?

I'll start by explaining exactly what "case-sensitive" and
"case-insensitive" mean (as I understand the terms).  To say that a
text string is "case-insensitive" is to say that changing characters
from upper to lower case or vice-versa does not change the identity
of the string; in other words, case differences are ignored when the
string is compared to other strings.  To say that a text string is
"case-sensitive" is to say that changing characters from upper to lower
case or vice-versa does change the identity of the string; in other
words, case differences are not ignored when the string is compared.
Neither term says anything about whether the string is capable or
incapable of preserving mixed-case text; that is an orthogonal question.

So there are four possibilities:  A string can be case-sensitive
and case-preserving (like Unix file names), or case-insensitive
and case-preserving (like Macintosh and Amiga file names), or
case-insensitive and non-case-preserving (like MS-DOS file names), or
case-sensitive and non-case-preserving (I can't think of any real-world
examples).

For IDNA, we wanted the mapping between non-ASCII labels and ACE labels
to have the following property:  A case-insensitive comparison of
two ACE labels always returns the same answer as a case-insensitive
comparison of the two corresponding non-ASCII labels.  In order
to achieve that property, a case-folding step is essential in the
definition of the ACE mapping.  (Maybe you don't want that property, but
it was a fundamental design goal of IDNA, in order to avoid surprising
users with different comparison rules for ASCII versus non-ASCII names.)

The codec defined by IDNA has a number of steps, of which the two
biggest are Nameprep and Punycode, but it's all a single codec.
Punycode is broken out as a separate step because its implementation
is independent of the other steps and because Punycode might be useful
for things other than domain names.  But for IDNs, Punycode is not the
codec, it is merely one step of the codec, and Nameprep is another step
of the codec.

IDNA nowhere suggests the use of case-sensitive comparisons between
domain names in any form.

> If somebody needs an RR that preserves case, there's no reason they
> shouldn't be able to do so.

Agreed.  And I suggest two ways they might do this:  (1) Define a
case-sensitive data format and don't call it a domain name.  (2) Define
a mapping from non-ASCII domain labels to ASCII domain labels that
doesn't involve case-folding.  But don't call this mapping IDNA, because
it's not.  It might look very similar to IDNA, and might reuse pieces of
it, but it shouldn't use the IDNA ACE prefix for a mapping that is not
the IDNA ACE mapping.

> Labels are currently stored, transferred and compared as
> octet-streams, with the exception being that ASCII A-z is compared as
> case-insensitive.

That's how most DNS servers handle 8-bit labels in practice, but I
still don't think they're required to do so, I just think it's the best
effort they can make given that they don't know the charset.  But we've
heard reports of some new DNS servers that try to guess the charset,
in which case they might then do case-insensitive comparisons even for
the non-ASCII characters.  And there's still the wide world of entities
other than DNS servers, which also compare domain names, and their
handling of 8-bit names is even less predictable.

> you are arguing for mandatory lowercasing for storage and transfer in
> addition to comparison.

Yes, because that's the only way to achieve that property I mentioned
above.

> > Now consider an entity that knows that föo and FÖO and xx--fo-fka
> > and xx--FO-ohA are domain labels, but does not know that they are
> > special labels that don't use Nameprep.
>
> Why would it ask for a special RR that it doesn't know how to read?

Because it might be a caching DNS server.

If you only care about the end applications, which know the special
semantics of the special labels, then just use a different prefix to
go with your different Stringprep profile.  Then you can be sure that
entities that know IDNA but don't know about your special labels won't
accidentally muck with them.

> > Nameprep can of course produce identical output for two distinct
> > inputs.  But for two distinct outputs of Nameprep, ToASCII cannot
> > produce the same output.
>

I'm not sure what you mean by "encoding form".  The ACE form (which
involves both Nameprep and Punycode) is not guaranteed to be reversible
to the original capitalization.  There is a mechanism called "mixed-case
annotation", described in Appendix B of the Punycode spec, which can
remember any capitalization you want (except for titlecase), but the
ToASCII and ToUnicode operations described in the IDNA spec neither
create nor apply these annotations.  It's possible to write a conformant
ToASCII that creates them, and a conformant ToUnicode that applies them,
but the IDNA spec does not mention this possibility, mainly because the
first two authors have never been convinced that it's really safe or
effective.  :)  (I originally proposed this mechanism as a way to make
IDNs case-preserving like ASCII domain names are, but I long ago gave up
on that issue.)

There is no analogous mechanism for recovering a non-normalized string.

Punycode by itself can encode any arbitrary sequence of non-negative
integers, and always decodes to exactly the same sequence.

AMC

---

From: "Eric A. Hall" <[email-masked]>
Date: Sun, 09 Jun 2002 17:47:30 -0500

on 6/9/2002 3:51 PM Adam M. Costello said the following:

> To say that a text string is

That's right.

And since the encoded representation of the original string has to be
case-neutral for it to work in the legacy label, the input label has to be
made case-specific. The input label cannot be changed. This is regardless
of whether or not it is converted to lowercase before it is encoded; the
label which actually gets encoded is permanently made case-specific, at
least in its unencoded form.

> users with different comparison rules for ASCII versus non-ASCII names.)

We agree on history and partially agree on objectives. Let me explain
where we differ.

Specifically, I agree with the requirement to make *some domain names*
lowercase in order to facilitate simple comparisons. In particular, any
domain name which commonly represents a connection identifier (a hostname)
should conform to this requirement. Examples of this would include the
owner name of an A RR, the RRdata of MX and NS RRs, and most of the other
domain names which are commonly used for connection identifiers.

However, there are other domain names where this is not required. For
example, consider that Apple might want to encode the NBP name of AFP
servers within a zone as some kind of iNBP RR which is linked to an atalk
zone name. There is absolutely no reason that the iNBP RR owner name or
any of the RRdata elements must be mangled. Apple could choose to do so,
but there is no reason that we should require it. Similar arguments can be
made for NetBIOS names, NetWare SAP entries, NIS domains, and so forth.
There are plenty of other examples where this kind of facility needs to be
supported, but those are obvious candidates most of us are familiar with.

What we need in order to support those kinds of applications is to
separate nameprep from IDNA. Specifically, IDNA needs to apply encoding
against any label which suits the requirements (UCS character code inputs
which result in valid STD13 output), regardless of the stringprep profile
in use. Then the applications which create and parse the domain names are
the only ones that need to understand the stringprep profile in use for
that specific domain name.

The ridiculous part here is that under the existing STD13 rules, these RRs
can be used simply by defining an interpretation to the octets. For
example, Microsoft already provides a direct encoding of NetBIOS names
into UTF-8 and simply applies their own interpration to the RRs. Under
your rules, they couldn't use i18n domain names as effectively as STD13
domain names since they would have to sacrifice capitalization in the
process. Get it? i18n domain names need to have *at least* the same
flexibility as STD13 if they are to be adopted by the community. If not,
then interoperability will be harmed, because people will continue using
STD13 labels and doing their own thing.

I think you are missing a key concept here, which is that all of the RRs
are going to need to i18n definitions, and IDNA alone won't do it. When
the RR rules are defined, they will get stringprep profiles assigned to
them. At that point, the applications which create and interpret the
unencoded labels are the only ones that need to know anything, and the
infrastructure can store, transfer, compare and convert the opaque octets.
DM-IDNS-00 also tried to define a global namespace. It doesn't work. The
only way out is to use per-RR rules.

> it, but it shouldn't use the IDNA ACE prefix for a mapping that is not

(1) Anything which fits in the i18n namespace is a domain name, regardless
of whether or not IDNA can handle it. The problem is that IDNA is trying
to mandate the namespace according to the requirements of nameprep, when
there is no technological argument for doing so. (2) Defining alternative
type-specific codecs hinders deployment, and is unnecessary. Thus the rule
is not only arbitrary, but it also hinders interoperability.

> handling of 8-bit names is even less predictable.

Non-argument. The EDNS label is there to prevent this confusion. What the
owner of a zone does with the STD13 octets is up to them.

> Because it might be a caching DNS server.

Caches and replication servers have no need to understand the
capitalization or normalization rules in use with a particular domain
name. Only the nodes that create and interpret the domain names need to
know anything about the contents. Caches and replication servers only need
to understand the layout of the message.

> accidentally muck with them.

No, that won't work. That requires the resolvers, caches and replication
servers to understand special rules about the domain names before the
application can be deployed. Essentially, this requires the infrastructure
to be upgraded for every new domain name which gets defined.

There is absolutely no reason for this. It's a ridiculous artifact of an
arbitrary design. Decouple IDNA from nameprep and the problem is solved.

> to the original capitalization.

Okay, that's a problem. May have to use something else entirely.

---

From: "Adam M. Costello" <[email-masked]>
Date: Mon, 10 Jun 2002 02:16:43 +0000

This message responds to things in the order they appeared in the
previous message.  It might be easier to follow if I reordered some of
it, but composing it has left me too tired to do so.  You might want to
make two passes.  :)

"Eric A. Hall" <[email-masked]> wrote:

> case-neutral for it to work in the legacy label, the input label has
> to be made case-specific.

I asked for a definition of "case-specific", but you didn't give me one.
Now you've introduced a second term I'm unfamiliar with, "case-neutral".
I honestly don't know what you mean by those terms.

> I agree with the requirement to make *some domain names* lowercase in
> order to facilitate simple comparisons.
>
> However, there are other domain names where this is not required.

The same could be said for domain names that use only ASCII characters.
The case-insensitive comparison might not required for some of them, but
it's done for all of them, whether they need it or not.  IDNA extends
this philosophy to IDNs.  The same comparison rules apply to all IDNs.

With ASCII domain names, we had the luxury that we could preserve
case even while ignoring it; that is, ASCII domain names are
case-insensitive/case-preserving.  With IDNs in their ACE form, this
is not possible (at least not officially); instead we have to choose
case-insensitive/non-case-preserving or case-sensitive/case-preserving,
and we chose the former, judging the case insensitivity to be more
important that the case preservation.

If applications want to map case-sensitive identifiers directly onto
domain labels in owner names of resource records, they can, as long as
they avoid collisions.  This is already true for ASCII domain names,
and continues to be true for IDNs.  For example, in the ASCII world, we
can store information under the name FoO.net, and when someone looks
up FoO.net, they'll find the information.  We can't store different
information under fOo.net, even though fOo is a distinct identifier from
FoO.

Now reread that example but imagine an umlaut over the middle letter.
With IDNA, it's all still true.  The only difference is that if you do
a reverse query, you won't get the original capitalization, but reverse
queries are almost never used, so it's no big deal.

If case-preservation is important to an application (which is more
plausible if the applications is mapping case-sensitive identifiers onto
domain labels *inside* resource records), then it can define a mapping
that preserves case.  For example, it could use 8-bit labels (like
unprepped UTF-8 or foo-prepped UTF-8), or it could use something similar
to IDNA but with a different Stringprep profile and a different prefix.

> Microsoft already provides a direct encoding of NetBIOS names into
> UTF-8 and simply applies their own interpration to the RRs.  Under
> your rules, they couldn't use i18n domain names as effectively as
> STD13 domain names since they would have to sacrifice capitalization
> in the process.

Right, IDNA sacrifices case-preservation in order to get compatibility
with the ASCII infrastructure while continuing the tradition of
case-insensitive domain names.  Maybe NetBIOS doesn't like that
tradeoff, and would rather have case-preserving reverse queries.
Microsoft can continue to use 8-bit DNS names if they want.

Here's a stab at the relationship (or lack thereof) between 8-bit labels
(which are allowed by RFC 1035) and IDN labels (which are defined by the
IDNA spec).  I'm sure some people (even IDNA supporters) might not agree
with this interpretation, because it's a subtle question, but here goes:

8-bit labels in DNS (not EDNS) owner names, even if they are interpreted
as UTF-8 by the end clients, do not contain non-ASCII characters
from the point of view of the DNS infrastructure.  RFC 1035 does
not specify or allow any charset other than ASCII, therefore it's
impossible for an owner name to contain non-ASCII characters; the
octets 80..FF are allowed, but they don't represent any particular
characters (from the point of view of DNS).  Since IDNA explicitly
applies only to text labels (which I understand to mean labels composed
entirely of characters), DNS labels containing 80..FF are completely
outside the scope of IDNA; they are not IDN labels, but labels in an
independent namespace that is not subject to any of the rules for IDNs.
Applications can continue to use use such labels under the rules of
RFC 1035 without regard to IDNA.  I personally think this namespace is
under-specified and risky and should not be used, but it will still be
as present after IDNA as it was before.

That analysis applies to DNS, not EDNS.  EDNS could define entirely new
semantics and comparison rules for its 8-bit labels; there is no need
for EDNS labels to be compared in the same way as DNS labels.  EDNS
could even define multiple namespaces each with its own comparison
rules, and tag labels according to which namespace they belong to.

> I think you are missing a key concept here, which is that all of the
> RRs are going to need to i18n definitions, and IDNA alone won't do it.

I'm not missing that, I know that.  IDNA alone won't do it; IDNA is only
for internationalized textual domain labels.  RRs that map other data
types onto domain names might find that IDNA is not suited to their
needs.  They are welcome to define a more suitable mapping directly
from their non-domain-label data type to ASCII domain labels.  They are
welcome to borrow techniques from IDNA.

> When the RR rules are defined, they will get stringprep profiles
> assigned to them.  At that point, the applications which create and
> interpret the unencoded labels are the only ones that need to know
> anything, and the infrastructure can store, transfer, compare and
> convert the opaque octets.

I'm finally starting to understand your vision.  In order to correctly
convert labels between the non-ASCII form and the ACE form, or to
compare two labels, you would need to EITHER know and perform the
preparation algorithm for this particular label OR be guaranteed that
the the appropriate preparation has already been applied (in which case
you don't need to know what it is).

That's interesting, but I see a security concern:  What if the entity
handing you the label is maliciously not applying the appropriate
preparation?  It can trick you into making errors when comparing labels,
or trick you into converting a label into a non-equivalent label.  If
you don't know the appropriate preparation algorithm, you can't detect
this or protect yourself from it.

I suppose it might be possible to address that concern.  If you have an
interest in the correctness of a comparison/conversion, then you need
to know the preparation algorithm yourself.  On the other hand, if you
are performing comparisons/conversions without knowing the preparation
algorithm, you better not be relying on the correctness of the answers,
you better just be converting a name on behalf of the entity that
prepared it, or comparing names on behalf of an entity that prepared one
of them.

In your vision of the world (as I understand it), the ASCII
infrastructure would use ACE, while the new improved infrastructure
would use prepared-UTF-8, where the preparation is not the same for all
labels.  But I don't see what's so great about prepared-UTF-8 versus
ACE.  Both require the same amount of effort from all applications;
they have to do something special at the boundaries, the difference
is in the details.  If you want to sell me on a new infrastructure,
it's got to offer something more.  If it accepted unprepared-UTF-8,
then I might find it interesting, because it would require less effort
from applications that already use Unicode.  But in order for the
infrastructure to accept unprepared-UTF-8, the infrastructure would need
to know the preparation algorithm...

> (1) Anything which fits in the i18n namespace is a domain name,
> regardless of whether or not IDNA can handle it.

The i18n namespace doesn't exist until we define it.  As I argued above,
the 8-bit namespace that already exists under RFC 1035 is not an i18n
namespace, because it cannot represent non-ASCII characters, because no
charset other than ASCII is specified.  It is the job of this working
group to define the i18n namespace.  The definition of IDN in the IDNA
draft is a definition of the i18n namespace.

> > semantics of the special labels, then just use a different prefix
> > to go with your different Stringprep profile.  Then you can be sure
> > that entities that know IDNA but don't know about your special
> > labels won't accidentally muck with them.
>
> No, that won't work.

I don't see why not.  At some point, someone needs to perform Stringprep
with some profile.  Why can't that entity go ahead and do the whole
transformation at the same time (Unicode to ASCII, prepend the prefix)?
What's the advantage of doing only the Stringprep part?

AMC

---

From: "Eric A. Hall" <[email-masked]>
Date: Sun, 09 Jun 2002 22:06:36 -0500

Everything else discussed is irrelevant. We are there.

> you don't need to know what it is).

Exactly. Any node in the path can convert any RR (whose message structure
is understood) between IDNA and ACE simply be piping from one to the
other. They don't need to know the capitalization or normalization rules
which were used. It's just octets.

> this or protect yourself from it.

That's why DM-IDNS-00 required the app to perform validation. This is
discussed in the first paragraph of the Security Considerations section:

 |   Where possible, this specification strengthens DNS with multiple
 |   checks. For example, this specification requires that domain names
 |   be validated three times before they are used by applications:
 |   once on specification, once on entry at the authoritative zone or
 |   hosts database, and once again when the answer data is received by
 |   the requesting application.

> would use prepared-UTF-8, where the preparation is not the same for all

Actually, I kind of expect that tighter rules will be picked up for the
STD13 RRs at the same time (with a formal definition of hostnames, etc).
Some of the stringprep profiles will be for localpart and SRV anyway so
those can be reused without effort. I'll leave that up to DNSEXT but I am
kind of expecting it to happen (if I can proceed with this model at all).
I am also expecting that they will want to use some of the other things as
generic updates to STD13. The query timer would be useful for things like
TCP fallback and DNSSEC as much as they are to IDNS.

> But I don't see what's so great about prepared-UTF-8 versus ACE.

Well, that's another argument for another day. The data has to be cleansed
before it can reasonably and safely be used by any process, so its not a
big deal to have the application do this. At that point, the question is
whether or not direct UTF-8 access offers the application and/or protocol
any benefits, which it does.

> What's the advantage of doing only the Stringprep part?

Because EDNS->ACE conversion by some cache in the middle will require that
the cache have knowledge of the appropriate prefix tag. Everytime you roll
out a new stringprep profile, you have to tell *everything* that *might*
do conversion what the prefix is. This requires pgrades to the resolvers,
the caches, the replication partners, everything. Nobody will do it.

---

From: "Adam M. Costello" <[email-masked]>
Date: Mon, 10 Jun 2002 03:33:55 +0000

> Everything else discussed is irrelevant.  We are there.

Well, just because I'm finally starting to understand your vision
doesn't mean I'm sold on it.  :)

> > At some point, someone needs to perform Stringprep with some
> > profile.  Why can't that entity go ahead and do the whole
> > transformation at the same time (Unicode to ASCII, prepend the
> > prefix)?  What's the advantage of doing only the Stringprep part?
>
> Because EDNS->ACE conversion by some cache in the middle will
> require that the cache have knowledge of the appropriate prefix tag.
> Everytime you roll out a new stringprep profile, you have to tell
> *everything* that *might* do conversion what the prefix is.

What I'm suggesting is that whenever you apply Stringprep, you also
apply Punycode and prepend the prefix.  It's not really any extra
effort.  Whenever you roll out a new Stringprep profile, the things that
need to get updated to know the new profile are exactly the same things
that need to get updated to know the new prefix.

Of course, my suggestion implies that there is no prepared-UTF-8 format,
there's unprepared-UTF-8 and prepared-ACE.  I don't see the point of
using prepared-UTF-8 as an interchange format, when ACE works just as
well, requires essentially the same effort from applications, and has
the added benefit of backward compatibility.

AMC

---

From: "Eric A. Hall" <[email-masked]>
Date: Sun, 09 Jun 2002 23:54:25 -0500

on 6/9/2002 10:33 PM Adam M. Costello said the following:

> apply Punycode and prepend the prefix.

Which is the replication master and the application. That's not a problem.

> Whenever you roll out a new Stringprep profile, the things that

Resolvers, middle-boxes and replication masters all need to be able to
convert between EDNS and ACE as part of the fallback process. Distributing
the profile-specific prefix to every point where conversion might occur is
a massive problem.

The only way it would work in your model would be for conversion to only
occur at the application or at the replication master. But if the query
made it to the replication master there's no reason to do conversion, so
we are left with the application always performing conversion. That design
blows up the architectural benefits from having the middle-boxes do it (in
particular, having the caches learn the data so they can cache it). It
will sometimes be necessary to have applications perform conversion but
requiring it would blow up DNS.

> the added benefit of backward compatibility.

For generating names, ACE conversion is an extra step that comes after
creating the structured UTF-8 domain name. Furthermore, it is an
unnecessary step if the application and protocol are only using UTF-8
domain names. Meanwhile, there is nothing saved from using unstructured
UTF-8 in DNS, since the applications have to use the rules anyway if they
are specifically exchanging domain names.

The only "extra" step is validating data which has been received, which
isn't an extra step for any application with half a clue. It's a
fundamental tenet of application design to validate the data you get from
the network. Only an idiot would use complex strings without some kind of
validation first. Besides, you would also need to do this as part of any
decoding of ACE back into the canonical i18n domain name, so this extra
step also applies to you (not to mention the extra step of conversion).

On all counts, using structured domain names is the fastest of the safe
routes, and is only step longer than the shortest route.

---

From: Dave Crocker <[email-masked]>
Date: Sun, 09 Jun 2002 23:42:44 -0700

Eric,

You have posted 27 messages to this thread in 2 weeks.  As nearly as I can 
tell, you have some concerns about changes to the existing DNS infrastructure.

IDNA sits on top of the existing DNS infrastructure.  It specifies a set of 
enhancements that live above the DNS protocol and data structures.  It does 
not specify any changes to that existing DNS protocol or data 
structures.  That includes no changes to RR records or other DNS record 
specifications. Only software that interfaces with applications needs to 
add IDNA.

Consequently, your comments on this thread appear to pertain to concerns 
that have nothing at all to do with IDNA.

As such, it cannot possibly be helpful to IDNA forward progress to continue 
this line of discussion in this context.

d/

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 10 Jun 2002 02:01:43 -0500

> this line of discussion in this context.

If Adam and/or any of the other interested party wants to take the
discussion off-list, I'll meet them anywhere.

Otherwise, your attempt at squelching critical analysis of IDNA is duly
noticed and ignored.

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 10 Jun 2002 08:52:11 +0200

>> words, case differences are not ignored when the string is compared.

Well, when working with Unicode, you need more specific text.

Two strings, X and Y, are said to be case insensitive if f(X) = f(Y) where
f() is either map to lower case or map to upper case. In nameprep we choose
to map to lower case. Further, we have added special mappings so f(f(X)) =
f(X).

Together with normalization this is a little bit tricker, and, because of
this complexity and given how DNS software work today, we chose to make the
mapping (nameprep) before the strings are used in DNS.

I.e. the heavy computation is when doing the mapping, and we optimize for
lookups, not storage. Lookup algorithm is exactly the same (given that the
input has passed ToASCII in IDNA of course).

   paf

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 10 Jun 2002 08:58:57 +0200

> Okay, that's a problem. May have to use something else entirely.

The problem is not capitalization. If you ask for preservation, you should
ask for preservation of the original string. Just looking at case
preservation is a very very tiny issue.

In the beginning (eons ago) we looked at the ability to keep the original
string, and the conclusion was that that was not possible without doing a
lot of changes to how DNS works, or at least, create new RR types which
include both the string one do comparison on, and the one which is given
back. Question is then how to see that the relationsship between them stays
the same etc etc.

But, DNS doesn't work that way _today_. It uses one string to match on, and
that is also the string which is given back. If a different string is given
back, many resolvers reject the strings due to risk of cache-poisoning.
And, caches will have issues with it, and the compression algorithm and...

The list is long, very long.

So, the result was that at the end, we always to conversion of strings when
they go "into the system" of application and DNS protocols. Within that
world, that f(X) is what is used. Period.

   paf

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 10 Jun 2002 02:34:08 -0500

[thanks paf]

> preservation is a very very tiny issue.

Yeah, can I have preservation? Normalization will also vary.

> And, caches will have issues with it, and the compression algorithm and...

Some of these issues are showing up in the conversion work too, as you can
imagine. They give me headaches. EG, when you change an owner name from
UTF-8 to ACE, the converting system needs to find all of the compression
pointers which refer to that owner name and then expand/relocate them.
This can be handled through a mix of features -- compression-specific EDNS
label types for one -- and this can work without the converter having
intimate knowledge of the record structure (only the owner names will be
converted). If I can solve that, then I have also solved one of the big
problems with STD13 domain names at the same time.

I am planning to minimize the risk of collisions by prohibiting sister
owner names from being entered which would collapse to the same domain
name. Although this isn't technically required, better safe than sorry.
The rule can be relaxed later if it proves unnecessary.

> world, that f(X) is what is used. Period.

Yeah, I understand the need for it, and I support it for the common
scenario. But we also need to offer this capability if we want people to
not invent STD13 octet interpretations.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 10 Jun 2002 08:14:31 -0700

Eric,

My note made specific observation that this thread appears to have nothing 
to do with IDNA.

Since you think it IS relevant, I'll ask how it is relevant.

I've read the thread and all I see is discussion about things entirely 
outside the scope of the IDNA specification.

If a discussion goes on actively for 2 weeks and results in this sort of 
confusion, it is generally useful to try to re-synchronize things.

So, please clarify.  What aspects of IDNA does this thread pertain to?

d/

----------
Dave Crocker <mailto:[email-masked]>
TribalWise, Inc. <http://www.tribalwise.com>
tel +1.408.246.8253; fax +1.408.850.1850

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 10 Jun 2002 12:33:12 -0500

> So, please clarify.  What aspects of IDNA does this thread pertain to?

A lowercase-only idn namespace is not particularly compelling in
comparison with STD13 octets which can provide that feature over the
existing namespace, I am arguing to get this restriction lifted before it
is embedded in stone. Some things about IDNA can be changed
after-the-fact, this is not one of them.

Specifically, I am trying to get IDNA decoupled from mandatory use of
nameprep so that the applications will be able to use domain names which
are not lowercased and normalized, if those applications have such a need.
This will not affect normal operations, as the majority of the resource
records will still need to use nameprep anyway. It's a pretty simple
request: make the profile selection separate from the codec.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 10 Jun 2002 10:54:01 -0700

>request: make the profile selection separate from the codec.

The interpretation of domain name strings is not subject to 
application-specific choice.

The DNS is a single, unified, global service and it defines its own 
strings.  Interpretation (comparison) of strings must work the same in all 
cases.

For everyone.  Everywhere.  At all times.

What you are seeking is in fundamental opposition to global 
interoperability of the DNS.

d/

----------

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 10 Jun 2002 13:01:25 -0500

> application-specific choice.

Not in the current design it isn't.

> strings.  Interpretation (comparison) of strings must work the same in all 

That is historically and technically erroneous. Applications can and do
define their own formatting rules and interpretations.

> interoperability of the DNS.

Reread the thread. What I seek is already offered in STD13 labels.

---

From: John C Klensin <[email-masked]>
Date: Mon, 10 Jun 2002 14:29:25 -0400

--On Monday, 10 June, 2002 10:54 -0700 Dave Crocker
<[email-masked]> wrote:

>> Specifically, I am trying to get IDNA decoupled from
>> mandatory use of nameprep so that the applications will be
>> able to use domain names which are not lowercased and
>> normalized, if those applications have such a need. This will
>> not affect normal operations, as the majority of the resource
>> records will still need to use nameprep anyway. It's a pretty
>> simple request: make the profile selection separate from the
>> codec.
> 
> The DNS is a single, unified, global service and it defines
> its own strings.  Interpretation (comparison) of strings must
> work the same in all cases.
> 

Dave,

I'm neither supporting nor opposing Eric's proposal (intent) at
this stage, largely because I have yet to get my mind completely
around enough of the detail of what he is really suggesting to
understand its implications.  But let me suggest something
slightly narrower, which I think is consistent with global
interoperability, in the hope of clarifying the conversation.

At least in principle, we have traditionally been able to have
three types of neatly hierarchical rules about the content and
interpretation of a DNS label:

	(i) Rules that apply DNS-wide, to all Classes and RR
	types, now and in the future.
	
	(ii) Rules that apply to all RRs within a particular
	Class.
	
	(iii) Rules that apply to a particular RR (by
	definition, within a particular Class).

One way of looking at the difference of opinion some of us have
had about octet interpretation and mapping is that some of the
documents have historically not been clear enough as to whether
they are expressing rules about a semi-enumerated set of RRs,
about all RRs in a Class, or about the DNS generally, but that
is a separate conversation that I don't want to restart here.

Nothing above provides for an application-dependent
interpretation, so you and I are in agreement about that and, if
that is what Eric really intends, we presumably jointly disagree
with him.

Now IDNA (and friends) add a new class of rule, which is to
permit giving different semantic interpretation to a label based
on the _content_ of that label, e.g., whether applications are
expected to map it to or from Unicode based on the presence of a
prefix.  Suppose Eric said, consistent with the typology above,
that we should specify that IDNA (and that
prefix-interpretation, nameprep, etc.) are to be applied only to
particular RR types within Class=IN, or to all of Class=IN but
not to Classes as yet undefined.   I'd be sympathetic to that: I
think tighter and more conservative definitions (that can be
expanded in the future if needed) tend to serve us well in the
long term.

And, to the degree to which this discussion is really about
getting us to a clear statement about where IDNA (and nameprep)
should and should not be applied, it seems to be to be a
legitimate, and necessary, part of the IETF discussion on IDNA,
nameprep, and the current set of documents.  

One could even argue that, to the extent to which the range of
applicability is not precisely defined today, or has not been
discussed sufficiently for a legitimate claim of WG consensus to
be made, it could be taken as evidence that the documents are
not ready for prime time.

     john

---

From: Dave Crocker <[email-masked]>
Date: Mon, 10 Jun 2002 11:33:09 -0700

>Not in the current design it isn't.

oh. well, that certainly clarifies things well.

You want a different DNS than the world has been using for 15 years.

That is considerably beyond the scope of IDN.

>define their own formatting rules and interpretations.

That's pretty cool.  You think that the interpretation of a DNS string 
depends on which application is interpreting it.

The interoperability impact of that idea is quite impressive.

>Reread the thread. What I seek is already offered in STD13 labels.

So, let's keep this simple.

Please describe two scenarios -- in the current, global Internet -- in 
which the same domain name string is interpreted differently by different 
applications.

In particular, your concern is about comparisons, so the example needs to 
demonstrate differential comparison results, according to which application 
is doing the comparing.

d/

----------

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 10 Jun 2002 13:48:17 -0500

> You want a different DNS than the world has been using for 15 years.

This kind of facile argument is pointless to respond to. The simple fact
is that a lowercase-only i18n namespace is pretty useless as a global
database of named objects.

> depends on which application is interpreting it.

The interpretation of the eight-bit codes in STD13 labels is entirely left
to local interpretation. If you disagree with this, you need to reread the
thread again.

> which the same domain name string is interpreted differently by different 

Any application which uses eight-bit values applies local interpretation
to those codes. Reread the thread.

> In particular, your concern is about comparisons

No, my concern is with limiting the usefulness of the i18n namespace.

I will give you a test question now: tell me anybody should be prohibited
from storing application-specific domain names as RR data without kneeling
at the lowercase alter. What is the exact problem you foresee with
allowing an external application to put whatever they want into the RRs
which suit their needs?

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 10 Jun 2002 14:01:09 -0500

on 6/10/2002 1:29 PM John C Klensin said the following:

> prefix.

Actually what it does is require that all domain names be converted into a
lowercase and normalized form, even if the domain name is only supplied as
data in the resource record.

> Suppose Eric said, consistent with the typology above,

What I want to do is define this on a per-name/per-RR basis:

  <nameprep> A <address>

  <nameprep> NS <nameprep>

  <nameprep> MX <pref> <nameprep>

Those rules result in exactly the same usage as the current IDNA model.
I'm not asking to turn everything upside down. What I'm asking for is that
if an application needs to use an uppercase or non-normalized domain name
for some reason, that they be allowed to do so, but only after defining a
strong profile. Eg:

   <fooprep> FOO <barprep>

This doesn't hurt anybody and puts the i18n namespace on equal footing
with the STD13 namespace.

Nobody has yet told me why this won't work.

---

From: John C Klensin <[email-masked]>
Date: Mon, 10 Jun 2002 16:05:11 -0400

--On Monday, 10 June, 2002 14:01 -0500 "Eric A. Hall"
<[email-masked]> wrote:

>> permit giving different semantic interpretation to a label
>> based on the _content_ of that label, e.g., whether
>> applications are expected to map it to or from Unicode based
>> on the presence of a prefix.
> 
> Actually what it does is require that all domain names be
> converted into a lowercase and normalized form, even if the
> domain name is only supplied as data in the resource record.

I think it does both of those things, and that they are
independent issues.  In a perfect world, they would be
independent of each other, but it isn't a perfect world.

>> prefix-interpretation, nameprep, etc.) are to be applied only
>> to particular RR types within Class=IN, or to all of Class=IN
>> but not to Classes as yet undefined.   I'd be sympathetic to
>> that: I think tighter and more conservative definitions (that
>> can be expanded in the future if needed) tend to serve us
>> well in the long term.
> 
> Those rules result in exactly the same usage as the current
> IDNA model. I'm not asking to turn everything upside down.
> What I'm asking for is that if an application needs to use an
> uppercase or non-normalized domain name for some reason, that
> they be allowed to do so, but only after defining a strong
> profile. Eg:
> 
>    <fooprep> FOO <barprep>
> 
> This doesn't hurt anybody and puts the i18n namespace on equal
> footing with the STD13 namespace.

Well, if you want to define it on a "per-name/ per-RR" basis,
which is what both your statement and your examples seem to say,
I think we are 95% there.  We already have per-RR rules (e.g.,
different name-formation rules for SRV than for A RRs) and, at
least wrt what to do if one gets back a name that contains an
ACE prefix, per-name rules.

> Nobody has yet told me why this won't work.

It seems to be that "work" has little to do with it -- this can
be seen as a precision of definition problem.

In that regard, it seems to me to be useful to avoid talking
about "equal... to STD13 names", or "hostnames versus domain
names" here, as those references are more likely to cause more
confusion than to shed light.

Instead, what is needed is one very clear paragraph in the IDNA
document (I think).  That paragraph should say that IDNA is to
be used (with nameprep, etc.) for the representation of
non-ASCII domain names in labels associated with RRs of type
<list 1> in Class=IN, that it MUST NOT (?) be used with RRs of
type <list 2> in Class=IN, and that it SHOULD NOT be used with
RRs of type <list 3> in Class=IN until and unless a
standards-track specification is produced that specifies
otherwise.  It should say similar things about data fields (for
MX, NS, CNAME, etc (?)) using similar lists.  It should, I
think, go on to specify that any future RR definition (in
Class=IN or otherwise) needs to specify whether or not IDNA is
to be applied and, preferably, should specify what happens if
that statement is left out.

I am assuming that <list 1>, <list 2>, and <list 3> are
disjoint, that they together include all Class=IN RRs that have
been defined and not formally deprecated, and that it is
possible that <list 2> and/or <list 3> might be null.

Would that meet your needs?   Is that what we are really talking
about?

If so, this is just a "more specification and clarity, less
hand-waving and ambiguity" issue, and it is hard to be opposed
to that.  I think.

     john

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 10 Jun 2002 15:27:08 -0500

on 6/10/2002 3:05 PM John C Klensin said the following:

> different name-formation rules for SRV than for A RRs)

Exactly. We already have:

  <srvprep> SRV <...> <nameprep>

  <nameprep> RP <mboxprep> <txtprep>

  <txtprep> TXT <...>

  <nameprep> SOA <nameprep> <mboxprep> <...>

Allowing <fooprep> FOO <barprep> isn't any different.

[snip]

> Would that meet your needs?   Is that what we are really talking

I'm not sure I understand the suggestion. Can you rephrase it? I'm not
sure that itemizing the RRs which IDNA can/cannot be used with (as is your
suggestion, I think) will accomplish the ultimate goal, since the whole
idea is to be able to use IDNA for any owner name which requires
conversion, regardless of the profile used with that owner name.

The only change that I think needs to be made is the existing ~"must be
used with nameprep" statement be replaced with ~"this specification is
specifically intended to be used with domain names which have processed
through nameprep, but it may be used with any profile of stringprep which
specifies a domain name". The specific usage rules for profiles and their
IDNA interaction can be detailed in the RR-specific declarations.

AMC and paf seem to be intimating that the IDNA labels may not be
reversible, which may require an additional fixup if so, and if it is
possible. If it isn't possible then the discussion is moot. We might as
well stick with STD13 labels for i18n domain names at that point.

---

From: John C Klensin <[email-masked]>
Date: Mon, 10 Jun 2002 20:50:54 -0400

--On Monday, 10 June, 2002 15:27 -0500 "Eric A. Hall"
<[email-masked]> wrote:

>...

>> Would that meet your needs?   Is that what we are really
>> talking about?
> 
> I'm not sure I understand the suggestion. Can you rephrase it?
> I'm not sure that itemizing the RRs which IDNA can/cannot be
> used with (as is your suggestion, I think) will accomplish the
> ultimate goal, since the whole idea is to be able to use IDNA
> for any owner name which requires conversion, regardless of
> the profile used with that owner name.

Sorry, right idea (probably), wrong focus and point of
attachment.

The rephrase, much abbreviated, would be a list of RRs for which
IDNA is applied, with the prep method used for each.  I think I
would do that as a small table, e.g.,

   RR       IDNA yes/no    Prep method

where the third column could be "n/a" or some-prep.  Actually, I
presume that we would either need more columns or something like
   RR  LOC   IDNA y/n      Prep
    A  label   y          nameprep
  TXT  label   y          nameprep
  TXT  data    y          ???
  foo  label   y          fooprep
  foo  data    y          barprep
  baz  label   n           n/a

And, again, we need to be explicit that anything new, anything
out of Class=IN, and anything not in the table, requires
explicit standards-track action to be used with IDNA.  If you
don't do that, we recycle in the recent interactions, in which
people insist that "undefined" has some very specific (i.e.,
defined) meaning for processing.

Is that more clear?

> The only change that I think needs to be made is the existing
> ~"must be used with nameprep" statement be replaced with
> ~"this specification is specifically intended to be used with
> domain names which have processed through nameprep, but it may
> be used with any profile of stringprep which specifies a
> domain name". 

But I'm not sure that will be true for all time.  And pretending
that we know that, now, doesn't really buy us any marginal
future value (which I can see, at least) and invites trouble.
That said, I'm not sure the table suggested above needs to be
part of the nameprep or IDNA documents.  But I do think that
document, if separate, needs to exist, and that the IDNA and/or
nameprep docs need to normatively reference it.

> The specific usage rules for profiles and their

You are proposing to put those declarations where?  Certainly we
should not claim that 1035, by some stretch of prescient magic,
specifies application of nameprep to the legacy RRs.  In case it
isn't obvious, that is really a question -- I don't have a
strong opinion as to where the specification goes, as long as it
is written down very clearly.

> AMC and paf seem to be intimating that the IDNA labels may not
> be reversible, which may require an additional fixup if so,
> and if it is possible. If it isn't possible then the
> discussion is moot. We might as well stick with STD13 labels
> for i18n domain names at that point.

I don't think this changes that answer above, nor do I know what
you mean by "reversible".  Certainly, to the extent to which
nameprep discards case, information is lost in getting to those
labels.

     john

---

From: Dave Crocker <[email-masked]>
Date: Mon, 10 Jun 2002 18:12:23 -0700

>interoperability, in the hope of clarifying the conversation.

Unfortunately, I am remaining highly confused.

The IDNA effort is about domain NAMES.

As nearly as I can tell, this thread is about domain name PARAMETERS, such 
as non-name fields in RRs.  Although this makes for a clearly important 
topic, it is not relevant to IDNA.

As a follow-on effort, to increase the "internationalization" of strings 
used for Internet standards, worrying about non-nameprep issues sounds like 
a dandy topic.

But how, oh how, does it relate to the current set of specifications that 
are seeking standardization.

d/

ps.  you profess to still lack some clarity about this thread.  for a 
thread that has been quite active for 2 weeks, I hope the lack of clarity 
bothers you.

----------

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 10 Jun 2002 20:25:17 -0500

>    RR       IDNA yes/no    Prep method

I think we mean we're in agreement on this. I would definitely expect such
a list to be the output from the effort to classify each of the current
RRs, although such a list should not be a part of IDNA specifically, but
instead would be part of the classification effort. Yes?

> defined) meaning for processing.

I agree with the CLASS=IN part but I'm not sure about the standards-track
requirement. Letting Apple or Microsoft or whoever make use of this stuff
without political interference from antis in the IETF seems like the best
way to make sure it gets used. I really want to give MS a reason to stop
using STD13 high-value codes and if that means they need to come up with
an NBT-A4 addressing resource record then so be it. There are other
requirements they will have to comply with such as maximum names and
stringprep compliance and that should be enough.

> You are proposing to put those declarations where?

My plan is to define the valid i18n usage of the existing RRs in the
DM-IDNS-01 spec, and to provide guidelines for the creation of new RRs
there as well (use nameprep if possible, must define stringprep profile if
otherwise, etc).

> is written down very clearly.

Does the above suit your requirements?

> nameprep discards case, information is lost in getting to those

That's nameprep in particular, however. What I am asking about is the IDNA
encoding output, once it is separated from nameprep. The profile in use
should dictate the canonical label format, not the codec.

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 10 Jun 2002 21:03:02 -0500

> The IDNA effort is about domain NAMES.

Yes

> as non-name fields in RRs.

No

RRs define the syntax of their owner name as well as the syntax of the RR
data. New RRs often need new domain name syntaxes, either for the owner
name, or for the RR data (although it's hard to imagine an RR data domain
name which isn't subsequently used for an owner name at some point). The
rules currently defined in IDNA impose restrictions on the syntax of every
new RR invented from here on out. While these rules are appropriate for
the owner names of legacy RRs which are queried through direct input, they
impose unnecessary restrictions on every subsequent RR which could ever be
defined, and regardless of where the input comes from. This is a
fundamental architectural design decision which needs very serious
evaluation. It seems to me that it is an easy problem to avoid: decouple
nameprep from the codec and the problem goes away forever, instead of
hanging around forever. Nobody has told me why this is undoable. Feel free
to weigh in.

---

From: "Adam M. Costello" <[email-masked]>
Date: Tue, 11 Jun 2002 02:06:11 +0000

John C Klensin <[email-masked]> wrote:

> document (I think).  That paragraph should say that IDNA is to be used
> (with nameprep, etc.) for the representation of non-ASCII domain names
> in labels associated with RRs of type <list 1> in Class=IN, that it
> MUST NOT (?) be used with RRs of type <list 2> in Class=IN, and that
> it SHOULD NOT be used with RRs of type <list 3> in Class=IN until and
> unless a standards-track specification is produced that specifies
> otherwise.  It should say similar things about data fields (for MX,
> NS, CNAME, etc (?)) using similar lists.

But IDNA has to work with more than just DNS, it has to work with the
wide variety of other protocols that carry domain names.  By logical
extension, your proposed paragraph needs to list every field/argument of
every protocol/interface where IDNA may/should-not/must-not be used.

Isn't that too much trouble (or even impossible)?  Isn't it simpler to
design IDNA so that it can safely be used for any (textual) domain label
anywhere?  That was our intention.

"Eric A. Hall" <[email-masked]> wrote:

> Resolvers, middle-boxes and replication masters all need to be able
> to convert between EDNS and ACE as part of the fallback process.
> Distributing the profile-specific prefix to every point where
> conversion might occur is a massive problem.

I was suggesting that conversion between ASCII and non-ASCII never
be done inside the infrastructure except possibly when it uses the
well-known standard profile; for application-specific profiles, I was
suggesting that conversion be done only at the edges.  This model avoids
profile-agnostic conversion; only entities that know the proper profile
perform the conversion, which simplifies the security analysis.

Your model is based on profile-agnostic conversion happening inside the
infrastructure.  Let's examine how that would benefit applications.
Applications interact with the infrastructure in basically two ways:
sending strings into the infrastructure, and receiving strings from the
infrastructure.

When sending strings that use an application-specific profile into the
infrastructure, the application must perform Stringprep itself, because
the infrastructure needs to compare the string but doesn't know the
profile.  Performing Punycode and prepending the prefix is not any
extra effort for the application programmer; whether the program calls
Stringprep(profile) or ToASCII(profile,prefix), it's one function call
either way.  So there's no benefit in this case.

Now let's consider applications receiving strings that use an
application-specific profile.  If the infrastructure cannot do
profile-agnostic conversion, then the application might receive an ACE,
whereas if the infrastructure can do profile-agnostic conversion, then
it can ensure that the application never receives an ACE.  Whether this
is a benefit depends on what the application does with the string.  If
it compares the string, then it needs to call Stringprep at least, and
calling ToASCII is no more trouble, so there's no benefit.  If the
application passes the string along to a non-human, ACEs are not a
problem, so there's no benefit.  If the application displays the string
to a user, then the ACE will need decoding, whereas a non-ACE wouldn't.
That's the one case I can think of where applications could benefit from
profile-agnostic conversion inside the infrastructure.

Now let's consider the cost of your model.  Profile-agnostic conversions
and comparisons can return wrong answers if the inputs are not prepared
using the proper profile (whether by accident or by malice).  There is
nothing in the label itself to indicate the proper profile; you want to
use the same prefix regardless of which profile is needed.  The entities
that depend on correct conversions and comparisons need to know the
proper profile, and you are assuming that will be implied by context,
like the DNS RR type.  But IDNA is useless if it only works for DNS,
it also needs to work for mail headers and SMTP commands and URIs and
SSL certificates and so on.  So before IDNA could be used securely in
a given protocol/interface/etc, one would need to wait for the proper
profile to be specified for that particular protocol/interface/etc.  I'm
sure that would be fine with you Eric, but it would defeat one of the
main design goals of IDNA, which is to allow applications to start using
it without waiting for standards to be updated.

I think it's simpler to have a single conversion and comparison rule for
all domain labels everywhere.  In the few cases where applications need
to coerce other data types into domain names while preserving mixed-case
or non-normalized strings, they can define their own mapping function
(which does not use the IDNA prefix), and they'll just have to do the
conversion themselves with no help from the infrastructure.

> we are left with the application always performing conversion.
> That design blows up the architectural benefits from having the
> middle-boxes do it (in particular, having the caches learn the data so
> they can cache it).

I don't understand this.  If the conversion to/from ACE is done only in
applications, then the strings on the wire are all ASCII, and caches
handle them just as they always have.

> Nobody has yet told me why this won't work.

I'm very leary of allowing <fooprep> on the left.  If <fooprep> does
not include case-folding, then two queries for names that differ only
in upper/lower case could return different data.  That's a fundamental
departure from the current model.

As for <barprep> on the right, the same argument could be made for
reverse queries, though I admit that reverse queries are hardly ever
used.  My main concerns were give above.

Would it work?  Maybe it would.  But is it a good idea?  It still
seems to me that allowing multiple profiles for domain labels is more
complication than it's worth.

> possible.

Punycode is reversible.  It can encode any sequence of integers, and the
input sequence can always be recovered exactly.

Nameprep is deliberately non-reversible.  It does normalization and
case-folding.

ToASCII is non-reversible only because it calls Nameprep.

If you were to define Eric's-ToASCII, which does not call Nameprep, then
it would be reversible.

AMC

---

From: John C Klensin <[email-masked]>
Date: Mon, 10 Jun 2002 23:26:50 -0400

--On Tuesday, 11 June, 2002 02:06 +0000 "Adam M. Costello"
<[email-masked]> wrote:

>> Instead, what is needed is one very clear paragraph in the
>> IDNA document (I think).  That paragraph should say that IDNA
>> is to be used (with nameprep, etc.) for the representation of
>>...
> But IDNA has to work with more than just DNS, it has to work
> with the wide variety of other protocols that carry domain
> names.  By logical extension, your proposed paragraph needs to
> list every field/argument of every protocol/interface where
> IDNA may/should-not/must-not be used.
> 
> Isn't that too much trouble (or even impossible)?  Isn't it
> simpler to design IDNA so that it can safely be used for any
> (textual) domain label anywhere?  That was our intention.

In that instance (see other note(s)), the section should be put
in another document, and the IDNA one should say something a bit
closer to:

	This protocol is an isolated piece of work that only
	coincidentally has anything to do with domain names.
	Its use with the DNS, or elsewhere, requires that a
	standards-track specification be written and approved by
	the IESG that specifies that it may be used with that
	other protocol and specifies the profile of stringprep
	to be used with it.

Now, that is further than I think it is useful to actually go
(in addition to making IDNA outside the charter of the IDN WG),
but maybe it illustrates the point.  I think you can't have it
both ways.  Either this is a DNS protocol, in which case it
needs to specify applicable RRs and fields and may reasonably
specify a <foo>prep profile --even if it can also be used for
names (domain and otherwise) in other contexts-- or it is a
generic internationalization protocol, in which case
applicability to the DNS and domain names needs to be specified
somewhere else.

It seems to me that there are huge advantages to the latter.
However, if we adopt that approach, we haven't completed any
work on domain name internationalization until that other
document is written and moved through the system.

    john

---

From: Dave Crocker <[email-masked]>
Date: Mon, 10 Jun 2002 20:31:08 -0700

At 09:03 PM 6/10/2002 -0500, Eric A. Hall wrote:
>New RRs often need new domain name syntaxes, either for the owner
>name which isn't subsequently used for an owner name at some point).

Please humor me a bit further.

What RR has a domain name syntax that is different from the one used for 
the web and email references?

What RR data has a domain name using a syntax that is different from the 
ones used for web and email references?

In other words, as I have asked before, please describe specific scenarios 
in which the same domain name is interpreted differently.

d/

----------

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 10 Jun 2002 22:41:21 -0500

on 6/10/2002 9:06 PM Adam M. Costello said the following:

> wide variety of other protocols that carry domain names.

I agree that it makes more sense to do this definition as part of the RR
classification effort.

> perform the conversion, which simplifies the security analysis.

However, this can cause significant amounts of requery traffic for
applications that pull data from DNS frequently. If a pair of applications
are able to exchange UTF-8 data directly and that data resides in DNS,
then the cache needs to be able to handle any fallback conversion which
may be required so that it can handle the next query for that data. If the
query failed at some remote point in the infrastructure (like the
authoritative zone for the owner name in question), then the
infrastructure would get whacked twice every time the application went to
ask for that data (once for the EDNS form, again for the ACE form). This
is a very serious concern and must be prevented at all costs. Conversion
in the middle is the essence of a dual-mode approach.

> If the
> problem, so there's no benefit.

That's not a correct assumption. Consider a situation where the
application uses UTF-8 for all protocol data. The future is not ASCII. I
am not designing for legacy systems. Those systems could only use
EDNS/UTF-8 for connections and logging (and some things like SMTP relays
can't even use it for that), while newer applications can use it for all
kinds of stuff.

This is getting into the ACE-vs-UTF-8 argument that we've already had and
it's not necessarily getting us further along on the current debate.
Skipping to the next section.

> use the same prefix regardless of which profile is needed.

If an application got a hold of a non-nameprep ACE domain name, the lookup
would fail whenever the name was acted upon. The ACE sequence for that
domain name could not be used for any of the RRs that the legacy
application was looking for (A, MX, whatever). EG, if zz--goop was linked
to the FOO RR then it could not be linked with an A RR, since only
nameprepped owner names could have been linked to A RRs. This is the exact
same scenario as trying to use a domain that only has a TXT RR for SMTP,
it ain't gonna work. While it's an unexpected failure, it certainly isn't
an unforseen failure, and is quite common already.

However, this is a good argument against letting sister owner names exist
which collapse to the same domain name.

> complication than it's worth.

The problem is that this is a permanent choice. Standards are measured by
their use, not their intent.

> Nameprep is deliberately non-reversible.  It does normalization and

That's the way it should be.

> If you were to define Eric's-ToASCII, which does not call Nameprep, then

How significant would the change be to have the application call the
appropriate profile prior to calling ToASCII, rather than having ToASCII
make the call itself?

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 11 Jun 2002 00:48:37 -0500

[missed the cc list, reposted]

> the web and email references?

SRV specifically uses a different syntax

> ones used for web and email references?

RP and SOA both use localpart which has a different syntax

> In other words, as I have asked before, please describe specific
> scenarios in which the same domain name is interpreted differently.

There is a difference between syntax and interpretation. I already
answered the interpretation part, which is that any eight-bit code value
will be interpreted differently by every application. Use DJB's Pi test to
see this for yourself if you don't believe me.

Now that I have answered your questions twice, perhaps you could answer
mine. What is the exact problem you foresee with allowing an application
to put whatever it needs into the RRs it uses?

---

From: Dave Crocker <[email-masked]>
Date: Tue, 11 Jun 2002 00:19:40 -0700

>to put whatever it needs into the RRs it uses?

The simplest answer is that IDNA has nothing to do with putting anything 
into RRs.

IDNA is about a micro layer above DNS and below applications, as it says 
quite explicitly in the IDNA document.

Any other concerns are secondary.

You seem to be insisting on pursuing a very interesting topic but in the 
wrong forum.

d/

----------

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 11 Jun 2002 15:57:19 +0200 (CEST)

Eric,

tell me again how this concersion would work with DNSSEC.

   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 11 Jun 2002 16:14:56 +0200 (CEST)

> tell me again how this concersion would work with DNSSEC.

Can't type today.
s/concersion/conversion/

  Erik

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 11 Jun 2002 09:24:37 -0500

on 6/11/2002 8:57 AM Erik Nordmark said the following:
>>convert between EDNS and ACE as part of the fallback process.

> tell me again how this concersion would work with DNSSEC.

As a placeholder, I have an RCODE for "conversion failed" which tells the
original application that the data was found but that it cannot be
converted. The application then has to reissue the query which the cache
can answer with whatever data it has received as part of the fallback
process. If the original query was provided in UTF-8 and the UTF-8 data is
provided with DNNSEC there is no need for this of course.

I am hoping that the DNSSEC people can help make this more efficient, but
this addresses the prima concern.

ACE+DNSSEC NODE:

 App/Resolver      Cache             ACE-Zone

 getWide(<IDN>)-->
                   getWide(<IDN>)-->

                                   <--NOTIMPL

                   get(<ACE-IDN>)-->

                                   <--<ACE+DNSSEC>

                <--FALLBACKFAIL
                   (cache ACE+DNSSEC)

 get(<ACE-IDN>)-->

                <--<ACE+DNSSEC>

UTF-8+DNSSEC NODE, ACE PARENT:

 App/Resolver      Cache             ACE-Parent         UTF8-Zone

 getWide(<IDN>)-->
                   getWide(<IDN>)-->

                                  <--NOTIMPL

                   get(<ACE-IDN>)-->

                                  <--<ACE delegation>

                   getWide(<IDN>)-------------------->

                                  <--------------------<UTF8+DNSSEC>

                                  <--<UTF8+DNSSEC>

                <--<UTF8+DNSSEC>

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 11 Jun 2002 09:39:10 -0500

on 6/11/2002 9:24 AM Eric A. Hall said the following:

my turn for a typo

>                                   <--------------------<UTF8+DNSSEC>

                                        ^^^^^^^^^^^
                                         erroneous

---

From: John C Klensin <[email-masked]>
Date: Tue, 11 Jun 2002 10:46:24 -0400

--On Tuesday, 11 June, 2002 00:19 -0700 Dave Crocker
<[email-masked]> wrote:

>> Now that I have answered your questions twice, perhaps you
>> could answer mine. What is the exact problem you foresee with
>> allowing an application to put whatever it needs into the RRs
>> it uses?
> 
> The simplest answer is that IDNA has nothing to do with
> putting anything into RRs.
> 
> IDNA is about a micro layer above DNS and below applications,
> as it says quite explicitly in the IDNA document.
> 
> You seem to be insisting on pursuing a very interesting topic
> but in the wrong forum.

Dave,

I started a much longer note yesterday in response to some of
your questions, then concluded that the detail, and perhaps the
whole note, was a waste of people's time.  But, since the
questions seem important, let me try to summarize the questions
and then try to address the issues.  (I believe Eric has
identified all of these issues and that I am just presenting
them in a different way, but that may not be correct -- I may
have misunderstood some of his remarks in a way that has
inspired other thoughts.)

To dispose of the last question first, yes, I find that close
variants of this discussion have been going on for two weeks, and
we still aren't sure what the question is, to be very troubling.
Given the possibility that there might be an important topic for
the committee to deal with, I sat out most of those two weeks,
listening and trying to understand the issues.  I think that is
a responsible approach, although you could (and I think have)
argue that, at this late date, anything that shows up is
sufficiently likely to be irrelevant that shutting down the
discussion is more efficient.

One result of the confusion is, I think, that we have managed to
get four separate topics intertwined and conflated.  That is
never a good way to make progress, so I want to try to separate
them back out.  In semi-random order, they appear to be:

(1) Is IDNA properly and adequately specified for the uses to
which it will be put and is it designed appropriately for that
range of uses?  It seems to me that this question is relevant to
any specification that IETF is considering standardizing.  The
answer may depend somewhat on the answer to the next question.

(2) Is IDNA closely bound to internationalization of the DNS or,
as you note above, is it really "about a micro layer above DNS
and below applications" and hence "has nothing to do with
putting anything into RRs"?  And are Eric's concerns properly
addressed to the IDNA specification or should they be focused
somewhere else?

(3) Should the applicability of IDNA in the DNS context, and the
xxx-prep procedures to be used with it, be specified on a per-RR
(and per-Class) basis?

(4) To what extent should out-of-band communications between
applications, which utilize strings which the applications might
construe as internationalized domain names, influence the design
of IDNA and, if so, what should the impact be?  I have problems
with this one, because I think it leads us straight into a
rathole, especially when character sets and representations used
in applications (or on particular systems) get into the mix.
But, especially if IDNA is a micro layer for applications use,
rather than a DNS adjunct, it seems to me that questions about
the implementability, usability, and efficiency of a proposed
protocol have always been fair game for discussion wherever the
protocol is discussed.

I'm addressing the first three of these in separate notes.  I'll
leave the fourth to others, but ask that they separate it into
another thread so that people who don't care can more easily
ignore it.

    john

---

From: Dave Crocker <[email-masked]>
Date: Tue, 11 Jun 2002 10:05:02 -0700

Looking forward to your detailed notes, I'll offer some sound bites:

At 10:46 AM 6/11/2002 -0400, John C Klensin wrote:
>range of uses?

Basically, IDNA replicates the model of MIME.  If there are problems with 
it, they are in the category of the usual, initial specification detail 
bugs that will be fixed as the document moves to Draft.  I haven't noticed 
any such detail bugs being cited yet.

It does not appear that there are any problems with the model.  The model 
has been incrementally improved and strikes me as having gotten quite clean 
at this point, for the purpose it is designed to serve.

>putting anything into RRs"?

Is MIME closely bound to multi-media email or is it a micro-layer above 
email?

The answer is yes to both parts, rather than representing mutually 
exclusive conditions, as the question implies.

That the general topic of internationalization is difficult and 
multifaceted will come as no surprise to folks who work on that challenging 
arena.  That it can benefit from divide and conquer should come as no 
surprise to folks experienced with IETF work.

To repeat:  Messing with RRs, for FURTHER internationalization sounds like 
a dandy idea.  Messing with RRs as part of IDNA will only have the effect 
of adding another couple of years of delay.

>xxx-prep procedures to be used with it, be specified on a per-RR

An excellent starting question, for a separate, follow-on effort for 
FURTHER internationalization of the DNS.

>of IDNA and, if so, what should the impact be?

I think your question nicely captures a source of confusion that is 
currently present.

My own answer is that

         a) making the scope of such an effort too large is a good way to 
ensure that it never gets done; however it is often easy to have that 
larger scope as a background agenda that is serviced along the way.

         b) we are some years too late for visiting that question upon this 
effort.

d/

----------

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 11 Jun 2002 20:39:37 +0200 (CEST)

[I changed the subject line]

> this addresses the prima concern.

Yes, the examples you provided make the RRset go end-to-end
so the signatures would work.

Presumably the benefits of this scheme is that that caching resolver can
cache both the FALLBACKFAIL RCODE for the <IDN> QNAME and the
actual RRsets for the <ACE-IDN> QNAME, so that other queries immediately get
the FALLBACKFAIL error and retry using the ACE form.
I'm not an expert in DNS (I haven't even read RFC 2308) so I don't know what
the issues is with negative caching in general, thus I can't tell
if this scheme introduces new issues.

Also, it isn't clear to me if the caching resolver needs to ensure that
the negative cache for the <IDN> and the RRsets for the <ACE-IDN> expire
in concert (or there are some other constraints on how they expire).
It would make sense to consult with folks on namedroppers for this.

  Erik

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 11 Jun 2002 16:50:03 -0500

on 6/11/2002 1:39 PM Erik Nordmark said the following:

> Presumably the benefits of this scheme is that that caching resolver
> can cache both the FALLBACKFAIL RCODE for the <IDN> QNAME and the
> actual RRsets for the <ACE-IDN> QNAME, so that other queries
> immediately get the FALLBACKFAIL error and retry using the ACE form.

The primary benefit is that DNSSEC works at all. For subsequent queries,
the application has explicitly stated interest in UTF-8 data, so it needs
to be told that the data isn't available, and that the data that *is*
available can't be converted. The resolver probably won't enter into any
decisions that the application makes as to what to do next.

I'm sure the DNSSEC brains can find a dozen ways to streamline and
simplify this. This is only presented to make it work.

> I'm not an expert in DNS (I haven't even read RFC 2308) so I don't know
> what the issues is with negative caching in general, thus I can't tell

Not this scheme in particular, although there are negative caching issues
in general. A "negative cache" works by getting a negative response and
some supporting data from a server (such as an SOA for the zone). In the
case of a NOTIMPL response to an EDNS question, however, there is no
supporting information (the server couldn't read the question section, so
it can't provide an SOA). There are simple ways to deal with the problem,
such as using TTL information from the resulting STD13 query (the NS
and/or SOA RRs in the authority section). For the most part, the existing
negative caching knowledge work without any difficulies, and only a couple
of new landmines. Some of these have resulted from changes in the fallback
model itself (DM-IDNS-00 did not have servers performing fallback more
than once on the first query, but this is necessary change to support
DNSSEC, and has introduced other issues).

> the negative cache for the <IDN> and the RRsets for the <ACE-IDN>
> expire in concert (or there are some other constraints on how they
> expire).

Domain names in general are supposed to be stored as UCS strings, not as
views of a string. This model allows the cache to construct a view based
on the incoming message format, without having to track 2x the data. In
that design, all expirations occur whenever the base entry expires. For
the most part, the well-known and understood negative caching rules can
apply without any additional effort, although there are some peculiar
issues (as with NOTIMPL described above).

The biggest difficulties are in managing the RR data.

> It would make sense to consult with folks on namedroppers for this.

Yeah, DM-IDNS-01 will be brought to them for discussion. I need to find
out what kind of architectural ramifications will be imposed by the IDNA
spec before I can finish writing this up, however. Contrary to certain
commentary, the current rules wrt nameprep being mandatory impose multiple
considerations on the design, as well as on the future use of RRs within
DNS in general.

---

From: "Adam M. Costello" <[email-masked]>
Date: Tue, 11 Jun 2002 21:51:07 +0000

[This message replies to messages from both Eric Hall and John Klensin.]

"Eric A. Hall" <[email-masked]> wrote:

> > well-known standard profile; for application-specific profiles, I
> > was suggesting that conversion be done only at the edges.  This
> > model avoids profile-agnostic conversion; only entities that know
> > the proper profile perform the conversion, which simplifies the
> > security analysis.
>
> If the query failed at some remote point in the infrastructure (like
> the authoritative zone for the owner name in question), then the
> infrastructure would get whacked twice every time the application went
> to ask for that data (once for the EDNS form, again for the ACE form).

I guess I still wasn't clear enough.  For labels that use
application-specific profiles, there would not be two forms inside the
infrastructure, only one form.  The application would always convert
to/from that form at the edges as necessary.  Inside the infrastructure,
dual forms would be used only for labels that use the standard profile.
This adds a small burden to applications that don't use the standard
profile, but it significantly simplifies the model.

> This is a very serious concern and must be prevented at all costs.

I think that's an exaggeration.  A factor-of-two increase in overhead
(which I'm not proposing, but even if I were) would not bring down the
network.  It would be small compared to the exponential growth of the
internet.

> appropriate profile prior to calling ToASCII, rather than having
> ToASCII make the call itself?

Whether Stringprep is called inside ToASCII or before ToASCII is beside
the point.  The real question is "How significant would the change be
to allow IDNA to use more than one profile?"  It would be a fundamental
change that greatly complicates the model.

Here are some more examples of the complications:

What happens when two labels that use different profiles are compared?
They might be identical in their UTF-8 forms but different in their
ASCII forms, so you might get a different answer depending on which form
they're in.  Do we need to prohibit the comparison of labels that use
different profiles?  Old software cannot possibly be aware of such a
prohibition.  What are the security implications?  How can we prohibit
such comparisons and still allow DNS ANY queries, which by their nature
need to compare the same query string against many names associated with
many different RR types?

The same issue arises when a domain label is copied from one slot to
another, and the two slots call for different profiles.  Does that need
to be prohibited?  Old software cannot be aware of the prohibition.
What are the security implications?

What if someone wants to associate multiple RR types with the same name,
and those RR types call for different profiles?

What profile should the owner name of a CNAME record use?  Should there
be a single profile for all CNAME records?  If so, which profile?  Or
should the owner of a CNAME record use the same profile as the name it
refers to?  If so, what happens when the latter name is in another zone
and its RR type gets changed without notice?  What are the security
implications?

Is it possible to create subdomains of domains that use non-standard
profiles?  If so, a single domain name might need a different profile
for each label.  But each name is associated with only one RR type.  The
RR type might imply which profile to use for the first label (or the
first k labels), but what about the rest?

Eric, you are obviously a smart guy, and it wouldn't surprise me if
you could solve all these issues, but I think the multi-profile model
is too complex and too subtle to be worth its modest benefits.  The
single-profile model covers the common case, and applications that can't
use the standard profile can still do what they need to do, as long as
they do it outside the infrastructure (before converting their data
types into domain names, and after converting domain names back into
their data types).

An analogy might help clarify that model.  Each U.S. citizen typically
has a social security number, which is nine digits.  It is possible (and
in fact trivial) to map social security numbers onto domain labels; for
example, 123456789.nicemice.net.  Domain labels can contain letters, but
that doesn't mean social security numbers can contain letters.  Domain
labels and social security numbers are two entirely distinct data types.

Similarly, data types like email address local parts are not domain
labels, even if they are sometimes mapped onto domain labels.  Just
because domain labels can (soon) contain non-ASCII characters, that
doesn't mean email address local parts can.  RFC 2822 says they are
ASCII, so they can't contain non-ASCII characters until someone defines
internationalized email address local parts.

IDN labels do not preserve case or non-normalized forms.  If an
application needs to map a data type onto a domain label, and the
data type contains non-ASCII text for which mixed-case forms or
non-normalized forms must be preserved, then the trivial mapping simply
won't work.  The application will need to design a more complex mapping
to suit its needs.  For example, when internationalized email address
local parts are defined, that specification will have the opportunity to
say how they get mapped onto domain labels.

Whenever you try to use one data type to represent another data type,
you might get lucky and find that it's trivial, or there might be a
mismatch and you might have to do more complex mapping/encoding.  That's
just the way it goes.

John C Klensin <[email-masked]> wrote:

> Either this is a DNS protocol, in which case it needs to specify
> applicable RRs and fields and may reasonably specify a <foo>prep
> profile --even if it can also be used for names (domain and otherwise)
> in other contexts-- or it is a generic internationalization protocol,
> in which case applicability to the DNS and domain names needs to be
> specified somewhere else.

It is neither.  Domain name is a data type that is used in many
many protocols, and DNS is just one of them.  IDNA is a technique
for enabling applications to use non-ASCII characters in domain
names, regardless of which protocol/interface those domain names are
traversing.  IDNA is not a generic internationalization protocol; it
applies only to domain names.  IDNA is not an extension of DNS; it is
not specific to any particular protocol.

[In another note you point out several places where the IDNA spec seems
to get too far into the guts of DNS.  I agree with a lot of that.  I
personally have kept a closer watch on sections 2 through 4 (which I
wrote the first draft of, and which say nothing about DNS) than on the
other sections (which existed before I got here).]

> construe as internationalized domain names, influence the design of
> IDNA and, if so, what should the impact be?

I'm not sure what you mean as "out-of-band" and "might construe".
The domain names that appear in SMTP MAIL and RCPT commands are,
I would say, very much in-band, and there's no "construing", they
are unmistakably domain names.  If we are going to enable non-ASCII
characters in domain names in DNS, but not in other protocols, what's
the point?

AMC

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 11 Jun 2002 18:31:31 -0500

> profile, but it significantly simplifies the model.

You are essentially arguing for maintaining two different DNS networks:
one for nameprep and one for "other". I don't see how that simplifies
anything. One DNS network where the servers store raw UCS sequences and
provide answers based on the query message is much simpler than using one
model for some RRs and another model for other RRs.

> network.  It would be small compared to the exponential growth of the

The problem is that it's all cumulative. There are three potential threats
to DNS growth: query rate, server cache sizes and bandwidth. Bandwidth
utilization is pretty low even for the .com TLD (less than a T3, last time
I looked). Cache sizes aren't threatened yet either. However, the
query-per-second rate is already very high. Add to that the other efforts
underway -- ENUM wants to give every phone number a domain name and
multiple RRs to play with, people want to put certificates in DNS and
"only" add a few million TCP connections to the load -- and you see how it
all adds up. Worse, you can't just add servers because the message size is
limited (well you can do stuff with anycast hacks and people are looking
at that stuff, but you can't just add more servers). Query rate is a very,
very serious matter as it is the most likely source of any short-term
usage cap, especially if everybody gets everything they want.

> the point.

I think it is the essence of the question. An application which is calling
ToASCII at all has an i18n domain name they have to work with, so they
have to validate the domain name anyway. If they have to do this anyway,
why does IDNA even need to do it at all? Surely you weren't planning on
people offloading basic integrity checks to IDNA?

> they're in.

I've already said twice that two domain names should not be allowed to
exist if they collapse to the same sequence (if they normalize to the same
string). As such, there is zero danger of this happening. Looking at this
hypertechnically, I don't personally believe that this is necessary (what
happens when anybody provides a typo domain name? they get the right
answer to the wrong question), but I believe that it is better to prevent
confusion and I've already advocated this restriction twice. No argument
here, move along.

> Do we need to prohibit the comparison of labels that use different
> profiles?

No, because different profiles should result in different octet sequences.
If two domain names share the same sequence, they have violated the rule
above about collapsing to the same domain name.

> Old software cannot possibly be aware of such a

See above.

You are working under the impression that the profiles will be treated
differently during comparison -- and you stated as much in your not to
John -- while this is absolutely wrong. All i18n zone data will be stored
as octet sequences. All comparison will be for octet strings. The only
time a server would need to do anything active with the data is when it
was piped from one format to another, and even that one step should not
require any knowledge of the preparation rules; just run it through the
codec and voila.

> and those RR types call for different profiles?

Prohibited. If an RR needs to reuse existing domain names then it will
have to use the profile for that RR. In the common case, new RRs will
always use nameprep since they many of them will want to take advantage of
zone domain names. But if one of these RRs needs to store data in some
other domain name then it can certainly reference that other (non-nameprp)
domain name in the RRdata.

> What profile should the owner name of a CNAME record use?

I've said multiple times (check the archives) that the owner name of a
CNAME will inherit the stringprep rules associated with the domain name in
the RRdata target.

> If so, what happens when the latter name is in another zone and its RR
> type gets changed without notice?

Presumably the owner name of the target will also change to suit the
profile of the new RR, thus invalidating the CNAME RR. If by some chance
the two profiles use the exact same syntax rules then the CNAME will still
fail because the RR type of the target has also changed. I mean, if a
custom RR of type FOO is changed to custom RR of type BAR, any application
that is looking for FOO at CNAME won't find it.

> profiles? 

I'm not sure I understand your question but if you are asking if it is
possible to create a subdomain delegation without using nameprep the
answer is no. Zone delegation requires NS RRs which uses nameprep for the
owner and data. If you are asking if it is possible to create a multilabel
owner name within a current zone then sure. If you are asking if these can
be confused, the answer is no, zone authority goes to the delegation not
to the sister owner names in the parent.

> is too complex and too subtle to be worth its modest benefits.

Thanks for the compliment, but these aren't problems that need to be
solved. They are all handled through existing DNS rules (including the
no-variations rule, which is also stated in STD13 but for a different
scope naturally).

> mismatch and you might have to do more complex mapping/encoding.  That's

The concern is to make the storage, transfer and comparison rules
consistent. That is still there. The only parts that are different are at
the applications which generate and interpret the octet-streams they get
as a result of the storage, transfer and comparison pass-thru rules. There
is zero additional complexity introduced in this part of the model. All of
the functions remain and still have to be executed by the same agents, the
only difference is that this model allows a larger number of agents to
play in the octet-stream pool.

> not specific to any particular protocol.

It is an extension to DNS in multiple regards, not the least of which is
that it implicitly and explicitly dictates the format of every future
resource record which can ever be invented.