Subject: [idn] Update Charter revision 2

From: "James Seng/Personal" <[email-masked]>
Date: Wed, 24 Oct 2001 10:59:26 +0800

Comments please.

-James Seng

--- CUT HERE ---
Description of Working Group:

The goal of the group is to specify the requirements for
internationalized access to domain names and to specify a standards
track protocol based on the requirements.

Domain names and host names are forms of identifier. Language
information is not encoded in these identifiers; that is, "names" from
different languages are defined in a single namespace.

The scope of the group is to investigate the possible means of doing
this and what methods are feasible given the technical impact they will
have on the use of such names by humans as well as application programs,
as well as the impact on other users and administrators of the domain
name system.

A fundamental requirement in this work is to not disturb the current use
and operation of the domain name system, and for the DNS to continue to
allow any system anywhere to resolve any domain name.

The WG work may modify the DNS protocol and other related work
undertaken by the DNSEXT WG. But such changes must be co-ordinated with
the DNSEXT WG.

The WG will reference work from ISO/IEC, the Unicode Consortium as much
as possible. The consideration are the policy and principle adopted by
the I18N group on the stability of published codepoints and future
addition
of codepoints. The discussion of new codepoints, codepoints properties
and
mappings between codepoints are out-of-scope for the working group and
should be done in other relevant expert group.

The group will not address the question of what, if any, body should
administer or control usage of names that use this functionality.

The group must identify consequences to the current deployed DNS
infrastructure, the protocols and the applications as well as transition
scenarios, where applicable.

The WG will actively ensure good communication with interested groups
who are studying the problem of internationalized access to domain
names.

The Action Item(s) for the Working Group are

1. An Informational RFC specifying the requirements for providing
   Internationalized access to domain names. The document should
   provide guidance for development solutions to this problem,
   taking localized (e.g. writing order) and related operational
   issues into consideration.

2. A standard track specification on access to internationalized
   domain names including specifying any transition issues.

3. A standard track specification on an ASCII Compatible Encoding
   (ACE). This may or may not be used in the standard track
   specification on access to internationalized domain names.

4. A standard track specification on normalization of identifiers
   for the purpuse of comparisons. This document may includes case
   folding, map outs, and prohibited characters.

Goal & Milestone:

Nov 2001    Nameprep RFC wg last call
Dec 2001    Nameprep RFC send to IESG for advancement
Nov 2001    First draft of architecture draft specifying the
            relationship between input methods, namepreps and zonefile
Dec 2001    Protocol RFC wg last call
Dec 2001    Second draft of architecture draft
Jan 2002    Protocol RFC send to IESG for advancement
Feb 2002    Architecture draft last call
Mar 2002    Architecture draft send to IESG for advancement

---

From: Yoshiro YONEYA <[email-masked]>
Date: Wed, 24 Oct 2001 12:49:49 +0900 (JST)

Hi,

From: "James Seng/Personal" <[email-masked]>
Subject: [idn] Update Charter revision 2
Date: Wed, 24 Oct 2001 10:59:26 +0800

Here are my comments.

- There is no target for 'Requirements' in milestone.  I think it
  should be.

- I think RFC target in milestone should be identical to action items.
  Is 'architecture' in milestone denoting item 2?  Is 'protocol'
  denoting item 3?  Please clarify relation between terms in milestone
  and action items.

- Nameprep is now divided into framework (stringprep) and profile
  (nameprep).  Is stringprep scope of this WG?  I think it is
  eventually yes at this moment but I'm not sure, so please clarify
  position of stringprep.

Best regards,

-- 
Yoshiro YONEYA <[email-masked]>

---

From: Martin Duerst <[email-masked]>
Date: Wed, 24 Oct 2001 12:32:49 +0900

This looked good to me, except that it would seem more
natural to have the architecture doc out before the specs
nailing down the details, and that i'm not sure how
stringprep fits into this picture (it's not listed below,
but we depend on it).

Regards,   Martin.

---

From: "Kenny Huang" <[email-masked]>
Date: Wed, 24 Oct 2001 12:12:44 +0800

If the goal of the working group is changed, then many of our discussion will 
become useless. The original description of WG is attached.
Are we exploring an evolving goal with evolving activities ? If that is the case, then
we can discuss re-ordering or TC/SC issues right here.

Kenny Huang
---------------------------------------------------------------------

The goal of the group is to specify the requirements for internationalized access to domain names and to specify a standards track protocol based on the requirements. 

The scope of the group is to investigate the possible means of doing this and what methods are feasible given the technical impact they will have on the use of such names by humans as well as application programs, as well as the impact on other users and administrators of the domain name system. 

A fundamental requirement in this work is to not disturb the current use and operation of the domain name system, and for the DNS to continue to allow any system anywhere to resolve any domain name. 

The group will not address the question of what, if any, body should administer or control usage of names that use this functionality. 

The group must identify consequences to the current deployed DNS infrastructure, the protocols and the applications as well as transition scenarios, where applicable. 

The WG will actively ensure good communication with interested groups who are studying the problem of internationalized access to domain names. 

The Action Item(s) for the Working Group are: 

1. An Informational RFC specifying the requirements for providing Internationalized access to domain names. The document should provide guidance for development solutions to this problem, taking localized (e.g. writing order) and related operational issues into consideration. 

