Hi Joe, hi Michael, I completely welcome to add more text to the Interface description section (3.1.2). Currently this section is very short and says regarding the (higher layer) interface described in FRC793:
"A User/TCP Interface is defined in [RFC0793] providing six user commands: Open, Send, Receive, Close, Status. This interface does not describe configuration of TCP options or parameters beside use of the PUSH and URGENT flags.“ This text was already added based on Joe’s input. Please provide more text if you think this is not sufficient. Probably we should at least add one more sentence describing the TCP-to-User interface (as it is called in RFC 793) like this: „Further the TCP-to-User interface is described providing information on the local connection name, the response string, the send and received buffer addresses, the Byte count (which counts bytes received) as well as the PUSH flag and URGENT flag.“ However, from my point of view I actually think that these (basic) things do not need to be discussed in more detail because the described interface is completely okay and can probably be mostly say as it is. The more complicated question is which additional things are needed and, even more important, how can you design a transport interface where the application does not need to choose the protocol first. Because the interface in RFC 793 only describes a User/TCP interface where TCP already determines a certain transport service or a set of transport services features relating to specific transport components. The whole goal or taps is to make things more flexible which mean we need more information before we open a connection and probably also during the connection. One information could be „I want to use a TCP header“ and maybe together with these features… However, as soon as we have chosen certain protocol which might be TCP be still need Open, send, receive and closes commands as described in RFC 793. So what I want to say is, that the described interface in RFC 793 is so basic that it is not wrong and should be described in this doc (as it is) but it does help us very much to get to the goal we would like to reach in taps which I currently would describe as: Extend the application layer interface to consequently provide a more flexible transport layer. Or even better the other way around: Create a more flexible transport layer which most likely will lead to an extended application-level interface. Another thing I also would like to say (again) at this point is that the current doc will not specify an new interface. We on purpose ‚only‘ talk about transport components and features in this document because we first need to know what we want to do before we can talk about the interface. However, again, if you think there is something important missing in this doc, please send text! Currently we will (more or less) just integrate all text that we get because it is much easier to discuss about text that is there and something that is not there. That does also mean that any text that is currently in the doc can be discussed, changed or removed! Mirja > Am 30.05.2015 um 14:24 schrieb Michael Welzl <mich...@ifi.uio.no>: > > >> On 29. mai 2015, at 19.32, Joe Touch <to...@isi.edu> wrote: >> >> First, I think this discussion would benefit from a clarification of >> what "API" means, or at least to stop using that term in isolation. >> >> There are three distinct concepts: >> >> A- abstract protocol "upper layer interface" >> e.g., OPEN, CLOSE, ABORT, as per RFC 793 >> >> B- programmer API >> e.g., Linux C/C++ TCP socket interface >> >> C- instance of a programmer API >> e.g., Linux Ubuntu 15.04 C/C++ TCP socket interface >> >> IMO, this document MUST discuss A, and can be address potential >> extensions to A based on examining variants of B and C. >> >> There are also the protocol features, which are the properties of the >> protocol that: >> - can be explicitly configured and monitored >> these are *exactly* A, B, and/or C above >> >> - can be implicitly detected >> some are based on the definition of the protocol, >> such as reliable, byte sequence delivery >> >> some are an artifact of the implementation, >> such as specific delays due to burst losses >> >> However, *none* of this is a rat-hole IF TAPS is intended to explain the >> service interface to the user. IMO, B and C above should be secondary >> considerations after A is clearly documented, but this draft is a long >> way from that. > > I agree: A should be there, and it should probably the primary focus, as > starting with a list of A would add a lot of clarity to the document and the > discussion of it. > > Some text on protocol internals, explaing what a protocol does even though > these things may not be exposed to an application, can be valuable even if > only to know which protocol to choose. So I'm not suggesting removing > everything but I'd agree that the focus of the document should shift towards > a list of A. > > Cheers, > Michael _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
