Brief Plans for IDNAbis WG meeting at SF IETF
Erik van der Poel
erikv at google.com
Sat Mar 14 20:47:03 CET 2009
Given the nature of the IETF meeting format (lining up at the
microphone) and the possibility that we might end up spending a lot of
time on Agenda Item 1 below, may I suggest that since many of us
already know of basic implications for backward compatibility, that we
reiterate those with short explanations between now and the meeting,
and that you (possibly with the help of an assistant) collect and
summarize those statements before the meeting?
Similarly, the implications of Paul's approach can also be suggested
by mailing list participants, and those can also be collected and
Of course, the intention would be to have meeting attendees read those
summaries before attending, so that we can avoid spending too much
time on mere statements and explanations of the summarized items.
I believe your next two steps (after Agenda Items 1 and 2), i.e.
whether or not to publish IDNA2008 and whether or not IDNA2008 and
IDNAv2 can somehow be combined, are much more interesting and useful.
There may be a way to "generate" tables similar to IDNA2003's from
future versions of Unicode, without adding a new prefix each time. I
may have more to say on this later.
On Sat, Mar 14, 2009 at 11:21 AM, Vint Cerf <vint at google.com> wrote:
> We will meet on Monday and Tuesday, March 23/24.
> I would like to suggest that we attempt to come to some closure the
> work in the following way:
> 1. Assuming the charter as it is stated, we try to agree on what the
> system (IDNA2008) looks like. In particular, assuming that mapping is
> NOT part of the protocol. I would want also to try to agree on the
> basic implications for backward (in)compatibility with the existing
> IDNA2003 behavior. This effort is not necessarily a decision-making
> one but rather an attempt to agree on the implications of a charter-
> consistent design. I would emphasize here that an important component
> of the charter was to try to accommodate changes to UNICODE by
> algorithmic means (tables, bidi rules, etc) and not have to convene
> IETF WGs to agree on any implied changes to the tables
> 2. Consider the proposal by Paul Hoffman to implement an extension of
> IDNA2003 by direct additions or changes to tables of valid characters
> or mappings of characters. Again we would want to try to agree on the
> implications of this approach.
> If we can get this far, I would suggest two further steps. Within the
> current charter, I would seek to publish the IDNA2008 as the product
> of the WG. However, I would also raise the basic question, which of
> the two approaches appears to be most beneficial in terms of
> implementation in the short term and maintenance in the longer term. I
> would guess that there are different views on these points and perhaps
> other or better metrics by which to judge the alternatives. There may
> be intermediate alternatives that somehow combine the rule-based
> IDNA2008 approach with mapping or other tactics that increase the
> backward compatibility of the proposed and current practices.
> Your thoughts on this approach would be appreciated.
> Vint Cerf
> 1818 Library Street, Suite 400
> Reston, VA 20190
> vint at google.com
> Idna-update mailing list
> Idna-update at alvestrand.no
More information about the Idna-update