[rfc-i] APIs (Re: Text no longer definitive (was Re: Proposed way forwards on backward compatibility with v2))
touch at isi.edu
Tue Feb 18 16:23:19 PST 2014
On 2/18/2014 3:57 PM, Nico Williams wrote:
> 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
>>> 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.
Preaching to the choir. IMO, that's the only good way to design a
> (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?).)
More information about the rfc-interest