I agree with you that there are many similarities between the MAYBE and TRANSITIONAL. MAYBE at the time wasn't suitable because it was applied to a huge number of characters. However, applying the concept (with a few changes) to these 4 characters for a transitional period is, I think, feasible.<div>
<br clear="all">Mark<div><br></div><div><br><div class="gmail_quote">On Fri, Dec 4, 2009 at 12:40, John C Klensin <span dir="ltr"><<a href="mailto:klensin@jck.com">klensin@jck.com</a>></span> wrote:<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">erikv@google.com</a>> wrote:<br>
<br>
> 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>
<br>
> 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>
<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>
</blockquote></div><br></div></div>