jiebi/TextFlow huggingface dataset:
Original text:
Implementations ought to note that the full chain of names might not be available in common DNS resolution APIs, such as "getaddrinfo". <del> "getaddrinfo" does have an option for "AI_CANONNAME", but this will only return the last name in the chain (the canonical name), not the alias names. </del>  An implementation MAY include incomplete information in the "next- hop-aliases" parameter to accommodate cases where it is unable to

Reviewer comments:
CC NAME comment syntax: URL "Handling Ballot Positions": URL Why is the value defined as a String that can be comma-separated as opposed to a List (of Strings)? Up to you, but feel free to reference RFC 3493 section 6.1 for getaddrinfo and discussion of the AI_CANONNAME flag. "might not available" -> "might not be available"
The nit was fixed with
For the list-of-strings, parameters themselves can only contain bare items, not inner lists. URL

Revised text:
Implementations ought to note that the full chain of names might not be available in common DNS resolution APIs, such as "getaddrinfo".  <ins> "getaddrinfo" does have an option for "AI_CANONNAME" (Section 6.1 of RFC3493), but this will only return the last name in the chain (the canonical name), not the alias names. </ins> An implementation MAY include incomplete information in the "next- hop-aliases" parameter to accommodate cases where it is unable to
Original text:
11. <del> This specification registers the following entry in the Permanent Message Header Field Names registry established by RFC3864: </del>  <del> Header field name: Upload-Offset, Upload-Complete Applicable protocol: http Status: standard Author/change controller: IETF Specification: This document Related information: n/a This specification registers the following entry in the "HTTP Status </del>  Codes" registry: <del> Code: 104 (suggested value) Description: Upload Resumption Supported Specification: This document </del>

Reviewer comments:
IANA early review highlighted that we were attempting to register to the old table. Lets fix that and do a little more tidyup.
Thank you!

Revised text:
11.  <ins> IANA is asked to register the following entries in the "Hypertext Transfer Protocol (HTTP) Field Name Registry": </ins>  <ins> IANA is asked to register the following entry in the "HTTP Status </ins> Codes" registry:
Original text:
The Use-As-Dictionary response header is a Structured Field STRUCTURED-FIELDS sf-dictionary with values for "match", "match- <del> query", "match-dest", "ttl", "type" and "hashes". </del>  2.1.1.

Reviewer comments:
This removes the hashes negotiation and changes the Available-Dictionary request header to explicitly use sha-256 as discussed in URL If sha-256 becomes insufficient, the hash negotiation can then be added (or different mechanisms can be used). This is a rebased version of the (sorry, it got messy so it was cleaner to resubmit a clean one).

Revised text:
The Use-As-Dictionary response header is a Structured Field STRUCTURED-FIELDS sf-dictionary with values for "match", "match-  <ins> query", "match-dest", "ttl", and "type". </ins> 2.1.1.
Original text:
2.1.6. <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 server preference. The dictionaries are identified by the hash of their contents and this value allows for negotiation of the algorithm to use. The "hashes" value is optional and defaults to (sha-256). 2.1.7. 2.1.7.1. </del>  A response that contained a response header: Would specify matching any document request for a URL with a path <del> prefix of /product/ on the same Origin as the original request, </del>  expiring as a dictionary in 7 days independent of the cache lifetime <del> of the resource, and advertise support for both sha-256 and sha-512 hash algorithms. </del>  <del> 2.1.7.2. </del>  A response that contained a response header: <del> Would match main.js in any directory under /app/, expiring as a dictionary in one year and support using the sha-256 hash algorithm. </del>  2.2.

Reviewer comments:
This removes the hashes negotiation and changes the Available-Dictionary request header to explicitly use sha-256 as discussed in URL If sha-256 becomes insufficient, the hash negotiation can then be added (or different mechanisms can be used). This is a rebased version of the (sorry, it got messy so it was cleaner to resubmit a clean one).

Revised text:
2.1.6.  <ins> 2.1.6.1. </ins> A response that contained a response header: Would specify matching any document request for a URL with a path  <ins> prefix of /product/ on the same Origin as the original request, and </ins> expiring as a dictionary in 7 days independent of the cache lifetime  <ins> of the resource. </ins>  <ins> 2.1.6.2. </ins> A response that contained a response header:  <ins> Would match main.js in any directory under /app/ and expiring as a dictionary in one year. </ins> 2.2.
Original text:
dictionary available to use for compression. The "Available-Dictionary" request header is a lowercase <del> Base16-encoded RFC4648 hash of the contents of a single available dictionary calculated using one of the algorithms advertised as being supported by the server. </del>  Its syntax is defined by the following ABNF:

Reviewer comments:
This removes the hashes negotiation and changes the Available-Dictionary request header to explicitly use sha-256 as discussed in URL If sha-256 becomes insufficient, the hash negotiation can then be added (or different mechanisms can be used). This is a rebased version of the (sorry, it got messy so it was cleaner to resubmit a clean one).

Revised text:
dictionary available to use for compression. The "Available-Dictionary" request header is a lowercase  <ins> Base16-encoded RFC4648 SHA-256 hash of the contents of a single available dictionary. </ins> Its syntax is defined by the following ABNF:
Original text:
the content, because a change to the dictionary can result in a change to the decompressed content.  6.2. The CRIME attack shows that it's a bad idea to compress data from

Reviewer comments:
This removes the hashes negotiation and changes the Available-Dictionary request header to explicitly use sha-256 as discussed in URL If sha-256 becomes insufficient, the hash negotiation can then be added (or different mechanisms can be used). This is a rebased version of the (sorry, it got messy so it was cleaner to resubmit a clean one).

Revised text:
the content, because a change to the dictionary can result in a change to the decompressed content. <ins> The dictionary is validated using a SHA-256 hash of the content to make sure that the client and server are both using the same dictionary.  The strength of the SHA-256 hash algorithm isn't explicitly needed to counter attacks since the dictionary is being served from the same origin as the content.  That said, if a weakness is discovered in SHA-256 and it is determined that the dictionary negotiation should use a different hash algorithm, the "Use-As- Dictionary" response header can be extended to specify a different algorithm and the server would just ignore any "Available-Dictionary" requests that do not use the updated hash. </ins> 6.2. The CRIME attack shows that it's a bad idea to compress data from
Original text:
dictionary is updated frequently which can help limit the number of possible incoming dictionary variations. <del> The "ttl" value is optional and defaults to 31536000 (1 year). </del>  2.1.5.

Reviewer comments:
Discussion at IETF 118 was that the didn't necessarily need to be short to reduce variations (was originally planning on 7 days) but chaning it to last-fetched instead of last-written is important. This updates the default to 14 days as a balance (can always be overridden explicitly).

Revised text:
dictionary is updated frequently which can help limit the number of possible incoming dictionary variations.  <ins> The "ttl" value is optional and defaults to 1209600 (14 days). </ins> 2.1.5.
Original text:
To be considered as a match, the dictionary must not yet be expired as a dictionary.  When iterating through dictionaries looking for a match, the expiration time of the dictionary is calculated by taking <del> the last time the dictionary was written and adding the "ttl" seconds </del>  from the "Use-As-Dictionary" response.  If the current time is beyond the expiration time of the dictionary, it MUST be ignored.

Reviewer comments:
Discussion at IETF 118 was that the didn't necessarily need to be short to reduce variations (was originally planning on 7 days) but chaning it to last-fetched instead of last-written is important. This updates the default to 14 days as a balance (can always be overridden explicitly).

