Subject: [Taps] open issues on -interface

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Mon, 16 Jul 2018 11:59:14 -0400

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-masked] 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