Last Call Review of draft-ietf-regext-dnrd-objects-mapping-06
review-ietf-regext-dnrd-objects-mapping-06-i18ndir-lc-blanchet-2020-03-05-00
Request | Review of | draft-ietf-regext-dnrd-objects-mapping |
---|---|---|
Requested revision | No specific revision (document currently at 11) | |
Type | Last Call Review | |
Team | Internationalization Directorate (i18ndir) | |
Deadline | 2020-03-09 | |
Requested | 2020-02-24 | |
Authors | Gustavo Lozano Ibarra , James Gould , Chethan Thippeswamy | |
I-D last updated | 2020-03-05 | |
Completed reviews |
Genart Last Call review of -06
by Roni Even
(diff)
I18ndir Last Call review of -06 by Marc Blanchet (diff) Opsdir Last Call review of -06 by Joe Clarke (diff) Opsdir Telechat review of -08 by Joe Clarke (diff) |
|
Assignment | Reviewer | Marc Blanchet |
State | Completed | |
Request | Last Call review on draft-ietf-regext-dnrd-objects-mapping by Internationalization Directorate Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/i18ndir/1p2TG4KM9P-p_ktg7PCgJ_-jFts | |
Reviewed revision | 06 (document currently at 11) | |
Result | Ready w/issues | |
Completed | 2020-03-05 |
review-ietf-regext-dnrd-objects-mapping-06-i18ndir-lc-blanchet-2020-03-05-00
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.