Hi, all, In advance of tomorrow's meeting, here are a few changes and issues we'd like to discuss:
Reorganization of Properties ---------------------------- See [the PR][1]. We've reorganized the properties (selection, protocol, send, etc) into a single section. We (the authors) are sure this is a better editorial direction than what we had before, but we're not sure that the organization we have is correct. We'll spend a little time during our slot on this point Partial Sends and Receives -------------------------- See [the PR][2]. We've reworked how partial messages work, introducing a message context by which sends on partial messages can be grouped. Idempotent Send --------------- See discussion on [the stale PR][3] and on the [issue][4]. This is bit of a bikeshed (see also API designs for TCP Fast Open); the main problem is in trading off API complexity versus control about when sends happen. There are a few possibilities enumerated on the slides tomorrow: - Option 1: as in #124, hold any data sent until an explicit Connection.Start() call. - Send() before Start() is 0RTT if idempotent. - Start() is always required, even if you don't know what 0RTT is. - Option 3: 0RTT behavior is implied by 0RTT selection properties. When Initiate() is called and selects a 0RTT-capable stack, the actual initiation is delayed slightly to wait for the first Send(), which is 0RTT if idempotent. - Note this makes racing 0RTT-capable and 0RTT-incapable stacks impossible. - Option 3.5: as 3, but with a Preconnection.InitiateNow() to override the wait-for-Send() behavior (e.g. for application protocols where the server sends first) - Option 5: Add Preconnection.Send(), which initiates with 0RTT data. Other Open Issues ----------------- The following issues are still open, which we don't cover in the -interface talk tomorrow. Please discuss these either on the [email protected] list, or in the GitHub issue tracker itself: - Explicit state storage in architecture and API? [#45][5] - Be explicit about when name resolution occurs [#102][6] - Evaluate the applicability of ยง6.3 to ICE-like protocols [#103][7] - Multicast sources and sinks [#150][8] - Add delivered event? [#151][9] - Privacy considerations [#177][10] - What is the point of the closing state? [#182][11] - Clones and Entanglement [#202][12] - Max message and transmission size [#203][13] Cheers, Brian [1]: https://github.com/taps-api/drafts/pull/201 [2]: https://github.com/taps-api/drafts/pull/200 [3]: https://github.com/taps-api/drafts/pull/124 [4]: https://github.com/taps-api/drafts/issues/112 [5]: https://github.com/taps-api/drafts/issues/45 [6]: https://github.com/taps-api/drafts/issues/102 [7]: https://github.com/taps-api/drafts/issues/103 [8]: https://github.com/taps-api/drafts/issues/150 [9]: https://github.com/taps-api/drafts/issues/151 [10]: https://github.com/taps-api/drafts/issues/177 [11]: https://github.com/taps-api/drafts/issues/151 [12]: https://github.com/taps-api/drafts/issues/202 [13]: https://github.com/taps-api/drafts/issues/203
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
