Subject: [idn] report of the straw poll

From: Marc Blanchet <[email-masked]>
Date: Fri, 25 May 2001 08:38:50 -0400

On Sun, 20 May 2001 09:51:31 -0400, an electronic straw poll was requested 
by the idn co-chairs to reverify the previous concensus on 
idna-nameprep-ace proposal. Those who disagree were asked to identify the 
draft of the suggested alternative. The end of the poll was wednesday May 
23rd 2001, 23h59 GMT.

50 participants participated in the straw poll.

36 participants agree with the idna-nameprep-ace orientation.

14 participants disagree. In this group, here is a summary of the suggested 
alternatives with the number of people in the front of each line:

   1 UCS or UTF variants preferred
   2 draft-skwan-utf8-dns-06.txt
   2 Just send UTF

   1 The DNSII Multilingual Domain Name Protocol
   1 draft-ietf-idn-vidn-01.txt
   1 draft-ietf-idn-uname-00.txt

   2 draft-ietf-idn-udns, draft-ietf-idn-uname, draft-ietf-idn-idne, 
draft-ietf-idn-iptr, draft-ietf-idn-vidn, draft-skwan-utf8-dns,
      draft-klensin-dns-role
   1 premature to decide before exploring alternatives

   3 nothing proposed

The counters group: Marc Blanchet, Dave Crocker, James Seng, Rick Wesson, 
Yoshiro Yoneya

---

From: Keith Moore <[email-masked]>
Date: Fri, 25 May 2001 09:54:29 -0400

I'd be curious to know who would support idna-nameprep-ace in the
short term with the assurance that a native utf-8 query protocol
would be worked on after idna-nameprep-ace went out the door.

Granted, this wouldn't automatically force upgrade of all applications
to use utf-8 domains, but it would make it easier for new applications
to use utf-8 natively, which is something.  

Existing applications could also upgrade to use it, but this would
happen on a per-application basis, and would require (at a minimum)
that there be sufficient interest in a group to work out the details 
of a a smooth and non-disruptive transition.

Keith

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Fri, 25 May 2001 08:54:46 -0700

At 8:38 AM -0400 5/25/01, Marc Blanchet wrote:
>14 participants disagree. In this group, here is a summary of the 
>suggested alternatives with the number of people in the front of 
>each line:

The WG chair didn't seem to declare "rough consensus", unfortunately. 
The poll showed one strongly-favored choice and a vast smattering of 
other choices with none having even 10% of the support. Is there a 
suggestion about how we should proceed? If the folks not supporting 
the most-desired protocol could coalesce around a single Internet 
Draft, it would be most helpful. Otherwise, there is nothing to 
compare with the strongly-favored Internet Draft.

Given that the large majority of the voters want to see IDNA, Patrik 
and I will certainly continue to work on it. Note that there is, as 
far as we can tell, almost no more work to be done; we have received 
only one substantiative comment on the draft, and that will be 
included in a new draft in the next few days. Beyond that, we need to 
pick an ACE (and the ACE Design Team should have at least a 
preliminary statement shortly), and need to finish nameprep, which at 
this point is finished other than it does not address the new 
characters added in Unicode 3.1.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "J. William Semich" <[email-masked]>
Date: Fri, 25 May 2001 12:10:13 -0400

At 08:54 AM 5/25/01 -0700, Paul Hoffman / IMC wrote:
<snip>

>Given that the large majority of the voters want to see IDNA, ...>
>--Paul Hoffman, Director
Paul - The opinions of the tiny subset of 36 members of this WG do not
represent a "vast" majority of anything whatsoever in the truly vast set of
multi-millions of Internet users, systems and application developers, and
connectivity providers.

Bill Semich

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Fri, 25 May 2001 09:28:39 -0700

>multi-millions of Internet users, systems and application developers, and

So, what are you suggesting that we do instead? Because the IETF 
cannot ever get the opinions of even 1% of all Internet users as we 
develop new Internet protocols, are you saying we should just stop 
working on them right now? If so, who do you propose should work on 
Internet protocols? No other standards body polls any significant 
percentage of Internet users before creating protocols, and no 
private company does so before it creates its own proprietary 
protocols. Are you saying that no more protocols should be developed 
by anyone?

--Paul Hoffman, Director

---

From: Dave Crocker <[email-masked]>
Date: Fri, 25 May 2001 10:00:20 -0700

At 08:54 AM 5/25/2001, Paul Hoffman / IMC wrote:
>The WG chair didn't seem to declare "rough consensus", unfortunately. The 
>poll showed one strongly-favored choice and a vast smattering of other 
>choices with none having even 10% of the support. Is