2. An Informational RFC or RFC's documenting the various proposals and Implementations of Internationalization (i18n) of Domain Names. The document(s) should also provide a technical evaluation of the proposals by the Working Group. 

3. A standards track specification on access to internationalized domain names including specifying any transition issues. 
---------------------------------------------------------------------

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On 
> Behalf Of James Seng/Personal
> Sent: Wednesday, October 24, 2001 10:59 AM
> To: [email-masked]

---

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

I think the intention is this:

The discussion to do reordering is within scope. The table for
reordering in my view is a frequency analysis sorting and that maybe
within scope. If reordering creates any codepoints tables, then that
table is not.

The discussion of whether to do TC-SC equivalent matching, and if so,
where and how is also within scope.  The tables of TC-SC is not.

-James Seng

----- Original Message -----
From: "Kenny Huang" <[email-masked]>
To: "James Seng/Personal" <[email-masked]>; <[email-masked]>
Sent: Wednesday, October 24, 2001 12:12 PM
Subject: RE: [idn] Update Charter revision 2

>
> A fundamental requirement in this work is to not disturb the current
use and operation of the domain name system, and for the DNS to continue
to allow any system anywhere to resolve any domain name.
> 1. An Informational RFC specifying the requirements for providing
Internationalized access to domain names. The document should provide
guidance for development solutions to this problem, taking localized
(e.g. writing order) and related operational issues into consideration.
>
> 2. An Informational RFC or RFC's documenting the various proposals and
Implementations of Internationalization (i18n) of Domain Names. The
document(s) should also provide a technical evaluation of the proposals
by the Working Group.
>
> 3. A standards track specification on access to internationalized

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Wed, 24 Oct 2001 01:14:14 -0400

James,

The changes you propose (and I grant that someone else may have written them
and it just appears under your name as the co-chair of the moment) to the WG
description aren't useful. There are three, the first ("names") is irrelevant,
the second (DNSEXT) is probably wrong (this WG is going to modify DNS??? How
in an IDNA program?), and the third refers to two undefined entities, an "I18N
group" and "other relevant expert group".

