Subject: [idn] Document Status?

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 20 Aug 2002 11:25:55 -0400

With the most recent updates to the IDNA, punycode, nameprep, and stringprep
documents do the document editors believe that the issues raised by Erik's
questions have all been resolved?  I'm wondering if the current document set
is thought to be ready for IESG review (and if Erik concurs), or if more
edits are planned.

-Scott-

---

From: "James Seng" <[email-masked]>
Date: Tue, 20 Aug 2002 23:36:56 +0800

You can find the status of these draft here:

http://www.iesg.org/IESG/status.html

They are currently waiting for write up.

-James Seng

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 25 Aug 2002 09:36:33 +0200 (CEST)

> is thought to be ready for IESG review (and if Erik concurs), or if more

The stringprep document has been discussed by the IESG resulting in a request
to make the document more explicit about various Unicode related security 
issues.

The second set of last-called documents (IDNA, punycode, and nameprep) still
have some IETF last call issues to resolve. The resultion will be in the form
of an added applicability section in the IDNA document. There is
still some word-smithing on that section, after which the documents will
be ready to be discussed by the IESG as a whole.

  Erik

---

From: Dave Crocker <[email-masked]>
Date: Fri, 30 Aug 2002 09:40:37 -0700

>be ready to be discussed by the IESG as a whole.

Erik,

One last try... Having not yet seen any detailed response on the matters I 
put forward some time ago, I will raise them again.

Your note implies that the IESG does not agree that the current IDN 
specification suffers the following, basic deficiencies:

>1. IDNA makes a formal change to the DNS, by expanding the name space from 
>a subset of ASCII to a subset of Unicode. This change is not clearly 
>documented in the IDNA specification.

         We usually document such major changes to basic protocols rather 
more explicitly.

>2. The IDNA specification does not provide enough detail to permit its use 
>for the most common Domain names, which is those used in URLs and email 
>addresses.

         This means that someone registering an IDN domain name for use in 
email addresses and web addresses cannot know the exact set of valid IDN 
characters avalailable for use.

         If this interpretation of the specification is correct, IDN WILL 
NOT WORK.

         If this interpretation is not correct, it would help for someone 
to explain why.  So far, the only explanation I have is from one of the 
specification's authors, saying that the set of valid characters is unclear 
and might become more restricted in the future and that anyone choosing an 
IDN now is gambling that their name will be made syntactically invalid later.

>3. The specification imposes some user interface issues onto the protocol. 
>In particular, it defines multiple dot seperator characters, which is 
>equivalent to creating multiple newline definitions or multiple at-sign or 
>multiple "slash" definitions.

         This looks like a small matter of engineering preference, but it 
is the sort of thing that introduces notable implementation variations and 
interoperability problems.

>4. The style of the current IDNA specification makes its use as a protocol 
>specification challenging. It is primarily tailored to programming, at the 
>expense of direct specification of the protocol.

         Any specification needs to pay attention to clarity, both for 
technical accuracy and for ease of adoption by the Internet technical 
community.  The IDN specification effort has demonstrated a long and 
difficult history, notably including widespread failure to understand the 
nature and scope of the specification effort.  A specification that is not 
crystal clear encourages that misunderstanding.

         The document does not clearly distinguish normative from 
non-normative text.

         The document does not clearly distinguish implementation choice 
from protocol specification.  In fact, it is written almost entirely from a 
programming perspective, rather than as a protocol format.

         These are certain to encourage misunderstandings of the 
specification.  Never good for interoperability.

d/

----------
Dave Crocker <mailto:[email-masked]>
TribalWise, Inc. <http://www.tribalwise.com>
tel +1.408.246.8253; fax +1.408.850.1850

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Fri, 30 Aug 2002 10:38:31 -0700

The sky is not falling, Dave. A new draft that we believe meets the 
IESG's request for clarifications has already been turned into the 
Internet Drafts repository but has not been announced by the IETF 
Secretariat yet.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Dave Crocker <[email-masked]>
Date: Fri, 30 Aug 2002 11:07:31 -0700

At 10:38 AM 8/30/2002 -0700, Paul Hoffman / IMC wrote:
>The sky is not falling, Dave.
>A new draft that we believe meets the IESG's request for clarifications 
>has already been turned into the Internet Drafts repository but has not 
>been announced by the IETF Secretariat yet.