Revised text:
To be considered as a match, the dictionary must not yet be expired as a dictionary.  When iterating through dictionaries looking for a match, the expiration time of the dictionary is calculated by taking  <ins> the last time the dictionary was fetched and adding the "ttl" seconds </ins> from the "Use-As-Dictionary" response.  If the current time is beyond the expiration time of the dictionary, it MUST be ignored.
Original text:
The upload resource URL is the identifier used for modifying the upload.  Without further protection of this URL, an attacker may obtain information about an upload, append data to it, or cancel it. To prevent this, the server SHOULD ensure that only authorized clients can access the upload resource.  In addition, the upload resource URL SHOULD be generated in such a way that makes it hard to be guessed by unauthorized clients.  11. IANA is asked to register the following entries in the "Hypertext

Reviewer comments:
As brought up in , resumable uploads may interfere with intermediaries scanning the request content. This PR adds a paragraph in the security considerations. Closes URL
Some security measures that involve looking at incoming HTTP requests might be circumvented by resumable uploads. For example, a filter which looks for certain HTTP headers and corresponding text in the request payload might not be triggered when the header occurs in one request and the matching body fragment in a subsequent request. I don't believe there's anything we need to change about the protocol here, but it's probably mentioning this in Security Considerations. Perhaps guidance would be to ensure any security measures are either resumable-upload-aware or are explicitly called to inspect the final request between receipt of the last chunk and execution of the original request.
Thank you, that is a good point. I have opened to add a paragraph in this regard. Please let me know if that expresses the problem correctly.

Revised text:
The upload resource URL is the identifier used for modifying the upload.  Without further protection of this URL, an attacker may obtain information about an upload, append data to it, or cancel it. To prevent this, the server SHOULD ensure that only authorized clients can access the upload resource.  In addition, the upload resource URL SHOULD be generated in such a way that makes it hard to be guessed by unauthorized clients. <ins> Some servers or intermediaries provide scanning of content uploaded by clients.  Any scanning mechanism that relies on receiving a complete file in a single request message can be defeated by resumable uploads because content can be split across multiple messages.  Servers or intermediaries wishing to perform content scanning SHOULD consider how resumable uploads can circumvent scanning and take appropriate measures.  Possible strategies include waiting for the upload to complete before scanning a full file, or disabling resumable uploads. </ins> 11. IANA is asked to register the following entries in the "Hypertext
Original text:
The Use-As-Dictionary response header is a Structured Field STRUCTURED-FIELDS sf-dictionary with values for "match", "match- <del> search", "match-dest", "ttl", and "type". </del>  2.1.1.

Reviewer comments:
This adds support for a server-provided sf-string "id" of up to 1024 characters that is echoed back in a "Dictionary-ID" request header when the dictionary is advertised as being available. This allows for a server to use something other than the hash to retrieve the dictionary (i.e. a cache key). This should be more flexible than the client sending the original request URL and will allow for servers to store arbitrary context information with the dictionary. It doesn't open up any additional privacy or security concerns because the dictionary hash was already being treated as if it was user-identifiable information. For
NAME could you please take a look and see if this meets your needs and looks reasonable?
Yes, looks great! Thanks!

Revised text:
The Use-As-Dictionary response header is a Structured Field STRUCTURED-FIELDS sf-dictionary with values for "match", "match-  <ins> search", "match-dest", "ttl", "id", and "type". </ins> 2.1.1.
Original text:
2.1.5.  The "type" value of the Use-As-Dictionary header is a sf-string value that describes the file format of the supplied dictionary.

Reviewer comments:
This adds support for a server-provided sf-string "id" of up to 1024 characters that is echoed back in a "Dictionary-ID" request header when the dictionary is advertised as being available. This allows for a server to use something other than the hash to retrieve the dictionary (i.e. a cache key). This should be more flexible than the client sending the original request URL and will allow for servers to store arbitrary context information with the dictionary. It doesn't open up any additional privacy or security concerns because the dictionary hash was already being treated as if it was user-identifiable information. For
NAME could you please take a look and see if this meets your needs and looks reasonable?
Yes, looks great! Thanks!

