On Fri, Jun 19, 2015 at 6:15 PM, Joe Touch <[email protected]> wrote: > > > On 6/19/2015 6:22 AM, Michael Welzl wrote: > > > > On 19 Jun 2015, at 14:03, Mirja Kühlewind < > [email protected]> wrote: > >> So there current API is always bound to a specify protocol which > >> already provides you a certain set of service feature. At least in > >> TCP there is not much choice left and there the current API does > >> not give us a good indication which services are actually provided > >> by TCP. Therefore from my point of view the only way to identify > >> these services is to look at the protocol itself and not only the > >> API. In SCTP it’s different and we definitely have to and will > >> discuss the existing API in the document. > > > > Exactly that's why I thought starting with TCP's API > > (even when it's the abstract one) is not very helpful. > > > > Joe, Aaron: what is it you were expecting us to take away from > > reading section 3.8 of RFC 793? > > No. IMO, the current description of that API fails to indicate the > controls *already* available to TCP. > > I don't agree that the TCP API doesn't indicate the service TCP provides > - it's just implicit. E.g.: > > OPEN call > indicates TCP is connection oriented > > SEND/RECEIVE calls > indicates TCP is an ordered byte stream, > that the user-level byte boundaries are NOT > related to message boundaries, etc. > > Yes, there's some "reading between the lines" to do here. >
Of course, no one use a protocol without knowing the service it offers. When the application requests a TCP connection, it really request a reliable and ordered connection oriented service. The protocols primitives are used to each one to offer a part of this service. The difficulty occurs when several protocols are available, with mainly a certain service overlapping. In this case, exposing Transport services by the protocols offering them is not convenient to applications developers because they must be aware of the several protocols details that are not always evident to some of them. The objective is so simply to change this service exposition from a protocol-based to a service-based, allowing developers to request services without knowing anything about the underlying protocols offering these services. > > > ( I can see it highlighting the need > > to discuss communication patterns (or decide for a specific one) in > > document #2, but not really contributing much to the list in document > > #1 ? ) > > I believe the opposite is true. > > Joe > > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps >
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
