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