Paul, it would be far more helpful to see responses to the particulars, 
rather than this sort of dismissive, handwaving condescension.

It is absolutely fine for my concerns to be unwarranted.

What is not fine is the continuing failure to address those concerns, with 
explanations that make clear why they are not warranted.

d/

----------

---

From: "James Seng" <[email-masked]>
Date: Sat, 31 Aug 2002 10:32:55 +0800

Dave,

I concur with Paul. The authors and the co-chairs have been working with the
ADs to address these issues. We have several emails discussion on the
drafts. Any non-editorial changes (e.g. the bidi & unicode 3.2) was and will
be bought to the group again.

The feeling I get from these discussion is that IESG is trying its best to
make sure the document got things right, rather then finding faults with the
draft.

-James Seng

---

From: Dave Crocker <[email-masked]>
Date: Fri, 30 Aug 2002 21:39:49 -0700

James,

At 10:32 AM 8/31/2002 +0800, James Seng wrote:
>I concur with Paul. The authors and the co-chairs have been working with 
>the ADs to address these issues.

There seems to be a basic disparity of view about IETF process, 
here.  Comments in a working group forum are not simply one-way input for a 
design team to take in and privately decide whether it wishes to 
incorporate.  Comments are for public discussion, review, and acceptance or 
rejection.

>We have several emails discussion on the drafts.

These concerns were posted two months ago and no one, on that long list of 
folks working diligently on this specification, has publicly responded to 
the details of those concerns.  If I am incorrect please point to the place 
in the working group archive that shows otherwise.

>make sure the document got things right, rather then finding faults with 
>the draft.

James, presumably you are not directing the "rather than" comment at 
me.  If you were directing it at me, I would be very confused, since I made 
a point of submitting extensive text that attempts to correct the concerns 
I have raised.

Please forgive my sensitivity on this matter, but the responses from chairs 
and authors have been problematic, since you and they are preferring to 
dismiss these concerns, rather than respond to them.

d/

----------

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 31 Aug 2002 07:39:18 +0200

--On 2002-08-30 21.39 -0700 Dave Crocker <[email-masked]> wrote:

> There seems to be a basic disparity of view about IETF process, here.
> Comments in a working group forum are not simply one-way input for a
> incorporate.  Comments are for public discussion, review, and acceptance
> or rejection.

Dave, not at this time in the process. All documents have been handed over
from the wg to the AD. We have also passed last call.

When the document is in the lap of the AD, i.e. the wg chairs have passed
the document to the IESG, the comments follow a different path than before.

Comments during and after last call is to go to the AD.

In this case, we as document editors get request for changes from the AD,
we implement them, and report back to the mailing list what the changes are.

So, if you had issues during last call which you find are not implemented,
you should rise the issue with the AD in question.

As AD myself (for Applications Area), I find this being the _only_ way
possible to work. It can not happen that the IESG work on comments received
during last call. Normally about 50% of the (very few unfortunately) is
only sent to the IESG so the wg chair or document editors have absolutely
no clue the comments have come in. So, during the lifetime of the document,
either the wg chair or the AD is responsible for the document. The hand
over is when the wg chair go to the AD and claim the document is ready for
last call.

    paf

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 31 Aug 2002 07:41:45 +0200

--On 2002-08-30 21.39 -0700 Dave Crocker <[email-masked]> wrote:

> These concerns were posted two months ago and no one, on that long list
> of folks working diligently on this specification, has publicly responded
> to the details of those concerns.  If I am incorrect please point to the
> place in the working group archive that shows otherwise.

Were those concernes yours? I can not see you starting a thread on this
mailing list since May 27, and that is three months ago.

Can you send me the Message-ID with the list of issues?

   paf

---

From: Dave Crocker <[email-masked]>
Date: Fri, 30 Aug 2002 23:05:25 -0700

>you should rise the issue with the AD in question.

Patrik,

In that case it is a good thing that my original posting on this thread was 
in response to the AD's status report.

It is a pity that others did not wait for him to respond.

d/

----------

---

From: Dave Crocker <[email-masked]>
Date: Fri, 30 Aug 2002 23:45:43 -0700

>Can you send me the Message-ID with the list of issues?

         <http://www.imc.org/idn/mail-archive/msg06956.html>
         <http://www.imc.org/idn/mail-archive/msg06884.html>
         <http://www.imc.org/idn/mail-archive/msg06885.html>

d/

----------

---

