If we agree that "transport protocol" is undefined then "Transport Instance" should not use it?
then: > A Transport Instance is an arrangement of transport protocols, potentially > encapsulated, and configurations thereof that implement a Transport Service > Composition Could be > A Transport Instance defines an implementation of a Transport Service > Composition. (or something like that? Marie-Jose Montpetit, Ph.D. [email protected] @SocialTVMIT > On Nov 4, 2014, at 8:14 AM, Brian Trammell <[email protected]> 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? > > Cheers, > > Brian > > > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
