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

[Asmus Freytag <[e-mail]>]

On 3/5/2020 12:47 PM, John C Klensin wrote:
> (All list-type other than i18ndir removed)
>
> General observations about substance:
>
> (1) I completely agree with Marc about the UTF-8 issue.  Unless
> there is a really good reason for allowing either other
> normalization forms of Unicode or any other CCS, new protocols
> and IETF-specified formats should be restricted to UTF-8.  I
> would go a half-step further and suggest that any deviations
> from that principle should be explicitly discussed and justified
> in an Internationalization Considerations section, i.e., that
> section should not be just a description of what XML allows.

+1

(In fact, the i18n considerations in the draft were defective in not
discussing the CSV mode at all.)

About the your suggested "half-step further": do we need to write
a short RFC to explicitly put that on the record? Or how would you
think such a mandate would be expressed?

>
> (2) I have not studied this spec (or RFC 5732 carefully enough
> to be sure, but it appears to me that, with four normalization
> forms specified in The Unicode Standard and periodic disputes
> about preferences between NF[K]C and NF[K]D, "normalizedString"
> may be under-specified.  Clearly actual IDN labels should
> (SHOULD?) be in NFC form, but most other fields are less
> obvious.

I would say: IDN labels MUST be in NFC.

There's no reason for formal records of IDN U-labels not to be
in the form specified by IDNA.

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

We may need a statement specific to IETF that captures the
suggested policy.


>
> Directorate procedural issue:
>
> I want to thank Marc for copying the i18ndir list on this review.
>
> Given our low, and perhaps waning, levels of activity and the
> "no one is expert on all i18n issues" principle described in
> draft-klensin-unicode-review, I think it would be helpful if all
> requests for reviews of i18n-related documents and review
> assignments were posted to the i18ndir list.

Seems fine. Appointing a lead reviewer shouldn't make the
that information private.

> That would reduce
> the chances of duplicated effort and increase the odds of enough
> cross-checking (however slightly) to be sure that directorate
> opinions were at least consistent with each other.    Without
> that sort of communication, we are not a directorate; we would
> be, at best, a loosely-structured review team.

We would simply be a review pool (like a typing pool of old).

> With the understanding that it might not accomplish much of
> anything if we continue to be as inactive as we have been in
> recent months, is there any reason to not expose review requests
> and assignments to this list?
>
> thanks,
>     john
>
>
>
> --On Thursday, March 5, 2020 11:06 -0800 Marc Blanchet via
> Datatracker <[e-mail]> wrote:
>
>> Reviewer: Marc Blanchet
>> Review result: Ready with Issues
>>
>> I was assigned by the Internationalization Directorate to do a
>> review of this document with a specific eye on
>> internationalization and also a specific request from AD to
>> look at section 10.
>>
>> I would like to point out that in some cases, the spec seem to
>> provide a choice for the implementor/deposit provider to use
>> something else than UTF-8 for the non-ascii encoding. For
>> example, section 4.6.2.1. provides a choice of encoding for
>> csv files: "encoding  Defines the encoding of the CSV file
>> with the default encoding of "UTF-8". Moreover, section 10
>> talks about UTF-8 and UTF-16 and recommends UTF-8 instead of
>> making it mandatory. At the same time, there are multiple
>> fields in this spec that are defined as UTF-8. Therefore, it
>> would be appropriate and much less prone to interoperability
>> problems to make UTF-8 the only encoding possible, specially
>> given that most protocols, data payloads and software
>> librairies are using UTF-8 encoding. If the authors agree, then
>> section 10 and 4.6.2.1 could be revised, and probably adding a
>> paragraph in section 1 or 4 that states the only possible
>> encoding is UTF-8 for both CSV and XML files.
>>
>> Section 9.14 schema has a comment on ACE name field. Wonder if
>> A-label would be more appropriate.
>>
>> Section 5.6.2.1.1. While in other parts of the spec, the
>> encoding was clearly identified as UTF-8, the definition of
>> "<rdeCsv:fUName>  Name of the NNDN in Unicode character set
>> for the <csvNNDN:fAName> field element." does not state any.
>> Might want to say it clearly as UTF-8 like others.
>