Re: [Idna-update] How to get past Unicode 6.3

We need to bring the discussion back to "what are the concrete steps 
required to get IDNA update past Unicode 6.3"?

A./

On 3/14/2018 7:34 AM, Michel Suignard wrote:
> I want to show how on a concrete level not having a post Unicode 6.3 IDN table is hurting work done in ICANN. Unicode 7.0 added support for some Myanmar minorities. For many reasons that probably do not interest people in this list, the Myanmar script coverage was a late comer in Unicode encoding, especially Myanmar minorities coverage. Therefore, Unicode 7.0 added support for Shan Pali (again a Myanmar minority). If we could use Unicode 7.0 repertoire as available in an updated IANA IDN2008 table, the root zone Integration Panel would have added 6 characters to the Maximum Starting repertoire (MSR) which is the sand box for Generation Panels (GP) when they define their own repertoire. Obviously, we have no way to know whether a Myanmar GP would adopt these characters into the RZ-LGR when/if they do that. But at this point this is not even an option.
>
> At this point, most of the recent Unicode work on scripts (and I made the precision on purpose) is concentrated on historic ones, or disadvantaged communities. By being stuck on Unicode 6.3 we are putting these communities at disadvantage. Not a message you want to convey on these days and ages.
>
> I think I (and most of us) have decent understanding of the tasks separation mentioned by Patrik, I just want to move on past Unicode 6.3, so we can do our work in appropriate context.
>
> Michel
>
> -----Original Message-----
> From: IDNA-UPDATE <idna-update-bounces@ietf.org> On Behalf Of Patrik Fältström
> Sent: Wednesday, March 14, 2018 4:07 AM
> To: Andrew Sullivan <ajs@anvilwalrusden.com>
> Cc: idna-update@ietf.org
> Subject: Re: [Idna-update] emoji and security
>
> On 13 Mar 2018, at 21:18, Andrew Sullivan wrote:
>
>> But the IETF does not have, and does not want, authority to "keep them out".  That's a policy question, and one rather far from the IETF's area of expertise.  Indeed, that division of labour is precisely why the IANA root zone registry policy is set by someone other than the IETF, which sets the policies for IANA protocol parameter registries.
> Correct.
>
> The IETF Standard explicitly say that a registry must implement a policy for what code points they want to include, so by definition, and by design, the IDNA2008 is not a minimum set of code points. It is a maximum set of code points to be used.
>
>     Patrik
>
> _______________________________________________
> IDNA-UPDATE mailing list
> IDNA-UPDATE@ietf.org
> https://www.ietf.org/mailman/listinfo/idna-update
>