Here's a modified proposal, a bit rough yet.<div><br></div><div>Live page: <a href="http://www.macchiato.com/unicode/idna/transition-proposal">http://www.macchiato.com/unicode/idna/transition-proposal</a></div><div><span class="Apple-style-span" style="font-family: Garamond; font-size: 16px; "><h1 style="font-size: 18pt; ">
<b>Problem</b></h1><div style="margin-top: 0px; margin-bottom: 0px; "><font size="3">We would like to have the 4 deviation characters be valid, at some point. The key problem is that we don't want current URLs in web pages, etc. to go to two different locations depending on the browser, nor do we want <a href="mailto:joe@fu%C3%9Fball.com">joe@fußball.com</a> to go </font><i><font size="3">sometimes</font></i><font size="3"> to <a href="mailto:joe@fu%C3%9Fball.com">joe@fußball.com</a> and </font><i><font size="3">sometimes</font></i><font size="3"> to <a href="mailto:joe@fussball.com">joe@fussball.com</a>. Even once IDNA2008 is approved, for a long time a majority of the implementations will still be IDNA2003, so this also goes for new label registrations during the transition period.</font></div>
<div style="margin-top: 0px; margin-bottom: 0px; "><div style="margin-top: 0px; margin-bottom: 0px; "><h1 style="font-size: 18pt; "><a name="TOC-Proposal" style="color: rgb(78, 125, 191); outline-style: none; outline-width: initial; outline-color: initial; "></a><b>Proposal</b></h1>
<div style="margin-top: 0px; margin-bottom: 0px; "><font size="3">IDNA2008 changes as follows:</font></div></div></div><blockquote style="padding-top: 10px; padding-right: 10px; padding-bottom: 10px; padding-left: 10px; border-top-style: none; border-right-style: none; border-bottom-style: none; border-left-style: none; border-width: initial; border-color: initial; margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 40px; border-width: initial; border-color: initial; ">
<div style="margin-top: 0px; margin-bottom: 0px; "><div style="margin-top: 0px; margin-bottom: 0px; "><div style="margin-top: 0px; margin-bottom: 0px; "><font size="3">The 4 deviation characters get the property PVALID_AFTER_2015</font></div>
</div></div><div style="margin-top: 0px; margin-bottom: 0px; "><div style="margin-top: 0px; margin-bottom: 0px; "><div style="margin-top: 0px; margin-bottom: 0px; "><font size="3"><br></font></div></div></div><div style="margin-top: 0px; margin-bottom: 0px; ">
<div style="margin-top: 0px; margin-bottom: 0px; "><div style="margin-top: 0px; margin-bottom: 0px; "><font size="3">The requirements are:</font></div></div></div></blockquote><div style="margin-top: 0px; margin-bottom: 0px; ">
<div style="margin-top: 0px; margin-bottom: 0px; "><div style="margin-top: 0px; margin-bottom: 0px; "><ol style="list-style-type: decimal; margin-top: 0px; margin-bottom: 0px; "><ol style="list-style-type: decimal; margin-top: 0px; margin-bottom: 0px; ">
<li style="margin-top: 0px; margin-bottom: 0px; "><font size="3">On registration, PVALID_AFTER_2015 is equivalent to PVALID</font></li><li style="margin-top: 0px; margin-bottom: 0px; "><font size="3">On lookup, PVALID_AFTER_2015 is treated as DISALLOWED up until 2016 Jan 1, 00:00:00 GMT, and treated as PVALID thereafter.</font></li>
<ol style="list-style-type: decimal; margin-top: 0px; margin-bottom: 0px; "><li style="margin-top: 0px; margin-bottom: 0px; "><font size="3">Implementations must not map the characters after the switchover date.</font></li>
</ol><li style="margin-top: 0px; margin-bottom: 0px; "><font size="3">Implementations that map the characters before that date, must map as in IDNA2003.</font></li></ol></ol></div></div></div><blockquote style="padding-top: 10px; padding-right: 10px; padding-bottom: 10px; padding-left: 10px; border-top-style: none; border-right-style: none; border-bottom-style: none; border-left-style: none; border-width: initial; border-color: initial; margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 40px; border-width: initial; border-color: initial; ">
<div style="margin-top: 0px; margin-bottom: 0px; "><div style="margin-top: 0px; margin-bottom: 0px; "><div style="margin-top: 0px; margin-bottom: 0px; "><font size="3"><br></font></div></div></div><div style="margin-top: 0px; margin-bottom: 0px; ">
<div style="margin-top: 0px; margin-bottom: 0px; "><div style="margin-top: 0px; margin-bottom: 0px; "><font size="3">The goal is to </font></div></div></div></blockquote><div style="margin-top: 0px; margin-bottom: 0px; ">
<div style="margin-top: 0px; margin-bottom: 0px; "><div style="margin-top: 0px; margin-bottom: 0px; "><ol style="list-style-type: decimal; margin-top: 0px; margin-bottom: 0px; "><ol style="list-style-type: decimal; margin-top: 0px; margin-bottom: 0px; ">
<li style="margin-top: 0px; margin-bottom: 0px; "><font size="3">allow the 4 character to become valid, as soon as possible; </font></li><li style="margin-top: 0px; margin-bottom: 0px; "><font size="3">avoid the 'nightmare' scenario of the same URL going to two different locations, as much as possible.</font></li>
</ol></ol></div><h1 style="font-size: 18pt; "><a name="TOC-Scenarios" style="color: rgb(78, 125, 191); outline-style: none; outline-width: initial; outline-color: initial; "></a><b>Scenarios</b></h1><div style="margin-top: 0px; margin-bottom: 0px; ">
<font size="3">Let's see what happens with fußball.xxx over time, where xxx is some registry (eg .de, .<a href="http://blogspot.com">blogspot.com</a>, or others). Background: essentially all browsers and other major implementations are planning to map for compatibility. We'll look at browsers, but this also applies to email, etc.</font></div>
<div style="margin-top: 0px; margin-bottom: 0px; "><h2 style="font-size: 14pt; "><a name="TOC-Early-2010-just-as-IDNA2008-is-appr" style="color: rgb(78, 125, 191); outline-style: none; outline-width: initial; outline-color: initial; "></a><b>Early 2010 (just as IDNA2008 is approved)</b></h2>
<h3 style="font-size: 12pt; "><a name="TOC-At-this-time-the-world-browsers-are" style="color: rgb(78, 125, 191); outline-style: none; outline-width: initial; outline-color: initial; "></a><b>At this time the world browsers are 100% IDNA2003</b></h3>
<div style="margin-top: 0px; margin-bottom: 0px; "><ol style="list-style-type: decimal; margin-top: 0px; margin-bottom: 0px; "><li style="margin-top: 0px; margin-bottom: 0px; "><font size="3">browsers map fußball.xxx to fussball.xxx.</font></li>
<li style="margin-top: 0px; margin-bottom: 0px; "><font size="3">registries can start accepting eszett, and should bundle with ss.</font></li><li style="margin-top: 0px; margin-bottom: 0px; "><font size="3">fußball shows up as fussball in the address bar</font></li>
<ol style="list-style-type: decimal; margin-top: 0px; margin-bottom: 0px; "><li style="margin-top: 0px; margin-bottom: 0px; "><font size="3">note: it is only by convention that fussball is seen in the address bar in this case; a browser could also display fußball, as in UTS46.</font></li>
</ol><li style="margin-top: 0px; margin-bottom: 0px; "><font size="3">results:</font></li><ol style="list-style-type: decimal; margin-top: 0px; margin-bottom: 0px; "><li style="margin-top: 0px; margin-bottom: 0px; "><font size="3">if the registry bundles, both fußball.xxx and fussball.xxx go to the same owner.</font></li>
<li style="margin-top: 0px; margin-bottom: 0px; "><font size="3">if the registry doesn't bundle, both fußball.xxx and fussball.xxx go to the same owner.</font></li></ol><li style="margin-top: 0px; margin-bottom: 0px; ">
<font size="3">The odd IDNA2008 browser that doesn't map just fails, because ß is not PVALID; it doesn't take fußball.xxx to a different location than the vast majority of browsers.</font></li></ol></div><h2 style="font-size: 14pt; ">
<a name="TOC-In-2013" style="color: rgb(78, 125, 191); outline-style: none; outline-width: initial; outline-color: initial; "></a><b>In 2013</b></h2><h3 style="font-size: 12pt; "><a name="TOC-At-this-time-the-world-browsers-are1" style="color: rgb(78, 125, 191); outline-style: none; outline-width: initial; outline-color: initial; "></a>At this time the world browsers are 50% IDNA2003, 50% IDNA2008</h3>
<div style="margin-top: 0px; margin-bottom: 0px; "><div style="margin-top: 0px; margin-bottom: 0px; "><ol style="list-style-type: decimal; margin-top: 0px; margin-bottom: 0px; "><li style="margin-top: 0px; margin-bottom: 0px; ">
<font size="3">same as above. No ambiguity in results.</font></li></ol></div></div><div style="margin-top: 0px; margin-bottom: 0px; "><h2 style="font-size: 14pt; "><a name="TOC-In-2016-Feb" style="color: rgb(78, 125, 191); outline-style: none; outline-width: initial; outline-color: initial; "></a><b>In 2016 Feb</b></h2>
<h3 style="font-size: 12pt; "><a name="TOC-At-this-time-the-world-browsers-are2" style="color: rgb(78, 125, 191); outline-style: none; outline-width: initial; outline-color: initial; "></a><b>At this time the world browsers are 1% IDNA2003, 99% IDNA2008</b></h3>
<div style="margin-top: 0px; margin-bottom: 0px; "><ol style="list-style-type: decimal; margin-top: 0px; margin-bottom: 0px; "><li style="margin-top: 0px; margin-bottom: 0px; "><font size="3">99% of browsers switch to not mapping fußball.xxx.</font></li>
<li style="margin-top: 0px; margin-bottom: 0px; "><font size="3">Registries no longer need to bundle; they can have different owners for fußball.xxx and fussball.xxx.</font></li><li style="margin-top: 0px; margin-bottom: 0px; ">
<font size="3">fußball shows up as fußball in the address bar</font></li><li style="margin-top: 0px; margin-bottom: 0px; "><font size="3">results:</font></li><ol style="list-style-type: decimal; margin-top: 0px; margin-bottom: 0px; ">
<li style="margin-top: 0px; margin-bottom: 0px; "><font size="3">if the registry bundles, both fußball.xxx and fussball.xxx go to the same owner.</font></li><li style="margin-top: 0px; margin-bottom: 0px; "><font size="3">if the registry doesn't bundle, fußball.xxx and fussball.xxx go to different owners.</font></li>
</ol><li style="margin-top: 0px; margin-bottom: 0px; "><font size="3">The odd IDNA2003 browser that is left goes to the wrong location for the affected languages; people that use them need to upgrade.</font></li></ol></div>
</div></div></div></div></span>Mark<br>
<br><br><div class="gmail_quote">On Tue, Dec 8, 2009 at 01:44, "Martin J. Dürst" <span dir="ltr"><<a href="mailto:duerst@it.aoyama.ac.jp">duerst@it.aoyama.ac.jp</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I agree with Mark that while there are similarities between MAYBE and TRANSITIONAL, there are also huge differences.<br>
<br>
One difference, which Mark has mentioned, is the number of characters affected.<br>
<br>
A second difference is that there would only be one transition from TRANSITIONAL to PVALID, not a series of transitions from MAYBE to PVALID.<br>
<br>
A third difference is that MAYBE was essentially saying "we don't have a clue now, we may have later". In my understanding (I didn't participate in any meeting), one of the main reasons brought by the Unicode side against MAYBE was that if it's MAYBE, we can as well look at the thing and decide now. For TRANSITIONAL, we may know exactly what we want to do, it just doesn't fit into PVALID and DISALLOWED.<br>
<br>
BTW, I don't think that any of the dynamic lookup schemes proposed by Andrew or Eric are feasible, they quite are simply overengineered. We need something much simpler, even if this temporarily goes against user convenience.<br>
<br>
Regards, Martin.<br>
<br>
On 2009/12/05 6:45, Mark Davis ☕ wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I agree with you that there are many similarities between the MAYBE and<br>
TRANSITIONAL. MAYBE at the time wasn't suitable because it was applied to a<br>
huge number of characters. However, applying the concept (with a few<br>
changes) to these 4 characters for a transitional period is, I think,<br>
feasible.<br>
<br>
Mark<br>
<br>
<br>
On Fri, Dec 4, 2009 at 12:40, John C Klensin<<a href="mailto:klensin@jck.com" target="_blank">klensin@jck.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Once upon a time, not really that long ago, there was a proposal<br>
to differentiate what is now PVALID by including MAYBE YES and<br>
MAYBE NO categories. Anyone interested should try to find a<br>
copy of draft-klensin-idnabis-issues-06.txt and earlier. The<br>
general model, in today's vocabulary, was to put characters (and<br>
groups of characters) that we weren't sure about into categories<br>
that would encourage different handling on registration and<br>
looking from characters about which we were more certain, to<br>
permit later reclassification, and to arrange for controlled<br>
transitions. There was consensus for removing those categories<br>
because they made things too fragile, because they would require<br>
that all registries and applications check for updates and<br>
changes frequently (which would be too fragile), and so on.<br>
<br>
In practice, the only real difference between MAYBE and the sort<br>
of implied TRANSITIONAL you imply (or the explicit versions<br>
others have suggested) is that MAYBE would have laid out the<br>
"this is likely to change" aspect of the situation more clearly,<br>
while the idea you outline above raises all of the issues that<br>
the WG has discussed about transitions from DISALLOWED to PVALID<br>
(and decided that reclassification should require a catastrophic<br>
situation).<br>
<br>
If I remember correctly, both you and Mark were at the meeting<br>
at which the decision to drop MAYBE was made and were among<br>
those pushing for that decision, pretty much on the basis<br>
outlined above.<br>
<br>
While I don't object to revisiting that general idea -- under<br>
the identification of TRANSITIONAL or otherwise-- if the WG<br>
really feels that it wants to go there and that the old model<br>
might be worth the aggravation that caused it to be dropped the<br>
last time around, I hope that everyone does understand that<br>
TRANSITIONAL, as you and others have described it, is very close<br>
to that old and discarded idea... close enough that we might<br>
even be able to borrow text from documents that are now more<br>
than 18 months old.<br>
<br>
best,<br>
john<br>
<br>
p.s. I'm not going to comment at any length on the "global<br>
mappings" part of your proposal because I think everything has<br>
been said already. Having required global mappings is<br>
equivalent to _almost_ having U-label<-> A-label symmetry.<br>
And, of all mappings, "map to nothing" is the worst: while part<br>
of the problem with a mapping between "ß" and "ss" is that one<br>
cannot tell by looking at "ss" afterward whether the registrant<br>
intended "ss" or "ß", one at least knows that "x" or "ab" was<br>
not intended. With "map to nothing", the character that was<br>
eliminated could, in principle, have appeared in any position in<br>
any domain name label.<br>
<br>
<br>
<br>
--On Friday, December 04, 2009 04:11 -0800 Erik van der Poel<br>
<<a href="mailto:erikv@google.com" target="_blank">erikv@google.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Here is another proposal that is dead simple, yet allows<br>
implementations to take advantage of a machine-readable file,<br>
and does not involve "flag days" (dates at which we change<br>
something).<br>
<br>
Instead of having a machine-readable file at each host, we<br>
have two global files at <a href="http://iana.org" target="_blank">iana.org</a>. One file is similar to<br>
Patrik's table with entries like:<br>
<br>
00DF ; DISALLOWED # LATIN SMALL LETTER SHARP S<br>
03C2 ; DISALLOWED # GREEK SMALL LETTER FINAL SIGMA<br>
200C ; DISALLOWED # ZERO WIDTH NON-JOINER<br>
200D ; DISALLOWED # ZERO WIDTH JOINER<br>
<br>
There is no new value called TRANSITIONAL. The infamous 4<br>
characters (above) start with the value DISALLOWED. Later, we<br>
change them to PVALID (or CONTEXTJ for 200C/200D). We<br>
encourage ICANN to redelegate TLDs the registries of which<br>
flout our rules.<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The other file is for global mappings. Not language-specific<br>
mappings. The format might be similar to RFC 3454's:<br>
<br>
0041; 0061; Case map<br>
00AD; ; Map to nothing<br>
<br>
The absence of a character from this file means that there is<br>
no mapping for that character. It maps to itself. The infamous<br>
...<br>
</blockquote>
<br>
_______________________________________________<br>
Idna-update mailing list<br>
<a href="mailto:Idna-update@alvestrand.no" target="_blank">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>
<br>
</blockquote>
<br>
<br>
------------------------------------------------------------------------<br>
<br>
_______________________________________________<br>
Idna-update mailing list<br>
<a href="mailto:Idna-update@alvestrand.no" target="_blank">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>
</blockquote>
<br>
-- <br>
#-# Martin J. Dürst, Professor, Aoyama Gakuin University<br>
#-# <a href="http://www.sw.it.aoyama.ac.jp" target="_blank">http://www.sw.it.aoyama.ac.jp</a> mailto:<a href="mailto:duerst@it.aoyama.ac.jp" target="_blank">duerst@it.aoyama.ac.jp</a><br>
</blockquote></div><br></div>