Revised text:
2.1.5. <ins> The "id" value of the Use-As-Dictionary header is a sf-string value that specifies a server identifier for the dictionary.  If an "id" value is present then it MUST be sent to the server in a "Dictionary- ID" request header when the dictionary is advertised as being available. The server identifier MUST be treated as an opaque string by the client. The server identifier MUST NOT be relied upon by the server to guarantee the contents of the dictionary.  The dictionary hash MUST be validated before use. The "id" value string length (after any decoding) supports up to 1024 characters. The "id" value is optional. 2.1.6. </ins> The "type" value of the Use-As-Dictionary header is a sf-string value that describes the file format of the supplied dictionary.
Original text:
The "type" value is optional and defaults to "raw". <del> 2.1.6. </del>  <del> 2.1.6.1. </del>  A response that contained a response header:

Reviewer comments:
This adds support for a server-provided sf-string "id" of up to 1024 characters that is echoed back in a "Dictionary-ID" request header when the dictionary is advertised as being available. This allows for a server to use something other than the hash to retrieve the dictionary (i.e. a cache key). This should be more flexible than the client sending the original request URL and will allow for servers to store arbitrary context information with the dictionary. It doesn't open up any additional privacy or security concerns because the dictionary hash was already being treated as if it was user-identifiable information. For
NAME could you please take a look and see if this meets your needs and looks reasonable?
Yes, looks great! Thanks!

Revised text:
The "type" value is optional and defaults to "raw".  <ins> 2.1.7. </ins>  <ins> 2.1.7.1. </ins> A response that contained a response header:
Original text:
expiring as a dictionary in 7 days independent of the cache lifetime of the resource. <del> 2.1.6.2. </del>  A response that contained a response header:

Reviewer comments:
This adds support for a server-provided sf-string "id" of up to 1024 characters that is echoed back in a "Dictionary-ID" request header when the dictionary is advertised as being available. This allows for a server to use something other than the hash to retrieve the dictionary (i.e. a cache key). This should be more flexible than the client sending the original request URL and will allow for servers to store arbitrary context information with the dictionary. It doesn't open up any additional privacy or security concerns because the dictionary hash was already being treated as if it was user-identifiable information. For
NAME could you please take a look and see if this meets your needs and looks reasonable?
Yes, looks great! Thanks!

Revised text:
expiring as a dictionary in 7 days independent of the cache lifetime of the resource.  <ins> 2.1.7.2. </ins> A response that contained a response header:
Original text:
2.3.  When a HTTP server responds with a resource that is encoded with a dictionary the server MUST send the hash of the dictionary that was used in the "Content-Dictionary" response header.

Reviewer comments:
This adds support for a server-provided sf-string "id" of up to 1024 characters that is echoed back in a "Dictionary-ID" request header when the dictionary is advertised as being available. This allows for a server to use something other than the hash to retrieve the dictionary (i.e. a cache key). This should be more flexible than the client sending the original request URL and will allow for servers to store arbitrary context information with the dictionary. It doesn't open up any additional privacy or security concerns because the dictionary hash was already being treated as if it was user-identifiable information. For
NAME could you please take a look and see if this meets your needs and looks reasonable?
Yes, looks great! Thanks!

Revised text:
2.3. <ins> When a HTTP client makes a request for a resource for which it has an appropriate dictionary and the dictionary was stored with a server- provided "id" in the Use-As-Dictionary response then the client MUST echo the stored "id" in a "Dictionary-ID" request header. The "Dictionary-ID" request header is a Structured Field STRUCTURED- FIELDS sf-string of up to 1024 characters (after any decoding) and MUST be identical to the server-provided "id". For example: 2.4. </ins> When a HTTP server responds with a resource that is encoded with a dictionary the server MUST send the hash of the dictionary that was used in the "Content-Dictionary" response header.
Original text:
The "match-dest" value is optional and defaults to the empty string. <del> 2.1.4. </del>  The "ttl" value of the Use-As-Dictionary header is a sf-integer value that provides the time in seconds that the dictionary is valid for

