[regext] I18ndir last call review of draft-ietf-regext-dnrd-objects-mapping-06
Marc Blanchet via Datatracker <noreply@ietf.org> Thu, 05 March 2020 19:06 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: regext@ietf.org
Delivered-To: regext@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4BA3A09D3; Thu, 5 Mar 2020 11:06:41 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Marc Blanchet via Datatracker <noreply@ietf.org>
To: i18ndir@ietf.org
Cc: regext@ietf.org, draft-ietf-regext-dnrd-objects-mapping.all@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.119.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <158343520135.15044.10991712449156105132@ietfa.amsl.com>
Reply-To: Marc Blanchet <Marc.Blanchet@viagenie.ca>
Date: Thu, 05 Mar 2020 11:06:41 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/CvjzAHWVAds2G9SPyGFZAEObqhE>
Subject: [regext] I18ndir last call review of draft-ietf-regext-dnrd-objects-mapping-06
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Mar 2020 19:06:42 -0000
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.
- [regext] I18ndir last call review of draft-ietf-r… Marc Blanchet via Datatracker
- Re: [regext] I18ndir last call review of draft-ie… Barry Leiba