Re: [Taps] IETF100 meeting agenda uploaded

[Michael Welzl <[e-mail]>]

Hi,

 
> On Nov 5, 2017, at 10:21 PM, Tommy Pauly <[e-mail]> wrote:
> 
> Indeed! But, as far as I can tell, drafts like draft-tiesel-taps-socketintents-01 are not trying to propose a top-level API, but rather an aspect of the API.

I agree with everything you say here. About draft-tiesel-taps-socketintents-01, okay - I wasn’t so sure where this is heading … but both draft-trammell-taps-post-sockets-03 and draft-fairhurst-taps-neat-00.txt describe an abstract API.


> Even when we discuss the draft for what I'm referring to as the "top-level API", I think we need to (in the spirit of the charter) not be specifying a specific set of language-specific API calls, or a specific framework, but the shape that instances of an API should take. My goal coming out of TAPS would be to change the approach implementers take when designing transport APIs, to make sure that the resulting APIs not only support the flexibility TAPS was designed for, but also can be standard and cross-compatible across all operating systems. Thus, we want the documents to encompass API principles and concepts, but leave the semantics flexible and as an exercise to the reader. Perhaps in the examples, even give several options in different language styles, and show how code can be easily translated between the approaches.

Yes - and these principles (also in the spirit of the charter) should be based on the analysis of existing transports and the definition of a minimal set of services that TAPS systems should support. I made an effort to be reasonable in the minimum set that we’ve derived:
- avoid getting stuck in a corner (being tied to only one protocol)
- allow for one-sided deployment, with a fall-back to TCP or UDP ( (D)TLS TBD - I think that was a very reasonable request)
- not miss out on functionality that can never be offered unless it’s put in the API


> To be specific, I would imagine that whatever API examples we have in the various documents we write will not necessarily be part of any specific implementation. Rather, various implementations will conform to the principles and patterns of the API description. Apple's transport APIs would match it, NEAT's APIs would match it, Android APIs would match it, Windows APIs would match it, etc, etc.

I agree with all that.

To be clear, this is not me arguing for or against one specific API. I’m only keen on ensuring that the result matches the principles I used for the minset, as listed above (or, if folks disagree with them, we should discuss them).  I only want TAPS to be implementable, useful and deployable (where I think that allowing one-sided deployment is a big deal).

Cheers,
Michael