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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2CEE11331E5 for <>; Sun, 17 Sep 2017 13:55:29 -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=VRzlyRHk; dkim=pass (2048-bit key) header.b=UKax/FtL
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KZge0ZfQpVeB for <>; Sun, 17 Sep 2017 13:55:27 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BDD64133352 for <>; Sun, 17 Sep 2017 13:55:24 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id CBABA20C0B; Sun, 17 Sep 2017 16:55:23 -0400 (EDT)
Received: from frontend1 ([]) by compute2.internal (MEProxy); Sun, 17 Sep 2017 16:55:23 -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=LDqaGJxrAeuUqyvIZUxzkSbhlTg+Lx5Pt4BgIKumG qA=; b=VRzlyRHk5lxAx1wURY1c8rLM/T1v6uG3UnNgPYma7S/RIBaYIuSZzbY3D 7LH7BfS9Cw8zCVvT6fTX70fnk+ft+IxYo14Za4qi8r3oIlBpk6Opakpfzk5kyNnK F73Kel8BbBFaAJDrmDuT3vtq8teQv8Tl1yPSrG8BcvcTtsY1kvdQOFbRfGzgHQWJ j2jKFogNpFcrVlD9jCMjCfJ+AZpvsMadTckTbQUiaBDgCZ1qHFjzCbV6k2y/46Ly ZNUCu+XeL9A/NVQvVlY5lilD9iHlAJeI3F3gEaLHTeju/2OO8tAZ32+Di3PbYy8+ +bDtTG0PKsf26oUNGglLI40E69cbA==
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=LDqaGJxrAeuUqyvIZU xzkSbhlTg+Lx5Pt4BgIKumGqA=; b=UKax/FtLH7FFhGaE82Vrc6LKwB0jROe7nn S776QxPSx9CBGlMIrryQTvEFfFnUZnhBh60KZ7yHoTk7iYrsAAU3gCaE28fm1xf5 jTtm1AnPcNJFw5XzNf0zw5ZOywRr88inxxqa+Kf06FTxiKUKcaljFClT6DXNL8xB n3Yj3CsGjha8DFicAvJswTeu8QpUYxhOIXm4BDyFIuk1FR8ICE4SojOG0lpZfBC3 NJ0ayKdqBWbxWC3EyvQP+07NIJWlOpUbBBxL3xvIG8N0TCDoNV8pe2SoeC7zh8GE Cmo2vjWR9LMsYqlMekzVr1pYGAMb7MTjin50fuPf0ignYxozL+Jg==
X-ME-Sender: <xms:O-G-WeZFJEzz4T6D2kn1T_WfXHFa-u17vxfRK31wmHgk7ocs_dvQNg>
X-Sasl-enc: WktLBefgbdwTR1wcikWf1LCBDlqEtnqNXl1+Qgqz+I77 1505681723
Received: from aither.local (unknown []) by (Postfix) with ESMTPA id 371EF7E446; Sun, 17 Sep 2017 16:55:23 -0400 (EDT)
To: Sam Whited <>
References: <> <> <> <> <> <> <> <> <> <>
From: Peter Saint-Andre <>
Message-ID: <>
Date: Sun, 17 Sep 2017 14:55:22 -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="5HWHtha59X7qQgTNgpAPifdmGqvkLWPDS"
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:55:29 -0000

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.