> On 29. mai 2015, at 19.32, Joe Touch <[email protected]> wrote: > > First, I think this discussion would benefit from a clarification of > what "API" means, or at least to stop using that term in isolation. > > There are three distinct concepts: > > A- abstract protocol "upper layer interface" > e.g., OPEN, CLOSE, ABORT, as per RFC 793 > > B- programmer API > e.g., Linux C/C++ TCP socket interface > > C- instance of a programmer API > e.g., Linux Ubuntu 15.04 C/C++ TCP socket interface > > IMO, this document MUST discuss A, and can be address potential > extensions to A based on examining variants of B and C. > > There are also the protocol features, which are the properties of the > protocol that: > - can be explicitly configured and monitored > these are *exactly* A, B, and/or C above > > - can be implicitly detected > some are based on the definition of the protocol, > such as reliable, byte sequence delivery > > some are an artifact of the implementation, > such as specific delays due to burst losses > > However, *none* of this is a rat-hole IF TAPS is intended to explain the > service interface to the user. IMO, B and C above should be secondary > considerations after A is clearly documented, but this draft is a long > way from that.
I agree: A should be there, and it should probably the primary focus, as starting with a list of A would add a lot of clarity to the document and the discussion of it. Some text on protocol internals, explaing what a protocol does even though these things may not be exposed to an application, can be valuable even if only to know which protocol to choose. So I'm not suggesting removing everything but I'd agree that the focus of the document should shift towards a list of A. Cheers, Michael _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
