On 6/3/2015 2:26 PM, Mohamed Oulmahdi wrote:
> I think that speaking specifically about any protocol in this document
> will not be in the sens of an "abstract" interface for the Transport
> layer, because abstraction means that application will no longer be
> aware of who or what Transport services are really offered.
We need to be more clear in what we are discussing.
E.g., an "abstract API" (as I've been calling it) is described as in RFC
793:
OPEN, SEND, RECEIVE, CLOSE, ABORT, and STATUS
That's abstract only in the sense that it does NOT specify an
implementation in Linux, for example. It is not so abstract that it
applies to all transports - it's indicated for TCP only.
What you're proposing is a "universal interface", whether abstract
(described as above, using words to describe app-level actions and
events) or instantiated (e.g., using Unix socket(), connect(), accept(),
listen(), etc.).
Joe
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
