jiebi/TextFlow huggingface dataset:
Original text:
that requested the creation of the session. Upon receiving an extended CONNECT request with a ":protocol" field <del> set to "webtransport", the HTTP server can check if it has a WebTransport server associated with the specified ":authority" and ":path" values.  If it does not, it SHOULD reply with status code 404 (Section 6.5.4,RFC7231).  If it does, it MAY accept the session by replying with status code 200.  The WebTransport server MUST verify the "Origin" header to ensure that the specified origin is allowed to access the server in question. </del>  From the client's perspective, a WebTransport session is established when the client receives a 200 response.  From the server's

Reviewer comments:
The resource does. It's a fine distinction, but an important one.
An excellent distinction, thank you :)

Revised text:
that requested the creation of the session. Upon receiving an extended CONNECT request with a ":protocol" field  <ins> set to "webtransport", the HTTP server checks if the identified resource supports WebTransport sessions.  If the resource does not, the server SHOULD reply with status code 404 (Section 6.5.4 of RFC7231).  To accept a WebTransport session the server replies with 2xx status code.  Before accepting a session, a server MUST ensure that it authorizes use of the session by the site identified in the "Origin" header. </ins> From the client's perspective, a WebTransport session is established when the client receives a 200 response.  From the server's
Original text:
frames and can also be used to provide protection against traffic analysis or for other reasons. <del> The padding extends to the end of the WT_PADDING frame and that many bytes can be discarded by the recipient. </del>  5.2.

Reviewer comments:
The frame format depends on having a definition. I've also made a requirement for this to be zero values. Do we need to say that recipients MUST NOT validate this or that they MAY opt to avoid validation.

Revised text:
frames and can also be used to provide protection against traffic analysis or for other reasons.  <ins> The Padding field MUST be set to an all-zero sequence of bytes of any length as specified by the Length field. </ins> 5.2.
Original text:
4.2. <del> WebTransport streams have states that mirror the states of QUIC streams (Section 3 of RFC9000) as closely as possible to aid in ease of implementation. </del>  Because WebTransport does not provide an acknowledgement mechanism for WebTransport frames, it relies on the underlying transport's in

Reviewer comments:
Attempting to be minimal and just point at RFC9000.
Do we talk about the stream ID numbering space here? It could be completely scoped to the WebTransport session, which is different than H3. Originally posted by NAME in URL
Thanks for doing that.

Revised text:
4.2.  <ins> WebTransport streams have identifiers and states that mirror the identifiers ((Section 2.1 of RFC9000)) and states (Section 3 of RFC9000) of QUIC streams as closely as possible to aid in ease of implementation. WebTransport streams are identified by a numeric value, or stream ID. Stream IDs are only meaningful within the WebTransport session in which they were created.  They share the same semantics as QUIC stream IDs, with client initiated streams having even-numbered stream IDs and server-initiated streams having odd-numbered stream IDs. Similarly, they can be bidirectional or unidirectional, indicated by the second least significant bit of the stream ID. </ins> Because WebTransport does not provide an acknowledgement mechanism for WebTransport frames, it relies on the underlying transport's in
Original text:
<del> WebTransport using HTTP/2 </del>  draft-ietf-webtrans-http2-latest Abstract

Reviewer comments:
woohoo, making real progress!
The HTTP/2 draft uses "using". This one uses "over". This looks bad in my (sidebar) browser tabs.
HTTP/3 draft describes itself as "a mapping of HTTP semantics over QUIC", so I moderately prefer "over" based on that precedent (and well, the fact that all drafts that I wrote use "over").

Revised text:
 <ins> WebTransport over HTTP/2 </ins> draft-ietf-webtrans-http2-latest Abstract
Original text:
WebTransport server MUST verify the "Origin" header to ensure that the specified origin is allowed to access the server in question. <del> From the client's perspective, a WebTransport session is established when the client receives a 200 response.  From the server's perspective, a session is established once it sends a 200 response. Both endpoints MUST NOT send any WebTransport capsules on a given session before that session is established. </del>  3.4.

