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

Add protocols constructor argument to WebTransport + protocol read arg #598

Merged
merged 11 commits into from
Sep 17, 2024

Conversation

jan-ivar
Copy link
Member

@jan-ivar jan-ivar commented Apr 8, 2024

Fixes #536. Right now this seems only defined for HTTP/3, so that's what I went with. Is this what we want?


Preview | Diff

@jan-ivar
Copy link
Member Author

jan-ivar commented Apr 9, 2024

Meeting:

  • overall reaction seems positive
  • s/protocols/subprotocols/
  • Make sure to preserve order in header field list.

@jan-ivar jan-ivar changed the title Add protocols constructor argument to WebTransport Add subprotocols constructor argument to WebTransport Apr 11, 2024
index.bs Outdated Show resolved Hide resolved
index.bs Outdated Show resolved Hide resolved
index.bs Outdated Show resolved Hide resolved
index.bs Show resolved Hide resolved
index.bs Outdated
[Section 4.1](https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-overview-06#section-4.1-2.2.1),
with using |origin|, [=ASCII serialization of an origin|serialized=] and [=isomorphic encoded=],
as the [:Origin:] header of the request.
When establishing a session, the client MUST NOT provide any [=credentials=].
The resulting underlying transport stream is referred to as the session's <dfn>CONNECT stream</dfn>.
Additionally, if the [=underlying connection=] is using HTTP/3 and the |protocols| array is non-empty,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I saw that you mentioned only specifying this for HTTP/3 as it's only defined in that IETF doc, but I'm not sure if making this HTTP/3 specific is what we want. We should probably file an issue to get it added to the HTTP/2 or overview doc as well, and keep the language here as protocol-agnostic as possible.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree this should be the goal. @nidhijaju or @vasilvv can you open this issue? But in the meantime, can we iterate here by merging what we have, and come back and fix this when it's available in the overview doc?

jan-ivar and others added 2 commits April 23, 2024 14:50
Co-authored-by: Nidhi Jaju <41948741+nidhijaju@users.noreply.github.com>
@jan-ivar
Copy link
Member Author

Meeting:

  • @nidhijaju to open issue on HTTP/2 and overview doc
  • then update this PR to reference overview doc and merge.

@jan-ivar
Copy link
Member Author

jan-ivar commented Jun 4, 2024

Meeting:

  • protocols or subprotocols?

@wilaw
Copy link
Contributor

wilaw commented Jun 5, 2024

Could we call this "applicationProtocol"? This avoids overloading the multiple references to internet protocols (UDP, QUIC, WebTransport) and instead refers to the protocol we wish to describe, which is defined completely by the application using the WebTransport connection.

@jan-ivar
Copy link
Member Author

Meeting:

  • Two votes (plus martin) for protocols instead of subprotocols
  • or applicationProtocols
  • If we change it we should change the IETF specs to match.
  • Our spec says "protocol" a lot to refer to the underlying/IETF parts
  • Leave it subprotocols for now and ask the IETF if they want to change it to protocols

@jan-ivar jan-ivar changed the title Add subprotocols constructor argument to WebTransport Add protocols constructor argument to WebTransport + protocol read arg Jul 30, 2024
@jan-ivar
Copy link
Member Author

IETF preferred "protocol" by overwhelming margin in a poll (19 protocol, 3 subprotocol, 9 applicationLevelProtocol)

@wilaw
Copy link
Contributor

wilaw commented Aug 21, 2024

Note ietf-wg-webtrans/draft-ietf-webtrans-overview#15 (comment), calling for harmonization around the use of "protocol".

@jan-ivar
Copy link
Member Author

jan-ivar commented Sep 9, 2024

The API is now "protocol" throughout, except prose still uses "subprotocol" to disambiguate it from its own § 3. Protocol concepts (HTTP3 does a similar thing).

@jan-ivar
Copy link
Member Author

s/subprotocol/protocol/ for variable names

Copy link
Member

@nidhijaju nidhijaju left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/subprotocol/protocol based on last meeting

index.bs Outdated Show resolved Hide resolved
index.bs Outdated Show resolved Hide resolved
index.bs Outdated Show resolved Hide resolved
index.bs Outdated Show resolved Hide resolved
index.bs Outdated Show resolved Hide resolved
index.bs Outdated Show resolved Hide resolved
index.bs Outdated Show resolved Hide resolved
index.bs Outdated Show resolved Hide resolved
index.bs Outdated Show resolved Hide resolved
index.bs Outdated Show resolved Hide resolved
index.bs Outdated Show resolved Hide resolved
@nidhijaju nidhijaju merged commit 11009de into w3c:main Sep 17, 2024
2 checks passed
github-actions bot added a commit that referenced this pull request Sep 17, 2024
SHA: 11009de
Reason: push, by nidhijaju

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Reconsider whether we need sub-protocol negotiation
4 participants