The changes to you (see above) propose to the WG goals are also problematic.
You've got the WG turned into an ACE-specific WG. That is consistent with a
rough consensus (I don't mind being "wrong"), but inconsistent with your new
bit in the description section that touts this WG as something that may change
the DNS, outside of the DNSEXT WG. Pick one, but not both.

The proposed deletion of an informational RFC(s) documenting various proposals
and implementations and providing a technical evaluation of the proposals is a
real loss. I guess we'll find out if the IESG is so tired of this mess that it
is willing to conclude "de minimus".

I'm so unfond of the way the requirements draft has been edited that I don't
mind if it never sees the light of day, I don't think it got a close reading
since -07, when John observed that it didn't appear to have ever been the
subject of a close and careful reading.

Overlooking the hand waving, you propose to wrap up the IDN WG in six months.
I have the impression that even with an IDNA/Nameprep/ACE (amc-z) site of
drafts (which I don't support, but that's not the point), that carefully
getting to the point of closure of a WG with a complex problem area would
take sligtly longer -- given that no draft has yet gone to LC (other than
the requirements draft back in February, and possibly more than once since
then, corrections welcome). The experience of the http WG comes to mind.

BTW, your "(bias) summary of reordering discussion" note was the most
constructive thing I've seen you do.

Eric

---

From: "James Seng/Personal" <[email-masked]>
Date: Wed, 24 Oct 2001 13:20:10 +0800

Then propose the changes you want in the update charter.

Broad comments like this lead us nowhere nearer to the goal, unless of
cos your goal is to derail the group as long as possible.

-James Seng

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Wed, 24 Oct 2001 01:57:40 -0400

James,

My goal isn't to delay anything, here. I plan to exercise the LC periods
responsibly, but I don't consider that "delay" as its absence is "haste".

Here is a specific recommendation.

Delete every one of your (caveat, someone else could have written them, etc.)
deltas on the description section.

Delete every one of your (caveat, see above) deltas on the goals section.

This includes leaving the informational memo(s) as part of what this WG is
committed to delivering to the IETF.

What you do with the requirements document is up to you. I suggest you ask
for someone who actually cares and is careful to take over editing of it.
If you do that, then add it to the set of informational memo(s) this WG has
a stake in reporting out.

That is the easy part. The harder part is milestones.

There is (ideally) a set of standards track memos, and a set of informational
track memos. I've given this a lot more thought than the space after the "."
usually conveys. Your drafts and your WG with its "rough consensus" (not mine,
thanks) ought to reach LC between the 1st and 2nd meetings of next year. The
drafts you don't have even started, input methods, namepreps, zonefile, and
the forgotten writing order, and other bits that surface as all the big items
are "solved" should take you and your WG out through the end of the year, and
a really careful basic evaluation memo (revision of Paul's) not quite that
long.

Eric

---

From: "James Seng/Personal" <[email-masked]>
Date: Wed, 24 Oct 2001 14:04:10 +0800

No explaination other than asking for deletion?

-James Seng

----- Original Message -----
From: "Eric Brunner-Williams in Portland Maine" <[email-masked]>
To: "James Seng/Personal" <[email-masked]>
Cc: "Eric Brunner-Williams in Portland Maine" <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Wednesday, October 24, 2001 1:57 PM
Subject: Re: [idn] Update Charter revision 2

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Wed, 24 Oct 2001 07:47:16 -0400

> No explaination other than asking for deletion?

The author (whomever that may be) of the proposed changes to the WG charter,
"Description", and "Action Items" sections, contributed nothing useful, as
my prior note pointed out.

To be pendantic, I'm not "asking for deletion", you (or someone else, whoever
that may be), is asking to change the charter -- description, action items,
and goals and milestones.

If anything, this surprise "rechartering" is something that begs explination.

---

From: "James Seng/Personal" <[email-masked]>
Date: Wed, 24 Oct 2001 20:35:59 +0800

> and goals and milestones.

The reasoning behind the changes to the charter is stated in the first
revision of the update.
http://www.imc.org/idn/mail-archive/msg04341.html

I dont need to repeat here again.

> If anything, this surprise "rechartering" is something that begs
explination.

There is nothing surprising. It was asked and I have fore warn the group
about possible update to the charter, goal & milestone.

http://www.imc.org/idn/mail-archive/msg04217.html

-James Seng

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Wed, 24 Oct 2001 09:38:12 -0400

James,

Your note of the 23rd got exactly one response -- David Hopwood's, who
offered the text present in your final version's first change, but has
no compelling value to motivate a "rechartering".

Your second proposed change hasn't been discussed in the DNSEXT WG, has
it? It really _is_ rechartering to add "the [IDN] WG may modify the DNS
protocol and other work undertaken by the DNSEXT WG", neh?

The ironic part is that having so avidly, even abusively, taken a apps
path, infrastructure now pops up. Humor me. What is the rational again?
What was "unclear" about the relation between IDN and DNSEXT? Since this
WG isn't going to do anything but applications, by existing rough (wrong)
consensus, what is the necessity for "clarification"?

Your third proposed change really flatters the Unicadettes, but "mappings
between codepoints are out-of-scope" is odd. What is an "ACE" if not a
mapping from one range of integers (codepoints) into another, possibly
identical, range of integers?

If your point is to kill off reordering, and all the related hard items
of living with rfc2130 on a diet of 63 octets, say so.

Incidently, the "I18N group" is undefined.

Similarly, the "other relevant expert group" is undefined.

Your fourth change is an abuse of process.

Individuals, and co-chairs, do not by themselves, add or delete work items
from a working group, at least not according to rfc2026. Paul doesn't want
to continue to edit draft-ietf-idn-compare, fine. Now it is time to look
for a capable and interested editor, or bump this issue to the ADs and the
appeals chain.

Now everything in this item of mail is a repeatition of what I wrote, in my
first note.

If you want to maintain that I've not offered an explination for suggesting
that these of your (and whomever) proposed changes are better not made than
made, that's up to you.

Eric

P.S. All the co-chairs need to accomplish is to reconcile the timeline with
their, and the WG's collective, hoped for future accomplishments. Actually
attempting a re-chartering while attempting to get closure on complex and
contentuous deliverables is risk-seeking, not risk-adverse.

Then again, this is the WG that puts a recommendation into the scope statement
of its requirements draft, so anything is possible.

---

From: "James Seng/Personal" <[email-masked]>
Date: Wed, 24 Oct 2001 21:53:34 +0800

> no compelling value to motivate a "rechartering".

The recharter has been discussed for a while, some of them offline to
me. The note on 23rd is a notice that there will be a new update, not a
request for discussion. If you are surprised by it, then you have not
follow the list.

The idea is to explicitly limited the scope of work in IDN WG so we can
actually produce something. We been on a very vague charter for a long
time because we are exploring. But it is time to finish it up.

> protocol and other work undertaken by the DNSEXT WG", neh?

The text is extracted from the requirements doc. Your sentence is not
incomplete without the second. "But such changes must be co-ordinated
with the DNSEXT WG". Dont pull statement out of context.

The intention: It is possible that an IDN solution (e.g. UTF-8 solution)
would requires modify DNS protocol. However, such solution need to be
co-ordinate with DNSEXT WG. And Olafur is already aware of this
intention for a while (since San Diego?).

> consensus, what is the necessity for "clarification"?

Because you are assuming that IDNA is the only one moving forward. I am
assuming we will get other proposal.

> identical, range of integers?

"Mappings between codepoints" refers to codepoint tables mapping. You
are stretching the meaning. Of course, you can stretch anything you
want. I could argue the existing charter allows us to redefine a new
character code set for the purpose of IDN.

> of living with rfc2130 on a diet of 63 octets, say so.

I repeat the intention again:

"The discussion to do reordering is within scope. The table for
reordering in my view is a frequency analysis sorting and that maybe
within scope. If reordering creates any codepoints tables, then that
table is not.

The discussion of whether to do TC-SC equivalent matching, and if so,
where and how is also within scope.  The tables of TC-SC is not."

You have obviously twist my words, as usual.

> for a capable and interested editor, or bump this issue to the ADs and
the

The ADs have seen the proposed changes. The removed work item is deem no
longer neccessary or relevant at this moment in time. Some (or you) may
still argue it is relevant but on the whole, the topic of comparsion
have not and never been a focus of discussion in the group over the
24months.

> that these of your (and whomever) proposed changes are better not made
than

That is your opinion. I see no valid arguments in your comment.

Thank you but i like to hear from others.

-Jaes Seng

---

From: "James Seng/Personal" <[email-masked]>
Date: Wed, 24 Oct 2001 22:00:03 +0800

> - There is no target for 'Requirements' in milestone.  I think it

It is already move forward for IESG action. it is technically out of the
hand of the wg. (unless the iesg bounce it back to the group) so there
is no need for a explicit milestone.

I will put a changes there tho.

>   denoting item 3?  Please clarify relation between terms in milestone

some action items may have more than one RFC.

>   eventually yes at this moment but I'm not sure, so please clarify

Good question. As far as it stand now, only draft-ietf-idn-nameprep is
part of IDN work. draft-hoffman-stringprep is not. How it goes will
depends on the author.

I suspect only nameprep will stay within IDN group and stringprep may
remains generic or go to other wg, which may not be formed yet.

-James Seng

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Wed, 24 Oct 2001 12:59:42 -0400

James,

If writing "you have not follow the list" makes you feel better, enjoy.

In 030701c15c37$e463d8b0$1401000a@jamessonyvaio, Subject: [idn] Update
>--- CUT HERE ---
...

In 005a01c15c93$4610ab50$1501000a@jamessonyvaio, Re: [idn] Update Charter
revision 2, you wrote:
...
> The note on 23rd is a notice that there will be a new update, not a
> request for discussion.

Now, as to the substance.

Of the changes you propose to the Description section, only one, the 3rd,
has the effect of limiting scope. Whether the limit is useful is another
issue.

The second proposed change:

	The WG work may modify the DNS protocol and other related work
	undertaken by the DNSEXT WG.

	But such changes must be co-ordinated with the DNSEXT WG.

I left off comment on the second sentance because it is unnecessary, no
matter what the first sentance reads, in fact, the very idea that your
off-list discussion has extended to you controlling authority over DNSEXT
is comic.

> assuming we will get other proposal.

In your working group there is rough consensus to exclude any non-application
framework, and the DNSEXT WG exists for extensions to the DNS (and in this
context "DNS" is understood not to be an "application", though it sure as heck
is one).

I'm writing a UTF-8 draft (no surprise except how long its taking), and Erik
asked me to send a copy to your working group, but I'm submitting it to the
DNSEXT WG, for consideration to adopt as a working group document, not to your
WG, which I view as out of control and about the worst run WG I've seen in the
decade+ I've been participating in the IETF. To be fair, most of my work since
the mid-80's has been in a more collegial operating systems environment, where
higher levels of professional courtsey are the norm. 

Commenting on the third proposed change, you observed:
...
> I could argue the existing charter allows us to redefine a new
...

Correct. This was the subject of a discussion (off-list) between myself,
the ADs (Erik and Tom), the technical advisors (John and Harald), Patrik,
and both you and Marc.

There is a difference between creating an alternative or alternatives to
iso10646, and discussing CRLF mapping. In your zeal to control the reordering
problem space (and it is complex), you over reached.

> You have obviously twist my words, as usual.

Maybe you made a mistake. Consider the possibility.

> ... I see no valid arguments in your comment.
>

By all means, the work group is more than just some egos let loose on a list.

Eric

---

From: Martin Duerst <[email-masked]>
Date: Thu, 25 Oct 2001 12:34:56 +0900

>remains generic or go to other wg, which may not be formed yet.

Hello James,

I have raised this issue, too. The title of the 'nameprep' draft
is now "Stringprep Profile for Internationalized Host Names",
and this is an accurate reflection of it's content. 'nameprep'
therefore depends on 'stringprep'. If we want to go to Proposed
Standard with 'nameprep', we cannot have 'stringprep' still as
an I-D. Given your schedule for 'nameprep', it seems impossible
for a new WG to be formed and to take up and finish 'stringprep'
in time. Also, it seems quite dangerous to leave 'stringprep'
to it's authors without at least close coordination with this
WG. Leaving this at suspicions is not good enough. It shouldn't
be difficult to improve on this given that the authors of
stringprep are one of the co-chairs in this group and an
active participant of this group.

Regards,   Martin.

---

From: David Hopwood <[email-masked]>
Date: Thu, 25 Oct 2001 08:34:56 +0100

-----BEGIN PGP SIGNED MESSAGE-----

James Seng/Personal wrote:
> hand of the wg.

Nonsense. There has been no Last Call. I made comments on the draft that
have not been adequately addressed (in fact none of my technical points
were addressed at all). Until the end of the Last Call period, the document
certainly isn't "out of the hands of the WG".

It is worth pointing out that:

 - IDNA does not satisfy requirements 11 (since it allows unassigned
   codepoints in queries without versioning) and 18 (since it allows
   more than one representation of a name, differing in case),

 - no solution that requires changes to the DNS protocol can satisfy
   requirement 1,

 - no solution that uses both ACE and transparent representations can
   satisify requirement 18.

IMHO there is little point in publishing a document specifying
requirements that are unachievable.

Here are my comments again, and hopefully we can have some substantive
technical discussion of them this time.

- -----

The original (-08) document is quoted using '>', and my suggested changes
are quoted using '=>'.

> 6. A transfer encoding syntax (TES) is a reversible transform of encoded
>    data which may (or may not) include textual data represented in
>    one or more character encoding schemes. Examples: 8bit,
>    Quoted-Printable, BASE64, UTF-7 (defunct), UTF-5, and RACE.

This definition is never used.

> ... This document attempts to
> set requirements for an equivalent of the "used services" given above,
> where "hostname" is replaced by "Internationalized Domain Name". This
> does not preclude the fact that IDN should work with any kind of DNS
> queries. IDN is a new service. Since existing protocols like SMTP or
> HTTP use the old service, it is a matter of great concern how the new
> and old services work together, and how other protocols can take
> advantage of the new service.

IDN is not a new service; it makes more sense to consider it as an
extension of all the existing services. For example, in IDNA, the
existing IP-to-hostname service can return an (ACE-encoded) IDN, or a
non-IDN query can follow a DNAME record that points to an IDN. These
cases wouldn't be possible if IDN was a separate service.

=> ... This document attempts to
=> set requirements for extensions of the "used services" given above,
=> where "hostname" is replaced by "Internationalized Domain Name".
=> That is, IDN should work with any kind of DNS queries. Since we are
=> extending services used by existing protocols like SMTP or HTTP,
=> compatibility with these existing uses is a matter of great concern,
=> as well as how both new and old protocols can take advantage of the
=> new facilities.

> 2. General Requirements
> 
> These requirements address two concerns: The service offered to the
> users (the application service), and the protocol extensions, if needed,
> added to support this service.
> 
> In the requirements, we attempt to use the term "service" whenever a
> requirement concerns the service, and "protocol" whenever a requirement
> is believed to constrain the possible implementation.

What we are setting requirements for are IDN proposals. Some (not all)
of the cases where "service" or "protocol" is used should actually say
"proposal", IMHO. I've made those changes below without further comment.

> [1] The DNS is essential to the entire Internet. Therefore, the service
> MUST NOT damage present DNS protocol interoperability. It MUST make the
> minimum number of changes to existing protocols on all layers of the
> stack.

Requiring the "minimum number of changes" fails to consider the cost
or feasibility of any change; it is requiring an absolute, which is
always a bad idea.

I.e. if proposal B needs protocol changes in addition to those of proposal
A, then no matter how insignificant the cost of those changes are, or what
other advantages B has, this requirement would eliminate B. The effect is
that minimising protocol changes overrides every other consideration.

> It MUST continue to allow any system anywhere that implements
> the IDN specification to resolve any internationalized domain name.

"continue to" should be deleted. Obviously no system can resolve an IDN
at the moment.

=> [1] The DNS is essential to the entire Internet. Therefore, the proposal
=> MUST NOT damage present DNS protocol interoperability. It MUST allow any
=> system anywhere that implements the IDN specification to resolve any
=> internationalized domain name. The overall cost and feasibility of
=> changes to existing protocols, on all layers of the stack, is of great
=> importance when evaluating any IDN proposal.

> [3] The DNS protocol (the packet formats that go on the wire) MUST
> NOT limit the codepoints that can be used. A service defined on top of
> the DNS, for instance the IDN-to-address function, MAY limit the
> codepoints that can be used. The service descriptions MUST describe
> what limitations are imposed.

The packet formats that go on the wire use octet strings, not strings
of codepoints. In order to maintain compatibility with the requirements
of RFC 2181, it is the set of octet strings that must not be limited.

Also, there may be other restrictions on host names besides the set of
allowed codepoints (for example relating to mixing of left-to-right and
right-to-left scripts, or names that start with an ACE prefix).

=> [3] The DNS protocol (the packet formats that go on the wire) MUST
=> NOT limit, apart from in length, the set of octet strings that can be
=> used as an encoded domain name. A service defined on top of the DNS,
=> for instance the IDN-to-address function, MUST define a mapping between
=> host name strings and these octet string encodings, and MAY impose
=> limitations on host names, for example by restricting the set of
=> allowed codepoints. The service descriptions MUST describe what
=> limitations are imposed.

> [4] 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
> that requests the IP-to-(old)-domain-name mapping service.

This is unclear. Returning an ACE name to an "old" requestor will
clearly not break anything, and an ACE name is an (encoded) IDN. It also
doesn't take into account that some resolver interfaces are already
Unicode-aware, in which case they would not require any distinction
between old and new requests (this is true for InetAddress.getHostName
in the Java API, for example, or for getipnodebyaddr, etc. in Plan-9).

=> [4] The proposal MUST work for all features of DNS, IPv4, and IPv6.
=> The proposal MUST ensure that the responses to requests for an IP
=> to domain name mapping will not break existing requestors.

> [5] 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 is also unclear (with respect to the resolver; I agree about the
rest). Surely it wasn't meant to prohibit any use of locale information
in defining the API to the resolver?

=> [5] The same name resolution request MUST generate the same response,
=> regardless of the location or localization settings in the master
=> server, or in any slave servers involved in the resolution process.
=> Any description of functionality required of a resolver API MUST
=> discuss any dependency of the API on localization settings in the
=> client.

> [8] The service MAY modify the DNS protocol RFC 1035 and other related
> work undertaken by the DNSEXT WG. However, these changes SHOULD be as
> small as possible and any changes SHOULD be coordinated with the
> DNSEXT WG.

"As small as possible" is too strong - it is possible to support IDNs
without changing the DNS/DNSEXT protocol at all, and so this is equivalent
to "the DNS/DNSEXT protocol SHOULD NOT be changed". Nevertheless, changing
it may have advantages.

=> [8] The proposal MAY modify the DNS protocol RFC 1035 and other related
=> work undertaken by the DNSEXT WG. However, any such changes SHOULD be as
=> small as needed to support the basic design of the proposal, and SHOULD
=> be coordinated with the DNSEXT WG.

> [9] 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.

A better way of expressing this is

=> [9] The user's perspective of each service SHOULD be as simple as can
=> be practically achieved. Ideally, users will find the services no more
=> difficult to use than if internationalised names had always been
=> supported by the DNS.

> [11] The protocol should handle with care new revisions of the CCS.
> Undefined codepoints should not be allowed unless a new revision of
> the protocol can handle it. Protocol revisions should be tagged.

The current version of nameprep allows unassigned code points in queries
without revision tagging, for good reasons.

=> [11] The proposal should handle with care new revisions of the CCS.
=> Proposals MUST discuss how undefined codepoints are handled.

> [12] Internationalized characters MUST be allowed to be represented and
> used in DNS names and records. The protocol MUST specify what charset is
> used when resolving domain names and how characters are encoded in DNS
> records.

Note that "charset" usually means a MIME-registered charset, which is
not necessarily the case here (for example when the encoding is ACE, or
when more than one possible encoding is allowed - see [18] below).

In fact the modified version of [3] above requires the mapping between
host names and the octet strings used on the wire to be specified (and
in any case, not doing this would be a violation of BCP 18), so the
second sentence is now redundant.

=> [12] Internationalized characters MUST be allowed to be represented and
=> used in DNS names and records.

[14], [15], [16], [17]: protocol -> proposal.

> [18] While there are a wide range of devices that use the DNS and a
> wide range of characteristics of international scripts and methods of
> domain name input and display, IDN is only concerned with the
> protocol. Therefore, there MUST be a single way of encoding an
> internationalized domain name within the DNS.

No, there does not need to be a single way of encoding an IDN (there is
not even for pure ASCII names, because equivalent names that differ in
case are allowed in the DNS protocol). For example, a solution where
names on the wire can be either ACE or UTF-8 will work perfectly well.
The wire encoding isn't even directly visible to users or applications,
so I don't see why the requirements document should be saying anything
about it.

If the intention was to refer to the external representation of a name,
rather than the wire encoding, that would prohibit any solution that
involves a transition from ACE to transparent names, or simultaneous use
of ACE and transparent names. Either way, this requirement is unnecessary
and should be deleted.

> [19] To achieve interoperability, canonicalization MUST be done at a
> single well-defined place in the DNS resolution process. The protocol
> MUST specify canonicalization; it MUST specify exactly where in the
> DNS that canonicalization happens and does not happen; it MUST specify
> how additions to ISO 10646 will affect the stability of the DNS and
> the amount of work done on the root DNS servers.

The overspecification here is "at a *single* ... place". For example,
if canonicalization is specified by nameprep, it is idempotent, i.e.
nameprep(nameprep(x)) = x. So doing it more than once only hurts
efficiency, not interoperability or any other requirement. It doesn't
even hurt efficiency very much, since the common case where a name is
already in the correct form can be optimised.

> ... The protocol MUST specify canonicalization; ...

This is meaningless without specifying what the goal of canonicalization
is. The minimum requirement is to ensure that characters that are
indistinguishable to users are treated the same, and so that is what
should be stated:

=> [19] Characters that appear absolutely indistinguishable to users
=> MUST be canonicalized. To achieve interoperability, canonicalization
=> MUST be done at a well-defined place or places in the DNS resolution
=> process, i.e. the proposal MUST specify exactly where in the DNS
=> canonicalization can and cannot happen.

[I changed "happens and does not happen" to "can and cannot happen",
because whether a particular piece of the infrastructure actually does
canonicalization will depend on which pieces have been upgraded. If they
haven't been upgraded, then they obviously won't do canonicalization,
regardless of whether the IDN proposal says that they should.
Note that this is a potential motivation for a proposal to specify that
canonicalization may be done in more than one place.]

> [23] If other canonicalization is done, it MUST be done before the
> domain name is resolved.

It makes perfect sense to do canonicalization as part of resolution, not
before it. Also, canonicalizing after resolution is certainly feasible,
even if it is inefficient.

> ... Further, the canonicalization MUST be easily
> upgradable as new languages and writing systems are added.

It *will not* be easy to upgrade canonicalization, no matter where or how
it is done, because the incentive to upgrade to support scripts that most
people will consider completely obscure, is much less than the incentive
to get IDN support working the first time round.

=> [23] Consideration MUST be given to the ease of upgrading
=> canonicalization as new languages and writing systems are added.
=> As long as a name containing new characters has been canonicalized
=> according to the latest canonicalization version, resolving that name
=> MUST NOT depend on further upgrades to the resolver or DNS servers.

> [25] If the charset can be normalized, then it SHOULD be normalized
> before it is used in IDN. Normalization SHOULD follow Unicode
> Technical Report #15.

Although this describes a perfectly reasonable approach, it does not
belong in a requirements document. [26] already captures part of the
requirement ("The protocol SHOULD avoid inventing a new normalization
form provided a technically sufficient one is available."), and the
modified [19] above captures the rest. So, delete this requirement.

[29]: service -> proposal.
[30]: protocol -> proposal.

> 3. Security Considerations
> 
> Any solution that meets the requirements in this document MUST NOT be
> less secure than the current DNS.

That is not necessarily achievable. The main issue is name spoofing using
look-alike characters: even if a proposal specifically tries to address
that (by registration procedures, for example), it can't absolutely
guarantee that there will not be cases of this that rely on IDNs.

> Specifically, the mapping of
> internationalized host names to and from IP addresses MUST have the
> same characteristics as the mapping of today's host names.
> 
> Specifying requirements for internationalized domain names does not
> itself raise any new security issues. However, any change to the DNS MAY
> affect the security of any protocol that relies on the DNS or on
> DNS names. A thorough evaluation of those protocols for security
> concerns will be needed when they are developed.

That evaluation is needed for existing protocols, not just new protocols.

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

---

From: "James Seng/Personal" <[email-masked]>
Date: Thu, 25 Oct 2001 16:45:35 +0800

> Nonsense. There has been no Last Call. I made comments on the draft
that

Last Call is norm but not neccessary. It was agreed on London meeting to
move forward the doc since there is no comments or any changes proposed

> were addressed at all).

Your comments comes after the doc have been moved forward for IESG. Any
changes to it will have to wait after their review.

-James Seng

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 25 Oct 2001 10:39:32 +0200 (CEST)

> certainly isn't "out of the hands of the WG".

David,

there was a WG last call on the document on the mailing list in February - see 
the attached email.

Based on this last call the chairs forwarded the requirements document
to us ADs on Oct 2. But as James later clarified this doesn't mean that
folks can't continue to discuss the document - it just means that the
chairs concluded there was rough consensus in the WG for moving the document
to the next step.

The process moving forward is that the ADs (Thomas and I) will read
the document to determine whether it is ready for IETF wide last call.
While we haven't completeled this yet it is very likely to result in
feedback to the WG that the document needs to be clarified.

So I'd urge other to participate in continued discussion on the requirements
document to make it clear and concise and also to verify that the solution(s)
that the WG are working on indeed match the requirements. (If they don't
either the requirements or the solution(s) need to be fixed.)

   Erik

> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3i
> Charset: noconv
> 
> iQEVAwUBO9e+oDkCAxeYt5gVAQEOCgf8Dgk0sC/8cl1ltpRRy/CZKwSdj4Cs89EV
> tRqu4+DOBRBRE5x0s1ZkQKxCx2VjKu2fJ73lHLDsqiWgwolfOlO0cx4iovfpempy
> K2yPytC+n37yUjaxX3iTJYe48KNuozldNjdtV1F4SXQCbKfNRDQhHVqQj/2CTzCy
> PNYPTZpcFoL/gXLJ94QyBCAH24EIS7n3FuAY0rDt3IWyG1Lbdkr1SkpDzf7iToji
> msuMl00YOn6u1TL3DO9qBBzejHVav5Bpw9L/NXGEIgtjZl1ShPgLRwFBztLC0IrV
> lewoJInjswf4sCXW2yEBOeyZq99pzQ1FLZpwTdkXf4zkm2nHOSn+Wg==
> =FDVk
> -----END PGP SIGNATURE-----
> 

Subject: [idn] W.G. Last Call on "Requirements of Internationalized Domain Names"
From: Marc Blanchet <[email-masked]>
To: [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: Erik Nordmark <[email-masked]>
Date: Thu, 25 Oct 2001 10:49:20 +0200 (CEST)

> changes to it will have to wait after their review.

The WG should discuss the comments and they can even decide how they'd like
to modify the document.
But it is best to not issue an updated I-D until the AD review comments 
are back.

  Erik

---

From: "James Seng/Personal" <[email-masked]>
Date: Thu, 25 Oct 2001 19:02:49 +0800

Thanks Erik. Yes, that is what I mean.

Discussion of the points raised by David can and should continue.

But dont expect any update to the doc for a while.

-James Seng

---

From: "Soobok Lee" <[email-masked]>
Date: Fri, 26 Oct 2001 02:01:46 +0900

----- Original Message ----- 
From: "David Hopwood" <[email-masked]>
> => Proposals MUST discuss how undefined codepoints are handled.

I agree on this modification.

current nameprep I-D:

  1) old nameprep's applications may find its unassigned code points in
      received queries that come from newer nameprep's applications.
  2) but, old nameprep cannot generate ACE labels with at least one
      unassigned code point.

