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

Peter Saint-Andre <> Sun, 17 September 2017 20:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A480213337F for <>; Sun, 17 Sep 2017 13:59:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Status: No, score=-2.721 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] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=ej5tK4kJ; dkim=pass (2048-bit key) header.b=XT7TvXZC
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xUIqe1LUMYyd for <>; Sun, 17 Sep 2017 13:59:18 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3A3EE1331E5 for <>; Sun, 17 Sep 2017 13:59:18 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id A050520B6A; Sun, 17 Sep 2017 16:59:17 -0400 (EDT)
Received: from frontend1 ([]) by compute2.internal (MEProxy); Sun, 17 Sep 2017 16:59:17 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=cc :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=niQaTAa9qvOfMBhTfciXY8y5y7JQWWEKKzJcLiLZm EI=; b=ej5tK4kJ8VPDo95cgRffPZ5YulgdF/tAOsNG9nHAFUFOXZeU0Chc6YEwr r6pMi+16OFPTQh2gMHznLxv//xGPXyY3nMiDY+pEzSXkB96R547kD4GMyXyjsK5C dZkeJ44cATcBf46/kD+o8FBIOlziSX1Bd2sV6I9Ie5jb0t88m688xINdjz8UB3JT JEt453/LruWDmr3HuYKhDCWXhDKICzbclOcVlBts8cOtnbyivC0kJsJkKbYChhtq VYDPpquG2WU3pXzevHXfqDDnVFQxMCnFHGyZLRKPA3SWEcpzCEDRtZ+PUZ+hxZ4J q0m3J3ULGBY4+ingni4Fd9r6KMh7Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc: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=niQaTAa9qvOfMBhTfc iXY8y5y7JQWWEKKzJcLiLZmEI=; b=XT7TvXZCDNDXA5pst6hwzKbSLCJGEhDtJH mQzSZMZ990dXe4KJxhpynWmndISek+ZzsDXqiXJ3paF5Yl86UnIvLiBMJTG2aX2f RNJuInvPXLhL3DLqPVFTVIbygEurGsQnPAIVqyGf0OEel7DGOskuU/8IGFyhTN5e wmkbXMrZG7Qi9nA5gpTUJwLh0tB9U3Dn4MfnOWY+CWpcXrEPO+r/xM90jC860kHd 6XxGXTi4kLkHD4LgVDn2EN4hOBGZCY1fjdsV2+tm5Xyn1nRmHZ0tb71UVVicyMy4 hzVHCmhFO+IBJdDeWLlPHw4tEwzMDjhN2GsZ0Sbktk5Of1MLg78w==
X-ME-Sender: <xms:JeK-WQEkkqUR0aDSWRMsMOLd0Rriok-kgYxFzfwbUl11ZIBslDdHYw>
X-Sasl-enc: 3H0Rv6wDPiVG/f0XWj0Mk+h0PmYgpTkg6Myc7fTZb7b0 1505681957
Received: from aither.local (unknown []) by (Postfix) with ESMTPA id 1223D7E8ED; Sun, 17 Sep 2017 16:59:17 -0400 (EDT)
From: Peter Saint-Andre <>
To: Sam Whited <>
References: <> <> <> <> <> <> <> <> <> <> <>
Message-ID: <>
Date: Sun, 17 Sep 2017 14:59:16 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="AihO69WiJoeAJWIluTXEQLnCucB1tvUBH"
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: Sun, 17 Sep 2017 20:59:20 -0000

On 9/17/17 2:55 PM, Peter Saint-Andre wrote:
> On 9/17/17 2:51 PM, Sam Whited wrote:
>> On Sun, Sep 17, 2017, at 15:41, Peter Saint-Andre wrote:
>>> Why would an application need to care about this? This is an internal
>>> implementation detail of a PRECIS library/API, and IMHO it would be
>>> irresponsible of the library/API author to offer an option for
>>> application developers to select how many times to apply the rules.
>> That's fair, but in that case this specific profile is a special case
>> that takes a massive performance penalty even when it doesn't need too
>> (if the library author did this at all).
>> My point is that we can't count on this, and there are still opinions
>> and if's in that statement. We should be trying to make this as secure
>> as possible at the spec level; regardless of what we feel might be more
>> important, if it's easier to not do this, or it incurs a big performance
>> penalty to do it some library authors probably won't.
>>> Sam, I am going to reiterate that we are EXTREMELY close to publication
>>> of this document - it could have happened on, say, Thursday morning
>>> right before you posted to the list about this. Please please please
>>> either propose very specific text or point to an earlier email message
>>> where you did so, because personally I have forgotten if you already did
>>> that and my recollection from the previous discussion was that you did
>>> not raise objections to the compromise text that Bill Fisher and I
>>> agreed on. If your proposal is that we make significant changes to the
>>> document at this time, then the Working Group chair or Area Director
>>> will likely have to suggest a path forward, because your feedback is
>>> coming so very late in the process.
>> I don't have a specific solution; I understand that this would require
>> reworking the Nickname profile to not use NFKD which is a huge change,
>> and that's unfortunate, but I still do not beleive it's appropriate to
>> publish this document in its current form. I voiced this opinion early
>> on, and the compormise change did nothing to address it, so I did not
>> voice it again at that time, maybe I should hvae. I am voicing the
>> feedback again now because I think the spotify article is better
>> evidence that this is a real problem than I had before.
> In that case, we'll need to invoke the WG chair and/or AD.

I have forwarded this note to the chair and AD with a suitably scary
subject line. If we don't hear back from them before 8 AM Pacific time
tomorrow, I will send a similar note to the RFC Editor team to stop the