Subject: Re: [idn] URL encoding in html page

From: Kenneth Whistler <[email-masked]>
Date: Mon, 1 Apr 2002 15:47:57 -0800 (PST)

David Leung stated:

> > > Agrees, the design of how UTF-8 encodes and decodes can be expanded to
> > > support more bits... so that's why UTF8 should be reasonable to be the
> > long
> > > term solution for designing i18n applications, including IDN...

and Doug Ewell responded:

> > Please, everybody, read the definition of UTF-8 before making these
> > claims that it supports an encoding structure wider than 31 bits.  (And
> > please read the statements of WG2 and Unicode concerning expansion
> > beyond U+10FFFD.)

and then David Leung retorted:

> The word "EXPAND" here means it can be extended or modify to cope with
> future requirements over the limits now... i didn't say that it is "READY"
> to support more... any one that reads carefully show see the words "can be
> expanded" and not "can be able" : )

I'm presuming that David is referring to the fact that the byte values
0xFE and 0xFF are unused in UTF-8. Currently the longest UTF-8 forms
defined in 10646 are 6-byte sequences, and the maximum value is
FD BF BF BF BF BF, corresponding to the code point U-7FFFFFFF. If you
took the same bit-slicing scheme and used 0xFE and 0xFF as introducers for
7-byte sequences, you could conceivably extend the UTF-8 scheme from
representing 31-bit code points to representing 37-bit code points, i.e.
covering a code space 0..1FFFFFFFFF, or 128 gig of code points, instead
of the puny 2 gig of code points theoretically available to 10646 now.

Well, to paraphrase a former president, yes, we *could* do that, ... but
it would be *wrong*!

The problem is that envisioning this kind of expansion misconstrues
the problem.

The *real* problem is guaranteeing interoperability for UTF-8, UTF-16,
and UTF-32, which are the three sanctioned encoding forms of Unicode --
all of them seeing real use in widespread applications. To ensure this,
the UTC and WG2 are busy *constraining* the code space -- not worrying
about opening it up to multiple gigabytes of numbers because someone
is concerned that someday aliens may land. The *useful* code space
is 0..10FFFF, the 17 planes of 10646 accessible via UTF-16.

The recurrent urban folk legends that Unicode doesn't have enough
code points (1,114,112 to be exact), or that UTF-16 is insufficient,
or that UTF-8 may have to be expanded, and so on, are just that: urban
folk legends. They are driven by people overly impressed by the CJK
character numbers, failing to do their research on the public Unicode
roadmap pages:

http://www.unicode.org/roadmaps/

and are apparently coupled with a tendency to profound innumeracy.
There are still wide-open spaces in Plane 1 of the Roadmap, even
after nearly every historic script known to man is laid out with
tentative allocations. Even if CJK spills over Plane 2 and starts
filling up Plane 3, that still leaves 10 planes (655,340 code points,
not counting 20 noncharacters) totally unaccounted for, with no
viable candidate characters anywhere to even start filling them.

And except for the occasional burps of CJK characters, the relevant
character encoding committees, the UTC and WG2, are managing to
process approximately 1000 characters per year for new standardization
as part of 10646 and the Unicode Standard. You do the math and tell
me at that rate how long it will take to standardize over 700,000
characters. The Internet and the IETF will be forgotten ancient
footnotes long before anybody manages to standardize 700,000 more
characters.

--Ken

---

From: "James Seng" <[email-masked]>
Date: Tue, 2 Apr 2002 09:10:18 +0800

I am sorry I bring this up.

I bought up the point on 128bit clean for applications to illustrate my
point that one cannot accurately know what is "long term". Maybe 128bit is
not needed for encoding, maybe it is needed for IPv6, and something I don't
know.

It is difficult to do standardisation for something that is coming in the
"long term" cos no one really knows what future looks like. We can only do
standardization based on the things we know now. This is a "backward"
looking view to standardisation.

Another group of people advocate that standardization should be "forward"
looking, driving the adoption of new technologies. This is also important.

The conflict between these two group has always exist in this wg or others
in IETF, one claim the other impractical, the other claim one is
conservative. The difficulty is the balancing of the two "backward" and
"forward" looking view.  Doug hit the nail on the wall when he asked "How
far into the future?".

(And now try imaging you sit between theses two group of people, trying to
guage rough consensus of the whole group :-)

Anyway, let me concluded to say that this is my fault to bring up 128 bit.
Lets drop this and move back to our other discussion, such as IRI and Host:,
copy & paste etc.

-James Seng

---

From: Dave Crocker <[email-masked]>
Date: Mon, 01 Apr 2002 18:51:46 -0800