2) requires  old nameprep applications should be upgraded to
support newly assigned script. Auto-update  features will help 
some interative applications, but may not be available  for  
non-interative/offline-mode idn-aware applications or embedded IDNA
applets / OCX components which has no human or outerworld interaction.
Some disruption/failure in service may be caused by this latter situation.

Soobk Lee

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 25 Oct 2001 14:38:00 -0700

>active participant of this group.

Martin is right: we cannot finish nameprep until stringprep is 
finished. If the WG chairs don't want it as part of the WG, that's 
fine, but it is going to go through the same IETF last call as 
nameprep will. There is no reason not to have it in this WG.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Dave Crocker <[email-masked]>
Date: Thu, 25 Oct 2001 15:10:27 -0700

At 02:38 PM 10/25/2001, Paul Hoffman / IMC wrote:
>Martin is right: we cannot finish nameprep until stringprep is finished. 
>If the WG chairs don't want it as part of the WG, that's fine, but it is 
>going to go through the same IETF last call as nameprep will. There is no 
>reason not to have it in this WG.

In fact, there is every reason TO have it in this working group:

1.  the work has been done here.
2.  no other working group is laying claim to it.
3.  we need the work.
4.  we need it NOW.

People have confused the need to separate a specification into two parts 
with the idea of having the two parts done by different groups.

