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

Sam Whited <> Sun, 17 September 2017 20:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EFEBC13339D for <>; Sun, 17 Sep 2017 13:51:47 -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=ONWlvnsd; dkim=pass (2048-bit key) header.b=XoVaIAtu
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9LrZ68rc_0Pl for <>; Sun, 17 Sep 2017 13:51:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DCEFB13337F for <>; Sun, 17 Sep 2017 13:51:46 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 51920209F3; Sun, 17 Sep 2017 16:51:46 -0400 (EDT)
Received: from web3 ([]) by compute4.internal (MEProxy); Sun, 17 Sep 2017 16:51:46 -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; s=fm1; bh=q6OHEqFsNwAiXOvXr SlbnYfoX+HFGfZH/PgQSGfh1Yk=; b=ONWlvnsd/JF98BpLNQnJFwnja4pIjz9Ph Mm7iUiyjeV7m7Lf+YmjKw53Lxj3t4p8axopg7nSJnR1n10PnRkIUapgEX25+lZSJ NMOfRVt1z83weEGT7H1xDgtFwi+Zf2NjQcQg+IhVHwVgsgQIJMpv59Wh+mRgz1A4 DavpKOSI2/RTZkFK8DZ1FGEsnQ9zEzfLGaonKYgTXH8Gw2FKPyPWJYyPVNWPuN0O tZSW6+GA5jibQasSC1dEhil7L1bOR5dGoub3Clvsh1Rqlr7U6mnNOkFkfK7KYQVy ll/0MqVtWkRNpctD6WS0ODvw1vMDLmr0E3xqDTMaqeAJxzL5NEylw==
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; s=fm1; bh=q6OHEq FsNwAiXOvXrSlbnYfoX+HFGfZH/PgQSGfh1Yk=; b=XoVaIAtu7in2UEFvOyw2Vp +AihydhIWODDM20YzpnpJoK2YfzT70gKBPgQ3QRfaiINCdj23ox5h0p8mqOMgAw5 h+9dTOqSbGWcUmKq1hJI6F6WpULPKJFXem5ACcnPy7zh4GTY83CCpnazgF1ffBPH oAi8XAmLsELQpotO5jkhjR5MmW7Vke84cSStlIluAvGuCpCS1yeEVc+e3glScezg tzFAr+yWM2g7YOzXHV/UjACjyp2NGPZxG80lBTecUlwebZoO1zVRU7MVCowjBg30 CRh5coS6dZ4fC5j3e7614A9ns7To1YCLXPY/9a4DNoT6TEhkwnts9OPA1wQSjBXA ==
X-ME-Sender: <xms:YuC-WZpwDXo5_SvafMGiREpkM-RWEvs7lEVHNYBRPk49HCrWnA999A>
Received: by mailuser.nyi.internal (Postfix, from userid 99) id 19DA89EB1B; Sun, 17 Sep 2017 16:51:46 -0400 (EDT)
Message-Id: <>
From: Sam Whited <>
To: "Peter Saint-Andre" <>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
X-Mailer: Webmail Interface - ajax-64b08692
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
Date: Sun, 17 Sep 2017 15:51:46 -0500
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:51:48 -0000

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.