>Lets drop this and move back to our other discussion, such as IRI and Host:,

Dealing with complex character sets -- and especially converting between 
different representations of characters -- certainly is a difficult aspect 
of user interface design.

However user interface design is not part of IETF protocol design.  That is 
why it is not part of this working group's charter.  Rather, this working 
group has a task of working on a network interchange standard.

So, it is difficult to understand why it is being discussed in this forum.

d/

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

---

From: "James Seng" <[email-masked]>
Date: Tue, 2 Apr 2002 11:23:53 +0800

> group has a task of working on a network interchange standard.

Okay, lets look at network interchange then.

Assuming there is an application (A1) that uses IDN it send IDNs around to
another application (A2) maybe through some immediated relay/proxy/cache
(MIM).

For IDNA, there is no change in the infrastructure, ie, MIM remains
unchange.

Case 1: From IDNA A1 thru MIM to IDNA A2

A1 is capable of handling IDN input, display and resolution as defined in
IDNA. It will send out IDN as ACE.

MIM receive ACE, thinking it is some ASCII string, process it as usual.

A2 receive ACE and able to handle IDN input, display and resolution as
defined in IDNA.

Case 2: From IDNA A1 thru MIM to non-IDNA A2

A1 is capable of handling IDN input, display and resolution as defined in
IDNA. It will send out IDN as ACE.

MIM receive ACE, thinking it is some ASCII string, process it as usual.

A2 receive ACE. But it is not able to understand ACE so it display the ACE
as-it-is.

Case 3: From non-IDNA A1 thru MIM to IDNA A2

A1 capability to handle IDN is unknown. It may send out as-is in whatever
encoding the user specify.

This is a failure case unless the user input IDN into A1 as ACE directly.

If so, MIM receive ACE, thinking it is some ASCII string, process it as
usual. A2 receive ACE and able to handle IDN input, display and resolution
as defined in IDNA.

Case 4: From non-IDNA A1 thru MIN to IDNA A2

A1 capability to handle IDN is unknown. It may send out as-is in whatever
encoding the user specify.

This is a failure case unless the user input IDN into A1 as ACE directly.

If so, MIM receive ACE, thinking it is some ASCII string, process it as
usual. A2 receive ACE. But it is not able to understand ACE so it display
the ACE
as-it-is.

Summary for IDNA:

Protocol:
             Resolution        Display
           A1    MIM   A2      A1   A2
Case 1 :  okay  okay  okay    okay  okay   // IDNA A1, IDNA A2
Case 2 :  okay  okay  okay    okay  fail   // IDNA A1, non-IDNA A2
Case 3 :   ?    okay* okay*    ?    okay*  // non-IDNA A1, IDNA A2
Case 4 :   ?    okay* okay*    ?    fail*  // non-IDNA A1, non-IDNA A2

? the processing fail here unless ACE is used to bypass non-IDNA support.
* subjected to the condition that ACE is used to bypass non-IDNA support.

cut & paste:
           Resolution    Display
           A1    A2      A1    A2
Case 1 :  okay  okay    okay  okay         // IDNA A1, IDNA A2
Case 2 :  okay    ?     okay    ?          // IDNA A1, non-IDNA A2
Case 3 :  okay  okay    fail  okay         // non-IDNA A1, IDNA A2
Case 4 :  okay  okay    fail  fail         // non-IDNA A1, non-IDNA A2

? Case 2, A2 is likely to fail in the resolution altho A2 may be or may not
able to display the string correctly. We cannot predict what an non-IDNA
applications going to do to the domain names.

-James Seng

---

From: Dave Crocker <[email-masked]>
Date: Mon, 01 Apr 2002 20:22:42 -0800

At 11:23 AM 4/2/2002 +0800, James Seng wrote:
>...

So that we are clear:  nothing breaks.  The string is ugly, but it is legal 
and A2 does with that string whatever it usually does with ASCI DNS strings.

>encoding the user specify.

Sorry, no.  If A1 is a non-IDNA DNS mechanism, then it supports non-IDN 
strings.  In other words, it supports the existing set of ASCII DNS strings.

You are specifying that a mechanism which is not converted to IDNA will 
somehow start issuing new strings that are neither current ASCII nor 
IDNA-encoded ASCII.

Unless you can provide more detail to this example -- so that we can 
understand concretely how it could happen -- then the problem with the 
example is that it will not happen.

>encoding the user specify.

This example has the same problem as Case 3.

The simple scenarios that ARE valid are simply:

Reality 1:  Old ASCII mechanism interacts with Old ASCII mechanism the same 
always.

