[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:40:00 PST 2014


On Tue, Feb 18, 2014 at 4:54 PM, Joe Touch <touch at isi.edu> wrote:
> On 2/18/2014 1:58 PM, Nico Williams wrote:
>> On Tue, Feb 18, 2014 at 3:44 PM, Joe Touch <touch at isi.edu> wrote:
>>> Not new to everyone. It should be required as a minimum expectation,
>>> though
>>> - including addressing the upper layer interface (API).
>>
>> You know well that I'm a fan of abstract APIs, but I'd not make it a
>> guideline that such should be included -- that's a bridge too far for
>> me even though I would like more RFCs to include some treatment of
>> abstract API semantics.
>
> I'm not sure what it means to define a protocol if you don't specify how to
> control it - which means an API of some sort, whether by example (a Unix
> API) or abstract.
>
> A protocol operating without an API is easy. It doesn't *need* to do
> anything.

We have plenty of such protocols:

 - TLS
 - SSHv2
 - SASL

 - IP!
 - UDP!
...

TCP has an abstract API, sort-of.  UDP doesn't.  Since we had BSD
sockets more or less concurrently, it didn't matter.

Mostly this is not that big a deal, but sometimes it can be.

TLS is a case where APIs would have helped avoid at least one serious problem.

IPsec is an utter failure for end-to-end security (it doesn't scale)
because of the lack of APIs.

PKIX is a another great example of a [family of] protocol[s] where
abstract APIs would have helped a tremendous lot.  Anyone who's
bothered with typical PKIX libraries knows what I'm talking about.

NFS defines a veritable API over RPC, but it doesn't have a
higher-layer API and doesn't need one: POSIX and Win* exist separately
and clearly are a target of NFS.

IMAP and LDAP are, effectively, RPC protocols with well-defined RPCs,
so really, they do define an API, just not in such terms.  I don't
know how well IMAP maps to what MUAs need, but LDAP doesn't really --
that I know.

Clearly in many cases we manage well enough without a requirement for
abstract APIs.  In a few the results have been catastrophic, though
very few of us will recognize the results as such and blame lack of
APIs for them.

IMO it'd be better to have abstract APIs than not.  IMO the record
backs me up, though as a matter of interpretation and opinion.

But I also think demanding abstract APIs will first require convincing
a lots of people of their value... and that's much harder than
convincing them of the value of a11y -- legal regulations are already
doing the latter, after all.  Clearly most authors and implementors
have managed reasonably well without bothering with abstract APIs, so
they won't be predisposed to accept a guideline/requirement that
really does add a harder-to-define burden [than just an a11y
guideline].

Nico
--


More information about the rfc-interest mailing list