[rfc-i] APIs (Re: Text no longer definitive (was Re: Proposed way forwards on backward compatibility with v2))

Nico Williams nico at cryptonector.com
Tue Feb 18 15:57:58 PST 2014


On Tue, Feb 18, 2014 at 5:48 PM, Joe Touch <touch at isi.edu> wrote:
> On 2/18/2014 3:40 PM, Nico Williams wrote:
>>> A protocol operating without an API is easy. It doesn't *need* to do
>>> anything.
> ...
>
>> Clearly in many cases we manage well enough without a requirement for
>> abstract APIs.
>
> At best, only because they have existed but not been documented. And, as per
> the several examples you gave, we get into trouble exactly because of that.
> ...
>
>> But I also think demanding abstract APIs will first require convincing
>> a lots of people of their value...
>
> Yes, and that a protocol is more than "on the wire" information. But that
> doesn't mean it's not important to at least try.

No argument from me.

But often the protocols and the APIs develop separately, in divergent
ways, organically, and over long periods of time.  Few are the cases
where an API was well-thought-through first, and it's hard to argue
that those have been successful protocols (I'm thinking of the
GSS-API, of course, one of my favorite technologies to work on/with).
Quite often we need implementation experience first.  I think we're
not going to get the abstract APIs we want without actually writing
them ourselves or convincing authors of the value of doing a little
bit of API design concurrent with protocol design.

(Also, it's easy to point to PKIX's problems as a lack of APIs as I
did, but really, PKIX's biggest problem was X.500 naming (oh, but I
repeat myself, no?).)

Nico
--


More information about the rfc-interest mailing list