I agree, the discussion should be better structured ... On Fri, Jun 5, 2015 at 10:21 PM, Joe Touch <[email protected]> wrote:
> > > 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
