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

[Marc Blanchet <[e-mail]>]

On 6 Mar 2020, at 3:40, Asmus Freytag (c) wrote:

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

For protocol identifiers, there is already a framework to manage that: Precis.
We don’t need to reinvent the wheel in this directorate.

Marc.

>
> A./


> -- 
> I18ndir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i18ndir