Reality 2:  New IDNA mechanism interact with New IDNA mechanism, for 
extended names, as specified by IDNA.

Reality 3:  New IDNA mechanism interact with New IDNA mechanisms AND with 
Old ASCII mechanisms, for old names, the same as always.

Reality 4:  New IDNA mechanism interacts with Old ASCII mechanism, for 
extended the names, in the old way, except that the Old ASCII mechanism 
sees some truly ugly strings.  Except for the lack of prettiness, the 
interaction with Old ASCII DNS mechanisms is unchanged.

d/

----------

---

From: "D. J. Bernstein" <[email-masked]>
Date: 2 Apr 2002 04:47:37 -0000

Kenneth Whistler writes:
> and UTF-32, which are the three sanctioned encoding forms of Unicode

The obvious choice for Internet protocols is UTF-8. See RFC 2277.
Systems that use 16-bit encodings internally, such as Windows, handle
UTF-8 conversions at the boundary between the system and the network.

What's the problem?

Converting between UTF-8 and UTF-16 and UTF-32 doesn't cause IDNA-style
interoperability failures. It's crystal clear which pieces of text are
8-bit and which are 16-bit. Nobody says ridiculous IDNA-type things like
``you should think about converting that to 8 bits if you think it might
be displayed, but definitely leave it as 16 bits if you think another
program will look at it.'' Each interface makes a clear size choice.

Of course, Windows still has all sorts of problems related to its old
``code pages,'' and there are many similar problems with old character
encodings under UNIX. The use of more than one 8-bit ASCII extension
provides ample opportunity for IDNA-style interoperability failures.
UTF-8 is a way out of this mess.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

---

From: John C Klensin <[email-masked]>
Date: Tue, 02 Apr 2002 10:57:25 -0500

>> However user interface design is not part of IETF protocol
>> design.  That
> is
>> why it is not part of this working group's charter.  Rather,
>> this working group has a task of working on a network
>> interchange standard.

Dave,

I said this at least twice, in different contexts, in
Minneapolis.  Let me say it again here, with the understanding
that this is just my opinion and that the above is just your
opinion -- until and unless one of the ADs says something
authoritative:

While the IETF does not design or standardize user interfaces,
it seems to me that discussion about user interfaces and what
functions they do, or do not, require is entirely appropriate.
If we specify a wire ("network interchange") standard that is
intended to provide some functionality, and that functionality
cannot be rationally implemented in a user interface, then the
standard is useless.  Conversely, if a user interface requires
some capability or information that must come from other sources
on the network, and we don't provide that information, we have
produced an equally useless standard.

Your repeated comments along the lines of the above risk our
taking the path that you have sometimes claimed was ITU's big
mistake with X.400 -- ignoring both the installed base of
similar and related applications and usability issues.

I believe that the IETF's WGs need to work these problems in the
way that any decent engineering organization would, and that
involves including and examining _all_ relevant constraints on
the solution space.   

If, for example, it is argued that a particular approach would
cause serious user confusion problems, across a broad range of
languages, that could not be avoided by reasonable
implemenations or designs of UIs, then I think we are obligated
to examine that argument and, if it turns out to be correct, to
look for protocol choices that don't have that property.  While
I don't believe we should change a protocol to benefit one
language while disadvantaging all others, those cases may need
examination too.

Again, none of this means that we should go into the UI design
business.  But ignoring or dismissing discussions of UI issues,
or arguments based on what UIs can or cannot do with the
protocol facilities anticipated, puts us, I think, at serious
risk.

Your opinion may differ, and probably does.  But I suggest it is
improper to try to suppress discussion by making claims about
what IETF does or does not do when those claims are based on
personal opinion or preference.

     john

---

From: Dave Crocker <[email-masked]>
Date: Tue, 02 Apr 2002 09:27:16 -0800

At 10:57 AM 4/2/2002 -0500, John C Klensin wrote:
>cannot be rationally implemented in a user interface,

The only problem is that this extended discussion is that it is not serving 
that purpose.

It is not assessing the UI issues correctly, it is confusing protocol 
issues with implementation issues, AND it is trying to specify UI 
designs.  None of which is constructive to an IETF working group effort.

Frankly, both of these problems are persistent in IDN.  We start with a 
topic that has a generic relevance to the work -- although we often engage 
in that discussion far past the time that is appropriate to a design 
effort.  We get quite a bit of inaccurate technical input.  Then we try to 
specify implementation choices that are a) based on the erroneous 
assessment, and b) outside the scope of the working group.

