[idn] IDN WG Summary

["James Seng/Personal" <James@Seng.cc>]

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