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