Re: [precis] I-D Action: draft-ietf-precis-7564bis-09.txt

Peter Saint-Andre <> Fri, 21 July 2017 03:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C18BF131D38 for <>; Thu, 20 Jul 2017 20:08:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=HtVnRCyS; dkim=pass (2048-bit key) header.b=fhZwY1h1
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8fcVHotTITwY for <>; Thu, 20 Jul 2017 20:08:16 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 16497131D37 for <>; Thu, 20 Jul 2017 20:08:15 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 4BD2B2094E; Thu, 20 Jul 2017 23:08:15 -0400 (EDT)
Received: from frontend1 ([]) by compute2.internal (MEProxy); Thu, 20 Jul 2017 23:08:15 -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=woL52qTaeiXP+shwOe zv0P4If/3ZoJtv95qFFPabc1I=; b=HtVnRCySIp5Ujuxi0DgLflZJZ5IceKpBOw xwg05APZiqWkdVpNN2jn7dbO5J0dN33DetOtjcoXAC7PHK5gja56fQjnM7I/GxIV sq3owuoOkEgTdZbdApLcfkHxejQnVveGzhTeiUoPRF/RRDJRHHTgDttwSUnBzVjy 8NgkFmYbns+ELQ1CmU1IWQMzw0x1jqh1wh30B5uCRj4pIKvoUbewvOHucBaQ1rct dYjdaGRR7Jq3wYU91aUor6YnMUiXsAMC2vWv2aJptvtz2MvDjM/z5+hT7CEZK2SI 4FYMbki5jbLfmf5YyOHYNkJ3QHp5+o/qUEHOXMAWVzDH3oEC92zA==
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=woL52qTaeiXP+shwOezv0P4If/3ZoJtv95qFFPabc1I=; b=fhZwY1h1 VCYx8DX38bWPmYIqI6uDW2WHCMEPlRI6eugNP346x2DojZ/6qgNcLKn20+BnYuM7 KL1n88L+Sjyffuap/a9leib79EDoCNB7sG2LiPhrNjFBMdgryFbZO9bkWB37i88C Tgc8bRh5fBPj+xt6emzXw2z8xUvFesNkPABOsNT2CGX/NwZ2kwvPGleyPz5V8Gp4 kt0gvcK77sw+EvkZXY/fc/aethEzkSuMPRLBLhhRhcHhfSw4zQJzH5BPBM+6Pv88 Ye+qBcbQW5eu66ehz/Ky723JEPGIfdfXzszZU3/WEid6pAI+KpoafXC9G2Ei35q0 CNymlfJMu3IT6A==
X-ME-Sender: <xms:H3BxWRA7AOiNOTnAKQ3dRA1wO3iKErsL697yPrOtFjFIdF0VW5-26w>
X-Sasl-enc: GuCqoRi2Vs3rQbmg2CkB1SSDcsTXX+VQdt9QIOk13ZYl 1500606495
Received: from aither.local (unknown []) by (Postfix) with ESMTPA id 61E217E4EE; Thu, 20 Jul 2017 23:08:14 -0400 (EDT)
To: William Fisher <>
References: <> <> <>
From: Peter Saint-Andre <>
Message-ID: <>
Date: Thu, 20 Jul 2017 21:08:13 -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=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [precis] I-D Action: draft-ietf-precis-7564bis-09.txt
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: Fri, 21 Jul 2017 03:08:17 -0000

On 7/19/17 11:30 PM, William Fisher wrote:
>> What do implementers think is a "reasonable number of iterations"? My
>> sense is that we're talking about at most 4 or 5, and usually 2 or 3.
> I interpreted the word "iteration" to mean "reapplication" of the
> rules; not counting the first application. The Nickname test cases
> become stable after 2 iterations of the rules.
>   output1 = precis_encode(input)
>   output2 = precis_encode(output1)      # iteration 1
>   output3 = precis_encode(output2)      # iteration 2 confirms that
> output3 == output2
> I can't come up with a Nickname test case that requires more than 2
> iterations to become stable, but that doesn't mean they don't exist.

As far as I can determine based on reviewing various code points, that's
right. This _should_ be a function of the code points involved (i.e.,
how many steps a code point is from something more stable), not the profile.

> It's possible that a new PRECIS profile could be defined that has
> stability issues. IMO, if a PRECIS profile isn't stable after 3
> iterations, it's broken.


> The last sentence might read like this:
>   Therefore, an implementation SHOULD reapply the rules
>    repeatedly until the output string is stable; if the output string
>    does not stabilize after three iterations, the
>    implementation SHOULD reject
>    the input string as invalid.
> In the worst case, this means that you are calling precis_encode()
> four times for an input string.

That seems reasonable.


> -Bill
> On Wed, Jul 19, 2017 at 6:40 PM, Peter Saint-Andre <> wrote:
>> On 7/16/17 5:20 PM, wrote:
>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>> This draft is a work item of the Preparation and Comparison of Internationalized Strings of the IETF.
>>>         Title           : PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols
>>>         Authors         : Peter Saint-Andre
>>>                           Marc Blanchet
>>>       Filename        : draft-ietf-precis-7564bis-09.txt
>> Our area director pointed out to me offlist that the definition of
>> "reasonable" is vague in the following text:
>>    Because of the order of operations specified here, applying the rules
>>    for any given PRECIS profile is not necessarily an idempotent
>>    procedure (e.g., under certain circumstances, such as when Unicode
>>    normalization form KC is used, performing Unicode normalization after
>>    case mapping can still yield uppercase characters for certain 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 invalid.