Subject: Re: [I18n-discuss] comments on draft-freytag-troublesome-characters-01

From: Asmus Freytag <[email-masked]>
Date: Sun, 6 Aug 2017 19:14:33 -0700

On 7/9/2017 2:02 PM, Marc Blanchet wrote:
>
> The registry is updated by Expert Review.
>
> <MB> »Expert Review », as is, I disagree. As we all know and discussed 
> since the early days of idn wg, sometimes a single code point may 
> raise a lot of different opinions and perspectives. Therefore, a 
> single expert to me is not enough to approve changes to this registry. 
> I would suggest something in the form of the mime process, where the 
> proposal is sent to a specific mailing list for discussion and maybe a 
> reviewer (or two) will inform IANA of the conclusion. Or any public 
> process that includes more than one person isolated talking to IANA.
> </MB>
>
> It ought to contain only
> code points that are significant in identifiers and that need special
> policies (including policies of exclusion). Only code points that
> are eligible for use in identifiers (i.e. that are not DISALLOWED)
> ought to be included. Code points that are CONTEXTJ or CONTEXTO
> ought to only be included if concerns are identified that are not
> mitigated by the existing IDNA context rules.
>
> <MB>I think this policy is not enough precise for the Expert Review 
> (or whatever process) to identify which one should be included or not. 
> Therefore, I would highly suggest that the authors define a set of 
> criteria to help the review process
> </MB>
>
> <MB>I wonder if there should be some words about managing the changes 
> in this table. Specially, if later, things are found that make an 
> entry not « backward » compatible with an earlier version of the 
> table. I think assuming that the table will only add stuff may be 
> risky… And I think we can assume that this registry will be parsed by 
> software programs in registries, registrars, etc… Therefore, some 
> guidelines for both the expert review or whatever process and for the 
> implementor/reader about non-compatible changes is necessary.
> </MB>
>
I am currently drafting the following text for this section. Comments 
welcome.

A./

<section title="Maintenance" anchor="sec_maintenance" toc="default">

         <t>The registry is updated by Expert Review using an open process.
       Code points that are DISALLOWED in IDNA 2008 are not eligible to be
       listed.  Code points that are CONTEXTJ or CONTEXTO
      do not need to be included unless there are documented concerns 
that are
      not mitigated by the existing IDNA context rules.
      The focus should be on scripts that are significant for identifiers;
       code points from scripts that are historic or otherwise of 
limited use
       would normally not be considered - however exceptions might be made
       where authoritative information is readily available.
      Code points and code point sequences to be included are those that
     need special policies (including, but not limited to policies of 
exclusion).</t>

      <t>New code points of sequences are listed whenever information
      becomes available that identifies a specific issue that requires
      attention in crafting a policy for the use of that code point or 
sequence
      in network identifiers.  Likewise cross references, categories, 
explanations
      and references cited may be updated. </t>

      <t>The contents of the registry
      should not represent original research but a collection of issues 
documented
      elsewhere, with appropriate references cited. An exception might be
      cases that are in clear analogy to existing entries, but not 
covered by
      existing references, for example, because the code point in 
question was
      recently added to Unicode. The use and nature of such analogy is to
      be documented.</t>

     <t>If a particular language or script community reaches an apparent
     consensus that some code point is problematic, or that of two identical
     code points or sequences one should be preferred over the other, such
     recommendations should be documented in this registry. In addition, if
     the Unicode Standard designates a code point as "deprecated" or 
identifies
     code points that are "intentionally identical", this is also 
something that
     should be reflected in the registry. Another source of potential 
information
     might be existing registry policies or recommended policies, 
particularly
     where it is apparent that they represent a careful analysis of the 
issue
     or a wider consensus, or both.</t>

      <t>Propsosed additions to the registry are to be shared on a mailing
      list to allow for broader comment and vetting.If there is a 
disagreement about the existence of an issue
      or its severity, it is preferable to document both the issue and the
      different evalutations of it. In all cases, the information and 
documentation
      presented must allow a user to fully evaluate the status of any 
entry in the
      registry.</t>

      <t>There is no requirement for the registry to be backward compatible
      or stable in any way. If new information emerges, code points may be
      added or reclassified. In case of significant changes, the 
explanation should
      note the nature of the change and cite a reference to document the 
basis for it.</t>
       </section>

---

From: "Marc Blanchet" <[email-masked]>
Date: Mon, 07 Aug 2017 10:24:41 -0400

For « community review with expert », I would suggest to use similar 
text from MIME (RFC6838) section 5. It talks of the roles of each 
(community, mailing list, expert, etc…) and has been in use for quite 
some time.

Marc.

On 6 Aug 2017, at 22:14, Asmus Freytag wrote:

>> <MB> »Expert Review », as is, I disagree. As we all know and 
>> discussed since the early days of idn wg, sometimes a single code 
>> point may raise a lot of different opinions and perspectives. 
>> Therefore, a single expert to me is not enough to approve changes to 
>> this registry. I would suggest something in the form of the mime 
>> process, where the proposal is sent to a specific mailing list for 
>> discussion and maybe a reviewer (or two) will inform IANA of the 
>> conclusion. Or any public process that includes more than one person 
>> isolated talking to IANA.
>> </MB>
>>
>> It ought to contain only
>> (or whatever process) to identify which one should be included or 
>> not. Therefore, I would highly suggest that the authors define a set 
>> of criteria to help the review process
>> </MB>
>>
>> risky… And I think we can assume that this registry will be parsed 
>> by software programs in registries, registrars, etc… Therefore, 
>> some guidelines for both the expert review or whatever process and 
>> for the implementor/reader about non-compatible changes is necessary.
>> </MB>
>>
>      note the nature of the change and cite a reference to document 
> the basis for it.</t>
>       </section>