From: John C Klensin <[email-masked]>
Date: Sat, 31 Aug 2002 04:44:30 -0400

--On Saturday, August 31, 2002 7:39 AM +0200 Patrik Fältström
<[email-masked]> wrote:

>>> I concur with Paul. The authors and the co-chairs have been
>>> working with  the ADs to address these issues.
>> 
>> There seems to be a basic disparity of view about IETF
>> process, here. Comments in a working group forum are not
>> simply one-way input for a design team to take in and
>> privately decide whether it wishes to incorporate.  Comments
>> are for public discussion, review, and acceptance or
>> rejection.
> 
> Dave, not at this time in the process. All documents have been
> handed over from the wg to the AD. We have also passed last
> call.
> 
> When the document is in the lap of the AD, i.e. the wg chairs
> have passed the document to the IESG, the comments follow a
> different path than before.
>...

> In this case, we as document editors get request for changes
> from the AD, we implement them, and report back to the mailing
> list what the changes are.
> 
> So, if you had issues during last call which you find are not
> implemented, you should rise the issue with the AD in question.
>...

Patrik,

I agree with you that this is a reasonable way to proceed.
However, I trust that the results of the rewriting process will
be circulated back to the WG and last-called again, and possibly
run back through an additional IETF Last Call.  It seems to me
that it is appropriate for IESG and document editors to "tune" a
document and then advance it without consulting the WG that
produced it iff either 

	* the changes are not substantive or
	
	* they clearly represent WG (and, for standards-track
	material, IETF) consensus

Given the nature of Dave's comments (with which I still largely
concur), I cannot picture a non-substantive change that would
satisfy those concerns (although one might be possible).  And it
is unclear to me how you would determine the existence of the
appropriate consensus in this complex area without some relative
of a Last Call.

best,
       john

---

From: John C Klensin <[email-masked]>
Date: Sat, 31 Aug 2002 05:06:10 -0400

--On Saturday, August 31, 2002 10:32 AM +0800 James Seng
<[email-masked]> wrote:

> working with the ADs to address these issues. We have several
> emails discussion on the drafts. Any non-editorial changes
> (e.g. the bidi & unicode 3.2) was and will be bought to the
> group again.

James,

It seems to me that Dave (and I) have raised two sorts of issues
which are very different in character than, e.g., bidi and
unicode 3.2.   One has to do with the _style_ of the documents,
e.g., to paraphrase Dave (I hope accurately), whether they
specify a protocol or outline an implementation.   That is
somewhat a matter of taste, and you could legitimately argue
that it is an editorial matter, as long as the specification is
complete and unambiguous.

The other issues go directly to the questions of completeness
and ambiguity.  They are, by definition, substantive rather than
editorial unless there is very clear consensus within the IETF
about what the answers are to any questions that are unresolved
by  the text and the text merely needs to be clarified to
reflect that consensus.

To be specific about this,

(i) If there is any question at all about how a given codepoint
or character is to be interpreted, or whether it is permitted,
in any context, then that question must be resolved.  Without
such a resolution, the document would contain "known
deficiencies", which makes it inappropriate for standardization.

(ii) If there is a substantive claim that the document cannot be
implemented in an interoperable way without out-of-band
profiling or oral tradition --and I think Dave has made exactly
that claim, although in different language-- then either

	* the document must be fixed to reflect that fact (and,
	I would think, re-Last-Called through the whole IETF
	process, since introducing such profiling in a standards
	track protocol is a very serious step), or
	
	* the document must be fixed to eliminate the ambiguity/
	choices, or
	
	* the documents should be published as Experimental, not
	standards track, until we better understand just what
	profiling issues are involved, how the profiles should
	be specified, and what impact on interoperability
	profiling would cause,  or

	* someone needs to come up with a persuasive case that
	Dave (and I) have misread and misinterpreted the
	document.  And, procedurally, I believe that case needs
	to persuade the members of the WG and other concerned
	parties in the IETF who are interested enough to study
	the issues, not just the co-chairs, editors, and AD.

Again, given that these documents (or some approximation to
them) made it through Last Call, I think that the co-chairs,
editors, and IESG trying to work through these issues to see if
a solution can be found that satisfies the IESG is quite
reasonable.  But that solution then needs to be cycled back
through the system to be sure it still has WG and IETF consensus.

      john

---

From: "James Seng" <[email-masked]>
Date: Sat, 31 Aug 2002 17:37:18 +0800

