IDNA2008: concerns about inconsistent mappings, and german sharp s

[Paul Hoffman]

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.

   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:

   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.

   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.