[Latingp] Response of IP to Cyrillic GP's query on U+02BC

Sarmad Hussain sarmad.hussain at icann.org
Mon Oct 16 08:01:05 UTC 2017


Dear All,

Following the discussion in the previous conference call, please find attached the response of IP on U+02BC for inclusion in the root zone LGR to Cyrillic GP query:

===========

While the Integration Panel understands the use cases for Modifier Letter Apostrophe (U+02BC) in Belarusian and Ukrainian, we are bound by the principles prescribed in the Procedure and RFC 6912. In the background section of RFC 6912, the IAB has cited the code point as being problematic for the root zone:



   It is not clear that all code points permitted

   under IDNA2008 that have a General_Category of Lo or Lm are

   appropriate for a zone such as the root zone.  To take but one

   example, the code point U+02BC (MODIFIER LETTER APOSTROPHE) has a

   General_Category of Lm.  In practically every rendering (and we are

   unaware of an exception), U+02BC is indistinguishable from U+2019

   (RIGHT SINGLE QUOTATION MARK), which has a General_Category of Pf

   (Final_Punctuation).  U+02BC will also be read by large numbers of

   people as being the same character as U+0027 (APOSTROPHE), which has

   a General_Category of Po (Other_Punctuation), and some computer

   systems may treat U+02BC as U+0027.  U+02BC is PROTOCOL VALID

   (PVALID) under IDNA2008 (see the IDNA Code Points document

   [RFC5892]), whereas both other code points are DISALLOWED.  So, to

   begin with, it is plain that not every code point with a

   General_Category of Ll, Lo, or Lm is consistent with the type of

   conservatism principle discussed in Section 4.1 below or the previous

   IAB recommendations.



...



Further, RFC 6912 made clear that:



   Public zones are, by definition, zones that are shared by different

   groups of people.  Therefore, any decision to permit a code point in

   a public zone (including the root) should be as conservative as

   practicable.  Doubts should always be resolved in favor of rejecting

   a code point for inclusion rather than in favor of including it, in

   order to minimize risk.



Given that the root zone necessitates a conservative LGR design, the code point cannot be included in the MSR.
=============

Regards,
Sarmad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/latingp/attachments/20171016/aa013cb7/attachment.html>


More information about the Latingp mailing list