[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 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,
>>>> - 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
> 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
> 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