IDNA2008: concerns about inconsistent mappings, and german sharp s

[Martin Duerst]

At 12:14 08/12/12, Paul Hoffman wrote:
>At 4:29 PM -0800 12/11/08, Vint Cerf wrote:
>>This advice belongs in rationale I would think. V
>
>Here is the relevant text on this topic from the Rationale document. You 
>can decide for yourself if this constitutes advice that is or is not sufficient.

I think it is probably sufficient, but wording should be improved.
In particular, there are too many might/could/...


>   While it is beyond the scope of these documents to specify a
>   preference for any of them, or to suggest that there are not other
>   possibilities, there have traditionally been several approaches to
>   problems of this type:

Reword to remove forward reference for "any of them", along the lines
of:

There have traditionally been several approaches to problems of this
type. Without any preference or claim to completeness, these are:

>   o  Do not permit use of the newly-available character at the registry
>      level.  This might cause lookup failures if a domain name were
>      written with the expectation of the IDNA2003 mapping behavior, but
>      would eliminate any possibility of false matches.

might -> can; were -> is; would -> will


Regards,    Martin.

>   o  Hold a "sunrise" arrangement in which holders of the previously-
>      mapped labels (labels containing "ss" in the Eszett case or ones
>      containing Lower Case Sigma in the Final Sigma case) are given
>      priority (and perhaps other benefits) for registering the
>      corresponding string containing the newly-available characters.
>
>   o  Adopt some sort of "variant" approach in which registrants either
>      obtained labels with both character forms or one of them was
>      blocked from registration by anyone but the registrant of the
>      other form.
>
>   In principle, lookup applications could also compensate for the
>   difference in interpretation by looking up the string according to
>   the IDNA208 interpretation and then, if that failed, doing the lookup
>   with the mapping, simulating the IDNA2003 interpretation.  The risk
>   of false positives is such that this is generally to be discouraged
>   unless the application is able to engage in a "did you really mean"
>   dialogue with the end user.




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