Bill Semich's concern that 'yes' got only 36 votes has some appeal, 
although the normal IETF view is that we only consider the concerns and 
desires of those who show up.  We cannot guess the desires of people who 
did not participate in the straw poll.

On the other hand, the 36 was less than 2/3 of the vote.  My personal 
approximation between "rough consensus" a percentage is not less than 2/3, 
because having 1/3 of a group disagree with a decision is simply too strong 
a constituency to have unhappy.

As to how to proceed, I wonder whether we should first resolve the question 
of urgency.  Although it is beyond my comprehension, a number of people 
seem to believe that there is little urgency.  Perhaps we should assess 
working group view of urgency.  If there is consensus about urgency THEN we 
can try to consider what solutions are amenable to quicker deployment.

d/

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

---

From: "J. William Semich" <[email-masked]>
Date: Fri, 25 May 2001 13:09:49 -0400

I think we should wrok harder to get consensus, that's all. Among the 14
are representatives of the interests of many millions of users, working all
over the world with systems using established protocols based on UTF-8,
etc. That should be given some weight as well.

I agree it would be a good idea to put forward a single alternative to IDNA
for consideration ...

Bill

>--Internet Mail Consortium
Bill Semich
President and Founder
WorldNames, Inc.
http://www.worldnames.net
[email-masked]

---

From: Bright Fulton <[email-masked]>
Date: Fri, 25 May 2001 10:34:26 -0700 (PDT)

36 of 50 is 72%.  The other 28% was split.  Whether or not the poll was
accurate, and whether or not the majority is right, there is a clear
majority.

Bright

---

From: "Eric A. Hall" <[email-masked]>
Date: Fri, 25 May 2001 10:40:42 -0700

> would be worked on after idna-nameprep-ace went out the door.

Can you turn that statement around and still be happy with it? Rather than
saying, "we commit to do something better in the long term" can we say
"ACE is the legacy interface component of XXXX long-term strategy"? IOW,
can we define a long-term strategy that ACE plugs into?

I've advocated EDNS as the best technical solution to the problem, but I
also recognize that the use of UTF-8 data breaks older systems (I favor
EDNS because it forces the break, and because it offers the broadest
future features). If we can agree that EDNS (as an example) is the
appropriate long-term solution AND begin designing around it, AND then we
include ACE as a way to provide fall-back backwards compatibilty to legacy
systems, then we have a holistic solution.

Let's take email as an example of this principle. Just for arguments sake,
we agree that EDNS is the way to go and begin desingingh an ESMTP
extension to negotiate the use of IDN, and specify the use of ACE if the
negotiation fails.

In that example, ACE provides necessary backwards compatibility to a
long-term approach, rather than being a destination in its own right. We
can design for long-term features and capabilities from the start, without
asking designers to do everything twice (once for ACE, once for something
else).

FWIW, I did not vote in the straw poll because neither option represented
my feelings on the matter.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Rick H Wesson <[email-masked]>
Date: Fri, 25 May 2001 10:39:53 -0700 (PDT)

Bill,

first you state that the 36 yes votes represent individuals, later you
state the 14 no votes represent "millions of users," you can't have it
both ways.

you did get one thing orrect, you need to coloess the 14 no votes with
nearly 7 proposals into one single alternative to IDNA.

-rick

---

From: Dave Crocker <[email-masked]>
Date: Fri, 25 May 2001 10:40:12 -0700

>accurate, and whether or not the majority is right, there is a clear

Every now and again, I seem to be demonstrate that knowing something about 
computer science does not mean that one is any good at all with 
numbers...  Sorry to have imposed that demonstration on the list.

I'll add that while I use 2/3 as a minimal measure, 3/4 is vastly 
preferred.  So, at best, we are in grey territory.

Anyhow, the fact that the disagreers are fragmented about the desired 
solution is not as significant as the fact that they are aligned in 
disagreeing.

That is why I'm suggesting trying to go through a sequence that steps 
toward a constructive group decision, based on a series of strategic 
concerns, starting with assessing group urgency.

d/

----------

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Fri, 25 May 2001 10:48:27 -0700

At 1:09 PM -0400 5/25/01, J. William Semich wrote:
>I think we should wrok harder to get consensus, that's all.

Ah! That's not what you said in the last message. Good to hear that 
you are interested in working towards consensus.

>  Among the 14
>etc.

Yes, and among the 36, there are also representatives of the 
interests of many millions of users, working all over the world with 
systems using established protocols based on UTF-8, etc. What does 
that have to do with achieving consensus?