By way of a counter-example, the fax group managed to do standards work 
that uses TIFF without having to have protracted debate about cut-and-paste 
translation to jpeg.  (In fact, yes, there was a bit of discussion about 
such issues at the beginning of the effort, but it was brief and focused 
and it did not recur years latter.)  From an IETF protocol design 
perspective, that is exactly the same issue as is being discussed at 
length, here.

In other words, John, instead of serving the constructive purpose of 
validating or challenging real IDNA protocol issues, these sorts of threads 
merely have the effect of being deprivation of service attacks.

>similar and related applications and usability issues.

And isn't it strange that, at this point, such an issue would be mentioned 
here?  The IDNA effort is the epitome of paying attention to the installed 
base.  Similarly it has paid an enormous amount of attention to usability.

The benefits and limitations of the IDNA approach have been discussed and 
debated and clarified ad nauseam.  After a few years, there is no insight 
being added by discussing, debating and obscuring it further.

>If, for example, it is argued that a particular approach would

And upon reviewing your posting a bit, what is significant is that you cite 
generic issues and generic benefits about this TYPE of debate.  However 
what you do not do is to highlight SPECIFIC benefits that are being derived 
from this SPECIFIC exchange

So let's get concrete:  What issues has this exchange raised that are new, 
valid and poorly understood AND are relevant to the PROTOCOL work of this 
effort?  What problems have been raised that require us to make changes to 
the specification?

If this exchange were happening two years ago, it might be worth indulging 
in.  What real benefits are we deriving from having it now, after 
specifications have been sent to the IESG?

>language while disadvantaging all others, those cases may need

Fine.  Working on the theory that your concern is being mentioned because 
there is a problem with the IDNA specifications, then what alternative 
specification are you putting forward or what changes to the current 
specifications?

>personal opinion or preference.

John, as you well know, IETF working group progress requires constantly 
enforcing the scope restrictions specified by the charter.  Ensuring 
forward progress often has more to do with limiting scope of discussion 
than with anything else.

Perhaps it is silly of me to worry about the difference between pleasant 
academic discussions, versus practical engineering work that results in 
practical protocols developed in a timely manner.

For some reason, I have been under the impression that the latter is the 
purpose of the IETF.

d/

----------

---

From: "James Seng" <[email-masked]>
Date: Wed, 3 Apr 2002 02:03:29 +0800

> and A2 does with that string whatever it usually does with ASCI DNS
strings.

"nothing breaks" is probably too strong. For some, "nothing" => resolution
only, for others, display too.

I think it is reasonable to say A1 works for both resolution and display and
A2 works for resolution but not display.

> example is that it will not happen.

We are not disagreeing.

The behavior of non-IDNA A1 is totally unknown. It is likely to fail in
resolution. The display may or may not work, depending on implementation.
But I agree that this is an expected behavior of any application feed with
data it is not able to process anyway.

It is not my intention to specify how non-IDNA is going to behave.

However, if non-IDNA is feed with ACE, then resolution works altho display
will still be in ACE. This is basically what my conclusion.

Can we at least agree on the case example for IDNA? If we can, then we can
draw up similar case examples for other proposal (UDNS, UTF-8 or what we
have) and do a proper comparsion between them.

-James Seng

---

From: "James Seng" <[email-masked]>
Date: Wed, 3 Apr 2002 02:40:06 +0800

> Exactly correct.  However we need to highlight that the DNS concerns
> resolution.  It does not really concern display.

I am here in the middle with one group saying "we care only about
resolution" and another which say "display is also important". I am trying
to balance the two group by putting the all concerns together.

If display is not of your concern, then you can ignore that column. Some may
see it important, some may not. Let the fact speak for themselves.

> James, forgive me, but I do not understand why the analysis is considering
> a component that is entirely outside the standard.  Components that do not
> participate in a standard are not relevant to a discussion about
> interoperability.

Okay. This is reasonable.

Then let me rewrite this:

Protocol:
             Resolution        Display
           A1    MIM   A2      A1   A2
Case 1 :  okay  okay  okay    okay  okay   // IDNA A1, IDNA A2
Case 2 :  okay  okay  okay    okay  fail   // IDNA A1, non-IDNA A2
Case 3 :   ?     ?     ?       ?     ?     // non-IDNA A1, IDNA A2
Case 4 :   ?     ?     ?       ?     ?     // non-IDNA A1, non-IDNA A2

? since sending application A1 is non-IDNA, it is outside IDNA to predict
its behavior.

Let me know if this is agreeable. (Personally, I find it quite sad that we
could have at least capture when Case 3/4 would work if ACE is use directly
on A1)

-James Seng

---

From: "David Leung \(Neteka Inc.\)" <[email-masked]>
Date: Tue, 2 Apr 2002 13:22:31 -0500

