I'm a bit uncomfortable with characterizing this as a conclusion of the "rest of the WG". <br><br>On
my part, there are definitely positives and negatives to IDNA2008, and
the incompatible mappings are in the negative column. As Erik said,
people in Japan (for example) will be as surprised that full-width
mappings don't work as Europeans would be that uppercase mappings don't
work.<br>
<br>Off the top of my head, I see IDNA2008 as the following.<br><br><b>Pluses</b><br>+ Major improvement in update to Unicode 5.1<br>+ Major improvement in making process of updating to future Unicode versions mostly-automatic<br>
+ Major improvement in allowing needed sequences (combining marks at end of bidi label).<br>+ Significant improvements to the BIDI rules<br>+ Significant improvements to the definitional framework<br>+ Significant improvements in user expectations for special cases: sigma, sharp s, joiners<br>
<br><b>Minuses</b><br>- Major interoperability/security issue with special cases, URLs going to different places<br>- Major interoperability issue with local mappings<br>- Significant interoperability issue by not continuing 2003 mappings<br>
- Significant increase in complexity, reducing the likelyhood of correct implementation<br>- Small interoperability issue by excluding symbols, punctuation<br>- Updating to future Unicode versions requires a manual step to avoid incompatibilities<br>
<br>(The special cases have both pluses and minuses.)<br><br>On the whole, if we can address some of the open issues (including
a fix to the local mappings), IDNA2008 is better than remaining with
IDNA2003. But that doesn't meant that some of these negatives aren't
true negatives.<br>
<br>The problem I find is that where interoperability is important (and
it is here!) each break in compatibility needs to be assessed on its
merits: <br><ul><li>what (precisely!) are the problems, and <br></li><li>is the proposed solution worth the change.</li></ul>Merely
sayings that "we've heard that there are problems with mappings in
multiple meetings" doesn't establish the cost or the benefit of a
breaking change. In particular, it doesn't tell us *which* mappings
were problems, and *what* those purported problems are, so that we can assess the magnitued. It's a bit of design by
hearsay. It could well be that the mappings that people have problems
with are four special cases referenced above, and that just excluding
them is sufficient. Or it could be a broader set. Without a listing of what the mappings are,
and what problems they cause, we just don't know!<br>
<br>In some cases, I think we can agree that broad strokes are ok. For
example, the breaking change of excluding all symbols from IDNA even though only
a few cause problems is probably ok, because the frequency of usage of
all symbols is so very low. And few people really expect symbols in
identifiers anyway. <br><br>The compatibility changes for BIDI are clear; we know why we are making them, and have clear justification for each of the changes in order to reduce visual confusion.<br><br>But mappings like lowercase, fullwidth, etc are
different.<br><br clear="all">Mark<br>
<br><br><div class="gmail_quote">On Mon, Jan 26, 2009 at 23:25, John C Klensin <span dir="ltr"><<a href="mailto:klensin@jck.com">klensin@jck.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Paul,<br>
<br>
We may need to agree to disagree about this. The conclusions of<br>
the rest of the WG --and, to the extent to which we can<br>
understand it-- the rest of the Internet community and<br>
particularly the people more affected in the non-ASCII scripts<br>
in their everyday lives than you or I are -- are more important.<br>
I'm been traveling internationally for the last several years<br>
and attending a lot of meetings. Some of those meetings and<br>
trips have been specifically related to IDN-related topics.<br>
Others have not, but that fact has, many times, not prevented me<br>
from getting a lot of input on these issues. Before I stopped<br>
going to ICANN meetings, I was hearing a lot there too and have<br>
since been hearing from Cary, Tina, and others who are still<br>
involved. I've heard from registrars, registries, and end users<br>
(many of each). And, with two qualifications, everything I said<br>
in my note is an accurate reflection of those discussions.<br>
<br>
Those qualifications are:<br>
<br>
(1) You misread my "all of the mappings in IDNA2003" comment.<br>
You read it as hyperbole, presumably that I was suggesting that<br>
every mapping was a problem. I intended "all" as in "the very<br>
large number of mappings in IDNA2003:".<br>
<br>
(2) To a certain extent, each person has his or her favorite<br>
mapping and is willing to dispense with most or all of the<br>
others. It seems to me that there are three ways to deal with<br>
that observation, two of which are obvious and, at least<br>
conceptually, fairly easy:<br>
<br>
(i) Put all of the desired mappings into the spec. I<br>
note that I've heard requests for mappings that go<br>
beyond those in IDNA2003, often justified by "if you are<br>
going to do _those_, you should certainly support<br>
_mine_".<br>
<br>
(ii) Draw the line at "having no mappings at all makes<br>
everyone equally unhappy and has some other advantages".<br>
<br>
(iii) Try to find some middle ground.<br>
<br>
Ignoring, for the moment, the issue of information preservation<br>
and reverse mapping (see below), the first is guaranteed to<br>
leave some people unhappy and to leave the IETF either in the<br>
position of making a lot of very subtle and script-specific (or<br>
usage-specific) decisions or trying to blame any decision people<br>
don't like on Unicode. Remember, in that regard, that some<br>
decisions that may be entirely correct for the very large set of<br>
applications of Unicode may not be appropriate for people's<br>
perceptions of what works well in IDNs, conditioned by<br>
traditional DNS "exact match" constraints. Some of the other<br>
input I've gotten makes it very clear that assigning blame,<br>
rather than getting things right, is neither acceptable nor<br>
useful. YMMD and, based on your knowledge and whatever<br>
communities you have gotten input from, probably does.<br>
<br>
Because the second has proven difficult in terms of an adequate<br>
explanation of local -- "if you think those are the same, map<br>
them before the putative label gets to IDNA and make sure that<br>
nothing that requires mapping appears on the wire" -- mappings,<br>
I thought it was worthwhile exploring the third. If Vint tells<br>
me that exploration of out of charter and that I should stop, I<br>
will promptly do so. But, at the moment, I think it is clearly<br>
more desirable to find out whether there is a position on which<br>
we can agree than to try to simulate protocol-lawyer action on<br>
the charter.<br>
<br>
FWIW, I believe that _adopting_ any mappings into the protocol<br>
would require a modification or exception to the charter, since<br>
"no mapping" is one of the "requires rechartering" listed in the<br>
three points at the end of the description. Whether even<br>
raising that possibility is out of order is, IMO, up to the<br>
Chair... but, if it position is that it is, then, IMO, so are<br>
both your substantive suggestions and your recharter proposal on<br>
this mailing list. I think that position would lead us into a<br>
silly state, but, again, YMMD.<br>
<br>
My reading of the charter is that everything we have actually<br>
agreed to do, and everything that is reflected in the documents<br>
so far, is clearly within charter, too much optimism about<br>
scheduling notwithstanding. Please note in particular the 11th<br>
full paragraph of the description, which begins:<br>
<br>
"Subject to the more general constraints described<br>
above, the WG is permitted to consider changes that are<br>
not strictly backwards-compatible."<br>
<br>
That seems fairly clear to me. The rest of that paragraph<br>
requires us to document those changes. If you don't think we<br>
have done an adequate job of that documentation, please send<br>
proposed text.<br>
<br>
Finally, "the mappings were never meant to be two-way." is<br>
certainly a correct statement about IDNA2003. The contention is<br>
that having two-way mappings is a better decision and an<br>
important one, not that the decisions of IDNA2003 were not what<br>
they were.<br>
<br>
regards,<br>
john<br>
<br>
--On Monday, January 26, 2009 6:18 PM -0800 Paul Hoffman<br>
<div class="Ih2E3d"><<a href="mailto:phoffman@imc.org">phoffman@imc.org</a>> wrote:<br>
<br>
> At 8:26 PM -0500 1/26/09, John C Klensin wrote:<br>
>> Reasonable people may disagree, but we've gotten very clear<br>
>> signals that all of the mappings of IDNA2003 were bad news.<br>
><br>
> Reasonable people do disagree. The hyperbole about "all of" is<br>
> particulary silly.<br>
><br>
>> They create, rather than reduce confusion, especially since<br>
>> information is lost in the reverse mappings.<br>
><br>
> That is a very old straw man. The mappings were never meant to<br>
> be two-way.<br>
</div>>...<br>
<div><div></div><div class="Wj3C7c"><br>
_______________________________________________<br>
Idna-update mailing list<br>
<a href="mailto:Idna-update@alvestrand.no">Idna-update@alvestrand.no</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/idna-update" target="_blank">http://www.alvestrand.no/mailman/listinfo/idna-update</a><br>
</div></div></blockquote></div><br>