[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [idn] IDN WG Summary




| 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