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

Peter Saint-Andre <> Sun, 09 July 2017 22:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D84C61200FC; Sun, 9 Jul 2017 15:26:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=Mzf16+TE; dkim=pass (2048-bit key) header.b=kRn4bbzZ
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FQ_DY-nYKFQm; Sun, 9 Jul 2017 15:26:54 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DDF991200ED; Sun, 9 Jul 2017 15:26:53 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 41146206EA; Sun, 9 Jul 2017 18:26:53 -0400 (EDT)
Received: from frontend2 ([]) by compute2.internal (MEProxy); Sun, 09 Jul 2017 18:26:53 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=W/iW/aA1Mte2fP+gRf LqB7NmS6HDQ0RPW+Zl8/564uk=; b=Mzf16+TEYM8cDjUYj8VdNCdCbiNXvIbcd6 iupDOO9ZEda2MfSrs88uiAEoXLp8/cij3JiJ72An6H9FasHD/hSFCImls2rQ7NwQ UF3btaW7dEgHU+XbGY9ATkIy4Q5zRHxxL8GaBrnQtfg4j8VxAcczeG2jscOF/OhQ EMH7eFb/+JOzPEPgH+v4w6UHSZ/iGPi+y8I+demy3Ry54gaL7cU+8zTs5ultnuPr VeK3tvuPO+PfMOCg2j5NZo/A9oItCOPI+8d9CNIrNMzpDmQgrhzgsaPPYKZYXHJV YvXG8xbHSXy2HGKE8zYxyleXxaxSVzA+7kOnice1tHyCt8/1vwZg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=W/iW/aA1Mte2fP+gRfLqB7NmS6HDQ0RPW+Zl8/564uk=; b=kRn4bbzZ lEj0buqeu/GLctuTr8STlQObnisTlAJpkDXjkXgBkAYySDI8CdhVcvt8cK/prTy+ Ra8C056FBEwTnw/2UsytrN9Giwf3B8LX1aJVgkOAYBE+8V1CqUeI8qnzLzyLCfBm TzWKtLKGen4LUz9NuEjK+qA+07yFJKce8hBlF+rib6W3qn+FCXw6UBw8KaafXJDn 26OHayf+X0flQ2j4XDmY0g+Cp+YXYusNioPnvSCRVN3BuJUYE+7sMYnaBJSmXVif flqpQU5D9Jte+2uC0VC/88bpzKoXcaPmrkAL1X2wP7NKRCVZIi7pFT4AgZOAeuDA iLesfPJ6IO66wQ==
X-ME-Sender: <xms:ra1iWQjS2JwAsPpTuXOo_QpRjrKSDx-VqIDF_Ht-49G8d_0uxnv_cw>
X-Sasl-enc: paiNJtxCl6S3pgYJrgq469LoOMw3NQh8v6LcjMzyFlOK 1499639212
Received: from aither.local (unknown []) by (Postfix) with ESMTPA id 8A2992424D; Sun, 9 Jul 2017 18:26:52 -0400 (EDT)
To: Adam Roach <>, The IESG <>
References: <> <>
From: Peter Saint-Andre <>
Message-ID: <>
Date: Sun, 9 Jul 2017 16:26:51 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [precis] Adam Roach's Yes on draft-ietf-precis-7700bis-08: (with COMMENT)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Preparation and Comparison of Internationalized Strings <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 09 Jul 2017 22:26:56 -0000

On 7/5/17 4:41 PM, Peter Saint-Andre wrote:
> On 7/5/17 4:13 PM, Adam Roach wrote:
>> 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
>> 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
>> useful:
>> 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
> draft-ietf-precis-7564bis contains the following sentence:
>    When an application applies a profile of a PRECIS string class, it
>    transforms an input string (which might or might not be conforming)
>    into an output string that definitively conforms to the profile.
> It strikes me that something similar would be useful here, especially
> the concepts of "input string" and "output string".

I'd like to propose that we add the following text at the end of Section
2.3 on Enforcement:

   The result of the foregoing operations is an output string that
   conforms to the Nickname profile.  Until an application produces such
   an output string, it MUST NOT treat the string as conforming (in
   particular, it MUST NOT assume that an input string is conforming
   before the enforcement operation has been completed).

And the following text at the end of Section 2.4 on Comparison:

   Until an application determines whether two strings are to be
   considered equivalent, it MUST NOT treat them as equivalent (in
   particular, it MUST NOT assume that an input string conforms to the
   rules before the comparison operation has been completed).

Would that address the concern?

(I'd add similar text in 7613bis.)

>> 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.
> Thanks for the suggestion; although we might think that's implicit in
> the notion of non-idempotence, it's much better to make the
> ramifications and handling explicit. I'll add this text in the post-IESG
> version.

Does the following text address the concern?

   Implementation experience has shown that applying the rules for the
   Nickname profile is not an idempotent procedure for all code points.
   Therefore, an implementation SHOULD apply the rules repeatedly until
   the output string is stable; if the output string does not stabilize
   within a reasonable number of iterations, the implementation SHOULD
   terminate application of the rules and reject the input string as