> UTF-8 conversions at the boundary between the system and the network.

Totally agree, I thought the IETF has decided on using UTF8 on all protocol.
So I dont understand why someone is saying me trying to predict the future
that all application and protocol should move towards the use of UTF8. It
seems like we(UTF8 supporters) are taking the role of Mark Davis, trying to
promote the use of Unicode : )

David Leung

---

From: "James Seng" <[email-masked]>
Date: Wed, 3 Apr 2002 02:31:44 +0800

Lets be realistic:

1. RFC2277 is a result of IAB Character Workshop in March 1996.

2. RFC2277 is an BCP, not Standard Track.

3. RFC2277 say

   "Names are a problem, because people feel strongly about them, many of
   them are mostly for local usage, and all of them tend to leak out of
   the local context at times. RFC 1958 [RFC 1958] recommends US-ASCII
   for all globally visible names.

   This document does not mandate a policy on name internationalization,
   but requires that all protocols describe whether names are
   internationalized or US-ASCII."

Note: I am not saying we reject UTF-8. You need better technical
justification then to just say "it is obvious" or "it is stated in RFC2277".

-James Seng

---

From: Dave Crocker <[email-masked]>
Date: Tue, 02 Apr 2002 10:25:45 -0800

At 02:03 AM 4/3/2002 +0800, James Seng wrote:
> > >A2 receive ACE. But it is not able to understand ACE so it display the
>ACE as-it-is.
> >

James, "nothing breaks" is the precisely correct term.  It is highlights 
that protocol violations do not occur and software does not break.

I believe that the issue you are raising is that while software does not 
crash, the recipient user does not obtain the desired benefit.  And your 
are certainly correct.

However, we need to understand that the user does not receive benefit only 
because the user has not yet adopted the new standard.  It is difficult to 
complain about that, except to suggest to them that they will like the upgrade.

"Nothing breaks" means that an interaction between a user of the old 
technology and a user (or server or whatever) of the new technology does 
not break the protocol or software of either participant.

>have) and do a proper comparsion between them.

Sorry, no.  You are describing a node that is not conforming to Old Ascii 
and is not conforming to New IDNA.  Hence it is irrelevant to the IDNA effort.

d/

----------

---

From: Dave Crocker <[email-masked]>
Date: Tue, 02 Apr 2002 11:09:26 -0800

>to balance the two group by putting the all concerns together.

James, display of new strings within old parts of the system is NOT a 
concern for this working group.  With respect to new strings in old part of 
the system, the only thing that matters for this working is that the 
protocol and software do not break.

>If display is not of your concern, then you can ignore that column.

I'm sorry, but this is not a question of my own interests. Personally, I 
happen to like discussions about usability and human factors. However the 
question is what is within the scope of this working group's effort.

Yes, it is important for this group to know enough so that it does not 
break user software that conforms to Old ASCII DNS.  However that is all.

It is not our job to specify end-user software.  If we pursue that topic at 
length, we do two things that are wrong.  One is that we go outside the 
scope of the charter.  The second is that we will be trying to work on 
something for which we have no history of competence.

>Let me know if this is agreeable.

definitely is agreeable.  thanks!

d/

----------

---

From: "Doug Ewell" <[email-masked]>
Date: Tue, 2 Apr 2002 12:04:45 -0800

> protocol and software do not break.

