Re: [Taps] TCP components

[Michael Welzl <[e-mail]>]

> On 19 Jun 2015, at 14:03, Mirja Kühlewind <[e-mail]> wrote:
> 
> Hi Michael,
> 
>> *My* goal is, and has always been, to provide a simpler, general API that is protocol independent. Note that this is not only for simplicity for ease of use BUT also for the sake of being able to automatize. After all the major goal is to remove the strict binding between applications and a specific protocol choice.
> 
> Yes, I agree! (not sure if this is simpler though… depends on the definition of simple… but hopefully easier to use and understand for the overlying application).

Agree too, easier to use is what I meant


>> To be able to do this (documents 2 and 3), we first need a list of the existing services - our toolbox, if you wish (document 1). Figuring out what's missing / wrong about today's APIs (except that they are bound to a specific protocol) has never been *my* major intention, and I certainly don't see that as the goal of this document. I'd be surprised if that's what the charter suggests?! But of course my opinion is only what it is, the charter reflects the consensus…
> 
> 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?
( 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 ? )


>> All this being said, it can be a nice side-effect of the document (and note that noone knows what a TAPS system will really look like, and how these RFCs will actually end up being used). So I'm not strongly opposing the approach you're now following in that I don't see a big issue with there being a list of components - I just think it's not particularly useful for the goal of the document and doesn't really help the group progress towards its goals. I thought that proposing something more systematic with less arbitrariness could make it easier to put everyone in the same boat (in a way: "look, the boat HAS to be like that, there wasn't much choice, sit down please" rather than "sorry I painted it green, I like that color; I can understand you would have preferred a blue boat...“).
> 
> I totally understand this point. But at least for TCP I think it is not sufficient to look at the (abstract) API because in TCP there are not much choices and therefore the services TCP provides are not exposed over the API. I personally currently don’t see how another approach would bring us the the goal of identify existing services.

Agree about TCP


> Again, if you have time to work on an alternative approach, please go ahead and provide input or even submit an own draft and I’m/we’re really open to discuss this and see what makes more sense. 

Ok....  well, I agree that what I request is easier said than done  :-(     myself, I've been working on a first version of document #2 as I think this would help us understand if the set of "services" or whatever we call them in document #1 is useful for the group's purpose.

Michael