[Comments-technical-rz-lgr-15may19] various comments on Technical Utilization of the RZ-LGR
Marc Blanchet
marc.blanchet at viagenie.ca
Mon May 20 17:24:55 UTC 2019
Please find my comments on the Technical Utilization of the RZ-LGR, as
published at
https://www.icann.org/en/system/files/files/recommendations-rz-lgr-14may19-en.pdf
My comments are provided as an individual.
Regards,
Marc Blanchet
=============================================
section 3.2: Self-identified variants are to my knowledge not being
delegated. Therefore, they should not be taken into account. Instead,
the RZ-LGR should be the only normative source of variants.
section 4.1: in this context, IDNA2008 is not enough precise. IDNA2008
provides rules that are applied to Unicode properties. Therefore the
assessment of if a code point is DISALLOWED or UNASSIGNED depends on
which Unicode version it is applied. History has shown that new Unicode
versions may not automatically be applied. Suggested modification of
text: « An applied-for label containing any DISALLOWED or UNASSIGNED
code point(s) per IDNA 2008 applied to the most recent supported Unicode
version, at the time of the verification, or its successors, must not
proceed. »
section 5: Option B. I strongly disagree in opting for Option B. Option
B is trying to replicate the Procedure while not really doing it.
Experience of past and current work of GPs and IP have shown how much
complex can be the study of scripts repertoire and variants, including
complex rules. Cross-script interaction is also key to this assessment.
The cross-script study can only be done in a consistent way by people
looking at the whole process and all the scripts, not by a restricted
set of people familiar with the script being studied. Moreover, Option B
is in some ways bypassing the whole process of the procedure. Finally,
by not looking at the whole problem space, Option B may bring
incompatible labels for the future script LGR. Option B must not be
considered.
section 6. While the SG may have decided to punt the issue of the number
of delegated variants, it remains a very significant potential problem
that should be undertaken. If no recommendation about this issue is
agreed with the community, then we may end up later with applicants
asking for a large number of variants, which will have way too many
implications in security, in deployment, in software, … We have to
remind ourselves that, in general, tools to manage and use variants in
the DNS do not really exist. This issue has to be undertaken, soon.
multiple sections: It should be noted that the RZ-LGR consists of
multiple XML files, or is an XML files set. Current writing in many
places imply a single XML file.
nits: section 10. The reference is misplaced. As it is, it seems to say
that the IANA authoritative files are provided by the toolset. Instead
of « but as a tool for community service. Only the XML file of the
RZ-LGR published by PTI/IANA is to be considered authoritative or
normative.[10] » , the suggested modification would be: « but as a
tool for community service[10]. Only the XML file of the RZ-LGR
published by PTI/IANA is to be considered authoritative or
normative. »
More information about the Comments-technical-rz-lgr-15may19
mailing list