This is probably true, but James is also correct.  Several people have
complained on this list, loudly and frequently, that leakage of
ACE-encoded names to old software clients is unacceptable.  (This is
often followed by a claim that UTF-8 is immune to such leakage problems,
though I don't follow the logic there.)

I believe James was simply trying to set up all the scenarios and
establish what "works" and what "doesn't work."  Determining which
"doesn't-work" situations are showstoppers and which are merely
annoyances is the next step.

-Doug Ewell
 Fullerton, California

---

From: Dave Crocker <[email-masked]>
Date: Tue, 02 Apr 2002 12:21:33 -0800

At 12:04 PM 4/2/2002 -0800, Doug Ewell wrote:
>ACE-encoded names to old software clients is unacceptable.

There are always people complaining about some design choice.  For a 
working group to make progress, it needs to deal with those concerns when 
they are raised.  Then it needs to move on.  It is not productive to have 
those complaints constantly added to the discussion mix.

It is also necessary to insist that complaints be accompanied by solutions.

The simplistic UTF-8 advocacy is simply wrong.  And we have covered that 
ground many times over the years. (I hope folks note the repeated 
references to years.  This was an urgent project when it started and we 
still have not begun deployment.)  It is worth noting that none of the 
UTF-8 advocacy produced a complete specification.  In particular they 
failed to deal with transition.  This is not surprise because it is the 
fundamental weakness of the "just start using binary" approach.

>establish what "works" and what "doesn't work."

Yes, such an effort is essential for understanding transition of the 
installed base.

However it is never productive to look outside the group that is being 
transitioned.  Components that do something other than Old Ascii DNS and/or 
New IDNA have nothing at all to do with this working group.  And, yes, I 
mean nothing at all.  They are a distraction.

We might as well also worry about printers that only do ASCII text or that 
do graphics.  Some can print only Old Ascii DNS strings and others can 
print extended characters.  So they are part of the wide world of 
internationlized character strings.

However they have nothing to do with this working group.

d/

----------

---

From: John C Klensin <[email-masked]>
Date: Tue, 02 Apr 2002 16:13:55 -0500

--On Tuesday, 02 April, 2002 09:27 -0800 Dave Crocker
<[email-masked]> wrote:

> The only problem is that this extended discussion is that it
> is not serving that purpose.
> 
> It is not assessing the UI issues correctly, it is confusing
> protocol issues with implementation issues, AND it is trying
> to specify UI designs.  None of which is constructive to an
> IETF working group effort.
> 
> Frankly, both of these problems are persistent in IDN.  We
> start with a topic that has a generic relevance to the work --
> although we often engage in that discussion far past the time
>...
> John, as you well know, IETF working group progress requires
> constantly enforcing the scope restrictions specified by the
> charter.  Ensuring forward progress often has more to do with
> limiting scope of discussion than with anything else.
> 
> Perhaps it is silly of me to worry about the difference
> between pleasant academic discussions, versus practical
> engineering work that results in practical protocols developed
> in a timely manner.
> 
> For some reason, I have been under the impression that the
> latter is the purpose of the IETF.

Dave, assume, at least for the purposes of this discussion, that
I agree with you about at least the first part of this (I do
agree about much of it).   I've been disappointed that the WG
Chairs have, for whatever reason, been ineffective in shutting
off useless and redundant lines of discussion. And I recognize
that the problem is largely not theirs, but that a significant
fraction of the active participants on the WG list seem to want
or need to move forward with it no matter what -- this
collection of cats seems determined to not be herded, and I
doubt that either of us could do much better were we sitting in
the Chair.

I wish, too, that the WG would simply omit something and go
silent -- what is disturbing to me about this round of
discussions is how much they are going over old ground, without
contributing any new information or insights -- and let the IESG
do something, and move on (more on this below).   There too, we
probably agree, at least in large measure.

What I am objecting to is your tactics.  I don't think we make
progress by making up rules and trying to enforce them, or by
bending the rules to your (or even my) personal convenience.  To
take one of the clearer examples, I found the "user interface"
discussion during the Minneapolis "keyword" BOF interesting and
helpful, not because anyone was suggesting that we standardize a
UI, but because it provided real (and new, to at least some of
us) information and details about the context in which some of
this work would be used.  I think it would have been helpful to
spend more time teasing protocol requirements out of that
presentation, but the time in the BOF was overscheduled and we
had to spent time dealing with criticisms of the fact that the
presentation was permitted instead.  

Holding a WG to its charter is certainly appropriate, but

(i) The charter doesn't say what you seem to think it does.  The
wording "...specify the requirements for internationalized
access to domain names and to specify a standards track protocol
based on the requirements..." was very carefully chosen.  It
does not say "produce a solution that gets Unicode names into
the DNS". I think reasonable people can read what it does say as
including discussions about what is actually required and where
in the stack to do it (those two options were certainly
considered in-scope when the charter was written) and even what
character repertoires are required for us to consider the
"access" to be "internationalized".   The charter goes on to say

		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. 

Which, it seems to me, makes understanding of application (and
even UI) requirements on topic, and probably even makes consumer
confusion issues on topic.
		
		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.

Which, however wrongheaded or misguided some of us think the
UTF-8 discussion to be, and however ill-advised a few of us
think one or two of the clarifications in RFC 2181 are, makes
that arguably in-charter too.

(ii) It is possible to argue that once a WG is chartered to
produce a protocol, it must produce a result, and the IESG must
accept that result because the WG put in a lot of work on it and
reached some sort of consensus.  But that makes the IESG as an
approval body, and IETF Last Call, nearly pointless.  It also
suggests that a WG should not be shut down until and unless it
reaches consensus.   And those conclusions either lead to
guarantees that the IETF will periodically eject very
poor-quality work or that some WGs will go on forever.  I can't
accept either of those outcomes, and I think you have argued
against both of them in other contexts.  Otherwise, it seems to
me to be much better that a WG be able to conclude that it
cannot produce a reasonable protocol (or a protocol that
satisfies all of the requirements as it sees them) and ask to be
shut down than that the IESG have to do that against the WG's
will (or perceived charter).  I don't think that outcome is
desirable here, but, if it is to be even possible, there must be
the possibility of discussing it and it seems to me that you
have been advocating suppressing discussions along those lines
too.

I don't see that as constructive, and I don't see it as
consistent with either the charter or with open exchange of
views in the IETF.

    john

---

From: Dave Crocker <[email-masked]>
Date: Tue, 02 Apr 2002 16:12:43 -0800

At 04:13 PM 4/2/2002 -0500, John C Klensin wrote:
>  -- this

indeed.

>discussions is how much they are going over old ground,

yup.

>bending the rules to your (or even my) personal convenience.

I agree.  Therefore it is a good thing that that was not what I am trying 
to do.

And as responded earlier, this has nothing to do with my personal 
preference.  Personally I find discussions of usability issues quite 
delightful, since they permit me to indulge in my original formal training.

What is, instead, at issue is working group progress and 
productivity.  This is more mundane than making things personal, but it is 
also more relevant.

>   To
>helpful,

1.  I suppose it is heartening to hear that someone found the Keyword BOF 
enlightening.  All I can do is applaud your skills at extracting benefit.

2.  Perhaps the Keyword BOF has some relevance to this DNS working group, 
but it escaped me in that BOF and it escapes me now.

3.  Even as an example, I do not know how an early-stage, unfocused 
discussion about keywords has any relevance to a late-stage DNS working 
group specification effort.

>based on the requirements..."

The goal of requirements is frequently in a charter and is just dandy for 
early-stage working group effort.  To the extent that anyone feels that it 
is worth reviewing and writing formal IDN working group requirements, that 
might even be OK.  However the current thread has not been attempting that, 
nor is such a goal typical at such a late stage, usually because it is not 
very productive.

As to the protocol specification work, I will reiterate my request that you 
explain how any of this thread relates to it.  The request was intended to 
move from abstractions to specifics.  While such a move is anathema to many 
of the critics of this working group's efforts, it is nonetheless the usual 
way IETF working groups makes progress.

>  was very carefully chosen.  It
>the DNS".

John, presumably you offer a quoted phrase, like that, because it has some 
relevance to what I said.  That relevance escapes me, since I made no such 
statement.  Please feel free to clarify.

>  I think reasonable people can read what it does say as
>in the stack to do it

I'd find it interesting to see some explication of how this thread was 
doing more than rehashing old issues.

Rehashing old issues is a frequent basis for declaring a topic 
inappropriate for continuation in an IETF working group.

>that arguably in-charter too.

As long as we are beating dead horses, let me reiterate that things that 
are reasonable in the early stages of a working group are not reasonable in 
the late stages, especially when those stages are separated by years.

And I will repeat my query as to how this thread shows any actual or 
possible relevance to the protocol specification work of this group.  Not 
theoretical, John. Actual.

The criticisms in this working group have a massive tendency towards 
assertions of theoretical fact, often without theoretical or experimental 
basis.  They also have a massive tendency to avoid moving to the pragmatics 
of specifics.

>reached some sort of consensus.

Again I find it impossible to guess how this line of comment is relevant 
here.  No one suggested anything about the IESG, such as it being a rubber 
stamp, nor any of the rest of the possibilities you cite.

Please clarify.

d/

----------

---

From: John C Klensin <[email-masked]>
Date: Tue, 02 Apr 2002 22:27:34 -0500

--On Tuesday, 02 April, 2002 16:12 -0800 Dave Crocker
<[email-masked]> wrote:

>> discussion during the Minneapolis "keyword" BOF interesting
>> and helpful,
> 
> 1.  I suppose it is heartening to hear that someone found the
> Keyword BOF enlightening.  All I can do is applaud your skills
> at extracting benefit.
> 
> 2.  Perhaps the Keyword BOF has some relevance to this DNS
> working group, but it escaped me in that BOF and it escapes me
> now.
>...

Again, I was commenting exclusively on the tactic of trying to
cut off discussion by making over-broad assertions about what
the IETF does or does not permit groups to do, what charters
prohibit, etc.   I mentioned the keyword BOF because there
seemed to be to be a pattern and it illustrated the pattern.

> The goal of requirements is frequently in a charter and is
> just dandy for early-stage working group effort.  To the
> extent that anyone feels that it is worth reviewing and
> writing formal IDN working group requirements, that might even
> be OK.  However the current thread has not been attempting
> that, nor is such a goal typical at such a late stage, usually
> because it is not very productive.
> 
> As to the protocol specification work, I will reiterate my
> request that you explain how any of this thread relates to it.
> The request was intended to move from abstractions to
> specifics.  While such a move is anathema to many of the
> critics of this working group's efforts, it is nonetheless the
> usual way IETF working groups makes progress.

Assuming you have seen my other note by now, it should be clear
that I agree with you on the substance.  But the formal
determination of relevance is a WG Chair or AD problem.  You and
I can give them advice (unsolicited or solicited), advise or
plead with the WG participants (as I have tried to do in that
other note), but our telling people what they can't do on the
basis of over-narrow reading of the charter or limits on IETF
scope seems inappropriate.

>> including discussions about what is actually required and
>> where in the stack to do it
> 
> I'd find it interesting to see some explication of how this
> thread was doing more than rehashing old issues.
> 

Absolutely.  See comments above about the role of Chairs and ADs
versus roles of participants.  And your notes weren't saying
"this is rehashing old issues, please stop it".  The one that I
cited said, more or less, "this is a UI issue and we don't
discuss UI issues".

> As long as we are beating dead horses, let me reiterate that
> things that are reasonable in the early stages of a working
> group are not reasonable in the late stages, especially when
> those stages are separated by years.

If a WG is converging smoothly, I agree.   And I would argue
that rehashing old issues is inappropriate two months into a
working group and certainly no more appropriate two years in.
On the other hand, if there were the slightly shred of really
new and significant information that might impact the content or
evaluation of appropriateness of an evolving standards-track
effort, I'd contend that introducing it would be reasonable at
any time.    And, no, I haven't seen any discussion or arguments
I would have interpreted as either new or significant
information (much less both) since before the WG Last Call
concluded.

> And I will repeat my query as to how this thread shows any
> actual or possible relevance to the protocol specification
> work of this group.  Not theoretical, John. Actual.

I don't believe there is any.  You don't believe there is any.
James has pointed out (yet again) that (my words, not his) the
ratio of loud assertions to actual alternative proposals that
are posted as I-Ds and that contain enough technical specifics
to be considered  remains infinite. Absent such proposals, those
assertions are just noise, and I believe the noise ought to
stop, and have said so.

But, in my opinion, your assertions about topics that can be
discussed or not discussed on the basis of charters and real or
imagined IETF procedures just distract from the point that we
have been through these arguments many times before, that no
significant new information is being placed into discussion, and
that there are no meaningful proposals on the table.

     john

---

From: Dave Crocker <[email-masked]>
Date: Tue, 02 Apr 2002 23:47:40 -0800

At 10:27 PM 4/2/2002 -0500, John C Klensin wrote:
>prohibit,

Over-broad?  OK.  Then consider responding to the specifics I provided.

>  etc.   I mentioned the keyword BOF because there

"Pattern?" Do you mean the pattern of your objecting when you do not agree 
with a citation of IETF practise?

Alas, John, in the IETF the plebeians are allowed to know and contribute to 
management discussions.  Some of us even have quite a bit of experience 
writing IETF process specifications, being area directors, and/or chairing 
working groups.  Consequently, quite a few of us know quite a bit about 
IETF practise.  And we are allowed to cite that knowledge.  (Feel free to 
cite rules to the contrary.)

>   But the formal
>determination of relevance is a WG Chair or AD problem.

Formal determination?  Glad you included the word formal.  Your objection 
was not to my making a formal determination, since I did not make a formal 
determination.

So we are left with your again citing a point that is not relevant.

> > group are not reasonable in the late stages,
>
>If a WG is converging smoothly, I agree.

Even if it is converging roughly.  That is, after all, the other meaning of 
rough consensus.

>    And I would argue

Ahh, so you agree with that aspect of my concern, too.  This is making is 
increasingly difficult to figure out what you are objecting to.

>effort,
>     And, no, I haven't seen any discussion or arguments

Please forgive my continued confusion about your points.  How is citing 
this one relevant here?

>I don't believe there is any.

So we have just had a pleasant bit of jousting over a point that you 
acknowledge is irrelevant to the thread in question.

In the midst of an important standards effort that carries enough of its 
own baggage and noise, what is the possible benefit of your adding to them, 
John.

>imagined IETF procedures

Perhaps you have not noticed that responding to the content of these 
persistent lobbyists has had no effect on their repeated efforts?

At such times, turning to prohibition is the usual management practise, in 
the IETF and elsewhere.  Citing the working group charter is also the usual 
IETF management practise.

The only thing that is peculiar is your choosing to object to these facts.

d/

----------