Hi, > On Nov 5, 2017, at 10:21 PM, Tommy Pauly <tpa...@apple.com> 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
_______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
