Re: i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call))

Nico Williams <nico@cryptonector.com> Fri, 02 January 2015 17:06 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A69931A1B87; Fri, 2 Jan 2015 09:06:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level:
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id voOWqVs0SvsC; Fri, 2 Jan 2015 09:05:59 -0800 (PST)
Received: from homiemail-a29.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id B11001A1B84; Fri, 2 Jan 2015 09:05:59 -0800 (PST)
Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 51C3D674058; Fri, 2 Jan 2015 09:05:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=h/KzyacF2bPlSHbWLvUSBebE8Us=; b=O3JLqmmkokb oFLWQamZSmrmvF63UTvOFWv1vvoyMcCgbK1FmAmil46YO0wNQ93JvZED9TJgKk21 rnvXYhG/lhP9s1j2BVxeS5fXUqdcbC66EVhaOA1V9xoH8CG4hv6yWDoVfujigd5d lJrzQVCE4kpM+A+Rb1V68aqVO7SJh6P4=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPA id C6813674057; Fri, 2 Jan 2015 09:05:58 -0800 (PST)
Date: Fri, 02 Jan 2015 11:05:58 -0600
From: Nico Williams <nico@cryptonector.com>
To: John C Klensin <john-ietf@jck.com>
Subject: Re: i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call))
Message-ID: <20150102170553.GW24442@localhost>
References: <A4CC6CEC-D17E-4235-B615-9D2AD88096D4@frobbit.se> <20141231070328.GK24442@localhost> <B08B813F-B8B4-49F1-A0B9-60F322C8E9C7@frobbit.se> <20141231074641.GM24442@localhost> <947CA101-D717-4B56-8EEE-84B3A53BF4A1@frobbit.se> <20141231082551.GN24442@localhost> <E4837FDB76D5ACDEB1C568DF@[192.168.1.128]> <20150102030130.GN24442@localhost> <F109C828-AFF0-43AB-9214-5C9F42E36942@frobbit.se> <881FA95C72F0C69B513D143E@P5>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
In-Reply-To: <881FA95C72F0C69B513D143E@P5>
User-Agent: Mutt/1.5.21 (2010-09-15)
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/r3UHhnAs3TgWjFZ38BWyrCING1w
Cc: Darren J Moffat <Darren.Moffat@oracle.com>, ietf@ietf.org, saag@ietf.org, Jan Pechanec <jan.pechanec@oracle.com>, Patrik Fältström <paf@frobbit.se>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Jan 2015 17:06:00 -0000

On Fri, Jan 02, 2015 at 09:30:22AM -0500, John C Klensin wrote:
> --On Friday, 02 January, 2015 07:57 +0100 Patrik Fältström
> <paf@frobbit.se> wrote:
> 
> > For the record, I like what is suggested the below.
> 
> Wfm, but please note the other comments in my prior note.  To
> summarize, normalization is not the only issue.  Even for some
> normalization cases, NFC is not the cure.  For example, NFKC is

Indeed, which is why the proposed text also mentions confusable scripts.
(I didn't include references, but they could be added, all as
informative given the special circumstances here).

> needed to rationalize characters of various widths but causes
> problems elsewhere.  So, I would suggest some additional words
> that say, more or less, that, until PKCS#11 is revised to be
> clear about how to handle characters outside the ASCII
> repertoire, those who discover a need to use such characters
> should be cautious, conservative, and expend extra effort to be
> sure they know what they are doing and that failure to do so
> will create both operational and security risks.

I'm not opposed.  I just don't think this will really add value.

Thanks for your and Patrick's help BTW (my apologies if my earlier reply
to you seemed caustic; I tend to get annoyed when told that the IETF
"doesn't do APIs" :/).

Happy new year,

Nico
--