>I agree it would be a good idea to put forward a single alternative to IDNA

Please note that I said a single Internet Draft. This mailing list 
discussion has been fruitful, but trying to nail down fruit is not 
useful in the long run.

--Paul Hoffman, Director

---

From: Keith Moore <[email-masked]>
Date: Fri, 25 May 2001 13:56:52 -0400

> can we define a long-term strategy that ACE plugs into?

I am not sure what is the appropriate long-term strategy for existing
applications.  I think it might be different for different applications,
that such strategies need to be worked out by the folks who are 
most familiar with those applications. And at least for some of those 
applications, the precise details of how the transformation would be
done are very important and should not be anticipated by the IDN group.

For the specific example of email I would be reluctant to support per-hop
negotiation of IDN capability, and more generally I would be reluctant
to support any per-hop negotiation which required MTAs to mung or translate
messages.  I think MTAs should in general relay mail as faithfully as 
possible from end to end without trying to anticipate what translations
are wanted by the recipients. OTOH, I might support a strategy that had 
sending UAs decide whether to generate UTF-8 or ACE addresses (on a 
per-recipient basis) based on the result of a rescap query for each 
recipient address.

Keith

---

From: "Mark Davis" <[email-masked]>
Date: Fri, 25 May 2001 10:50:01 -0700

This is clearly urgent.

1) There is a vast pent-up demand for this, as evidenced by the number of
registrations at the Verisign test bed and other places. (I suspect that if
the English speakers on this list had been forced to write URLs with
Cyrillic characters all their lives, they would have more of a sense of
urgency also ;-)

2) The delay is just producing dozens of incompatible ad-hoc 'solutions',
all getting more and more entrenched. (From the outside, it does not appear
that the debate on this list has been particularly productive for some time,
in that there is little evidence of people changing their positions due to
the discussions.)

Mark

---

From: Keith Moore <[email-masked]>
Date: Fri, 25 May 2001 15:44:34 -0400

> concerns, starting with assessing group urgency.

and this is why I suggested that the group consider agreeing to work
on a native UTF-8 protocol, after getting IDNA out the door - as a
compromise for those who are concerned that we will be stuck with
ACE forever.  we can't go to utf8 everywhere immediately, but we can 
at least make it easier for new applications to use native utf-8,
and for old applications to migrate when they can work out the details.

Keith

---

From: "D. J. Bernstein" <[email-masked]>
Date: 25 May 2001 21:46:41 -0000

Paul Hoffman / IMC writes:
> a vast smattering of other choices with none having even 10% of the support.

In fact, several of those ``other choices'' were UTF-8; some of us
support UTF-8 but didn't list a choice in the poll; and we don't know
how many of the IDNA supporters also support UTF-8.

Bottom line: This poll was not presented to us as a measurement of UTF-8
support. It is thoroughly inappropriate for you to be using it that way.

> nameprep, which at this point is finished

No, it isn't, because it allows Beta, in violation of the nameprep-02
requirement that normalization ``must not introduce any chance that two
host names could be represented by two distinct strings of characters
that look identical to typical users.''

You seem to have removed that requirement without WG approval, but the
problem remains: you are allowing B and Beta in host names, normalized
to the distinct characters b and beta, even though B and Beta have
identical appearances in print.

---Dan

---

From: Dave Crocker <[email-masked]>
Date: Fri, 25 May 2001 16:48:21 -0700

At 12:44 PM 5/25/2001, Keith Moore wrote:
>on a native UTF-8 protocol,

Keith,

There is massive distance between agreeing that a problem is urgent and 
agreeing that a particular technical path is the best solution.

Jumping to assert the correctness of a particular solution has proved 
problematic, here.  That is why I am suggesting a series of SMALL decision 
steps, starting with one that is focussed on the anture problem and not the 
solution.  Getting agreements about the problem are necessary before people 
can agree on the choice of solution.

d/

----------

---

From: Keith Moore <[email-masked]>
Date: Fri, 25 May 2001 20:19:53 -0400

> agreeing that a particular technical path is the best solution.

no doubt.
 
> problematic, here.  

No doubt about that either.  But I don't think I've made any such assertions.

There is a point beyond which you're not likely to get any agreement on the
nature of the problem.  I think we reached that point several months ago.
There is likely to continue to be a gap between those who strongly feel
that we must provide the minimal possible disruption to the installed base
and those who strongly feel that we cannot afford to saddle everyone with
ASCII baggage forever.    Both views have merit, they simply reflect different
kinds of experience.  But there's no way to establish for certain which path 
is better.

