On 4. nov. 2014, at 14:14, Brian Trammell wrote: > Greetings, all, > > As promised, here's an initial suggestion for terminology in > draft-fairhurst-taps-transports, compatible with but elaborating on the > minimal terminology in the charter, which would we would propose applies to > all TAPS work derived from this document: > > > Transport Service: > An end-to-end facility provided by the transport layer that impacts the > design, operation, or deployment of the application using it. Example > Transport Services include reliable delivery of data, ordered delivery of > data, confidentiality of data with respect to in-path devices, or latency > guarantees for data transport. > > > Transport Service Composition: > A set of Transport Services taken together to meet the requirements of an > application for a given end-to-end interaction. Note that some potential sets > of Transport Services given transport service may preclude the simultaneous > use of other transport services for a given end-to-end interaction (e.g. > "reliable delivery" and "time-dependent expiry of unacknowledged messages" as > per SCTP-PR are mutually exclusive). An example of a Transport Service > Composition would be that provided by the BSD SOCK_STREAM socket type: > reliable, ordered, non-boundary-perserving, stream-oriented transport, with > limited out of band capability. > > > Transport Instance: > A Transport Instance is an arrangement of transport protocols, potentially > encapsulated, and configurations thereof that implement a Transport Service > Composition. A given Transport Service Composition may be implemented by > multiple Instances (e.g., SOCK_STREAM can be implemented atop TCP, SCTP, or > SCTP over UDP). > > > Application: > In this and subsequent documents, an Application is defined as an entity that > uses the transport layer to interact with a remote Application according to > some set of requirements which can be met by Transport Services. > > > Here I'm pointedly leaving "transport protocol" undefined, mainly so as to > sidestep marginally productive conversations about how many transport > protools SCTP over DTLS over UDP is. The exact implementation of a Transport > Service Composition would appear to be a matter for our third deliverable > anyway. :) > > It's not perfect but it's a start. Thoughts?
We can and will probably debate this to death, but before that happens I'll say: I think this is a very good starting point, thanks! Cheers, Michael _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
