MAYBE-TRANSITIONAL, a historical tale (was: Re: Additional thoughts on TRANSITIONAL)

John C Klensin klensin at jck.com
Fri Dec 4 21:40:41 CET 2009


Once upon a time, not really that long ago, there was a proposal
to differentiate what is now PVALID by including MAYBE YES and
MAYBE NO categories.   Anyone interested should try to find a
copy of draft-klensin-idnabis-issues-06.txt and earlier.  The
general model, in today's vocabulary, was to put characters (and
groups of characters) that we weren't sure about into categories
that would encourage different handling on registration and
looking from characters about which we were more certain, to
permit later reclassification, and to arrange for controlled
transitions.  There was consensus for removing those categories
because they made things too fragile, because they would require
that all registries and applications check for updates and
changes frequently (which would be too fragile), and so on.

In practice, the only real difference between MAYBE and the sort
of implied TRANSITIONAL you imply (or the explicit versions
others have suggested) is that MAYBE would have laid out the
"this is likely to change" aspect of the situation more clearly,
while the idea you outline above raises all of the issues that
the WG has discussed about transitions from DISALLOWED to PVALID
(and decided that reclassification should require a catastrophic
situation).

If I remember correctly, both you and Mark were at the meeting
at which the decision to drop MAYBE was made and were among
those pushing for that decision, pretty much on the basis
outlined above.

While I don't object to revisiting that general idea -- under
the identification of TRANSITIONAL or otherwise-- if the WG
really feels that it wants to go there and that the old model
might be worth the aggravation that caused it to be dropped the
last time around, I hope that everyone does understand that
TRANSITIONAL, as you and others have described it, is very close
to that old and discarded idea... close enough that we might
even be able to borrow text from documents that are now more
than 18 months old.

best,
   john

p.s. I'm not going to comment at any length on the "global
mappings" part of your proposal because I think everything has
been said already.  Having required global mappings is
equivalent to _almost_ having U-label <-> A-label symmetry.
And, of all mappings, "map to nothing" is the worst: while part
of the problem with a mapping between "ß" and "ss" is that one
cannot tell by looking at "ss" afterward whether the registrant
intended "ss" or "ß", one at least knows that "x" or "ab" was
not intended.  With "map to nothing", the character that was
eliminated could, in principle, have appeared in any position in
any domain name label.



--On Friday, December 04, 2009 04:11 -0800 Erik van der Poel
<erikv at google.com> wrote:

> Here is another proposal that is dead simple, yet allows
> implementations to take advantage of a machine-readable file,
> and does not involve "flag days" (dates at which we change
> something).
> 
> Instead of having a machine-readable file at each host, we
> have two global files at iana.org. One file is similar to
> Patrik's table with entries like:
> 
> 00DF       ; DISALLOWED  # LATIN SMALL LETTER SHARP S
> 03C2       ; DISALLOWED  # GREEK SMALL LETTER FINAL SIGMA
> 200C       ; DISALLOWED  # ZERO WIDTH NON-JOINER
> 200D       ; DISALLOWED  # ZERO WIDTH JOINER
> 
> There is no new value called TRANSITIONAL. The infamous 4
> characters (above) start with the value DISALLOWED. Later, we
> change them to PVALID (or CONTEXTJ for 200C/200D). We
> encourage ICANN to redelegate TLDs the registries of which
> flout our rules.
 
> The other file is for global mappings. Not language-specific
> mappings. The format might be similar to RFC 3454's:
> 
> 0041; 0061; Case map
> 00AD; ; Map to nothing
> 
> The absence of a character from this file means that there is
> no mapping for that character. It maps to itself. The infamous
>...



More information about the Idna-update mailing list