Reviewer comments:
I don’t agree with this. A client can send a request body without awaiting a response. Always. Originally posted by NAME in URL
Are those concerns orthogonal? I don't believe there is anything in the text that says you cannot send data before the session is established.
I don't think that this is necessary, or helpful. And I don't think that you can police it either. It is true that a client cannot initiate any streams before the session is created (because the stream limits start at zero), but I see no reason not to pipeline WTDATAGRAM or MAX frames if the h2-level flow control permits it. The MAX_ frames are particularly useful in that they allow the server to send real data immediately, cutting a round trip off.
Given that the limits start at zero (do we state that explicitly anywhere?), and we're not including any sort of SETTINGS/default settings, it definitely seems like we ought to be able to just start spewing frames into the CONNECT stream, which are discarded if the CONNECT request is rejected.
Chair: discussed at 113, consensus in room to allow sending any frames allowed by flow control
Text in H3 here: URL, can probably make it look similar for H2.

Revised text:
WebTransport server MUST verify the "Origin" header to ensure that the specified origin is allowed to access the server in question.  <ins> A WebTransport session is established when the server sends a 200 response.  A server generates that response from the request header, not from the contents of the request.  To enable clients to resend data when attempting to re-establish a session that was rejected by a server, a server MUST NOT process any capsules on the request stream unless it accepts the WebTransport session. A client MAY optimistically send any WebTransport capsules associated with a CONNECT request, without waiting for a response, to the extent allowed by flow control.  This can reduce latency for data sent by a client at the start of a WebTransport session.  For example, a client might choose to send datagrams or flow control updates before receiving any response from the server. </ins> 3.4.
Original text:
Upon receiving an extended CONNECT request with a ":protocol" field set to "webtransport", the HTTP server checks if the identified resource supports WebTransport sessions.  If the resource does not, <del> the server SHOULD reply with status code 404 (Section 6.5.4 of RFC7231).  If it does, it MAY accept the session by replying with a </del>  2xx series status code, as defined in Section 15.3 of SEMANTICS.  The WebTransport server MUST verify the "Origin" header to ensure that the specified origin is allowed to access the server in question.

Reviewer comments:
Change 404 to 406 Not Acceptable
Current text: >Upon receiving an extended CONNECT request with a field set to , the HTTP server checks if the identified resource supports WebTransport sessions. If the resource does not, the server SHOULD reply with status code 404 ({{Section 6.5.4 of !RFC7231}}). If it does, it MAY accept the session by replying with a 2xx series status code, as defined in Section 15.3 of {{!SEMANTICS=I-D.ietf-httpbis-semantics}}. The WebTransport server MUST verify the header to ensure that the specified origin is allowed to access the server in question. Originally posted by NAME in URL
The corresponding text in HTTP/3 appears to be: This is correct, though I am not sure how necessary it is.
Discussed in editor's call: 406 sounds good

Revised text:
Upon receiving an extended CONNECT request with a ":protocol" field set to "webtransport", the HTTP server checks if the identified resource supports WebTransport sessions.  If the resource does not,  <ins> the server SHOULD reply with status code 406 (Section 15.5.7 of RFC9110).  If it does, it MAY accept the session by replying with a </ins> 2xx series status code, as defined in Section 15.3 of SEMANTICS.  The WebTransport server MUST verify the "Origin" header to ensure that the specified origin is allowed to access the server in question.
Original text:
between other HTTP datagrams and can also be used to provide protection against traffic analysis or for other reasons.  The Padding field MUST be set to an all-zero sequence of bytes of any length as specified by the Length field.

Reviewer comments:
This is not a bad thing. In fact it's a deliberate choice. It might be worth noting the redundancy so people don't think we're a bit dim. We might also add that this padding is less tunable than h2 padding.
Do we actually need WT_PADDING, and if so, does it need to be in this document?
NAME do you remember why we deliberately chose to have this separate padding instead of just relying on the h2 padding?
I don't recall the specifics 18 months on. However, the basic problems are invariant. The different padding schemes offer different capabilities due to a bunch of different design trade-offs and inherent properties of each approach. h2 padding only applies to one hop, but WTPADDING would traverse intermediaries (because it is application data as far as they are concerned). Consequently, you might want to use WTPADDING if your goal is to protect against leaks on remote hops. This is because each operates on a different scope. WTPADDING doesn't get to be smaller than the minimum capsule size, but h2 padding can be any size. That means that a padding strategy is potentially more efficient in h2 as you need to include WTPADDING and its overheads. This is because the more padding integration in h2 is more complete, but also more complex. Finally, there are all the usual software engineering constraints. Maybe you have access to padding functions in your WT stack, but not the h2 stack.
Many thanks NAME Added a version of that to the padding section (noting that padding is a generic capsule being defined here, so others can use it even if not over HTTP/2).

