An issue we discussed today in the TAPS meeting was whether or not we should add a concept of "profiles" to the Transport Services APIs. An example of a profile is a "reliable, secure, in-order stream"; or "unreliable datagrams". Another way to think of these profiles are as convenient ways to initialize common parameters.
One option is described in this PR: https://github.com/ietf-tapswg/api-drafts/pull/328 To help discern the working group's position, I'll try to distill the high-level options here: 1. Add Profiles as a top-level API document concept that modifies how transport properties and/or preconnections are created. (This is PR #328.) 2. Mention in the API document that specific API implementations may expose conveniences and profiles (presumably as a way to initialize preconnections), but do not modify the API or specify an abstract symbol for profiles. 3. Do not mention profiles at all in the API document, but mention something in the implementation document. Let's use this thread to discuss how to converge! Thanks, Tommy _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
