On 6/5/2015 12:53 PM, Mohamed Oulmahdi wrote: > > > On Thu, Jun 4, 2015 at 11:12 PM, Joe Touch <[email protected] > <mailto:[email protected]>> 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 first step towards a universal abstract interface is to understand the current specific abstract interfaces. That's what the current document is focused on. > 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) In order to unify or further abstract the API, the current API needs to be understood - but the discussion on the list indicates a lot of disagreement on this. Joe _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
