jiebi/TextFlow huggingface dataset:
Original text:
consider as members of the Origin Set (set) for the connection it occurs within.  The ORIGIN frame type is 0xb (decimal 11). The ORIGIN frame's payload contains the following fields, sets of

Reviewer comments:
Relax DNS requirements when ORIGIN is received Change the initial origin set to just SNI
wait - no. You wouldn't send the alternative in the ORIGIN frame, you would send the origin that you are the alternative for, right? that would make sense - if you want to use an alternative you can't rely on the SNI default.
this is indeed looking goodminor nitsThis is looking good.

Revised text:
consider as members of the Origin Set (set) for the connection it occurs within. <ins> 2.1. </ins> The ORIGIN frame type is 0xb (decimal 11). The ORIGIN frame's payload contains the following fields, sets of
Original text:
This document introduces no new security considerations beyond those discussed in RFC8878.  5. 5.1.

Reviewer comments:
Fixes URL
NAME could you take a look?
Comment by NAME This is rather unimportant, but I just wanted to mention it in case the authors find it useful. Feel free to ignore. The document states that there are no new security considerations, but that's perhaps not quite true. I think it might be useful to call out that an implementation cannot rely on its peer behaving correctly, so implementers will have to take into account they may still receive oversized frames from misbehaving clients. This is arguably no different from the situation today, so it can be argued that the current considerations are accurate. I just thought it might be useful to call it out so some engineer doesn't remove validation checks since the other side is supposed to behave now. Just because we have standards, doesn't mean that everyone complies.
RFC8878 says in its security considerations: Perhaps we could add something like: "Decoders still need to take into account that they can receive oversized frames that do not follow the window size limit specified in this document and fail decoding when such invalid frames are received." NAME Thoughts?
We could do something explicit like that, yeah. But I'm partial to just broadening the existing statement a little: This seems sufficient to me because this issue is called out explicitly in para 4 there (URL). What do you think, NAME NAME
Don't have strong opinions, but I think maybe adding a sentence explicitly about the window size limit is good, given the document is specifically about enforcing the window size limit. This will ensure nobody misses it even if they don't click through the reference to RFC8878.

Revised text:
This document introduces no new security considerations beyond those discussed in RFC8878. <ins> Note that decoders still need to take into account that they can receive oversized frames that do not follow the window size limit specified in this document and fail decoding when such invalid frames are received. </ins> 5. 5.1.
Original text:
header field as a set-cookie-string (defined below). NOTE: The algorithm below is more permissive than the grammar in <del> sane-set-cookie.  For example, the algorithm strips leading and trailing whitespace from the cookie name and value (but maintains internal whitespace), whereas the grammar in sane-set-cookie forbids whitespace in these positions.  In addition, the algorithm below accommodates some characters that are not cookie-octets according to the grammar in sane-set-cookie.  User agents use this algorithm so as </del>  to interoperate with servers that do not follow the recommendations in sane-profile.

Reviewer comments:
This is a partial revert of 5469d51 from PR
Talked with NAME a moment ago. I think there are some additional changes that will be necessary, but I don't object to the idea of this revert. Seems like a mistake in the original PR.
Happy to amend the PR if you can give me an idea of what additional changes are required.
I wrote up a change that should cover all the points we want to make. Namely, we still want UAs to accept that larger character set while encouraging server to use the more limited character set.
This looks reasonable to me, thanks to you both.

Revised text:
header field as a set-cookie-string (defined below). NOTE: The algorithm below is more permissive than the grammar in  <ins> sane-set-cookie.  For example, the algorithm allows cookie-name to be comprised of cookie-octets instead of being a token as specified in sane-set-cookie and the algorithm accommodates some characters that are not cookie-octets according to the grammar in sane-set-cookie. In addition, the algorithm below also strips leading and trailing whitespace from the cookie name and value (but maintains internal whitespace), whereas the grammar in sane-set-cookie forbids whitespace in these positions.  User agents use this algorithm so as </ins> to interoperate with servers that do not follow the recommendations in sane-profile.
Original text:
by the user (e.g. a force reload). The immutable extension only applies during the freshness lifetime of <del> the response.  Stale responses SHOULD be revalidated as they normally would be in the absence of immutable. </del>  <del> The immutable extension takes no arguments and if any arguments are present they have no meaning.  Multiple instances of the immutable extension are equivalent to one instance.  The presence of an immutable Cache-Control extension in a request has no effect. </del>  2.1.

Reviewer comments:
Editorial stuff, mostly line wrapping and adjusting terminology. Happy to chat through it if you like.
thanks for this

