MAYBE-TRANSITIONAL, a historical tale

"Martin J. Dürst" duerst at it.aoyama.ac.jp
Tue Dec 8 10:44:04 CET 2009


I agree with Mark that while there are similarities between MAYBE and 
TRANSITIONAL, there are also huge differences.

One difference, which Mark has mentioned, is the number of characters 
affected.

A second difference is that there would only be one transition from 
TRANSITIONAL to PVALID, not a series of transitions from MAYBE to PVALID.

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.

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.

Regards,   Martin.

On 2009/12/05 6:45, Mark Davis ☕ wrote:
> 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.
>
> Mark
>
>
> On Fri, Dec 4, 2009 at 12:40, John C Klensin<klensin at jck.com>  wrote:
>
>> 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
>>> ...
>>
>> _______________________________________________
>> Idna-update mailing list
>> Idna-update at alvestrand.no
>> http://www.alvestrand.no/mailman/listinfo/idna-update
>>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst at it.aoyama.ac.jp


More information about the Idna-update mailing list