 |
 |
On Fri, Sep 24, 2010 at 11:42:33AM +0200, Eliot Lear wrote: > Hi Nico, > > This is a great conversation. I want to just comment on one point: > > On 9/23/10 11:08 PM, Nicolas Williams wrote: > > > > [*] This is often taken to be an advantage for SASL, but I've never > > thought so. The lack of APIs at best makes it possible to write > > RFCs like 4422 that are all English language text, but that's not a > > benefit in my view. Specifying at least abstract APIs facilitates > > just the right level of formalism needed to make it easy to specify, > > in sufficient detail, how applications use the framework. > > First let's agree that reference implementations and libraries are a > good thing. They help interoperability and in general they help > adoption. AND let's also agree that standardization of calling > interfaces is also a good thing, so that code doesn't have to be > re-invented. And so really the only questions are WHERE and WHEN those > APIs should be standardized. The IETF is not a good place. There is a > whole lot of protocol expertise at the IETF and zippo by way of API > people. That work has gone on elsewhere far more successfully, most > notably in ANSI and the IEEE. What's more, having a clean protocol > description with a separate API description seems to me always > desirable, even if the two efforts are linked. > > No, I won't address WHEN only to say that ossification of APIs and > protocols is different and requires some study. This is way OT, though I realized that I invited the comment. I believe you're wrong about how many "API people" participate at IETF. In fact, a great many do. I would argue that most of the Kerberos and GSS crowd are "API people", that's a not-insignificant portion of the security area. I would also argue that many participants in the PKIX and TLS WGs also know quite a bit about APIs, since their implementations require them. And in the transport area much work has been done on extending socket APIs (e.g., for SCTP). More importantly: there is no other place to go to for standardizing APIs related to Internet protocols. The IETF is it, flaws and all. Nico --