Revised text:
by the user (e.g. a force reload). The immutable extension only applies during the freshness lifetime of  <ins> the stored response.  Stale responses SHOULD be revalidated as they normally would be in the absence of immutable. </ins>  <ins> The immutable extension takes no arguments.  If any arguments are present, they have no meaning, and MUST be ignored.  Multiple instances of the immutable extension are equivalent to one instance. The presence of an immutable Cache-Control extension in a request has no effect. </ins> 2.1.
Original text:
corruption incidents.  These incidents include cache poisoning attacks.  Three mechanisms are suggested for mitigation of this risk: <del> Clients should ignore immutable for resources that are not part of an authenticated context such as HTTPS.  Authenticated resources are less vulnerable to cache poisoning. </del>  <del> User-Agents often provide two different refresh mechanismss: reload and some form of force-reload.  The latter is used to rectify interrupted loads and other corruption.  These reloads, typically indicated through no-cache request attributes, should ignore immutable as well. </del>  <del> Clients should ignore immutable for resources that do not provide </del>  a strong indication that the stored response size is the correct response size such as responses delimited by connection close.

Reviewer comments:
Editorial stuff, mostly line wrapping and adjusting terminology. Happy to chat through it if you like.
thanks for this

Revised text:
corruption incidents.  These incidents include cache poisoning attacks.  Three mechanisms are suggested for mitigation of this risk:  <ins> Clients SHOULD ignore immutable from resources that are not part of an authenticated context such as HTTPS.  Authenticated resources are less vulnerable to cache poisoning. </ins>  <ins> User-Agents often provide two different refresh mechanisms: reload and some form of force-reload.  The latter is used to rectify interrupted loads and other corruption.  These reloads, typically indicated through no-cache request attributes, SHOULD ignore immutable as well. </ins>  <ins> Clients SHOULD ignore immutable for resources that do not provide </ins> a strong indication that the stored response size is the correct response size such as responses delimited by connection close.
Original text:
Let URL be the URL of the dictionary request. Let PATTERN be an instance of the URLPattern class constructed by <del> setting input=MATCH, and baseURL=URL (see URLPATTERN-CLASS). </del>  If the hasRegExpGroups attribute of PATTERN is TRUE then return <del> FALSE (see URLPATTERN-REGEXP). </del>  Return TRUE.

Reviewer comments:
This makes it clearer what standard is being depended on, while still deep-linking to the right section of that standard. This generates citations like "see of ]". The "RequestDestination" part is free text in the attribute. I don't see a way to change the "Part" text. We can use the to rearrange it to "see ], )" if y'all prefer.
Great, thanks for the PR. It's a lot cleaner than a bunch of independent references.
NAME just filed, thanks. URL URL
NAME have you asked the WHATWG folks for stable anchors to those sections? See URL for details of how to do that.

Revised text:
Let URL be the URL of the dictionary request. Let PATTERN be an instance of the URLPattern class constructed by  <ins> setting input=MATCH, and baseURL=URL (see URLPATTERN). </ins> If the hasRegExpGroups attribute of PATTERN is TRUE then return  <ins> FALSE (see URLPATTERN). </ins> Return TRUE.
Original text:
The "match-dest" value of the Use-As-Dictionary header is an Inner List of String values that provides a list of Fetch request <del> destinations for the dictionary to match (see REQUEST-DESTINATION). </del>  An empty list for "match-dest" MUST match all destinations.

Reviewer comments:
This makes it clearer what standard is being depended on, while still deep-linking to the right section of that standard. This generates citations like "see of ]". The "RequestDestination" part is free text in the attribute. I don't see a way to change the "Part" text. We can use the to rearrange it to "see ], )" if y'all prefer.
Great, thanks for the PR. It's a lot cleaner than a bunch of independent references.
NAME just filed, thanks. URL URL
NAME have you asked the WHATWG folks for stable anchors to those sections? See URL for details of how to do that.

Revised text:
The "match-dest" value of the Use-As-Dictionary header is an Inner List of String values that provides a list of Fetch request  <ins> destinations for the dictionary to match (see FETCH). </ins> An empty list for "match-dest" MUST match all destinations.
Original text:
Let MATCH be the value of "match" for the given dictionary. Let PATTERN be an instance of the URLPattern class constructed by <del> setting input=MATCH, and baseURL=BASEURL (see URLPATTERN-CLASS). </del>  Return the result of running the "test" method of PATTERN with input=URL which will check for a match between the request URL and <del> the supplied "match" URL Pattern (see URLPATTERN-TEST). </del>  2.2.3.

Reviewer comments:
This makes it clearer what standard is being depended on, while still deep-linking to the right section of that standard. This generates citations like "see of ]". The "RequestDestination" part is free text in the attribute. I don't see a way to change the "Part" text. We can use the to rearrange it to "see ], )" if y'all prefer.
Great, thanks for the PR. It's a lot cleaner than a bunch of independent references.
NAME just filed, thanks. URL URL
NAME have you asked the WHATWG folks for stable anchors to those sections? See URL for details of how to do that.