Fortunately we really don't have to have concensus on the nature of the 
problem in order to make progress.  All we have to do is get consensus
on a solution, or at this point, on a strategy for moving forward.  We 
don't have to have consensus on the reason for choosing that strategy.

Keith

---

From: Dave Crocker <[email-masked]>
Date: Fri, 25 May 2001 17:38:41 -0700

>No doubt about that either.  But I don't think I've made any such assertions.

Unfortunately, that is exactly what you did.  Re-read the way you asserted 
a particular solution.

>nature of the problem.  I think we reached that point several months ago.

I thought we did, too, but the fact that there is lack of clarity about the 
sense of urgency was a rather surprising suggestion that that we have NOT 
reached that point.

d/

----------

---

From: Keith Moore <[email-masked]>
Date: Fri, 25 May 2001 20:53:28 -0400

> Unfortunately, that is exactly what you did.  Re-read the way you asserted

Dave, you might or might not agree with the plan of action I proposed,
but I don't see how it's helpful for you to question my intent.  Nor do
I see how it's helpful for us to argue about whether I've asserted "a 
correct solution", asserted "a solution", or merely suggested a way 
forward.  So let's just drop it.

> sense of urgency was a rather surprising suggestion that that we have NOT

Even though I happen to think that our window of opportunity for doing
anything useful is fast disappearing, I'm not going to get hung up on 
whether other people feel a sense of urgency - because I believe that 
trying to convince people that there's a sense of urgency will take 
too long.  Just like any other factor, the urgency is more visible to 
some people than others.

Keith

---

From: "James Seng/Personal" <[email-masked]>
Date: Sat, 26 May 2001 11:11:01 +0800

To add another point, which we may/may not want to consider valid:

Verisign is moving ahead to put RACE into their .COM zone would means
wide deployment of RACE and also applications (or servers) to be
developed to support resolutions. They may or may not be IDNA or even
close to the what we like to be.

But the fact that this is happening is somewhat of a concern as it may
undermine the work we are doing in this Working Group as it *might* lead
to an industry driven protocol.

-James Seng

----- Original Message -----
From: "Mark Davis" <[email-masked]>
To: "Paul Hoffman / IMC" <[email-masked]>; "Dave Crocker"
<[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, May 26, 2001 1:50 AM
Subject: Re: [idn] report of the straw poll

> > working group view of urgency.  If there is consensus about urgency
THEN
> we

---

From: "James Seng/Personal" <[email-masked]>
Date: Sat, 26 May 2001 11:16:08 +0800

If we count the 14 who disagree with IDNA and suggested their own
Internet Draft instead, then ...

-James Seng

----- Original Message -----
From: "Bright Fulton" <[email-masked]>
To: "Dave Crocker" <[email-masked]>
Cc: "Paul Hoffman / IMC" <[email-masked]>; <[email-masked]>
Sent: Saturday, May 26, 2001 1:34 AM
Subject: Re: [idn] report of the straw poll

> > working group view of urgency.  If there is consensus about urgency
THEN we

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Fri, 25 May 2001 20:25:27 -0700

>close to the what we like to be.

VGRS *might* put RACE into the .com zone, or they might do the more 
rational thing and wait for the ACE Design Team's report. It is not 
appropriate to say what VGRS will or will not do in the future; that 
changes all the time.

Section C of Appendix K of the agreement between VGRS and ICANN 
reserves all RACE names for ICANN; VGRS needs permission before they 
can add them to the TLDs.

Why is any of this relevant to the straw poll?

>to an industry driven protocol.

Or it might not.

--Paul Hoffman, Director

---

From: "James Seng/Personal" <[email-masked]>
Date: Sat, 26 May 2001 11:38:50 +0800

> Why is any of this relevant to the straw poll?

Nope, of course it is not. It may not even be relevant to the work we do
here since it is a commerical testbed and we should not let it drive our
work. But still, it is unnerving.

OTOH, it is comforting to know there is a "Section C of Appendix K" of
some agreement which bind them. :-) I am obviously not a lawyer so I
have to presume it is air-tied (unlike the one they did in 98).

Anyhow, it is a side-topic which as we agree it may not be relevant. Let
not dwell on this.

-James Seng

---

From: Rick H Wesson <[email-masked]>
Date: Fri, 25 May 2001 22:07:42 -0700 (PDT)

It looks like we have a 3 week reprieve on RACE going into .com.

> To All IDN Registrars:
>
> Based upon recommendations from ICANN, VeriSign GRS is delaying the
> start of Resolution Phase 3.3 for three weeks.  The deployment date
> for Resolution Phase 3.3 is now scheduled for June 19, 2001.
> VeriSign GRS regrets the lateness of this notification.

