[precis] Adam Roach's Yes on draft-ietf-precis-7700bis-08: (with COMMENT)

Adam Roach <adam@nostrum.com> Wed, 05 July 2017 22:13 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: precis@ietf.org
Delivered-To: precis@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF5B0127201; Wed, 5 Jul 2017 15:13:27 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Adam Roach <adam@nostrum.com>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-precis-7700bis@ietf.org, Marc Blanchet <Marc.Blanchet@viagenie.ca>, precis-chairs@ietf.org, Marc.Blanchet@viagenie.ca, precis@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.55.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149929280791.22663.592778419584772415.idtracker@ietfa.amsl.com>
Date: Wed, 05 Jul 2017 15:13:27 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/precis/EUUBCBgp5KssIEv2WxwiOq1rB4Y>
Subject: [precis] Adam Roach's Yes on draft-ietf-precis-7700bis-08: (with COMMENT)
X-BeenThere: precis@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Preparation and Comparison of Internationalized Strings <precis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/precis>, <mailto:precis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/precis/>
List-Post: <mailto:precis@ietf.org>
List-Help: <mailto:precis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/precis>, <mailto:precis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Jul 2017 22:13:28 -0000

Adam Roach has entered the following ballot position for
draft-ietf-precis-7700bis-08: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


I like the clear explanation of some of the design choices in here (e.g., the
rationale for using NFKC).

There are two places that I think a slight bit of additional text might be

1. When talking about processing "each string" in section 2.4, it's probably
worth noting that implementations should be careful not to assume that any
information received from a wire protocol has necessarily had any of the rules
in this document applied to it (as this might allow intentionally noncompliant
clients to slip certain kinds of shenanigans past their checks); and

2. Where the final paragraph of section 4 indicates that the operations in this
document are not necessarily idempotent, it is probably worth being more
explicit that they should be applied repeatedly until the output string is
stable; or, if the string does not stabilize after a reasonable number of
iterations (is this possible?), that it should be rejected as invalid.