jiebi/TextFlow huggingface dataset:
Original text:
Return True. The "match" value is required and MUST be included in the Use-As- <del> Dictionary sf-dictionary for the dictionary to be considered valid. </del>  2.1.2. <del> The "match-dest" value of the Use-As-Dictionary header is an inner list of sf-string values that provides a list of request destinations </del>  for the dictionary to match (https://fetch.spec.whatwg.org/#concept- request-destination).

Reviewer comments:
Switched from using the ABNF field types to the human names (i.e. sf-dictionary to Dictionary) for all of the Structured Field header values. Switched dictionary "type" to a Token (from String).
NAME could you PTAL at the change in referencing the header field types? Specifically, I wasn't sure if I should capitalize the types or not (I did since that's how the structured fields RFC referred to them).
Yep, this looks good. It's common to add something to you Notational Conventions section (or whatever) that says roughly "This specification uses the following terms from [ref to SF]: String, Byte Sequence, Token, ..."

Revised text:
Return True. The "match" value is required and MUST be included in the Use-As-  <ins> Dictionary Dictionary for the dictionary to be considered valid. </ins> 2.1.2.  <ins> The "match-dest" value of the Use-As-Dictionary header is an Inner List of String values that provides a list of request destinations </ins> for the dictionary to match (https://fetch.spec.whatwg.org/#concept- request-destination).
Original text:
2.1.3. <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" value is present and has a string length longer than zero then it MUST be sent to the server in a "Dictionary-ID" request header when the dictionary is advertised as being available. </del>  The server identifier MUST be treated as an opaque string by the client.

Reviewer comments:
Switched from using the ABNF field types to the human names (i.e. sf-dictionary to Dictionary) for all of the Structured Field header values. Switched dictionary "type" to a Token (from String).
NAME could you PTAL at the change in referencing the header field types? Specifically, I wasn't sure if I should capitalize the types or not (I did since that's how the structured fields RFC referred to them).
Yep, this looks good. It's common to add something to you Notational Conventions section (or whatever) that says roughly "This specification uses the following terms from [ref to SF]: String, Byte Sequence, Token, ..."

Revised text:
2.1.3.  <ins> The "id" value of the Use-As-Dictionary header is a String value that specifies a server identifier for the dictionary.  If an "id" value is present and has a string length longer than zero then it MUST be sent to the server in a "Dictionary-ID" request header when the dictionary is advertised as being available. </ins> The server identifier MUST be treated as an opaque string by the client.
Original text:
2.1.4. <del> The "type" value of the Use-As-Dictionary header is a sf-string value </del>  that describes the file format of the supplied dictionary. "raw" is the only defined dictionary format which represents an

Reviewer comments:
Switched from using the ABNF field types to the human names (i.e. sf-dictionary to Dictionary) for all of the Structured Field header values. Switched dictionary "type" to a Token (from String).
NAME could you PTAL at the change in referencing the header field types? Specifically, I wasn't sure if I should capitalize the types or not (I did since that's how the structured fields RFC referred to them).
Yep, this looks good. It's common to add something to you Notational Conventions section (or whatever) that says roughly "This specification uses the following terms from [ref to SF]: String, Byte Sequence, Token, ..."

Revised text:
2.1.4.  <ins> The "type" value of the Use-As-Dictionary header is a Token value </ins> that describes the file format of the supplied dictionary. "raw" is the only defined dictionary format which represents an
Original text:
If a client receives a dictionary with a type that it does not understand, it MUST NOT use the dictionary. <del> The "type" value is optional and defaults to "raw". </del>  2.1.5.

Reviewer comments:
Switched from using the ABNF field types to the human names (i.e. sf-dictionary to Dictionary) for all of the Structured Field header values. Switched dictionary "type" to a Token (from String).
NAME could you PTAL at the change in referencing the header field types? Specifically, I wasn't sure if I should capitalize the types or not (I did since that's how the structured fields RFC referred to them).
Yep, this looks good. It's common to add something to you Notational Conventions section (or whatever) that says roughly "This specification uses the following terms from [ref to SF]: String, Byte Sequence, Token, ..."

Revised text:
If a client receives a dictionary with a type that it does not understand, it MUST NOT use the dictionary.  <ins> The "type" value is optional and defaults to raw. </ins> 2.1.5.
Original text:
dictionary available to use for compression. The "Available-Dictionary" request header is a Structured Field <del> STRUCTURED-FIELDS sf-binary SHA-256 hash of the contents of a single available dictionary. </del>  The client MUST only send a single "Available-Dictionary" request header with a single hash value for the best available match that it

