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

From: Marc Blanchet <[email-masked]>
Date: Tue, 13 Feb 2001 09:27:56 -0500

This is a idn working group last call for comments on advancing the 
following document as a Informational RFC:

  	Title		: Requirements of Internationalized Domain Names
  	Author(s)	: Editors Zita Wenzel, James Seng
  	Filename	: 
http://www.ietf.org/internet-drafts/draft-ietf-idn-requirements-04.txt

Please send substantive comments to the idn mailing list, and minor
editorial comments to the authors.  This last call period will end two
week from today on February 28th, 2001.

Marc Blanchet and James Seng

(PS. stolen wg last call template from Bob Hinden, for those who recognize 
it...)

Marc Blanchet
Viagénie inc.
tel: 418-656-9254
http://www.viagenie.qc.ca

----------------------------------------------------------
Normos (http://www.normos.org): Internet standards portal:
IETF RFC, drafts, IANA, W3C, ATMForum, ISO, ... all in one place.

---

From: Jonathan Rosenne <[email-masked]>
Date: Tue, 13 Feb 2001 17:59:54 +0200

I object to requirement [25] as unworkable.

To follow the example given, I may be a Turk sitting in London and wish to
access a Turkish host. The hostname will be folded using a British locale, which
is wrong.

As far as I know this is the only case of conflicting case maps, and even if
there are a few more, I suggest to fold them all together, i.e. for IDN purposes
I and Dotless I are to be considered equivalent.

Jony

---

From: "Mark Davis" <[email-masked]>
Date: Tue, 13 Feb 2001 08:32:54 -0800

I think it is just badly worded, since the principle is clear.

[25] Case folding MUST be locale independent. For example, Latin
capital letter I (U+0049) case folded to lower case in the Turkish
context will become Latin small letter dotless i (U+0131). But in the
English context, it will become Latin small letter i (U+0069).

should be something like:

Case folding MUST be locale independent. If it were locale-dependent,
then different clients would get different results. For example, Latin
capital letter I (U+0049) case folded to lower case in the Turkish
context will become Latin small letter dotless i (U+0131). But in the
English context, it will become Latin small letter i (U+0069).

---

From: Jonathan Rosenne <[email-masked]>
Date: Tue, 13 Feb 2001 18:01:33 +0200

Sorry - my mistake - I misread the requirement.

Jony

---

From: "D. J. Bernstein" <[email-masked]>
Date: 14 Feb 2001 01:10:48 -0000

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

---

From: "James Seng/Personal" <[email-masked]>
Date: Wed, 14 Feb 2001 12:00:06 +0800

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" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, February 14, 2001 9:10 AM
Subject: Re: [idn] W.G. Last Call on "Requirements of Internationalized
Domain Names"

---

From: "D. J. Bernstein" <[email-masked]>
Date: 14 Feb 2001 04:49:54 -0000

> The shortest answer I can give you is to go thru our previous discussion

I have. The archives don't answer any of my objections.

---Dan

---

From: "Allen Smith" <[email-masked]>
Date: Sun, 18 Feb 2001 00:12:28 -0500

I see a problem with the following section:

>[2.6] The protocol MUST work for all features of DNS, IPv4, and
>IPv6.  The protocol MUST NOT allow an IDN to be returned to a requestor

It's _way_ too limited. It isn't just applications requesting
hostnames from IP addresses that'll get broken if they get back a
name containing characters that they don't expect (namely anything not 
allowed in RFC1123). It's an application asking for _any_ type of DNS
record containing a hostname. I suggest considering the problems on
UNIX, for instance, of a script that calls another program with a
domain name that it got back from an MX request. What happens if that
domain name has shell-active characters (redirection, etcetera)?
Potential problems, up to and including security holes.

Suggested rephrase:

[2.6] The protocol MUST work for all features of DNS, IPv4, and
IPv6.  The protocol MUST NOT allow an IDN violating [RFC1034] and
[RFC1123] to be returned to a requestor that does not request
IDNs. This provision MUST be enforced by either nameservers or
resolvers and SHOULD be enforced by both.

	-Allen

-- 
Allen Smith				[email-masked]

---

From: "Allen Smith" <[email-masked]>
Date: Sun, 18 Feb 2001 01:05:17 -0500

My apologies for replying to my own post, but I realized that people
might not understand why I'm suggesting a limit to the full standards
in RFC1123, including length et al. Buffer overflows. If one concludes 
that applications not allowing for this are broken anyway, one could
use instead:

[2.6] The protocol MUST work for all features of DNS, IPv4, and
IPv6.  The protocol MUST NOT allow an IDN with characters other than
alphabet (A-Za-z), digits (0-9), minus sign (-), and period (.) to be
returned to a requestor that does not request IDNs. This provision
MUST be enforced by either nameservers or resolvers and SHOULD be
enforced by both.

This will allow for long domain names created by ACE.

	Thanks,

	-Allen