Re: [Taps] TCP components

[Michael Welzl <[e-mail]>]

> On 18. jun. 2015, at 15.56, Mirja Kühlewind <[e-mail]> wrote:
> 
> Hi Michael,
> 
>> Am 18.06.2015 um 15:43 schrieb Michael Welzl <[e-mail]>:
>> 
>> 
>>> On 18 Jun 2015, at 10:48, Mirja Kühlewind <[e-mail]> wrote:
>>> 
>>> Hi Joe,
>>> 
>>> I believe the approach Michael is proposing is to look at existing APIs as a starting point; not only abstract APIs.
>> 
>> No, wrong. Only abstract ones from RFCs, I said this before. These things would typically have preceding IETF debate, whereas trying to cover implementations is a huge and probably meaningless endeavour (the bar may be high for adding function calls to an API on system X and low for an API on system Y).
> 
> Okay, but then I don’t really understand your approach fully. Yes we should document and look at what’s already specified in RFC, however isn’t the goal of taps to actually figure out how to change/extend/improve these APIs? How can we figure out what’s missing/wrong if we only look at what’s already there?

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

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

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...").

Cheers,
Michael