Reviewer comments:
This changes the URLPattern match to use a single match pattern to be consistent with other uses of URLPattern.
NAME NAME this is an attempt at a change to have it use a single string for pattern construction. I don't feel great about the same-origin check part of the validation but I don't see why it wouldn't work. It still allows for people to waste bytes by not using path-relative patterns so I may have to re-open the issue around that but should provide the consistency you were asking for. This would be instead of PR .
a couple nitpicks while passing by

Revised text:
The "match-dest" value is optional and defaults to the empty string.  <ins> 2.1.3. </ins> The "ttl" value of the Use-As-Dictionary header is a sf-integer value that provides the time in seconds that the dictionary is valid for
Original text:
The "ttl" value is optional and defaults to 1209600 (14 days). <del> 2.1.5. </del>  The "id" value of the Use-As-Dictionary header is a sf-string value that specifies a server identifier for the dictionary.  If an "id"

Reviewer comments:
This changes the URLPattern match to use a single match pattern to be consistent with other uses of URLPattern.
NAME NAME this is an attempt at a change to have it use a single string for pattern construction. I don't feel great about the same-origin check part of the validation but I don't see why it wouldn't work. It still allows for people to waste bytes by not using path-relative patterns so I may have to re-open the issue around that but should provide the consistency you were asking for. This would be instead of PR .
a couple nitpicks while passing by

Revised text:
The "ttl" value is optional and defaults to 1209600 (14 days).  <ins> 2.1.4. </ins> The "id" value of the Use-As-Dictionary header is a sf-string value that specifies a server identifier for the dictionary.  If an "id"
Original text:
The "id" value is optional. <del> 2.1.6. </del>  The "type" value of the Use-As-Dictionary header is a sf-string value that describes the file format of the supplied dictionary.

Reviewer comments:
This changes the URLPattern match to use a single match pattern to be consistent with other uses of URLPattern.
NAME NAME this is an attempt at a change to have it use a single string for pattern construction. I don't feel great about the same-origin check part of the validation but I don't see why it wouldn't work. It still allows for people to waste bytes by not using path-relative patterns so I may have to re-open the issue around that but should provide the consistency you were asking for. This would be instead of PR .
a couple nitpicks while passing by

Revised text:
The "id" value is optional.  <ins> 2.1.5. </ins> The "type" value of the Use-As-Dictionary header is a sf-string value that describes the file format of the supplied dictionary.
Original text:
The "type" value is optional and defaults to "raw". <del> 2.1.7. </del>  <del> 2.1.7.1. </del>  A response that contained a response header:

Reviewer comments:
This changes the URLPattern match to use a single match pattern to be consistent with other uses of URLPattern.
NAME NAME this is an attempt at a change to have it use a single string for pattern construction. I don't feel great about the same-origin check part of the validation but I don't see why it wouldn't work. It still allows for people to waste bytes by not using path-relative patterns so I may have to re-open the issue around that but should provide the consistency you were asking for. This would be instead of PR .
a couple nitpicks while passing by

Revised text:
The "type" value is optional and defaults to "raw".  <ins> 2.1.6. </ins>  <ins> 2.1.6.1. </ins> A response that contained a response header:
Original text:
expiring as a dictionary in 7 days independent of the cache lifetime of the resource. <del> 2.1.7.2. </del>  A response that contained a response header:

Reviewer comments:
This changes the URLPattern match to use a single match pattern to be consistent with other uses of URLPattern.
NAME NAME this is an attempt at a change to have it use a single string for pattern construction. I don't feel great about the same-origin check part of the validation but I don't see why it wouldn't work. It still allows for people to waste bytes by not using path-relative patterns so I may have to re-open the issue around that but should provide the consistency you were asking for. This would be instead of PR .
a couple nitpicks while passing by

Revised text:
expiring as a dictionary in 7 days independent of the cache lifetime of the resource.  <ins> 2.1.6.2. </ins> A response that contained a response header: