Re: [idn] W.G. Last Call on "Requirements of Internationalized Domain Names"

["D. J. Bernstein" <djb@cr.yp.to>]

I have five general objections to the document:

   (1) The models are oversimplified to the point of being deceptive.
   (2) Some of the requirements are unclear.
   (3) Some of the requirements are in conflict with current practice.
   (4) No justifications are provided for most of the requirements.
   (5) Many of the requirements overstate ``here's a cost to consider''
       as ``we must minimize this cost.''

I also have specific comments on several of the requirements.

> It MUST make the minimum number of changes to existing protocols on
> all layers of the stack.

This requirement is wildly overstated. If, for example, we can save
years of effort and billions of dollars in redeployment costs by making
one additional change to (e.g.) the SMTP protocol, then we should do so.

Obviously we should consider the number of protocol changes required. 
But this number is not the same as cost. Demanding that it be minimized
is stupid.

> It MUST continue to allow any system anywhere to resolve any
> internationalized domain name.

Huh? ``Continue'' to resolve IDNs? What IDNs?

> The protocol MUST NOT allow an IDN to be returned to a requestor
> that requests the IP-to-(old)-domain-name mapping service.

Huh? Why shouldn't gethostbyaddr() provide IDNs?

> [3] The same name resolution request MUST generate the same response,
> regardless of the location or localization settings in the resolver, in
> the master server, and in any slave servers involved in the resolution
> process.

This requirement prohibits widespread current practice. Example:
Akamai's responses depend on the location of the resolver.

> [4] The protocol MUST NOT require that the current DNS cache
> servers be modified to support IDN.

This is another wildly overstated requirement. We should, of course,
carefully evaluate all necessary upgrade costs.

> [5] A caching server MUST NOT return data in response to a query that
> would not have been returned if the same query had been presented to an
> authoritative server.

This needs clarification. If a cache receives foo CNAME bar from one
server, and bar A 1.2.3.4 from another, then it will end up sending one
message with both pieces of information, even though that data would not
have been returned from any particular server.

> However, these changes SHOULD be as small as possible

This is overstated.

> [8] The protocol supporting the service SHOULD be as simple as possible
> from the user's perspective. Ideally, users SHOULD NOT realize that IDN
> was added on to the existing DNS.

Huh? Aren't we _trying_ to provide extra features for users?

> [10] The best solution is one that maintains maximum feasible
> compatibility with current DNS standards as long as it meets the other
> requirements in this document.

This is wildly overstated.

> It also needs to sort names into order.

Maybe, maybe not. The only reason for this requirement is DNSSEC's
controversial NXT feature.

> [22] To achieve interoperability, canonicalization MUST be done at a
> single well-defined place in the DNS resolution process.

This is wildly overstated. With fast nameprep, canonicalization won't
happen anywhere in the resolution process, because names subject to
resolution will already be good names.

> The protocol MUST specify canonicalization;

It's clear to me that we need to define which names are good. It's not
clear to me that we should allow bad names.

> [27] Any conversion (case, ligature folding, punctuation folding, etc)
> from what the user enters into a client to what the client asks for
> resolution MUST be done identically on any request from any client.

This requirement prohibits widespread current practice. Example: some
browsers automatically append .com to certain names; some don't.

> [33] An IDN-capable resolver or server SHALL NOT generate more traffic
> than a non-IDN-capable resolver or server would when resolving an
> ASCII-only domain name.

This requirement is wildly overstated. I don't think there are any
serious proposals that would generate extra bandwidth for ASCII names,
but why should we refuse to listen if someone comes up with a great idea
that has this minor side effect?

We should, of course, carefully evaluate traffic costs.

> [34] The service SHOULD NOT add new centralized administration for the
> DNS. A domain administrator SHOULD be able to create internationalized
> names as easily as adding current domain names.

The second sentence, taken literally, is unreasonable. Clarify.

> [35] Within a single zone, the zone manager MUST be able to define
> equivalence rules that suit the purpose of the zone,

This requirement prohibits widespread current practice. I have no idea
what the authors are thinking.

> Slave servers MAY be either authorized by the zone owner (secondary
> servers) or unauthorized (so-called "stealth secondaries").

The authors are obviously a bit confused about DNS here.

The difference between a stealth secondary and a non-stealth secondary
is that a stealth secondary is not listed in NS records. Both types of
secondary are normally authorized by the owner.

---Dan