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.
> ( 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
