On May 1, 2014:1:38 PM, at 1:38 PM, Joe Touch <touch@xxxxxxx> wrote: > > > On 5/1/2014 10:33 AM, Thomas Nadeau wrote: >> >> On May 1, 2014:12:49 PM, at 12:49 PM, Joe Touch <touch@xxxxxxx> wrote: >> >>> >>> >>> On 5/1/2014 8:26 AM, Thomas Nadeau wrote: >>>> >>>> On May 1, 2014:11:02 AM, at 11:02 AM, Joe Touch <touch@xxxxxxx> wrote: >>>> >>>>> >>>>> On 5/1/2014 5:12 AM, Thomas Nadeau wrote: >>>>>> >>>>>> APIs are not that useful unless there is code behind them. >>>>> >>>>> Ultimately, yes. But the code represents an instance of the API. >>>> >>>> That depends on your perspective. These days the code IS the API, in >>>> particular open source code. Standards bodies do not need to define the >>>> APIs; implementation communities do that already. The IETF should >>>> probably stick to on-the-wire protocols. >>> >>> A protocol is defined by: >>> >>> - internal state >>> - message "on the wire" formats >>> - upper layer events >>> - lower layer events (message arrivals/departures) >>> - time events >>> >>> Leave any of the 6 above out and you have an incomplete spec. >>> >>> The "on the wire" part is only a fraction of what's needed. If you don't believe that, then write a TCP implementation from the header format alone, and let's see how well it works. >> >> Why do any of those things need a standards-based API to program to? > > The API is the upper-layer events. Without that, you can't define the semantics of the interaction with the upper layer. > > FWIW, I'm talking about IETF standard API, not Unix-standard or C-standard. The latter are required to ensure implementation compatibility, but can't be defined without the former. I guess we will have to agree to disagree. I just don't see why that is going to be useful to anyone. If you were talking about open source and/or reference implementations that the source was available for, then that makes far more sense to me. --Tom
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail