Subject: [idn] IDN WG Summary

From: "James Seng/Personal" <[email-masked]>
Date: Tue, 5 Jun 2001 22:12:29 +0800

The Working Group has been in existence for over 18 months so far. While
we made a lot of progress in the these 18 months, we have unfortunately
not managed to keep to our original dateline and are way behind
schedule.

In particular, IDN WG suffers from a symptom common to WGs that exist
too long: repeat discussions of old arguments. Like any WG, we have new
members joining us at regularly basis and with them, they bring fresh
ideas and contributions. OTOH, we also begin to rehash arguments which
we thought we have finish with.

Attempting to do a summary of the WG would be extremely sensitive but
something that we (as working group chairs) have to do if we were to
move forward.

1. IDN Matching problem

So far, we have one serious proposal: draft-ietf-idn-nameprep.

There is also another draft-ietf-idn-jpchar but we do not see it
conflicting with Nameprep.

Another work been carried out outside the WG: draft-duerst-i18n-norm

There are also one undocumented proposal, namely: Dan's Fast-Nameprep
(aka Fix the keyboard so there is no bad names).

We should try to converge these solutions.

2. IDN Encoding

IDN Encoding means over-the-wire encoding of IDN. Here is fun, which we
have several proposals including 7-bit *ACE, 8-bit legacy, 8-bit UTF-8
and others. Here, we have to select probably one or more encodings for
IDN.

draft-ietf-idn-race
draft-ietf-idn-sace
draft-ietf-idn-trace
draft-ietf-idn-brace
draft-ietf-idn-lace
draft-ietf-idn-utf6
draft-ietf-idn-dude
draft-ietf-idn-altdude
draft-ietf-idn-dunce
draft-ietf-idn-step
draft-ietf-idn-amc-ace-m
draft-ietf-idn-amc-ace-o
draft-ietf-idn-amc-ace-r
draft-ietf-idn-amc-ace-w
draft-ietf-idn-amc-ace-v
draft-jseng-utf5
draft-dkjang-idn
UTF-8
UTF-16
UTF-32
Legacy Encodings (GBK, BIG5, ISO8859-X, ISO2022-X, ...)

3. IDN Protocol

IDN Protocol refers to a specify possible direction on how the WG
decides IDN protocol is going to work general. Some of this IDN Protocol
are independent of IDN Encoding and the matching problem. (e.g. IDNA
could use UTF-8 over-the-wire).

Either way, we have to find a solution here. It is also important to
note that some of the following solution cannot be done alone within
this Working Group especially if it touches DNS protocol.

draft-ietf-idn-idne
draft-ietf-idn-udns
draft-ietf-idn-icu
draft-ietf-idn-dnsii-xxx
draft-ietf-idn-idnra
draft-ietf-idn-idna
draft-ietf-idn-vidn
draft-ietf-idn-uname

Also, there are some proposals which is more radical which does not
fit into the (1) to (3) framework. In particular, we have
draft-klensin-dns-role which suggest there is no solution at all
in the DNS space but to move it higher.

draft-klensin-dns-role
draft-klensin-dnsclass0e
draft-klensin-i18n-newclass
draft-klensin-dns-search

4. Misc

These are I-Ds related to the working group which may be move forward as
Information RFC or more. At this moment, the working group chairs cannot
see any consensus what to do with them yet, except the requirements I-D
which we agreed to move it on.

draft-ietf-idn-requirements
draft-ietf-idn-compare
draft-ietf-idn-cjk
draft-ietf-idn-version
draft-ietf-idn-iptr
draft-ietf-idn-aceid
draft-ietf-idn-uri
draft-ietf-idn-mua
draft-masinter-url-i18n

This is a broad picture of the complexity of the problem we have. We
also noted two major problem in the working group, namely (a) we have
too many proposals (b) we do not have enough consensus behind any single
proposal.

The last strawpoll on IDNA is particularly interesting. With 36/14 poll,
we gathered that the WG have strong support for IDNA but it is not
sufficient for the WG chairs to declare consensus on IDNA. As such, we
recommend that the authors for IDNA to continue to refine their work.

And to solve problem (a), ie too many proposals, the chairs has been
given advise that eliminating proposals so we have a reduced problem-set
is one way to solve it. Given this good advice, we will be putting some
of them to be drop from the Working Group in the next few weeks. We
would also appreciate if the Authors could obsolete their own work
(either they do not feel it is worth pursuing or it is obsolete by
newer I-Ds).

Hopefully this would put the working group back on track to where we
suppose to be heading. Thank you.

-James Seng

---

From: "Brian W. Spolarich" <[email-masked]>
Date: Tue, 5 Jun 2001 10:53:37 -0400

| 2. IDN Encoding
|
| IDN Encoding means over-the-wire encoding of IDN. Here is fun, which we
| have several proposals including 7-bit *ACE, 8-bit legacy, 8-bit UTF-8
| and others. Here, we have to select probably one or more encodings for
| IDN.

  My understanding was that the ACE design team would make a recommendation
and the WG would use that recommendating in making its choice regarding
this.  Most of the drafts in the list you supplied are not currently under
consideration by the ACE design team.  I don't believe the ACE situation to
be as messy or undefined as you characterize it here.

| This is a broad picture of the complexity of the problem we have. We
| also noted two major problem in the working group, namely (a) we have
| too many proposals (b) we do not have enough consensus behind any single
| proposal.
|
| The last strawpoll on IDNA is particularly interesting. With 36/14 poll,
| we gathered that the WG have strong support for IDNA but it is not
| sufficient for the WG chairs to declare consensus on IDNA. As such, we
| recommend that the authors for IDNA to continue to refine their work.

  I think that the poll was unsuccessful as there was too much room for
ambiguity and confusion in the way it was presented (or at least
interpreted).

  I see a number of competing points of view that need to be brought
together into something more cohesive:

  1. IDNA/ACE/Nameprep now and forever;
  2. IDNA/ACE/Nameprep now and UTF-8 later (either direct, new class, or
EDNS);
  3. IDNA/ACE/Nameprep now and jck's directory service later;
  4. jck's directory service now;
  5. UTF-8 now and forever (either direct, new class, or over EDNS).

  I know that some people will likely shoot me for oversimplifying, but if
everyone insists on getting exactly what they want and only what they want,
we won't get anywhere with this.  Consensus typically requires compromise
and lots of listening to other people's point of view.

  I would suggest that the first three IDNA-related points of view do not
differ greatly.  If one believes that jck's concerns about the need for
ambiguous lookups and imprecise matching are important, and that they are
not well-placed in the DNS, then #3 above would be an acceptable path to
choose.  I would argue that 2 and 3 are practically mutually exclusive:
there's probably not much point in spending effort to make UTF-8 identifiers
available in the DNS if UTF-8-based searching is made available at a higher
level.

  jck believes strongly that if we actively pursue #3 then we'll never get
past IDNA, based on experience and pessimistic assumptions.  However I feel
strongly that the lack of a standard in the IDN space will create more
problems to overcome than a standard, and my sense is that many in the WG
would agree.

  So I believe that there is the real possibility of coalescing views 1-3,
and perhaps even 4, into a single proposal and action plan.

  If we could do that, I would expect the results of a new poll would be
somewhat improved wrt endorsing IDNA, which would bring us fairly close to
rough consensus.

  In my mind the UTF-8-now proponents need to agree upon a single proposal
in the form of a draft that they feel is acceptable.  Perhaps this is not
possible given the extremely divergent points of view that some have
expressed, but if the WG is going to move forward and seriously consider
this as an alternative to IDNA a coherent proposal, in the form of a draft,
is required.

| And to solve problem (a), ie too many proposals, the chairs has been
| given advise that eliminating proposals so we have a reduced problem-set
| is one way to solve it. Given this good advice, we will be putting some
| of them to be drop from the Working Group in the next few weeks. We
| would also appreciate if the Authors could obsolete their own work
| (either they do not feel it is worth pursuing or it is obsolete by
| newer I-Ds).

  This is a good idea.  We could eliminate many of the ACE drafts fairly
quickly (no offense to the authors intended, as all of these proposals have
generated good thinking and discussion on desirable features and the
necessary tradeoffs).  I'm sure Paul would be happy to retire RACE. :-)

  -bws

---

From: "Adam M. Costello" <[email-masked]>
Date: Mon, 11 Jun 2001 10:23:56 +0000

"Brian W. Spolarich" <[email-masked]> wrote:

>   2. IDNA/ACE/Nameprep now and UTF-8 later (either direct, new class,
>      or EDNS);

6. Both IDNA/ACE/Nameprep and UTF-8/Nameprep now and forever, and maybe
   a directory service later in addition.

That is, a protocol may use ACE or UTF-8 or both, depending on the
needs of that protocol.  For existing protocols like DNS and email, ACE
will be easier to deploy (UTF-8 alternatives could also be developed,
though it's not clear whether they'd offer much added value).  For new
protocols UTF-8 will be simpler.  Library interfaces could be encouraged
to work with UTF-8 and/or the local charset, regardless of the encoding
on the wire.

AMC

---

From: "J. William Semich" <[email-masked]>
Date: Wed, 13 Jun 2001 18:50:30 -0400

Verisign says the idn ACE design team plans to release a new version of ACE
in a few days (see below).

Can the chairs or design team participants add any light to that statement?

Thanks!

Bill Semich

X-Authentication-Warning: mx3.ops3.crsnic.net: majordomo set sender to
[email-masked] using -f
Reply-To: <[email-masked]>
From: "VeriSign Global Registry Services" <[email-masked]>
To: <[email-masked]>
Subject: [IDNList] IDN Testbed Update
Date: Wed, 13 Jun 2001 17:45:49 -0400
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
Sender: [email-masked]

To All IDN Registrars:

In the resolution report posted on May 28th, 2001, VeriSign GRS indicated
that a resolution strategy would be forthcoming.  Over the last two weeks we
have worked closely with ICANN and monitored the progress of the IETF's IDN
Working Group as they move to identify a new leading candidate ACE. We
believe that the IDN Design Team will have a recommendation shortly. This
will allow us to make final resolution strategy decisions so that VeriSign
GRS will be able to release the strategy in the next several days.

Best Regards,

Chris Sheridan
Customer Service
VeriSign Global Registry Services
www.verisign-grs.com
[email-masked]

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 13 Jun 2001 16:21:07 -0700

>in a few days (see below).

Reread what they said; you have badly restated it.

>Can the chairs or design team participants add any light to that statement?

Sure. The ACE design team is busily working on making a 
recommendation to the Working Group, just as we have been tasked to 
do all along. It is not ready in this moment; it will hopefully be 
soon. That last sentence is as true today as it was many weeks ago. 
That's how the IETF works.

--Paul Hoffman, Director
--Internet Mail Consortium