Charter changes and a possible new direction

Patrik Fältström patrik at frobbit.se
Tue Jan 13 22:15:18 CET 2009


Some quick comments (and therefore not comments on all of this email  
or the proposed draft).

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

> 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.

I strongly disagree with this. The change from just using a table, to  
use a series of rules, is a big change that make things very  
different. That some of the rules are tables (you mention exceptions  
and backward compatible lists) does not change the fact this  
algorithmic approach is Unicode independent. Given no drastic changes  
are made to Unicode in future versions, we will never see any  
codepoints be added to the backward compatible list.

The difference between your proposed approach and IDNA2008 is that for  
your tables to work, one *have* to update the RFC for every Unicode  
version. Something that is not needed in IDNA2008.

> - "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).

If I do not misunderstand you, I see no difference between IDNA2003  
and IDNA2008 (or your proposal) regarding this binding that must  
happen at time of registration. This due to registry policy and  
language table issues.

> - "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).

I strongly disagree with this conclusion of yours.

The statement is, once again: "This work is intended to specify an  
improved means to produce and use stable and unambiguous IDN  
identifiers."

This is true as it is making a very big change from IDNA2003, and that  
is to have a very well defined definition of an A- and U-label.

The problem you point out has to do with the transition from IDNA2003  
to IDNA2008 and the fact mappings where part of IDNA2003, so that it  
is unclear whether for example eszett is "ok" (note the citation) or  
not.

> 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.

For specific codepoints, yes. And you will not get away from that if  
you update IDNA2003. If you want to move forward with your proposal,  
you have to add exactly the same position dependent rules. So while  
the regular expressions have been added during the evolution of  
IDNA2008, it is not the case that one will get rid of them if one is  
trying your proposal. They exist for a reason, and that reasoning does  
not go away with your proposal.

> 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.

This conclusion is not correct. See above.

> 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.

FWIW, I have no problems throwing away the document I have been  
working on, but after being a document author of IDNA2003, implementor  
of IDNA2003 and various stringprep algrorithms, document author of  
IDNA2008, I think you take too lightly on how easy it is to update  
IDNA2003.

If you "just" update IDNA2003, you have to:

- Update the future RFC at EVERY update of the Unicode Standard. For  
IDNA2008 you only have to check whether something have to be added to  
the backward compatibility list -- an operation we all hope IANA can  
do after we have verified once that "it works" as expected.

- Separate the mappings from the actual codepoints that can be used in  
the DNS, and come up with a terminology for it.

- Fix the Bidi issues that we knew with IDNA2003 that we did not get  
right (or at all).

- Still have the regular expressions that say what codepoints are  
valid where.

- Still have issues with transition from IDNA2003 to IDNAv2 (as you  
call it) as there will be incompatibilities.

So I think your document, if that is the basis for future work in this  
wg, is very very short and to be frank, naive.

It could still be that this wg want to move forward with that  
approach. As a wg participant with the experience I have, and not  
document author, I would argue against it.

Regarding the stability of the documents, and the direct question to  
me as a document editor, I have not got any comments on my latest  
version of the tables-05 document, so part from one editorial mistake  
(that existed in -03, was fixed in -04 and now came back again) in the  
derived table, I claim there is consensus for it in the wg. So  
restarting with the work that is behind the tables document, and work  
in the issue in your document, that will be a 1-2 year process. Not  
something we can do over dinner. Regardless of how nice the dinner  
is ;-)

> 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.

Better to have this discussion now than later.

     Regards, Patrik



More information about the Idna-update mailing list