jiebi/TextFlow huggingface dataset:
Original text:
The "type" value is optional and defaults to "raw". <del> 2.1.4. </del>  The "hashes" value of the Use-As-Dictionary header is a inner-list value that provides a list of supported hash algorithms in order of

Reviewer comments:
This switches the custom wildcard matching to use with regexp support disabled. URLPattern is being used by the service worker routing API's and is what the web side is standardizing on for anything that pattern-matches URLs. This splits the match pattern into explicit path and search (query param) components and forces the origin to be inherited from the dictionary request URL. Also included here is a new field for to allow for matching on request destinations. The biggest use case for that will be for allowing site-wide HTML dictionaries to do something like and for the dictionary to not be sent for every request across the site (images, etc). See issues , ,

Revised text:
The "type" value is optional and defaults to "raw".  <ins> 2.1.6. </ins> The "hashes" value of the Use-As-Dictionary header is a inner-list value that provides a list of supported hash algorithms in order of
Original text:
The "hashes" value is optional and defaults to (sha-256). <del> 2.1.5. </del>  <del> 2.1.5.1. </del>  A response that contained a response header: <del> Would specify matching any URL with a path prefix of /product/ on the same Origin as the original request, expiring as a dictionary in 7 days independent of the cache lifetime of the resource, and advertise support for both sha-256 and sha-512 hash algorithms. </del>  <del> 2.1.5.2. </del>  A response that contained a response header:

Reviewer comments:
This switches the custom wildcard matching to use with regexp support disabled. URLPattern is being used by the service worker routing API's and is what the web side is standardizing on for anything that pattern-matches URLs. This splits the match pattern into explicit path and search (query param) components and forces the origin to be inherited from the dictionary request URL. Also included here is a new field for to allow for matching on request destinations. The biggest use case for that will be for allowing site-wide HTML dictionaries to do something like and for the dictionary to not be sent for every request across the site (images, etc). See issues , ,

Revised text:
The "hashes" value is optional and defaults to (sha-256).  <ins> 2.1.7. </ins>  <ins> 2.1.7.1. </ins> A response that contained a response header:  <ins> Would specify matching any document request for a URL with a path prefix of /product/ on the same Origin as the original request, expiring as a dictionary in 7 days independent of the cache lifetime of the resource, and advertise support for both sha-256 and sha-512 hash algorithms. </ins>  <ins> 2.1.7.2. </ins> A response that contained a response header:
Original text:
6.3.1. To make sure that a dictionary can only impact content from the same <del> origin where the dictionary was served, the "match" pattern used for matching a dictionary to requests MUST be for the same origin that the dictionary is served from. </del>  6.3.2.

Reviewer comments:
This switches the custom wildcard matching to use with regexp support disabled. URLPattern is being used by the service worker routing API's and is what the web side is standardizing on for anything that pattern-matches URLs. This splits the match pattern into explicit path and search (query param) components and forces the origin to be inherited from the dictionary request URL. Also included here is a new field for to allow for matching on request destinations. The biggest use case for that will be for allowing site-wide HTML dictionaries to do something like and for the dictionary to not be sent for every request across the site (images, etc). See issues , ,

Revised text:
6.3.1. To make sure that a dictionary can only impact content from the same  <ins> origin where the dictionary was served, the URLPattern used for matching a dictionary to requests is guaranteed to be for the same origin that the dictionary is served from. </ins> 6.3.2.
Original text:
Parsers MUST support Tokens with at least 512 characters.  3.3.5. Byte Sequences can be conveyed in Structured Fields.

