jiebi/CodeConvo huggingface dataset:
Code change:
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.

Related discussion:
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.
Code change:
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.

Related discussion:
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> <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
Code change:
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.

Related discussion:
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> <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>
Code change:
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.

Related discussion:
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> <ins> HTTP), which means that resumable uploads can be used with many forms of content - not just static files. </ins> 3.1.
Code change:
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.

Related discussion:
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> <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> <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> <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> <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> <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> <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> <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.
Code change:
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.

Related discussion:
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> <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
Code change:
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.

Related discussion:
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> <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 <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> <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 <del> successfully received a corresponding creation (upload-creation) request or append (upload-appending) request with the "Upload- Complete" header being set to true. </del> <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.
Code change:
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.

Related discussion:
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> <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 <del> MUST respond with "404 (Not Found)" status code. </del> <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
Code change:
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.

Related discussion:
text: 4.2. <del> The current interop version is 3. </del> <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
Code change:
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

Related discussion:
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> <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.
Code change:
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

Related discussion:
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> <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
Code change:
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!

Related discussion:
text: 11. <del> This specification registers the following entry in the Permanent Message Header Field Names registry established by RFC3864: </del> <ins> IANA is asked to register the following entries in the "Hypertext Transfer Protocol (HTTP) Field Name Registry": </ins> <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> <ins> IANA is asked to register the following entry in the "HTTP Status </ins> Codes" registry: <del> Code: 104 (suggested value) Description: Upload Resumption Supported Specification: This document </del>
Code change:
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).

Related discussion:
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> <ins> query", "match-dest", "ttl", and "type". </ins> 2.1.1.
Code change:
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).

Related discussion:
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> <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 <del> prefix of /product/ on the same Origin as the original request, </del> <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 <del> of the resource, and advertise support for both sha-256 and sha-512 hash algorithms. </del> <ins> of the resource. </ins> <del> 2.1.7.2. </del> <ins> 2.1.6.2. </ins> 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> <ins> Would match main.js in any directory under /app/ and expiring as a dictionary in one year. </ins> 2.2.
Code change:
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).

Related discussion:
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> <ins> Base16-encoded RFC4648 SHA-256 hash of the contents of a single available dictionary. </ins> Its syntax is defined by the following ABNF:
Code change:
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).

Related discussion:
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
Code change:
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).

Related discussion:
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> <ins> The "ttl" value is optional and defaults to 1209600 (14 days). </ins> 2.1.5.