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

["Marc Blanchet" <[e-mail]>]

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:

> 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>