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

Patrik Fältström <paf@frobbit.se> Fri, 02 January 2015 15:19 UTC

Return-Path: <paf@frobbit.se>
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 3DEF71A879F; Fri, 2 Jan 2015 07:19:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.961
X-Spam-Level:
X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 scLsZvLi_XgM; Fri, 2 Jan 2015 07:19:34 -0800 (PST)
Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 996AD1A8794; Fri, 2 Jan 2015 07:19:34 -0800 (PST)
Received: from [IPv6:2a02:80:3ffc::41e3:a051:8600:13d2] (unknown [IPv6:2a02:80:3ffc:0:41e3:a051:8600:13d2]) by mail.frobbit.se (Postfix) with ESMTPSA id ABEEB21DAD; Fri, 2 Jan 2015 16:19:32 +0100 (CET)
Subject: Re: i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call))
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
Content-Type: multipart/signed; boundary="Apple-Mail=_CB9DAAA5-C0ED-4B04-9ABF-8875EC49A8CE"; protocol="application/pgp-signature"; micalg="pgp-sha1"
X-Pgp-Agent: GPGMail 2.5b4
From: Patrik Fältström <paf@frobbit.se>
In-Reply-To: <881FA95C72F0C69B513D143E@P5>
Date: Fri, 02 Jan 2015 16:19:32 +0100
Message-Id: <681FC255-E7F5-4327-9B5D-6B7FEB0FE489@frobbit.se>
References: <CAK3OfOgm_ZYj-rY+4ExZzY8KY4G3rz2KLrZ8hQJi7ZUR4yiP0Q@mail.gmail.com> <alpine.GSO.2.00.1412300946340.4549@keflavik> <CAK3OfOha9qu=uDtqwDTdV78waLMaorYq0T6cq1YX3VzQn2OpKA@mail.gmail.com> <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>
To: John Klensin <john-ietf@jck.com>
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/OqRqFqZ4hr3ZQWjPeWHJHE7xAYQ
Cc: Darren J Moffat <Darren.Moffat@oracle.com>, saag@ietf.org, Jan Pechanec <jan.pechanec@oracle.com>, ietf@ietf.org
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 15:19:36 -0000

> On 2 jan 2015, at 15:30, John C Klensin <john-ietf@jck.com> 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.

This is why I think the way NFC is mentioned is correct.

> For example, NFKC is
> 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.

Having this clarification explicit and not only implicit would make the text even better.

   Patrik