Charter changes and a possible new direction

Vint Cerf vint at google.com
Wed Jan 14 06:03:06 CET 2009


Paul,

I think we are not is as bad straits as your note seems to imply. I  
think we are actually fairly close to reasonable closure on the new  
design - and continue to believe that the IDNA2008 structure provides  
for an update mechanism (through application of rules) that should,  
with the exception of some specific cases, render the protocol  
insensitive to changes in UNICODE. Before concluding that we should  
start yet another effort, I think I would like to try to close the  
remaining few areas of discussion in the present IDNA2008 documents.

The sharp S, final Sigma and the Joiner characters are exceptions  
that appear to me, at least, to be necessary.

I am not persuaded that a re-charter is needed if we have simply  
slipped the planned schedule.

I will read with interest your new draft but continue to believe that  
the rule-based model has desirable properties.

Vint Cerf
Google
1818 Library Street, Suite 400
Reston, VA 20190
202-370-5637
vint at google.com




On Jan 13, 2009, at 2:41 PM, 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