John,

> complete and unambiguous.

The draft in questions have gone through the working group last call.
Regardless of the merits of these issues, it should have been bought up
before or during the last call. After the co-chairs move the documents for
IESG consideration, we (as the group) have very little control over what
happen next.

As Patrik said, the IESG/ADs would make their own comments. Sometimes, they
reject the draft (for various reasons such as technical failure). If we are
lucky, they may have minor editorial changes. But typically, it is along the
vague line between editorial to substain technical changes.

These are done to make sure the "specification is complete and unambiguous".

My note is to clarify to the group (not just to Dave), that we are in this
process with the ADs. Most of the stuff going on are minor, request for
additional paragraph for clarification. But a few are substained enough to
warrant another partial wg last call (which is what we did).

> that claim, although in different language-- then either

These are technical failure. If it happen, the IESG would kill the whole
process and and throw the draft back to us. So far, they havent.

The ADs have done some write up of their concerns, and the authors is
working on the changes to be made. I have not seen all the changes myself
yet so we dont know if it is substainable to warrant another last call. If
it is, we will.

So lets not jump into conclusion. The short answer is "yes, we are still
moving. be patient"

-James Seng

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 31 Aug 2002 14:02:03 +0200

--On 2002-08-31 04.44 -0400 John C Klensin <[email-masked]> wrote:

> run back through an additional IETF Last Call.

I see this being of the decisions an AD _always_ have to make after getting
comments, and a new document, back after issues have been rised.

I.e. not my call.

   paf

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Sat, 31 Aug 2002 15:10:39 +0200

>warrant another partial wg last call (which is what we did).

May I offer a remark for this AD tuning? As a new comer I read the proposed 
text as will do reader. I am confused by two wordings and uncertain about 
others. Dave proposes a lexical: I think the idea helpful (as long as it 
respects the text).

1. would it not be a good occasion of getting rid of the odd phrase about 
domain/host names and to introduce a stable wording such as "internet 
name"and "international internet names" or "multilingual internet names" 
which corresponds to the compromise we actually use? I am concerned about:

- the confusion it adds about what is a domain name, specialy in this 
complex context. We try to simplify and stabilize in discussing only 
strings, not what international lawyers may do with them. In making clear 
we only talk about alphanum pointers to IP addresses we migh help 
disjointing the legal and the technical aspects?

- I am concerned about using a concept (international) for another 
(multilingual) when the international concept may become another issue with 
national DNS views.

2.  I am confused about the implications of the proposed change of part 7. 
If I am right the target is to stick to the current common status of the 
DNS, whatever it may be. Could we not just define a "DNS character set" (as 
"0-9 a-Z -." today) and say that it can extend with DNS specifications. 
Would it not be clearer and be more compact?

3. is "IESG--" meant to stay, or is it temporary? Would this wording not 
add to the root management problems, 2 extra characters making a difference 
for many international TLD?

jfc
liaison to Eurolinc

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 31 Aug 2002 17:07:47 +0200

--On 2002-08-31 14.02 +0200 Patrik Fältström <[email-masked]> wrote:

> I see this being of the decisions an AD _always_ have to make after
> getting comments, and a new document, back after issues have been rised.

s/being of the/being one of the/

  paf

---

From: Dave Crocker <[email-masked]>
Date: Sat, 31 Aug 2002 10:13:28 -0700

John's comments were so nicely done, the only reason I am responding is 
because he cited me a number of times and seemed to be seeking some 
confirmation about those citations.  (And, of course, I will fail to limit 
myself to those citations...)

At 05:06 AM 8/31/2002 -0400, John C Klensin wrote:
>specify a protocol or outline an implementation.

correct.

>         document.  And, procedurally, I believe that case needs

Yes, these are the set of available choices.

Personally, I believe that publishing as Experimental is unnecessary and 
that it would be disastrous.

Experimental makes sense when a technology is not well understood.  That is 
not the problem, here.  The problem, here, about making difficult 
decisions, not about understanding them.

The current specification has not made at least one essential, difficult 
decision.  As a consequence, someone registering an IDN for use with email 
or the web cannot know the correct set of characters available to them.

The Internet needs workable IDN now.  (Actually, it needed it a few years 
ago.)  So, we need to make the difficult decisions, to make IDN 
workable.  And we need to publish as Proposed.

d/

----------