Charter changes and a possible new direction

Patrik Fältström patrik at frobbit.se
Wed Jan 14 05:03:57 CET 2009


Let me turn this around to you Paul.

I thought that, given the comments on the mailing list since the last  
versions of the documents, we now are done with IDNA2008. Given this,  
and the fact I as you can see claim we do fulfil the requirements in  
the charter part from the timeline, we could declare ourselves done,  
and pass this to the IESG.

I simply does not see us not following the charter, so for me, your  
request of starting working on IDNAv2 would (a) require a change of  
the charter goals significantly, and (b) delay the release of a  
followup of IDNA2003 with at least two years, this because of, as I  
explained in a separate message, you have only resolved the bidi  
issue, not the other issues. Issues that I claim with the IDNA2003  
model used in IDNAv2, will be much harder to resolve.

The only trouble is the timeline, and that can be updated.

    Patrik

On 13 jan 2009, at 20.41, Paul Hoffman wrote:

> Greetings again. I spent a fair amount of time over the holidays  
> thinking about where we are in the IDNAbis WG and came to a few  
> conclusions that I wanted to bring to the WG.
>
> First and foremost: we are not meeting our hard-fought charter in a  
> couple of areas. In the IETF, this means that we need to go back to  
> the IESG and ask for a re-charter to fix the problems. If we don't,  
> we run the very real risk of having our protocols be rejected by the  
> IESG after we think we are finished. It is only after a lot of hard  
> work on the part of the WG, particularly on the part of the draft  
> authors, that we have been able to see that we could not meet our  
> charter.
>
> In specific:
>
> - "This WG is chartered to decouple IDNA from specific versions of  
> Unicode using algorithms that define validity based on Unicode  
> properties." That was true when we started, but it is no longer true  
> in IDNA2008. Now we have both the very long (and still growing) list  
> in Exceptions and the BackwardCompatible list (which is empty, but  
> recent threads on the list say that it could be populated in the  
> future). The latter list is there specifically to handle property  
> changes after Unicode version 5.1, which makes the sentence from the  
> charter inherently wrong.
>
> - "The constraints of the original IDN WG still apply to IDNABIS,  
> namely to avoid disturbing the current use and operation of the  
> domain name system, and for the DNS to continue to allow any system  
> to resolve any domain name in a consistent way." If we consider IDNA  
> to be part of the DNS, then this is no longer true with the current  
> drafts. In specific, registries that are following the model of  
> IDNA2003 now must start using registration-binding if they want to  
> follow IDNA2008 and use European languages such as German or Greek  
> (and possibly some Arabic languages, depending on the output of the  
> ASIWG and this WG's adoption of their proposals).
>
> - "This work is intended to specify an improved means to produce and  
> use stable and unambiguous IDN identifiers." IDNA2008 makes the  
> current IDN identifiers unstable for German or Greek (and possibly  
> some Arabic languages, depending on the output of the ASIWG and this  
> WG's adoption of their proposals).
>
> Separate from the charter problems, it is also clear that we cannot  
> meet our original goals of making the update easy to implement. The  
> original design was based on the idea (that I supported) that an  
> inclusion-based system would be easier to implement than the mapping- 
> based system in IDNA2003. Over time, that goal clearly became  
> impossible. We now have a protocol that relies on context-sensitive  
> and position-sensitive regular expressions. The original design was  
> that we would not have to revisit the tables when new versions of  
> Unicode came out; recent threads on this mailing list have shown  
> that we now don't think that is possible.
>
> Because of these two large categories of problems, I went back to  
> the original design that Patrik and I came up with for updates. As  
> an exercise, I looked at what it would take to update IDNA to  
> incorporate Unicode 5.1, fix the bidi rules to handle the additional  
> languages that we had inadvertently excluded, and allow both the old  
> IDNA and the new to completely co-exist interoperably on the Internet.
>
> It turned out that it wasn't that hard. See <http://www.ietf.org/internet-drafts/draft-hoffman-idna2-00.txt 
> >. It proposes a straight update to RFCs 3454, 3490, 3491. Even  
> after five years, the number of changes needed to the mapping  
> algorithms turns out to be quite small.
>
> Given that we need to go back to the IESG to ask for a charter  
> change anyway, I would like the WG to consider what we want to ask  
> the IESG. There are currently three options:
>
> - We could ask them to relax the rules that require that IDNA2008 to  
> be decoupled from specific versions of Unicode and that it be  
> allowed to require some registries to use registration-binding and  
> that it not be required to be stable with respect to IDNA2003.
>
> - We could ask for a major charter change to adopt the much simpler  
> approach to modernizing IDNA that is outlined in draft-hoffman-idna2.
>
> - We could give up and say that the world should stick to the  
> original IDNA.
>
> Given the relative ease of development and  deployment for the  
> second option, I think the first is not the best way forwards, and  
> the third is unnecessary.
>
> Of course, the current document authors might be very attached to  
> their proposals, given how hard they have worked on them. In the  
> IETF, that has some weight, but not much if the work turns out to  
> not meet a WG's charter and to be much harder to develop and deploy  
> that was anticipated.
>
> What is most important is that we come up with something workable  
> that meets our charter. Given that we need to recharter anyhow, I  
> hope my proposal gives the WG a way forward to give the world a  
> stable upgrade to the current IDNA. If no one is interested in  
> pursuing this, I'll drop it, but I think that going to the IESG with  
> a charter revision for this simpler work is more likely to succeed  
> quickly than asking them to break interoperability with a widely- 
> deployed protocol.
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>



More information about the Idna-update mailing list