-rick

---

From: Dave Crocker <[email-masked]>
Date: Fri, 25 May 2001 22:18:17 -0700

>but I don't see how it's helpful for you to question my intent.  Nor do

It was not your intent, it was your action.

The reason that I responded to your note was that I was (and am) suggesting 
that the way to reach a solution is to pursue a series of small steps.

Your note was phrased in a way that made it easy to think it was intended 
to be related to my suggestion, though it was not.  I therefore wanted to 
make sure that no one thought it was.

d/

----------

---

From: Keith Moore <[email-masked]>
Date: Sat, 26 May 2001 09:48:21 -0400

> make sure that no one thought it was.

fair enough.  I don't think my suggestion was much related to yours either.

Keith

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sun, 27 May 2001 10:29:12 -0400

Marc,

I sent one of the two "Just send binary (UTF)" ballots, (use rfc2044),
arch-1 in Paul's taxonomy (draft-ietf-idn-compare-01.txt).

NeuStar hasn't completed its independent review of the Walid and Ydsig
patent claims. NeuLevel will not deploy RACE, unless directed to do so
by ICANN.

On the presumption that the IPR issue can be resolved acceptably by the
claimants and the IETF, or alternatively that a second independent review,
possibly ours, concludes as Verisign did, that there is no infringement,
my view is consistent with arch-2, "send binary or ACE", and of the ACE
choices, I'm in agreement with the idna-nameprep-ace orientation.

NeuStar will complete its independent review of the Walid and Ydsig patent
claims before London, and I'll post our findings and work-product when they
are available, initially to cooperating registries, and promptly thereafter
to this working group and other interested parties.

People working on the problem of utf8-on-the-wire feel free to drop me a note
off-list.

Eric

---

From: Marc Blanchet <[email-masked]>
Date: Sun, 27 May 2001 10:47:10 -0400

At/À 10:29 2001-05-27 -0400, Eric Brunner-Williams in Portland Maine you 
>choices, I'm in agreement with the idna-nameprep-ace orientation.

you mean that, presuming no IPR, you change your vote to "agree on 
idna-nameprep-ace".
right?

>to this working group and other interested parties.

I'm sure that this will be valuable input to the wg.

Thanks, Marc.

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 29 May 2001 12:01:34 -0400

another (much more contentious, but I'm throwing it anyway) reading of the 
straw poll:
- in the disagree group, there is no concensus on alternatives.
- one would expect to vote for himself: i.e. I've not looked at who vote 
for what, but I could suspect interested parties to vote for their 
technology or their proposals.
- 3 disagree proposed nothing.

If one put aside the "vote for myself" and the "nothing proposed", then 
only 5 people remains and all propose some variant of UTF8.

compared to 36 participants who all agree on the same proposal.

So another reading of the results is maybe that we do have a "rough concensus".

controversial statement, right? Think about it before replying.

Before someone jump over me: I'm fairly neutral for the outcome of the wg 
orientation.

Marc.

At/À 08:38 2001-05-25 -0400, Marc Blanchet you wrote/vous écriviez:
>suggested alternatives with the number of people in the front of each line:
>

---

From: "Adam M. Costello" <[email-masked]>
Date: Fri, 1 Jun 2001 03:07:54 +0000

Paul Hoffman / IMC <[email-masked]> wrote:

> need to finish nameprep, which at this point is finished other than it
> does not address the new characters added in Unicode 3.1.

Nameprep currently includes the following steps:

    KC-normalize
    map
    KC-normalize
    prohibit

KC-normalize is defined (by the relevant Unicode technical report) as
compatible-decomposition followed by canonical composition.  So the
steps are really:

    compatible-decompose
    canonical-compose
    map
    compatible-decompose
    canonical-compose
    prohibit

Do libraries that provide a KC-normalize function also provide the
separate decompose and compose functions?  If so, consider simplifying
the procedure to:

    compatible-decompose
    map
    canonical-compose
    prohibit

Nameprep defines the mapping step itself, so it could take care to
define it in such a way that it preserves the compatibly-decomposed
property (easy--just make sure the output of each mapping entry is
compatibly decomposed), which ensures that the final output is in
normalization form KC.  The mapping table would be smaller this way,
because it would be operating on a smaller repertoire.

AMC

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 31 May 2001 20:38:37 -0700

>Nameprep currently includes the following steps:

Er, no it doesn't. It only includes map->normalize->prohibit.

--Paul Hoffman, Director