> On 1. jun. 2015, at 16.32, Mirja Kühlewind <mirja.kuehlew...@tik.ee.ethz.ch> > wrote: > > 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.“
I agree > 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. I agree > 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. True, but this sounds out of scope of this document? This is just supposed to list the services... > 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. I'd say "I want to use a TCP header" should definitely be out of scope of all this because it defeats the purpose of the TAPS idea. If I know I want to use a TCP header, I don't use TAPS, I use TCP! We're not aiming at replacing the interface for all applications, just offering something new. > 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. Yes, but... > Another thing I also would like to say (again) at this point is that the > current doc will not specify an new interface. Exactly :-) > 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! Good, thanks. Anyway my point was that, in this list of services, we should be clear about Joe's item A: what is currently offered to apps by the current specs. This is the most important part of the list because it reflects what designers of these protocols (and with them, some form of prior IETF group consensus) think should be offered to apps. Going beyond that by discussing internals or things that some apps now can tune is a nice extra perhaps, but I think it should be a secondary goal. Cheers, Michael _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
