On Thu, Jun 4, 2015 at 11:12 PM, Joe Touch <to...@isi.edu> wrote: > > > 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. >
This definition of 'abstract interface" is specific for a given protocol, but the aim in TAPS is a higher level (services). In other words, if this is the définition of an abstract interface, and is already defined in RFC 793, what will be the contribution of TAPS by defining its abstract interface? The objective of TAPS is to change the traditional way to use the Transport layer. In fact, traditionally, applications select the appropriate transport service by selecting a given transport protocol. The TAPS vision is to change this, so as applications will request only their desired services, via this abstract interface, and it is to the Transport layer to choose the appropriate protocol according to the application request. It is this level of abstraction that is aimed by TAPS. (see the charter, point 3 especially) > > 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 Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