Reviewer comments:
Switched from using the ABNF field types to the human names (i.e. sf-dictionary to Dictionary) for all of the Structured Field header values. Switched dictionary "type" to a Token (from String).
NAME could you PTAL at the change in referencing the header field types? Specifically, I wasn't sure if I should capitalize the types or not (I did since that's how the structured fields RFC referred to them).
Yep, this looks good. It's common to add something to you Notational Conventions section (or whatever) that says roughly "This specification uses the following terms from [ref to SF]: String, Byte Sequence, Token, ..."

Revised text:
dictionary available to use for compression. The "Available-Dictionary" request header is a Structured Field  <ins> STRUCTURED-FIELDS Byte Sequence containing the SHA-256 hash of the contents of a single available dictionary. </ins> The client MUST only send a single "Available-Dictionary" request header with a single hash value for the best available match that it
Original text:
echo the stored "id" in a "Dictionary-ID" request header. The "Dictionary-ID" request header is a Structured Field STRUCTURED- <del> FIELDS sf-string of up to 1024 characters (after any decoding) and MUST be identical to the server-provided "id". </del>  For example:

Reviewer comments:
Switched from using the ABNF field types to the human names (i.e. sf-dictionary to Dictionary) for all of the Structured Field header values. Switched dictionary "type" to a Token (from String).
NAME could you PTAL at the change in referencing the header field types? Specifically, I wasn't sure if I should capitalize the types or not (I did since that's how the structured fields RFC referred to them).
Yep, this looks good. It's common to add something to you Notational Conventions section (or whatever) that says roughly "This specification uses the following terms from [ref to SF]: String, Byte Sequence, Token, ..."

Revised text:
echo the stored "id" in a "Dictionary-ID" request header. The "Dictionary-ID" request header is a Structured Field STRUCTURED-  <ins> FIELDS String of up to 1024 characters (after any decoding) and MUST be identical to the server-provided "id". </ins> For example:
Original text:
used in the "Content-Dictionary" response header. The "Content-Dictionary" response header is a Structured Field <del> STRUCTURED-FIELDS sf-dictionary SHA-256 hash of the contents of the dictionary that was used to encode the response. </del>  If the HTTP response contains a "Content-Dictionary" response header with the hash of a dictionary that the client does not have available

Reviewer comments:
Switched from using the ABNF field types to the human names (i.e. sf-dictionary to Dictionary) for all of the Structured Field header values. Switched dictionary "type" to a Token (from String).
NAME could you PTAL at the change in referencing the header field types? Specifically, I wasn't sure if I should capitalize the types or not (I did since that's how the structured fields RFC referred to them).
Yep, this looks good. It's common to add something to you Notational Conventions section (or whatever) that says roughly "This specification uses the following terms from [ref to SF]: String, Byte Sequence, Token, ..."

Revised text:
used in the "Content-Dictionary" response header. The "Content-Dictionary" response header is a Structured Field  <ins> STRUCTURED-FIELDS Byte Sequence containing the SHA-256 hash of the contents of the dictionary that was used to encode the response. </ins> If the HTTP response contains a "Content-Dictionary" response header with the hash of a dictionary that the client does not have available
Original text:
upload's final size is the "Content-Length" field value and the server MUST record it to ensure its consistency.  If the client received an informational response with the upload URL in the Location field value, it MAY automatically attempt upload resumption when the connection is terminated unexpectedly, or if a

Reviewer comments:
This PR adds descriptions to all message exchange examples in the draft. It should make their purpose clearer and also help distinguish the two separate examples in section 4, as pointed out in .
Thank you all!
نزت
I think there's two different creation examples being shown in URL but the presentation of them isn't great and could be a source of confusion. If so, lets break them apart by having a short sentence before each example expliaining it.
Yes, these are two separate examples, which are confusing. Most of the example are in need of a proper description. I can open a PR to address this. Thank you!

Revised text:
upload's final size is the "Content-Length" field value and the server MUST record it to ensure its consistency. <ins> The following example shows an upload creation.  The client transfers the entire 100 bytes in the first request.  The server generates two informational responses to transmit the upload resource's URL and progress information, and one final response to acknowledge the completed upload: The next example shows an upload creation, where only the first 25 bytes are transferred.  The server acknowledges the received data and that the upload is not complete yet: </ins> If the client received an informational response with the upload URL in the Location field value, it MAY automatically attempt upload resumption when the connection is terminated unexpectedly, or if a
Original text:
The client MAY cancel the upload (upload-cancellation) after rejecting the offset.  The client SHOULD NOT automatically retry if a client error status code between 400 and 499 (inclusive) is received.

Reviewer comments:
This PR adds descriptions to all message exchange examples in the draft. It should make their purpose clearer and also help distinguish the two separate examples in section 4, as pointed out in .
Thank you all!
نزت
I think there's two different creation examples being shown in URL but the presentation of them isn't great and could be a source of confusion. If so, lets break them apart by having a short sentence before each example expliaining it.
Yes, these are two separate examples, which are confusing. Most of the example are in need of a proper description. I can open a PR to address this. Thank you!