Revised text:
between other HTTP datagrams and can also be used to provide protection against traffic analysis or for other reasons. <ins> Note that, when used with WebTransport over HTTP/2, the capsule exists alongside the ability to pad HTTP/2 frames (Section 10.7 of RFC9113).  HTTP/2 padding is hop-by-hop and can be modified by intermediaries, while the capsule traverses intermedaries.  The capsule is also constrained to be no smaller than the capsule overhead itself. </ins> The Padding field MUST be set to an all-zero sequence of bytes of any length as specified by the Length field.
Original text:
WebTransport server MUST verify the "Origin" header to ensure that the specified origin is allowed to access the server in question. <del> A WebTransport session is established when the server sends a 200 </del>  response.  A server generates that response from the request header, not from the contents of the request.  To enable clients to resend data when attempting to re-establish a session that was rejected by a

Reviewer comments:
The document currently mentions HTTP status code 200 explicitly, instead of following the usual convention of saying "any 2xx" status code. We already made this change in WebTransport over HTTP/3, we should do the same in this doc.
Ack, we're a bit mixed in the HTTP/2 document right now, will update so we're consistent everywhere.

Revised text:
WebTransport server MUST verify the "Origin" header to ensure that the specified origin is allowed to access the server in question.  <ins> A WebTransport session is established when the server sends a 2xx </ins> response.  A server generates that response from the request header, not from the contents of the request.  To enable clients to resend data when attempting to re-establish a session that was rejected by a
Original text:
10.1. <del> IANA is requested to add an extra column to the "TLS ExtensionType Values" registry to indicate whether an extension is only applicable to DTLS and to include this document as an additional reference for the registry. </del>  10.2. IANA is requested to allocate an entry to the existing "TLS ExtensionType Values" registry, for connection_id(TBD1) as described <del> in the table below. </del>  Note: The value "N" in the Recommended column is set because this extension is intended only for specific use cases.  This document

Reviewer comments:
Suggest a column name. Deprecate the old connection_id codepoint.
NAME
We currently have an early allocation of the TLS extensiontype codepoint 53 that was allocated on 2019-07-02. An implementation of the draft at that time will no longer interoperate with the current specification due to changes in how the MAC inputs and AAD are laid out. If we want to allocate a new extensiontype value for the new semantics, we should tell IANA that there is an existing early allocation and, e.g., that it should be left to expire (and what version of the draft to use as a reference until it does), with a new codepoint to be allocated in its stead. We also have the option to direct IANA that "once this document is approved for publication, the early allocation will be deprecated and the following assignment will be made".
I think we should take your last option.
See suggestion inline, though even as-is this is probably enough to cause the right things to happen at IANA and the RPC.

Revised text:
10.1.  <ins> IANA is requested to add an extra column named "DTLS-Only" to the "TLS ExtensionType Values" registry to indicate whether an extension is only applicable to DTLS and to include this document as an additional reference for the registry. </ins> 10.2. IANA is requested to allocate an entry to the existing "TLS ExtensionType Values" registry, for connection_id(TBD1) as described  <ins> in the table below.  Although the value 53 has been allocated by early allocation for a previous version of this document, it is incompatible with this document.  Once this document is approved for publication, the early allocation will be deprecated in favor of this assignment. </ins> Note: The value "N" in the Recommended column is set because this extension is intended only for specific use cases.  This document
Original text:
identifiers.  This can in turn ease parsing and connection lookup, for example by having the length in question be a compile-time constant.  Such implementations MUST still be able to send CIDs of <del> different length to other parties.  Implementations that want to use variable-length CIDs are responsible for constructing the CID in such a way that its length can be determined on reception.  Note that there is no CID length information included in the record itself. </del>  In DTLS 1.2, CIDs are exchanged at the beginning of the DTLS session only.  There is no dedicated "CID update" message that allows new

Reviewer comments:
Partly addresses
URL
Regarding: We could streamline that a bit: removing the affiliations (who knows which have become stale in the meantime?), and also Besides, is "task force" the right term? Would "QUIC CID design team" be a better designation? Robert Wilton has entered the following ballot position for draft-ietf-tls-dtls-connection-id-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to URL for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: URL COMMENT: Hi, I'm no DTLS expert, but I found the concepts/explanation in this document easy to follow. I was slightly confused by the requirement to encode the length in variable length CIDs, and had to read the relevant text a second time. As a suggestion, it might help if these two sentences were reworded the other way round: OLD: Implementations that want to use variable-length CIDs are responsible for constructing the CID in such a way that its length can be determined on reception. Note that there is no CID length information included in the record itself. NEW: Since the CID length information is not included in the record itself, implementations that want to use ... . One minor question. In the contributors, I noted that Jana is listed as being associated with Google, but it might be worth checking if that is still accurate. Regards. Rob

