[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 15:48:35 PST 2014

On 2/18/2014 3:40 PM, Nico Williams wrote:
> 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!

UDP has one, under the heading "User Interface"

IP has one too - see section 3.3

Granted, we've hopefully learned a lot in the past 34 years, and now 
aspire to something a little more specific.

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


More information about the rfc-interest mailing list