Revised text:
Let MATCH be the value of "match" for the given dictionary. Let PATTERN be an instance of the URLPattern class constructed by  <ins> setting input=MATCH, and baseURL=BASEURL (see URLPATTERN). </ins> Return the result of running the "test" method of PATTERN with input=URL which will check for a match between the request URL and  <ins> the supplied "match" URL Pattern (see URLPATTERN). </ins> 2.2.3.
Original text:
In browser terms, that means that both are either same-origin to the context they are being fetched from or that the response is cross- <del> origin and passes the CORS check (see CORS-CHECK). </del>  9.3.3.

Reviewer comments:
This makes it clearer what standard is being depended on, while still deep-linking to the right section of that standard. This generates citations like "see of ]". The "RequestDestination" part is free text in the attribute. I don't see a way to change the "Part" text. We can use the to rearrange it to "see ], )" if y'all prefer.
Great, thanks for the PR. It's a lot cleaner than a bunch of independent references.
NAME just filed, thanks. URL URL
NAME have you asked the WHATWG folks for stable anchors to those sections? See URL for details of how to do that.

Revised text:
In browser terms, that means that both are either same-origin to the context they are being fetched from or that the response is cross-  <ins> origin and passes the CORS check (see FETCH). </ins> 9.3.3.
Original text:
The terms Byte Sequence, Item, String, Token, Integer, and Boolean are imported from STRUCTURED-FIELDS. <del> The terms client and server are from HTTP. </del>  3.

Reviewer comments:
adds more used definitions from HTTP.
representation metadata, content, ... in Conventions and Definitions.

Revised text:
The terms Byte Sequence, Item, String, Token, Integer, and Boolean are imported from STRUCTURED-FIELDS.  <ins> The terms "representation", "representation data", "representation metadata", "content", "client" and "server" are from HTTP. </ins> 3.
Original text:
13. <del> A message might have a content coding, indicated by the "Content- Encoding" header field, and/or a transfer coding, indicated by the "Transfer-Encoding" header field (RFC9112), applied, which modify the representation of uploaded data in a message.  For correct interoperability, the client and server must share the same logic when counting bytes for the upload offset.  From the client's perspective, the offset is counted after content coding but before transfer coding is applied.  From the server's perspective, the offset is counted after the content's transfer coding is reversed but before the content coding is reversed. </del>  14.  The integrity of an entire upload or individual upload requests can be verifying using digests from DIGEST-FIELDS.

Reviewer comments:
splits C-E and T-E sections clarifications quoted from HTTP and MESSAGING link to DIGEST-FIELDS appendix This PR contains some quotes from HTTP and MESSAGING. While they can be redundant, the previous wording made me think that they were not.
Transfer-Encoding does not affect the selected representation data, see URL Since it only apply to MESSAGING, it should be probably decoupled from a section addressing representation metadata (e.g., content codings): URL
Thank you very much!

Revised text:
13.  <ins> Since the codings listed in "Content-Encoding" are a characteristic of the representation (see HTTP), both the client and the server always compute the upload offset on the content coded data (that is, the representation data).  Moreover, the content codings are retained throughout the entire upload, meaning thats that the server is not required to decode the representation data to support resumable uploads.  See DIGEST-FIELDS for more information. </ins> 14. <ins> Unlike "Content-Encoding" (see HTTP), "Transfer-Encoding" (see RFC9112) is a property of the message, not of the representation. Moreover. transfer codings can be applied in transit (e.g., by proxies).  This means that a client does not have to consider the transfer codings to compute the upload offset, while a server is responsible for transfer decoding the message before computing the upload offset.  Please note that the "Content-Length" header field cannot be used in conjunction with the "Transfer-Encoding" header field. 15. </ins> The integrity of an entire upload or individual upload requests can be verifying using digests from DIGEST-FIELDS.
Original text:
resource.  This way, the integrity of an individual request can be protected. <del> 15. </del>  The server might process the uploaded data and make its results available in another resource during or after the upload.  This

Reviewer comments:
splits C-E and T-E sections clarifications quoted from HTTP and MESSAGING link to DIGEST-FIELDS appendix This PR contains some quotes from HTTP and MESSAGING. While they can be redundant, the previous wording made me think that they were not.
Transfer-Encoding does not affect the selected representation data, see URL Since it only apply to MESSAGING, it should be probably decoupled from a section addressing representation metadata (e.g., content codings): URL
Thank you very much!

Revised text:
resource.  This way, the integrity of an individual request can be protected.  <ins> 16. </ins> The server might process the uploaded data and make its results available in another resource during or after the upload.  This
Original text:
an upload.  For example, a subsequent resource could allow the client to fetch information extracted from the uploaded data. <del> 16. </del>  The upload resource URL is the identifier used for modifying the upload.  Without further protection of this URL, an attacker may

