> On 28. mai 2015, at 20.18, Joe Touch <to...@isi.edu> wrote: > > > > On 5/28/2015 11:05 AM, Mirja Kühlewind wrote: >> Hi Joe, >> >> here is where the confusion comes from: this doc is not about APIs, >> it’s about transport services, or to say it even more concrete, >> transport services components and features. > > Such services are either inherent to the transport (e.g., in-order, > reliable delivery) or exposed as a control to the user (by the API). > > I.e., APIs are necessary but not sufficient to describe transport services.
Agreed. Things that are in the APIs are what the document calls "transport service features", whereas what you here call "inherent services" is what the document calls "transport protocol components". I think it's a bit unfortunate that the API descriptions look very different in style from the list of components. Maybe a line could be drawn between: "transport service features" (components that are exposed to the application) ... and here come all the things found in today's (not tomorrow's!) APIs, as defined by the specs alone, not implementations and "transport protocol components" ... which is all the rest. I'm thinking of just a way of splitting the component lists, just to say "the following ones are exposed in the API today". >> We do have a section on >> interfaces for each protocol but that just an add-on which might or >> might not be useful to have in this document, but the core of the >> document is to describe the components that are currently implemented >> independent of the current provided (app-layer) interface and then add >> some discuss of which of these components are useful to expose to the >> app as transport services feature (and which level of detail/degree of >> decision freedom for each feature). > > But then isn't it critical to also know what's already exposed, e.g., in > the existing API? I think so - and the document tries to say that, by describing APIs. Doing it like I propose above could add clarity. Cheers, Michael _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
