Make protocol-specific mappings in TAPS Implementation more rigorous #333
Conversation
There was a problem hiding this comment.
I think this is a good step forward.
This said, I think we should describe things focusing on the transport's API call to be made (in line with the spec - that's why we have RFCs 8303 and 8304) rather than protocol internals. E.g., rather than saying that Abort on a TCP connection transmits a RST, I think we should simply say that Abort calls ABORT.TCP [RFC 8303, Section 4.1].
I can take care of these things, later. I'd still like to focus more on the API doc at this time.
|
|
||
| - Unconnected. Unconnected protocols do not establish explicit state between endpoints, and do not perform a handshake during Connection establishment. | ||
| - Connected. Connected protocols establish state between endpoints, and perform a handshake during Connection establishment. The handshake may be 0-RTT to send data or resume a session, but bidirectional traffic is required to confirm connectedness. | ||
| - Multiplexing Connected. Multiplexing Connected protocols share properties with Connected protocols, but also explictly support opening multiple application-level flows. This means that they can support cloning new Connection objects without a new explicit handshake. |
There was a problem hiding this comment.
Did you want to write "Multiplexed Connected protocols share properties..." ? Else this seems grammatically wrong to me? (but maybe it's just me)
draft-ietf-taps-impl.md
Outdated
| API mappings for TCP are as follows: | ||
|
|
||
| Connection Object: | ||
| : TCP connections between two hosts maps directly to Connection objects. |
| : TCP can throw various errors during connection setup. Specifically, it is important to handle a RST being sent by the peer during the handshake. | ||
|
|
||
| ConnectionError: | ||
| : Once established, TCP throws errors whenever the connection is disconnected, such as due to receive a RST from the peer; or hitting a TCP retransmission timeout. |
There was a problem hiding this comment.
s/due to receive/due to receiving
|
I can also help with SCTP, which I would do in the same style that I suggest above (for TCP, in my example of "Abort") - also later. |
Starting to address #128
This is an early review, to check if we like the structure. I'd also like help filling out the SCTP section!