Reviewer comments:
splits C-E and T-E sections clarifications quoted from HTTP and MESSAGING link to DIGEST-FIELDS appendix This PR contains some quotes from HTTP and MESSAGING. While they can be redundant, the previous wording made me think that they were not.
Transfer-Encoding does not affect the selected representation data, see URL Since it only apply to MESSAGING, it should be probably decoupled from a section addressing representation metadata (e.g., content codings): URL
Thank you very much!

Revised text:
an upload.  For example, a subsequent resource could allow the client to fetch information extracted from the uploaded data.  <ins> 17. </ins> The upload resource URL is the identifier used for modifying the upload.  Without further protection of this URL, an attacker may
Original text:
allowed to have, and restricting the length of time an upload resource can exist. <del> 17. </del>  IANA is asked to register the following entries in the "Hypertext Transfer Protocol (HTTP) Field Name Registry":

Reviewer comments:
splits C-E and T-E sections clarifications quoted from HTTP and MESSAGING link to DIGEST-FIELDS appendix This PR contains some quotes from HTTP and MESSAGING. While they can be redundant, the previous wording made me think that they were not.
Transfer-Encoding does not affect the selected representation data, see URL Since it only apply to MESSAGING, it should be probably decoupled from a section addressing representation metadata (e.g., content codings): URL
Thank you very much!

Revised text:
allowed to have, and restricting the length of time an upload resource can exist.  <ins> 18. </ins> IANA is asked to register the following entries in the "Hypertext Transfer Protocol (HTTP) Field Name Registry":
Original text:
new connection to one or more alternative services immediately, or simultaneously with subsequent requests on the same connection. <del> To reduce the ability of servers to track individual clients over time (see tracking), an alternative service indication sent by a client include any alternative service information other than the protocol, host and port. </del> When using HTTP/2 (HTTP2), clients instead send an ALTSVC frame.  A single ALTSVC frame can be sent for

Reviewer comments:
Mark moved this note in his edits, but I think that we don't need it any more at all. The security considerations will suffice.

Revised text:
new connection to one or more alternative services immediately, or simultaneously with subsequent requests on the same connection.  When using HTTP/2 (HTTP2), clients instead send an ALTSVC frame.  A single ALTSVC frame can be sent for
Original text:
The terms Byte Sequence, Item, String, Token, Integer, and Boolean are imported from STRUCTURED-FIELDS. <del> The terms client and server are from HTTP. </del>  3.

Reviewer comments:
The definition of upload creation requests allows the client to include the entire file, some file data or no data at all. While we provide this flexibility, we don't give guidance on when which approach is best suited. This PR adds this missing piece and explains how an optimistic client can attempt to upload the file in one request and how a careful client uses a separate request for creating the upload. In addition, it also mentions how to transparently upgrade to resumable uploads, which wasn't explained in detail before. Let me know if you have any feedback on this.
Are "Optimistic Upload Creation" and "Upgrading To Resumable Uploads" the exact same way? Maybe the 3rd way could be checking first before uploading?
The way they are described right now they are similar, yes. In theory, an optimistic upload creation can also be used where the client doesn't upload the entire file, but just a large part of it (think 500 MB of a 10 GB file). When upgrading a non-resumable request to a resumable upload, this act of division is not allowed. But I am not sure if we should go into that much detail here. If not, then we can merge these two sections. Upload limits are a good point! With the careful upload, the client also knows the limits before sending the first PATCH request. The optimistic client must be prepared to receive a 104 response with limits that it has to adapt to. We can mention that a careful client may also send an OPTIONS request before hand if it deems that necessary.
I think upload-limit can just be enforced on the server side. If it sends a 104 and a 5xx response, the client would automatically retry. We have deployed a client-side implementation that is not aware of the upload-limit header field.
Thanks for all of your comments! I updated the PR to put the section about upgrading to resumable uploads under the optimistic upload creation since they are similar. I also added a brief mention of Upload-Limit and shortened the text a bit. Let me know if you think the text needs more adjustments.
Just a minor nit. Otherwise I think this is a very good addition and agree with NAME that we should add some text with regards to the . Proposal for optimistic: The client needs to adapt to the header provided in the intermediate response and fail the request if the file is larger than the maximum allowed size. Proposal for Careful: The client can use the header provided in the to verify that the file is allowed to be uploaded before sending any data.Some editorial suggestions, but one big question: What is the material difference between the first and third strategy? Could these be the same strategy?

Revised text:
The terms Byte Sequence, Item, String, Token, Integer, and Boolean are imported from STRUCTURED-FIELDS.  <ins> The terms "representation", "representation data", "representation metadata", "content", "client" and "server" are from HTTP. </ins> 3.