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

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

on 6/11/2002 4:51 PM Adam M. Costello said the following:
> [This message replies to messages from both Eric Hall and John Klensin.]

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

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.

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

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.

>>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?
> 
> Whether Stringprep is called inside ToASCII or before ToASCII is beside
> 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?

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

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

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.

> What if someone wants to associate multiple RR types with the same name,
> 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.

> Is it possible to create subdomains of domains that use non-standard
> 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.

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

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

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

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.

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

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.

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