Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implementation should separate out protocol-specific bits #248

Closed
tfpauly opened this issue Nov 8, 2018 · 5 comments
Closed

Implementation should separate out protocol-specific bits #248

tfpauly opened this issue Nov 8, 2018 · 5 comments

Comments

@tfpauly
Copy link
Contributor

@tfpauly tfpauly commented Nov 8, 2018

Right now, there are protocol specific examples mixed into the generic flow description; then, later, there is a section that has some description for protocol specific considerations.

Possible re-organizations:

Per-protocol mappings for each API call + per-protocol specific options. This is a guide to each protocol, such as a section for UDP and how each call is implemented for UDP, and what options UDP offers specifically.

General discussion about Pre-Establishment, Establishment, Data Transfer, etc, that has less information about specific protocols.

Structure everything with the general topics (Pre-Establishment, Establishment, Data Transfer, etc), and have a rigorous list of each protocol's mappings at the end of each section. So, for Establishment, we describe racing, etc; and then go through and explain what Initiate() does for TCP, UDP, UDP Lite, QUIC, SCTP.

@tfpauly tfpauly self-assigned this Nov 8, 2018
@JonathanLennox
Copy link

@JonathanLennox JonathanLennox commented Nov 14, 2018

I'd go further and say that protocol-specific stuff need to be split out into a separate document.

Protocol-specific mappings should be defined in a standards-track document, whereas most of the Implementation draft should be Informational.

@mwelzl
Copy link
Contributor

@mwelzl mwelzl commented Nov 15, 2018

@JonathanLennox - maybe ... I don't disagree with your proposal, but I do think that this should be a discussion for a larger group. Maybe the right strategy, for now, is to reorganize along Tommy's proposed method #1 or #2 (not sure myself which one is better), and then later take text out as you propose if this is the consensus. Make sense?

@JonathanLennox
Copy link

@JonathanLennox JonathanLennox commented Nov 15, 2018

Agreed -- this would need consensus of the WG, not just a GitHub issue discussion. Separating out the text to start, so it's clear what would end up in a separate document, would be a good first step.

@csperkins
Copy link
Contributor

@csperkins csperkins commented Nov 15, 2018

I'd tend to lean towards option 2, but I suspect we won't know for sure if it works until someone tries to implement the changes. I'd prefer not to introduce more drafts unless we absolutely have to.

@tfpauly
Copy link
Contributor Author

@tfpauly tfpauly commented Oct 28, 2019

I think this is covered well by #352

@tfpauly tfpauly closed this Oct 28, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants