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

John C Klensin <john-ietf@jck.com> Wed, 31 December 2014 15:41 UTC

Return-Path: <john-ietf@jck.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 CAF4A1A9066; Wed, 31 Dec 2014 07:41:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.411
X-Spam-Level:
X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 2gY2sxocXCjZ; Wed, 31 Dec 2014 07:41:35 -0800 (PST)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6DEA1A9090; Wed, 31 Dec 2014 07:41:34 -0800 (PST)
Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1Y6LOq-000Ect-Mc; Wed, 31 Dec 2014 10:41:28 -0500
Date: Wed, 31 Dec 2014 10:41:28 -0500
From: John C Klensin <john-ietf@jck.com>
To: Nico Williams <nico@cryptonector.com>, =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= <paf@frobbit.se>
Subject: i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call))
Message-ID: <E4837FDB76D5ACDEB1C568DF@[192.168.1.128]>
In-Reply-To: <20141231082551.GN24442@localhost>
References: <CAK3OfOjnRCmiu-TKCJ-AFanpCsqnw1o2w_EC2AKMUnQ2A4DqVw@mail.gmail.com> <alpine.GSO.2.00.1412292234010.1509@keflavik> <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>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/a9wiWlhuQ-xO9GutRgLFIDlVNlo
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: Wed, 31 Dec 2014 15:41:37 -0000


--On Wednesday, 31 December, 2014 02:25 -0600 Nico Williams
<nico@cryptonector.com> wrote:

> On Wed, Dec 31, 2014 at 08:54:00AM +0100, Patrik Fältström
> wrote:
>> What I think is then needed is for this case:
>> 
>> 1. A simple explanation what you really is talking about
>> 
>> What is the requirement on whom regarding
>> normalization/mapping/whatever?
> 
> The I-D in question defines a URI scheme for PKCS#11 resources
> some of whose naming attributes are character strings which
> PKCS#11 says should be UTF-8.  PKCS#11 (*not* an Internet
> standard) does not say anything about form.  Should this I-D
> say anything about form?
> 
> IMO the most it should say is "PKCS#11 doesn't specify a
> canonical form for these labels, therefore the application may
> need to canonicalize prior to comparing them".  The
> alternative is to say nothing.

Nico, commenting on this issue only and doing it in more general
terms (going a bit beyond Patrik's "IETF have in many cases
created profiles...": The conventions for IETF-approved
publications include that they are supposed to support
interoperability and that features/ characteristics that would
interfere with interoperability are grave defects.  This is
especially true of Standards Track documents, where 2026 very
clearly makes "known technical omissions" absent specific
reasons for waiving that requirement.  At least by convention
for nearly two decades, the IESG reaching such a conclusion
requires clear documentation of the defect and the reason for
making an exception in the specification and usually in the Last
Call.

Nowhere in our procedures is that any provision for a
standards-track document to get a waiver because some other
standards body got sloppy, did something that wouldn't meet our
standards, or didn't quite understand the implications of what
they were doing.

Now, we've had a lot of specs written on the assumption that a
sufficient path to internationalization of a protocol designed
around ASCII (or an ISO 646 profile or IA5) was "just say
'UTF-8' where we used to say 'ASCII', use UTf-8, and go merrily
on your way".  After a while, with help from both experience and
some of our friends, we figured out that wasn't a good idea and
various specs now, appropriately, push back anything resembling
"just use UTF-8" (a statement like "It's all UTF-8, all the
time, so that form-insensitive can work" (from your earlier
note, not the spec) is an example of "just used UTF-8" thinking.


In addition, we have an often-ignored requirement for an
"Internationalization Considerations" section when a document
touches on i18n issues (See Section 6 of RFC 2277).  Personally,
I don't think it is important for documents that really address
i18n topics but that it is extremely so when, e.g., the spec
doesn't really address the i18n issues but repeatedly says
things like "...in environments that are not strictly limited to
US-ASCII".  Without specific instructions (and I can find none
on quick skimming), that is dealing with i18n considerations by
aggressive handwaving.   One of the more impressive examples of
this is

	"...an implementer ought to use the spirit rather than
	the letter of the rules when generating or parsing these
	formats in environments that are not strictly limited to
	US-ASCII."

But the most frequent complaint we hear about i18n from protocol
designers in the IETF is similar to "I'm not an expert on this
stuff and don't intend to become one; just tell me what to do".
The above does nothing for "just tell me what to do".  It
instead implies that the implementer should become enough of an
expert to figure out what the implications of "the spirit"
actually are.  FWIW, I can't easily figure that out because
there are so many whitespace characters, zero-width things,
breaks and non-breaks of various sorts, etc., in Unicode to say
nothing of conventions in various scripts that don't separate
"words" with space-like things.  There is some guidance in a few
Unicode specs, but they are hard to read and understand, much
less apply reasonably to a particular situation, unless one
already has a good understanding of the Unicode Standard and
some of the issues involved.

Normalization is easily dealt with by making a clear statement.
Historically, our experience has been that the obvious
reasonably clear statement is "use NFC".  The growing community
opinion (including in the W3C i18n effort which is much more
active than various IETF-related groups) seems to be "don't
worry about normalization until comparison (or equivalent) time
because it will have to be done again then anyway to be safe).
You (and the authors) pick, but I agree with Patrik that
something needs to be said unless you take the alternate
suggestion below.

But other issues, like the whitespace one called out above, are
far more complex and require serious treatment of some sort.

Alternate suggestion in the interest of getting this out and
recognizing that this is mostly a PKCS#11 problem (presumably
ITU and/or RSA, but what do I know) and shouldn't be an IETF one:

(1) Put in an Internationalization Considerations section, which
I believe is required anyway.

(2) Indicate that PKCS#11 severely underspecifies issues
associated with characters outside the ASCII repertoire and,
especially, contexts not associated with European languages.  

(3) Say that, at least until PKCS#11 is updated to more
adequately handle and specify i18n issues, such characters, and
certificates that use them, SHOULD NOT be used in or referenced
from URIs, unless there is a clear need and the issues
associated with the characters to be used are clearly understood.

(4) As appropriate, update the handwaving in this document to
point to that new section.

That would make it very clear that you are not telling people
how to do it and would make the warning as obvious as it should
be.

Finally...

> PKCS#11 is an API.  PKCS#11 apps might "interoperate" using
> PKCS#11 URIs communicated over, e.g., IPC (or plain old
> cut-n-paste).
> 
> PKC#11 URI _templates_ might well be exchanged far and wide,
> but still not really as a part of a network protocol.

For many years, the IETF had a very strong "we don't do APIs"
policy.  That was motivated, at least in part, because APIs tend
to make strong assumptions about programming language and
operating system environments, either favoring some over others
(a business we didn't want to be in) or not standing the test of
time as things outside the IETF evolved.  The view was that we
were much better off specifying requirements and protocols and
leaving APIs to particular languages, libraries/packages, or
operational environments.

Times change but it seems that many of the times we do APIs drop
us into a rat hole similar to this one in which we are trying to
do an overlay to a spec over which we have little or no control.
Part of the problem is that an API is a somewhat different type
of beast from a protocol-style Technical Specification.  If we
are going to keep doing these, it may be time to modify/update
2026 to introduce a new class of standards-track document.
Until and unless we are willing to do that, I think we'd better
get used to these rough edges and stop pretending that they are
good excuses for work that doesn't meet the Technical
Specification target criteria.

   john