The problem with the previous combining into one document was not that the 
technical content was a bad idea or particularly badly written.  It was 
that having them combined proved to be very confusing to people and that 
separating the parts makes clearer what part is general and what part is 
specific to the DNS.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

---

From: "James Seng/Personal" <[email-masked]>
Date: Fri, 26 Oct 2001 08:12:41 +0800

Agree with Martin too.

But clarification: whether stringprep should be within IDN wg is a bit
more complex. Obviously with the dependency, it should be.

-James Seng

---

From: Martin Duerst <[email-masked]>
Date: Fri, 26 Oct 2001 16:04:11 +0900

>with the idea of having the two parts done by different groups.

Very much agreed up to here.

>that having them combined proved to be very confusing to people

This is the first time I have heard this argument.
It wasn't confusing to me, but maybe that's because I have
been involved in various discussions about it.

>and that separating the parts makes clearer what part is general and what 
>part is specific to the DNS.

To separate the general and the specific parts, in order to be able
to reuse the general parts, is a very valuable goal.

I'm personally not sure we already understand what part is really
general, and what part is specific. Of course, because for IDN we
need all of it, it doesn't really matter to this group.
But I'm a bit afraid that other groups might try to use the general
part of it (stringprep) without checking whether the level of
generality provided really works for them.