Revised text:
The client MAY cancel the upload (upload-cancellation) after rejecting the offset. <ins> The following example shows an offset retrieval request.  The server indicates the new offset and that the upload is not complete yet: </ins> The client SHOULD NOT automatically retry if a client error status code between 400 and 499 (inclusive) is received.
Original text:
upload's final size.  If they do not match, the server MUST reject the request with a "400 (Bad Request)" status code.  The client MAY automatically attempt upload resumption when the connection is terminated unexpectedly, or if a server error status code between 500 and 599 (inclusive) is received.  The client SHOULD

Reviewer comments:
This PR adds descriptions to all message exchange examples in the draft. It should make their purpose clearer and also help distinguish the two separate examples in section 4, as pointed out in .
Thank you all!
نزت
I think there's two different creation examples being shown in URL but the presentation of them isn't great and could be a source of confusion. If so, lets break them apart by having a short sentence before each example expliaining it.
Yes, these are two separate examples, which are confusing. Most of the example are in need of a proper description. I can open a PR to address this. Thank you!

Revised text:
upload's final size.  If they do not match, the server MUST reject the request with a "400 (Bad Request)" status code. <ins> The following example shows an upload append.  The client transfers the next 100 bytes at an offset of 100 and does not indicate that the upload is then completed.  The server acknowledges the new offset: </ins> The client MAY automatically attempt upload resumption when the connection is terminated unexpectedly, or if a server error status code between 500 and 599 (inclusive) is received.  The client SHOULD
Original text:
If the server does not support cancellation, it MUST respond with a "405 (Method Not Allowed)" status code.  8. 8.1.

Reviewer comments:
This PR adds descriptions to all message exchange examples in the draft. It should make their purpose clearer and also help distinguish the two separate examples in section 4, as pointed out in .
Thank you all!
نزت
I think there's two different creation examples being shown in URL but the presentation of them isn't great and could be a source of confusion. If so, lets break them apart by having a short sentence before each example expliaining it.
Yes, these are two separate examples, which are confusing. Most of the example are in need of a proper description. I can open a PR to address this. Thank you!

Revised text:
If the server does not support cancellation, it MUST respond with a "405 (Method Not Allowed)" status code. <ins> The following example shows an upload cancellation: </ins> 8. 8.1.
Original text:
upload's final size is the "Content-Length" field value and the server MUST record it to ensure its consistency.  If the client received an informational response with the upload URL in the Location field value, it MAY automatically attempt upload resumption when the connection is terminated unexpectedly, or if a

Reviewer comments:
This PR adds explanations helping readers to understand when empty requests for upload creation or appending might be useful and why server should support them. Closes URL
The field definitions allow for a client to send 0-length content. Sometimes this is useful, other times it it might not be. For example, A client could perform upload creation by making a request content-length: 0 and with upload-complete:?0. This would allow it to test creation wihout having to commit to an upload in the same message. A client could attempt to append to append zero bytes. Is this useful or should we prohibit it? This is a cheap way to keep an upload "active". However, that might be a vector for abuse by allowing a client to cause server-side state commintment. Depending on what we decide, we might need some text in the security considerations.
Just to add to the two bullet points: This can also be used for clients/servers that do not support 1xx response by sending a 0 byte upload-complete: ?0 request to get the unique resource URL. This is for instance how does it. For cases where multiple upload-complete: ?0 requests are made, a final 0 byte upload-complete: ?1 request can be used to notify the server that the upload is complete. This can be useful in cases where the client wants to provide all the data before finalizing the upload to reduce the risk of losing the final response. I don't really see a use case for sending multiple 0 byte upload-complete: ?0 but there might be some?

Revised text:
upload's final size is the "Content-Length" field value and the server MUST record it to ensure its consistency. <ins> The request content MAY be empty.  If the "Upload-Complete" header field is then set to true, the client intends to upload an empty entity.  An "Upload-Complete" header field is set to false is also valid.  This can be used to create an upload resource URL before transferring data, which can save client or server resources.  Since informational responses are optional, this technique provides another mechanism to learn the URL, at the cost of an additional round-trip before data upload can commence. The following example shows an upload creation.  The client transfers the entire 100 bytes in the first request.  The server generates two informational responses to transmit the upload resource's URL and progress information, and one final response to acknowledge the completed upload: The next example shows an upload creation, where only the first 25 bytes are transferred.  The server acknowledges the received data and that the upload is not complete yet: </ins> If the client received an informational response with the upload URL in the Location field value, it MAY automatically attempt upload resumption when the connection is terminated unexpectedly, or if a
Original text:
The client MAY cancel the upload (upload-cancellation) after rejecting the offset.  The client SHOULD NOT automatically retry if a client error status code between 400 and 499 (inclusive) is received.

