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