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

Nico Williams <nico@cryptonector.com> Mon, 12 January 2015 04:54 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 0CE551A8844; Sun, 11 Jan 2015 20:54:16 -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 VAKrMJnGDMxi; Sun, 11 Jan 2015 20:54:14 -0800 (PST)
Received: from homiemail-a106.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D5E531A87F1; Sun, 11 Jan 2015 20:54:14 -0800 (PST)
Received: from homiemail-a106.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTP id 420212005CF2C; Sun, 11 Jan 2015 20:54:14 -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; s=cryptonector.com; bh=tS/vru6vW6LPRu rQ0mBxO0mQksw=; b=DjMnJYZCczxxCwifHmqBpOXhUEfbVD2iUnOngiAj3Z2zfl 5qPGWVFpiM7TmejzL0iDclP0/SlBVAf8OedSRamba3WyFkb3pzpIp6Y8d7pYc/l3 r5H1ELlfofOYm2SbHgoXIoOAvlEoqrEwLonW0m5PpQEg45Y2h5j4/G3HD3hCE=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTPA id C72742005CF07; Sun, 11 Jan 2015 20:54:13 -0800 (PST)
Date: Sun, 11 Jan 2015 22:54:13 -0600
From: Nico Williams <nico@cryptonector.com>
To: "Salz, Rich" <rsalz@akamai.com>
Subject: Re: [saag] i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call))
Message-ID: <20150112045411.GD16323@localhost>
References: <9A043F3CF02CD34C8E74AC1594475C73AAF5744C@uxcn10-tdc05.UoA.auckland.ac.nz> <2A0EFB9C05D0164E98F19BB0AF3708C71D55675E67@USMBX1.msg.corp.akamai.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D55675E67@USMBX1.msg.corp.akamai.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/Iw3SglgMlczkNT72Tr7CwQCYA3o>
Cc: "saag@ietf.org" <saag@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, Jan Pechanec <jan.pechanec@oracle.com>, Peter Gutmann <pgut001@cs.auckland.ac.nz>
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: Mon, 12 Jan 2015 04:54:16 -0000

On Sun, Jan 11, 2015 at 05:28:30PM -0500, Salz, Rich wrote:
> > I'd go even further than that and just mandate MUST ASCII. 
> 
> I don't know if the IETF is "allowed" to do that any more, but +1 for
> the reasons you list.

I'm not sure if the IESG will agree to that, and I'm not sure if the
IETF will agree to that (well, this is an IETF LC, so we're finding
out).  The shepherd can probably give us a sense of the IESG, and we can
always come back and make it fit what the IESG wants.

As for myself, I'd rather we do something like this:

 - note that PKCS#11 used to be just-use-8

 - note that what used to interop did because of local conventions (what
   locales systems and/or user sessions use)

 - note that PKCS#11 _now_ says use-UTF-8 with no further advice

 - [therefore] note that

   a) US-ASCII is most likely to interop,
   b) where non-US-ASCII is needed then UTF-8 is most likely to interop
      (and is required by the latest PKCS#11 spec),
   c) where UTF-8 is used then one should normalize to NFC on create and
      lookup (and possibly use form-insensitive string matching).

I can't see the harm in any of those.  Requiring US-ASCII when PKCS#11
doesn't does strike me as a bit too pessimistic, but I'd be fine with
RECOMMENDing it.

Nico
--