Reviewer comments:
This PR adds explanations helping readers to understand when empty requests for upload creation or appending might be useful and why server should support them. Closes URL
The field definitions allow for a client to send 0-length content. Sometimes this is useful, other times it it might not be. For example, A client could perform upload creation by making a request content-length: 0 and with upload-complete:?0. This would allow it to test creation wihout having to commit to an upload in the same message. A client could attempt to append to append zero bytes. Is this useful or should we prohibit it? This is a cheap way to keep an upload "active". However, that might be a vector for abuse by allowing a client to cause server-side state commintment. Depending on what we decide, we might need some text in the security considerations.
Just to add to the two bullet points: This can also be used for clients/servers that do not support 1xx response by sending a 0 byte upload-complete: ?0 request to get the unique resource URL. This is for instance how does it. For cases where multiple upload-complete: ?0 requests are made, a final 0 byte upload-complete: ?1 request can be used to notify the server that the upload is complete. This can be useful in cases where the client wants to provide all the data before finalizing the upload to reduce the risk of losing the final response. I don't really see a use case for sending multiple 0 byte upload-complete: ?0 but there might be some?

Revised text:
The client MAY cancel the upload (upload-cancellation) after rejecting the offset. <ins> The following example shows an offset retrieval request.  The server indicates the new offset and that the upload is not complete yet: </ins> The client SHOULD NOT automatically retry if a client error status code between 400 and 499 (inclusive) is received.
Original text:
upload's final size.  If they do not match, the server MUST reject the request with a "400 (Bad Request)" status code.  The client MAY automatically attempt upload resumption when the connection is terminated unexpectedly, or if a server error status code between 500 and 599 (inclusive) is received.  The client SHOULD

Reviewer comments:
This PR adds explanations helping readers to understand when empty requests for upload creation or appending might be useful and why server should support them. Closes URL
The field definitions allow for a client to send 0-length content. Sometimes this is useful, other times it it might not be. For example, A client could perform upload creation by making a request content-length: 0 and with upload-complete:?0. This would allow it to test creation wihout having to commit to an upload in the same message. A client could attempt to append to append zero bytes. Is this useful or should we prohibit it? This is a cheap way to keep an upload "active". However, that might be a vector for abuse by allowing a client to cause server-side state commintment. Depending on what we decide, we might need some text in the security considerations.
Just to add to the two bullet points: This can also be used for clients/servers that do not support 1xx response by sending a 0 byte upload-complete: ?0 request to get the unique resource URL. This is for instance how does it. For cases where multiple upload-complete: ?0 requests are made, a final 0 byte upload-complete: ?1 request can be used to notify the server that the upload is complete. This can be useful in cases where the client wants to provide all the data before finalizing the upload to reduce the risk of losing the final response. I don't really see a use case for sending multiple 0 byte upload-complete: ?0 but there might be some?

Revised text:
upload's final size.  If they do not match, the server MUST reject the request with a "400 (Bad Request)" status code. <ins> The request content MAY be empty.  If the "Upload-Complete" field is then set to true, the client wants to complete the upload without appending additional data. The following example shows an upload append.  The client transfers the next 100 bytes at an offset of 100 and does not indicate that the upload is then completed.  The server acknowledges the new offset: </ins> The client MAY automatically attempt upload resumption when the connection is terminated unexpectedly, or if a server error status code between 500 and 599 (inclusive) is received.  The client SHOULD
Original text:
If the server does not support cancellation, it MUST respond with a "405 (Method Not Allowed)" status code.  8. 8.1.

Reviewer comments:
This PR adds explanations helping readers to understand when empty requests for upload creation or appending might be useful and why server should support them. Closes URL
The field definitions allow for a client to send 0-length content. Sometimes this is useful, other times it it might not be. For example, A client could perform upload creation by making a request content-length: 0 and with upload-complete:?0. This would allow it to test creation wihout having to commit to an upload in the same message. A client could attempt to append to append zero bytes. Is this useful or should we prohibit it? This is a cheap way to keep an upload "active". However, that might be a vector for abuse by allowing a client to cause server-side state commintment. Depending on what we decide, we might need some text in the security considerations.
Just to add to the two bullet points: This can also be used for clients/servers that do not support 1xx response by sending a 0 byte upload-complete: ?0 request to get the unique resource URL. This is for instance how does it. For cases where multiple upload-complete: ?0 requests are made, a final 0 byte upload-complete: ?1 request can be used to notify the server that the upload is complete. This can be useful in cases where the client wants to provide all the data before finalizing the upload to reduce the risk of losing the final response. I don't really see a use case for sending multiple 0 byte upload-complete: ?0 but there might be some?

Revised text:
If the server does not support cancellation, it MUST respond with a "405 (Method Not Allowed)" status code. <ins> The following example shows an upload cancellation: </ins> 8. 8.1.