Hi -
> From: "Tom Yu" <tlyu@xxxxxxx>
> To: "Sam Hartman" <hartmans-ietf@xxxxxxx>
> Cc: <iab@xxxxxxxx>; <ietf@xxxxxxxx>
> Sent: Wednesday, March 30, 2011 2:40 PM
> Subject: Re: IETF and APIs
>
> Personal observation: "API" is a subclass of "interface". "Network
> protocol" is a subclass of "interface". Interfaces (in the general
> case) are valuable things to standardize. An abstract interface
> ("abstract API"?) that gives guidance to implementors above and beyond
> the bare specification of the network protocol is useful for achieving
> conceptual alignment.
>
> Do people agree?
Yes and no. The experience with SNMPv3's ASIs (Abstract Service
Interfaces) might be instructive.
(1) because implementations of the protocol (or something very
similar to it) already existed, requiring conformance to the
ASIs (beyond the externally-visible behaviour they described)
found no support.
(2) Despite (1), there are *still* people who think the ASIs will be reflected
in implementations' APIs. (They generally aren't.)
(3) Even though there was already considerable experience with the
implementation of the protocol when these Abstract Service
Interfaces were defined, later work (especially in the isms WG)
found that these definitions required some serious tweaks to
handle cases that people were already thinking about when the
interfaces were defined in the first place.
(4) Some of the lengthy WG discussions and awkward hacks
resulting from (3) in subsequent RFCs were only an artifact of
the specification technique, and were not necessitated by
actual protocol or implementation constraints, in my opinion.
Still, I think it can be very helpful to specify a C library API for things that are
actually intended to be used like libraries, but I also know that it can
be surprisingly difficult to get them "right" for all environments.
Randy
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf