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

["James Seng/Personal" <James@Seng.cc>]

Dan,

The shortest answer I can give you is to go thru our previous discussion
since Dec 99.

This requirements doc was drafted from various comments make across the
many months of discussion within this mailing list so technically, Zita
or myself are Editors, not Authors.

Please note that if you have specific objections to any requirements,
then the most constructive way to move forward with it is to propose
your version of the wording.

Zita is current busy with her work at NATO so I will be doing the last
tweaking. And as we discussed before, I will do the tweaking if there is
specific replacement wordings proposed, so please keep them coming.

Expect -05 as soon as next week.

-James Seng

----- Original Message -----
From: "D. J. Bernstein" <djb@cr.yp.to>
To: <idn@ops.ietf.org>
Sent: Wednesday, February 14, 2001 9:10 AM
Subject: Re: [idn] W.G. Last Call on "Requirements of Internationalized
Domain Names"


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