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

[John C Klensin <[e-mail]>]

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

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

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

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.