Regards,   Martin.

---

From: "James Seng/Personal" <[email-masked]>
Date: Fri, 26 Oct 2001 15:49:12 +0800

I presumed that other group would have to look at nameprep as an example
how they can create a "profile" for their own purpose and requirements.

james

---

From: Martin Duerst <[email-masked]>
Date: Fri, 26 Oct 2001 17:09:47 +0900

>how they can create a "profile" for their own purpose and requirements.

Yes, definitely. But they also have to look at whether creating
just a stringprep profile as we do in nameprep works for them,
or whether they have requirements that make bigger changes
necessary.

Regards,   Martin.

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sun, 28 Oct 2001 07:33:32 -0500

> move forward the doc since there is no comments or any changes proposed

Please note the following:

Message-Id: <[email-masked]>
To: Zita Wenzel <[email-masked]>
cc: [email-masked], brunner
Subject: Re: [idn] draft-ietf-idn-requirements-07.txt 
In-Reply-To: Your message of "Tue, 19 Jun 2001 20:46:34 GMT."
             <[email-masked]> 
Date: Tue, 19 Jun 2001 21:45:32 -0400

Please also note the following:

Message-Id: <[email-masked]>
To: Marc Blanchet <[email-masked]>
cc: [email-masked], [email-masked], brunner
Subject: Re: [idn] new list of wg documents and next steps 
In-Reply-To: Your message of "Thu, 19 Jul 2001 12:03:07 EDT."
             <[email-masked]> 
Date: Thu, 19 Jul 2001 13:29:55 -0400

A killfile isn't an explination, its disfunction.

Eric

---

From: David Hopwood <[email-masked]>
Date: Mon, 29 Oct 2001 02:12:35 +0000

-----BEGIN PGP SIGNED MESSAGE-----

James Seng/Personal wrote (~4 days ago):
> > > > have not been adequately addressed (in fact none of my technical
> > > > points were addressed at all).
> > >
> > > Your comments comes after the doc have been moved forward for IESG.
> > > Any changes to it will have to wait after their review.
> >
> > The WG should discuss the comments and they can even decide how they'd
> > like to modify the document. But it is best to not issue an updated
> > I-D until the AD review comments are back.
> 

Good, I'm glad we agree. Since you're a coauthor of the requirements
draft, is it too much to ask that you actually make some substantive
comments, rather than just expressing a vague notion that it might be
a good idea to do so?

Please reply to my previous post suggesting the changes, saying to what
extent you agree or disagree with each of them.

- --

---

From: "James Seng/Personal" <[email-masked]>
Date: Mon, 29 Oct 2001 10:38:02 +0800

I am a co-author because I wrote -01. I relinquish that role to Zita
since -03 and since then, done very little editing.

-James Seng