Revised text:
identifiers.  This can in turn ease parsing and connection lookup, for example by having the length in question be a compile-time constant.  Such implementations MUST still be able to send CIDs of  <ins> different length to other parties.  Since the CID length information is not included in the record itself, implementations that want to use variable-length CIDs are responsible for constructing the CID in such a way that its length can be determined on reception. </ins> In DTLS 1.2, CIDs are exchanged at the beginning of the DTLS session only.  There is no dedicated "CID update" message that allows new
Original text:
Because each party sends the value in the "connection_id" extension it wants to receive as a CID in encrypted records, it is possible for <del> an endpoint to use a globally constant length for such connection identifiers.  This can in turn ease parsing and connection lookup, for example by having the length in question be a compile-time constant.  Such implementations MUST still be able to send CIDs of different length to other parties.  Since the CID length information is not included in the record itself, implementations that want to use variable-length CIDs are responsible for constructing the CID in such a way that its length can be determined on reception. </del>  In DTLS 1.2, CIDs are exchanged at the beginning of the DTLS session only.  There is no dedicated "CID update" message that allows new

Reviewer comments:
attempt at addressing Warren's concern about the use of "globally"
You're right, the "globally" seems to be used in the sense of a "programming language", so the scope is a peer and the CID emitted by this peer for other peers to be used, when the other peers sends records to the emitting peer. Maybe we find a better term than "globally" to describe that.
maybe "sitewide"?

Revised text:
Because each party sends the value in the "connection_id" extension it wants to receive as a CID in encrypted records, it is possible for  <ins> an endpoint to use a deployment-specific constant length for such connection identifiers.  This can in turn ease parsing and connection lookup, for example by having the length in question be a compile- time constant.  Such implementations MUST still be able to send CIDs of different length to other parties.  Since the CID length information is not included in the record itself, implementations that want to use variable-length CIDs are responsible for constructing the CID in such a way that its length can be determined on reception. </ins> In DTLS 1.2, CIDs are exchanged at the beginning of the DTLS session only.  There is no dedicated "CID update" message that allows new
Original text:
records without knowing how long the Connection ID is. In order to allow a receiver to determine whether a record has CID or <del> not, connections which have negotiated this extension use new record types for all protected records. new-cid-content-types shows the record types to use: </del>  5. <del> The CID value, when present, is included in the MAC calculation for the DTLS record.  The MAC algorithm described in Section 4.1.2.1 of RFC6347 and Section 6.2.3.1 of RFC5246 is extended as follows: </del>  6.

Reviewer comments:
discussed in YUL. NAME
URL Still contains the content types removed in PR . alertwithcid(25) handshakewithcid(26) applicationdatawithcid(27) heartbeatwithcid(28) I guess, it should be updated towards PR ? tls12cid(25)
The PR can be found here: URL
The PR will fix it.
If you subscribe to the theory that DTLS has to mux with the realtime protocols, this takes a good slice of the remaining codepoints space. Though TLS has between 20 and 63, DTLS 1.3 takes 32-63 and the registration of 4 more would leave just 3: 29, 30, and 31. I submit that we might be better considering the TLS 1.3 record construction with a single codepoint. That would get us content type encryption and arbitrary padding as a secondary benefit. All for the modest cost of one octet.
If DTLS 1.3 used a demux prefix scheme like the one proposed , this should be no longer an issue.
Addressed in

Revised text:
records without knowing how long the Connection ID is. In order to allow a receiver to determine whether a record has CID or  <ins> not, connections which have negotiated this extension use a distinguished record type tls12_cid(25).  Use of this content type has the following two implications: The CID field is present The true content type is inside the encryption envelope, as described below. </ins> 5.  <ins> When CID is being used, the DTLSCompressed value is first wrapped along with the true content type and padding into a DTLSWrappedCompressed value prior to encryption.  The DTLSWrappedCompressed value is then encrypted. The value of DTLSCompressed.fragment The true content type. Padding, as defined in RFC8446. In addition, the CID value is included in the MAC calculation for the DTLS record as shown below.  The MAC algorithm described in Section 4.1.2.1 of RFC6347 and Section 6.2.3.1 of RFC5246 is extended as follows: </ins> 6.