Reviewer comments:
Implementing Date in Python as a object has an issue -- Python dates are limited to a specific range. Given that it's good to expose SF as idiomatic data structures wherever possible, I poked around a bit for limits on date/time objects in libraries, and found (all expressed as limits on years, as that's the most significant bit): Python - Rust - Go - PHP - JavaScript - Ruby - Java - Should we specify a minimum range of dates that an implementation should support (likely 1-9999) so that developers can be confident of them (as we've done for other data types)?
Hm. Do these differences affect other parts of HTTP as well, such as processing the "Date" field (or fields specific to caching...?).
One would imagine that people put HTTP dates into these structures from time to time, yes.
(it's just that HTTP dates rarely go outside the range 1970 - "forseeable future")
Restricting to a year-based range would IMHO make sense if we actually would be using calendar dates (which we do not).
To be clear, I'm not proposing we restrict it -- just require implementations to support at least a particular range of values, just as we do with many other types. Don't get stuck on years, that's just a rough sizing to get an idea of what we're looking at. I think we'd express it in integer values.
I've commented in the PR that I dont like this, but let me add a bit of context: Handling of time, in real life and in computers, is incredibly messy and one of the most unreadable scientific books of all time is "Calendrical Calculations" which is our best shot at that subject matter. I really do not want us to wade into this tarpit, because everybody who has ever done so, has just added more tar in the process. My really strong preference is if Date was defined as "Seconds since Epoch" according to POSIX" with the full range of signed 15 decimal digits we inherit from Integer, so that we in no way adds any further complexity.
That's effectively what we have, even with this addition. This text is just requiring implementations to support at least a certain range, so that it can be relied upon for interoperability.

Revised text:
Parsers MUST support Tokens with at least 512 characters. <ins> Note that Tokens are defined largely for compatibility with the data model of existing HTTP fields, and may require additional steps to use in some implementations.  As a result, new fields are encouraged to use Strings. </ins> 3.3.5. Byte Sequences can be conveyed in Structured Fields.
Original text:
Date values can be conveyed in Structured Fields. Dates have a data model that is similar to Integers, representing a <del> (possibly negative) delta in seconds from January 1, 1970 00:00:00 UTC, excluding leap seconds. </del>  For example:  3.3.8. Display Strings are similar to Strings, in that they consist of zero

Reviewer comments:
Implementing Date in Python as a object has an issue -- Python dates are limited to a specific range. Given that it's good to expose SF as idiomatic data structures wherever possible, I poked around a bit for limits on date/time objects in libraries, and found (all expressed as limits on years, as that's the most significant bit): Python - Rust - Go - PHP - JavaScript - Ruby - Java - Should we specify a minimum range of dates that an implementation should support (likely 1-9999) so that developers can be confident of them (as we've done for other data types)?
Hm. Do these differences affect other parts of HTTP as well, such as processing the "Date" field (or fields specific to caching...?).
One would imagine that people put HTTP dates into these structures from time to time, yes.
(it's just that HTTP dates rarely go outside the range 1970 - "forseeable future")
Restricting to a year-based range would IMHO make sense if we actually would be using calendar dates (which we do not).
To be clear, I'm not proposing we restrict it -- just require implementations to support at least a particular range of values, just as we do with many other types. Don't get stuck on years, that's just a rough sizing to get an idea of what we're looking at. I think we'd express it in integer values.
I've commented in the PR that I dont like this, but let me add a bit of context: Handling of time, in real life and in computers, is incredibly messy and one of the most unreadable scientific books of all time is "Calendrical Calculations" which is our best shot at that subject matter. I really do not want us to wade into this tarpit, because everybody who has ever done so, has just added more tar in the process. My really strong preference is if Date was defined as "Seconds since Epoch" according to POSIX" with the full range of signed 15 decimal digits we inherit from Integer, so that we in no way adds any further complexity.
That's effectively what we have, even with this addition. This text is just requiring implementations to support at least a certain range, so that it can be relied upon for interoperability.

Revised text:
Date values can be conveyed in Structured Fields. Dates have a data model that is similar to Integers, representing a  <ins> (possibly negative) delta in seconds from 1970-01-01T00:00:00Z, excluding leap seconds. </ins> For example: <ins> Parsers MUST support Dates whose values include all days in years 1 to 9999 (i.e., -62,135,596,800 to 253,402,214,400 delta seconds from 1970-01-01T00:00:00Z). </ins> 3.3.8. Display Strings are similar to Strings, in that they consist of zero
Original text:
this will cause parsing to fail, but it is not possible to reliably fail in all such circumstances. <del> The Display String type conveys a Unicode string without any form of sanitization.  Applications using these values need to perform their own checks on their content; for example, they might contain escape sequences, or NUL.  Mitigation strategies include escaping untrusted content before displaying it. </del> 

Reviewer comments:
Implementing Date in Python as a object has an issue -- Python dates are limited to a specific range. Given that it's good to expose SF as idiomatic data structures wherever possible, I poked around a bit for limits on date/time objects in libraries, and found (all expressed as limits on years, as that's the most significant bit): Python - Rust - Go - PHP - JavaScript - Ruby - Java - Should we specify a minimum range of dates that an implementation should support (likely 1-9999) so that developers can be confident of them (as we've done for other data types)?
Hm. Do these differences affect other parts of HTTP as well, such as processing the "Date" field (or fields specific to caching...?).
One would imagine that people put HTTP dates into these structures from time to time, yes.
(it's just that HTTP dates rarely go outside the range 1970 - "forseeable future")
Restricting to a year-based range would IMHO make sense if we actually would be using calendar dates (which we do not).
To be clear, I'm not proposing we restrict it -- just require implementations to support at least a particular range of values, just as we do with many other types. Don't get stuck on years, that's just a rough sizing to get an idea of what we're looking at. I think we'd express it in integer values.
I've commented in the PR that I dont like this, but let me add a bit of context: Handling of time, in real life and in computers, is incredibly messy and one of the most unreadable scientific books of all time is "Calendrical Calculations" which is our best shot at that subject matter. I really do not want us to wade into this tarpit, because everybody who has ever done so, has just added more tar in the process. My really strong preference is if Date was defined as "Seconds since Epoch" according to POSIX" with the full range of signed 15 decimal digits we inherit from Integer, so that we in no way adds any further complexity.
That's effectively what we have, even with this addition. This text is just requiring implementations to support at least a certain range, so that it can be relied upon for interoperability.

Revised text:
this will cause parsing to fail, but it is not possible to reliably fail in all such circumstances.  <ins> The Display String type can convey any possible Unicode code point without sanitization; for example, they might contain unassigned code points, control points (including NUL), or noncharacters.  Therefore, applications consuming Display Strings need to consider strategies such as filtering or escaping untrusted content before displaying it. See also UNICODE-SECURITY and I-D.draft-bray-unichars. </ins>
Original text:
The remainder of this section uses an example of a file upload to illustrate different interactions with the upload resource.  Note, however, that HTTP message exchanges use representation data (see <del> HTTP), which means that resumable uploads can used with many forms of content - not just static files. </del>  3.1.

Reviewer comments:
See URL Lots of boring editorial tweaks to ensure better consistency both within the document and other HTTP specs.
One related question: The style guide also mentions that "examples should be in HTTP/1.1 format unless they are specific to another version of the protocol", but the draft uses a notation that resembles HTTP/2. Should we change the example messages to HTTP/1.1?
Thank you very for this tedious work! I only spotted a few minor typos.

Revised text:
The remainder of this section uses an example of a file upload to illustrate different interactions with the upload resource.  Note, however, that HTTP message exchanges use representation data (see  <ins> HTTP), which means that resumable uploads can be used with many forms of content - not just static files. </ins> 3.1.
Original text:
accept the upload from the client, and the client begins transferring the entire file in the request content. <del> An informational response can be sent to the client to signal the support of resumable upload on the server and transmit the upload resource URL in the Location header. </del>  <del> 2) If the connection to the server gets interrupted, the client may want to resume the upload.  Before this is possible, the client must know the amount of data that the server was able to receive before the connection got interrupted.  To achieve this, the client retrieves the offset (offset-retrieving) from the upload resource. </del>  <del> 3) Afterwards, the client can resume the upload by sending the remaining file content to the upload resource (upload-appending), appending to the already stored data in the upload.  The "Upload- Offset" value is included to ensure that the client and server agree on the offset that the upload resumes from. </del>  <del> 4) If the client is not interested in completing the upload anymore, it can instruct the upload resource to delete the upload and free all </del>  related resources (upload-cancellation). 3.2.

Reviewer comments:
See URL Lots of boring editorial tweaks to ensure better consistency both within the document and other HTTP specs.
One related question: The style guide also mentions that "examples should be in HTTP/1.1 format unless they are specific to another version of the protocol", but the draft uses a notation that resembles HTTP/2. Should we change the example messages to HTTP/1.1?
Thank you very for this tedious work! I only spotted a few minor typos.

Revised text:
accept the upload from the client, and the client begins transferring the entire file in the request content.  <ins> An informational response can be sent to the client, which signals the server's support of resumable upload as well as the upload resource URL via the Location header field (HTTP). </ins>  <ins> 2) If the connection to the server is interrupted, the client might want to resume the upload.  However, before this is possible the client needs to know the amount of data that the server received before the interruption.  It does so by retrieving the offset (offset-retrieving) from the upload resource. </ins>  <ins> 3) The client can resume the upload by sending the remaining file content to the upload resource (upload-appending), appending to the already stored data in the upload.  The "Upload-Offset" value is included to ensure that the client and server agree on the offset that the upload resumes from. </ins>  <ins> 4) If the client is not interested in completing the upload, it can instruct the upload resource to delete the upload and free all </ins> related resources (upload-cancellation). 3.2.
Original text:
Client implementations of draft versions of the protocol MUST send a header field "Upload-Draft-Interop-Version" with the interop version <del> as its value to its requests.  Its ABNF is </del>  Server implementations of draft versions of the protocol MUST NOT send a "104 (Upload Resumption Supported)" informational response

Reviewer comments:
See URL Lots of boring editorial tweaks to ensure better consistency both within the document and other HTTP specs.
One related question: The style guide also mentions that "examples should be in HTTP/1.1 format unless they are specific to another version of the protocol", but the draft uses a notation that resembles HTTP/2. Should we change the example messages to HTTP/1.1?
Thank you very for this tedious work! I only spotted a few minor typos.

Revised text:
Client implementations of draft versions of the protocol MUST send a header field "Upload-Draft-Interop-Version" with the interop version  <ins> as its value to its requests.  The "Upload-Draft-Interop-Version" field value is an Integer. </ins> Server implementations of draft versions of the protocol MUST NOT send a "104 (Upload Resumption Supported)" informational response
Original text:
offset of the incomplete upload by sending a "HEAD" request to the upload resource. <del> The request MUST NOT include the "Upload-Offset" header or the "Upload-Complete" header.  The server MUST reject the request with the "Upload-Offset" header or the "Upload-Complete" header by sending a "400 (Bad Request)" response. </del>  If the server considers the upload resource to be active, it MUST <del> send back a "204 (No Content)" response.  The response MUST include the "Upload-Offset" header set to the current resumption offset for the target resource.  The response MUST include the "Upload-Complete" header which is set to true if and only if the upload is complete. </del>  An upload is considered complete only if the server completely and <del> successfully received a corresponding creation (upload-creation) request or append (upload-appending) request with the "Upload- Complete" header being set to true. </del>  The client MUST NOT perform offset retrieval while creation (upload- creation) or append (upload-appending) is in progress.

Reviewer comments:
See URL Lots of boring editorial tweaks to ensure better consistency both within the document and other HTTP specs.
One related question: The style guide also mentions that "examples should be in HTTP/1.1 format unless they are specific to another version of the protocol", but the draft uses a notation that resembles HTTP/2. Should we change the example messages to HTTP/1.1?
Thank you very for this tedious work! I only spotted a few minor typos.

Revised text:
offset of the incomplete upload by sending a "HEAD" request to the upload resource.  <ins> The request MUST NOT include an "Upload-Offset" or "Upload-Complete" header field.  The server MUST reject requests with either of these fields by responding with a "400 (Bad Request)" status code. </ins> If the server considers the upload resource to be active, it MUST  <ins> respond with a "204 (No Content)" status code.  The response MUST include the "Upload-Offset" header field, with the value set to the current resumption offset for the target resource.  The response MUST include the "Upload-Complete" header field; the value is set to true only if the upload is complete. </ins> An upload is considered complete only if the server completely and  <ins> successfully received a corresponding creation request (upload- creation) or append request (upload-appending) with the "Upload- Complete" header value set to true. </ins> The client MUST NOT perform offset retrieval while creation (upload- creation) or append (upload-appending) is in progress.
Original text:
based on the resumption offset from a single offset retrieving (offset-retrieving) request. <del> The response SHOULD include "Cache-Control: no-store" header to prevent HTTP caching. </del>  If the server does not consider the upload resource to be active, it <del> MUST respond with "404 (Not Found)" status code. </del>  The resumption offset can be less than or equal to the number of bytes the client has already sent.  The client MAY reject an offset

Reviewer comments:
See URL Lots of boring editorial tweaks to ensure better consistency both within the document and other HTTP specs.
One related question: The style guide also mentions that "examples should be in HTTP/1.1 format unless they are specific to another version of the protocol", but the draft uses a notation that resembles HTTP/2. Should we change the example messages to HTTP/1.1?
Thank you very for this tedious work! I only spotted a few minor typos.

Revised text:
based on the resumption offset from a single offset retrieving (offset-retrieving) request.  <ins> In order to prevent HTTP caching, the response SHOULD include a "Cache-Control" header field with the value "no-store". </ins> If the server does not consider the upload resource to be active, it  <ins> MUST respond with a "404 (Not Found)" status code. </ins> The resumption offset can be less than or equal to the number of bytes the client has already sent.  The client MAY reject an offset
Original text:
4.2. <del> The current interop version is 3. </del>  Client implementations of draft versions of the protocol MUST send a header field "Upload-Draft-Interop-Version" with the interop version

Reviewer comments:
Since the last draft version was published, we replaced the header with the header. This requires an increase in the interop version as existing clients will need changes to be compatible with the next draft release.

Revised text:
4.2.  <ins> The current interop version is 4. </ins> Client implementations of draft versions of the protocol MUST send a header field "Upload-Draft-Interop-Version" with the interop version
Original text:
Upon parsing this name, "dot%5C.label" MUST be treated as a single label. <del> Similarly the "\" character in a label MUST be escaped as "\\". Other uses of "\" MUST NOT appear in the label after percent- decoding. </del>  3.

Reviewer comments:
From the list: At the end of Section 2.1 in URL, there is this: Can that last line be expounded on and clarified? Will a "\" character in a label be 'eventually' encoded as "\" or "%5C%5C" or some combination of them?
I think we can add an example for this

Revised text:
Upon parsing this name, "dot%5C.label" MUST be treated as a single label.  <ins> Similarly the "\" character in a label MUST be escaped as "\\" and then percent-encoded.  Other uses of "\" MUST NOT appear in the label after percent-decoding.  For example, if there is a DNS name "backslash\name.example.com", it would first be escaped as "backslash\\name.example.com", and then percent-encoded as follows: </ins> 3.