Re: [I18ndir] I18ndir last call review of draft-ietf-regext-dnrd-objects-mapping-06

["Asmus Freytag (c)" <[e-mail]>]

On 3/5/2020 9:46 PM, John C Klensin wrote:
> Asmus,
>
> --On Thursday, March 5, 2020 16:14 -0800 Asmus Freytag
> <[e-mail]> wrote:
>
>> On 3/5/2020 12:47 PM, John C Klensin wrote:
>>
>>> In addition, given increasing trend on the web 9at
>>> least) to do exactly what TUS says to do, which is to
>>> normalize only at comparison time rather than trying to carry
>>> strings around in normalized form, the application of that
>>> attribute all almost all text-type values may be
>>> inappropriate. I can find no evidence in the I-D that those
>>> issues were considered; the document should not progress
>>> until they are.
>> Right, there are many other contexts where it makes sense to
>> keep the data as submitted and not to force normalization.
>   
>> However, this does not appear to be one of them.
> For the many fields that do not appear to be IDN labels, why
> not?  From skimming the document, I'd assume that the IDN labels
> should be required to be in NFC but that a normalization
> requirement is probably inappropriate for most other fields,
> especially those fields that appear to be free text
> descriptions.  Which ones probably requires a field-by-field
> analysis.
>
>> We may need a statement specific to IETF that captures the
>> suggested policy.
> Indeed.
>
I did not do a full review, just checking some of the points that
others had noted against the original.

That means I have not looked into the details of all the text
fields. As a matter of policy, if we were to develop one to help
us guide in our review, we may perhaps partition:

(1) IDN U-labels

(2) Free text (description, comment)

(3) Other, protocol relevant

It makes sense to require (1) to be in the format specified by
IDNA (NFC and lowercase), and likewise it does not make sense
for (2) to be normalized.

String that may be relevant as part of some protocol, but are not
IDN U-labels, would be RECOMMENDED to be in whatever
format the protocol sets out for them. (There's a small
benefit to be able to use non-protocol aware tools to do
things like search data sets, and therefore it's preferable to
have the data in the expected form for easy comparison,
even if the protocol describes its own preprocessing step.

To give an example: Unicode allows for character and property
names to elide spaces with or without camel case or to use -
or _ as separators. However, in the context of the standard
as much as possible only one of these formats will be used
(single case with space as separator for character names and
_ separator for properties).

While everybody knows how to compare the values, it helps
the reader to know that the text of the standard follows a
uniform convention.

If a protocol allows mulitple forms, as Unicode does for its
identifiers, it would still be good form to pick a canonical
representation for such protocol-relevant items and as
reviewers we should have a policy on that.

A./