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