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

Joe Touch 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
>>>> 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.

Preaching to the choir. IMO, that's the only good way to design a 
protocol...

Joe

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