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

Nico Williams <nico@cryptonector.com> Wed, 31 December 2014 19:44 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 3DBEF1A1A3E; Wed, 31 Dec 2014 11:44:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.034
X-Spam-Level: *
X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 ejUE2iQvf9-d; Wed, 31 Dec 2014 11:44:32 -0800 (PST)
Received: from homiemail-a112.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id AC7DC1A1A39; Wed, 31 Dec 2014 11:44:32 -0800 (PST)
Received: from homiemail-a112.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a112.g.dreamhost.com (Postfix) with ESMTP id 7AB3520046B15; Wed, 31 Dec 2014 11:44:32 -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=Fqd3dp7CJeQ9QA wIqw39CFzt2qs=; b=RZsRFT9LChDKEQiyvIJm16RaOQS20ZUMFTaqno09jTw2FU Im1FXLhKcxQRo+BoxYyDIJOK/6vuip1kfZc9a1GqnqWSX+1ET1Z7gGVqxtdif2I8 0d+jwbl4JouDUSMyPRP2U3CXuTTl+I0i1UNK1H5zJwzK94b/pa4qDpm9rLSCI=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a112.g.dreamhost.com (Postfix) with ESMTPA id EA48220046913; Wed, 31 Dec 2014 11:44:31 -0800 (PST)
Date: Wed, 31 Dec 2014 13:44:31 -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: <20141231194426.GP24442@localhost>
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]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E4837FDB76D5ACDEB1C568DF@[192.168.1.128]>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/8fsTaKpSNGzFHuchn1OsO6zGlSU
Cc: Darren J Moffat <Darren.Moffat@oracle.com>, ietf@ietf.org, saag@ietf.org, Jan Pechanec <jan.pechanec@oracle.com>, Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= <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: Wed, 31 Dec 2014 19:44:34 -0000

On Wed, Dec 31, 2014 at 10:41:28AM -0500, John C Klensin wrote:
> 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.

I think you're misreading what I wrote.  Please read my latest reply to
Patrik.

> 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

We've had specs that naively said "normalize" too.  NFSv4 comes to mind.

> 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.

You're twisting my words.  I very specifically said that what to do
about normalization depends on the application.  I don't think there's a
one-size-fits-all approach, not without a time machine on hand.

> Normalization is easily dealt with by making a clear statement.

My experience with filesystems is that that's an easy statement to make
and much harder to make real.  This is why ZFS is form-preserving/
form-insensitive: it was the best solution in a world where none of the
moving parts could be expected to normalize to the one true canonical
form.

A funny story from back when: Apple apparently was porting ZFS to OS X,
and they made it normalize to NFD (close enough) to match HFS+.  This
caused breakage.  As I recall it the notable breakage was with git, and
ZFS got blamed by Linus T.  But of course, the problem was that the
filesystem in question (not ZFS, but ZFS modified to normalize to NFD)
was using an inconvenient NF.  That HFS+ normalizes to NFD is a reality
that can't be changed.  That input methods tend to produce NFC-ish
output is also a reality that can't be changed.  That system call stubs
in C libraries don't apply codeset conversions and normalization is a
reality that can be changed, but only at great effort.  I can go on.

The point is that "just normalize" is naive, and each application
requires careful consideration.

> You (and the authors) pick, but I agree with Patrik that
> something needs to be said unless you take the alternate
> suggestion below.

I agree with Patrick that something needs to be said at the very least
in the security considerations section.

Also, *I* brought up the issue, as I'm rather sensitive to normalization
issues.  *I* suggested something minimal and said that if there was no
consensus for it, I'd be fine with saying nothing, mostly because it's
late in the day and I don't think it will be critical in this case.

> 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:

RSA.

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

Is it?  I'd like that to be required.

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

Sure.

> (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.

I think that's too strong.

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

Sure.

> 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

Please point to a Standards-Track document that says that.

> 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.

We certainly have done APIs.  E.g., SCTP socket API, GSS-API.

GSS comes in two flavors: abstract, and bindings of the abstract API to
specific programming languages.

FYI, GSS defines a protocol _pattern_ (and just a handful of bits on the
wire of that pattern), but vast majority of it is an API.  Compare to
SASL, which also defines a protocol pattern, practically no bits on the
wire, and no API (of course, there are SASL APIs, because at the end of
the day most application developers want off-the-shelf implementatins of
such things).

Should we stop all work on GSS because you claim there's a policy
against APIs?

Further, I believe a lot of real problems have arisen from the lack of
APIs.  In particular I believe end-to-end IPsec is useless without
binding per-packet security into a higher-order construct like "packet
flow", which necessarily involves exposure of IPsec information to
higher layers, which then necessitates a notional (abstract) API.  That
API does not exist, therefore IPsec has been relegated to small networks
and VPNs, where local configuration is small, manageable, and can be
assumed.  The lack of an abstract API here hurt adoption.

> 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.

This might well be the case here, but the problem isn't "oh noes, it's
API", but that the API (which could have been a protocol) in question is
defined _elsewhere_.

> Part of the problem is that an API is a somewhat different type
> of beast from a protocol-style Technical Specification.  If we

I disagree vehemently.  See above examples.  I think this opinion of
yours is harmful and hand-wavy.  If you have a detailed argument for why
APIs are so different from "protocol-style" specs that we should not
engage in API design, I'd like to see it.

> are going to keep doing these, it may be time to modify/update
> 2026 to introduce a new class of standards-track document.

To read RFC2026 as a prohibition on IETF work on APIs is real stretch.
Clearly many have disagreed with that take over the years since RFC2026
was published, and they (we) have published RFCs that contravene your
reading of RFC2026.

Nico
--