jiebi/CodeConvo huggingface dataset:
Code change:
In order to allow existing applications to update from one octet of padding per record to two (PR , Issue ), this PR renames "aesgcm128" to "aesgcm" as the value for the Content-Encoding header, as well as the parameter name in the Crypto-Key header. This also affects the context used for deriving the nonce and the content encryption key. Examples have been updated. What I did not update is the JWE mapping (currently "A128GCM"). Do we wish to change that to "AGCM", which may be less descriptive?
NAME - for your consideration I updated the hashes, but would like you to verify those when you've got a moment (they include the uint8 -> uint16 change). I wasn't able to reproduce the output of the explicit example using the current spec.
Awesome. I'm still awaiting the return of my implementation (I'm annoyed that I put it on a boat), but I will verify when able. It's entirely possible that one (or more) of the examples are in error.
I still need to double-check the examples, but I won't be able to do that for a while now. Stupid travel. Might as well make progress at least. Thanks for putting this all together NAME
Each record currently includes between 1 and 256 octets of padding, while the default record size is set to 4096 octets. This is in many cases not sufficient, for example in the pad-to-next-power-of-two case. Extending the padding length to two octets will allow up to 65537 octets (65KB) of padding. I raised this on the ietf-http-wg list here: URL Martin about an upgrade path for existing users. I'll reply on the mailing list to not split the discussion.
This was fixed in and .

Related discussion:
text: 7.4.2. <del> Parameter Name: aesgcm128 </del> <ins> Parameter Name: aesgcm </ins> Purpose: Provide an explicit input keying material value for the <del> aesgcm128 content encoding. </del> <ins> aesgcm content encoding. </ins> Reference: this document
Code change:
Condensed version of .
Thanks, this looks good to me. It provides a more formal scaffold for the intent that the editors (and design team before them) had in mind for this scheme's extensibility. I do wonder if we might want to name the registry as the slightly more verbose "extensible priority parameters" but since we are not yet establishing a registry it is easy to iterate on that.

Related discussion:
text: 3.3. <del> When attempting to extend priorities, care must be taken to ensure any use of existing parameters leaves them either unchanged or modified in a way that is backwards compatible for peers that are unaware of the extended meaning. </del> <ins> When attempting to define new parameters, care must be taken so that they do not adversely interfere with prioritization performed by existing endpoints or intermediaries that do not understand the newly defined parameter.  Since unknown parameters are ignored, new parameters should not change the interpretation of or modify the predefined parameters in a way that is not backwards compatible or fallback safe. </ins> For example, if there is a need to provide more granularity than eight urgency levels, it would be possible to subdivide the range
Code change:
Condensed version of .
Thanks, this looks good to me. It provides a more formal scaffold for the intent that the editors (and design team before them) had in mind for this scheme's extensibility. I do wonder if we might want to name the registry as the slightly more verbose "extensible priority parameters" but since we are not yet establishing a registry it is easy to iterate on that.

Related discussion:
text: graphical user agent could send a "visible" parameter to indicate if the resource being requested is within the viewport. <ins> Generic parameters are preferred over vendor-specific, application- specific or deployment-specific values.  If a generic value cannot be agreed upon in the community, the parameter's name should be correspondingly specific (e.g., with a prefix that identifies the vendor, application or deployment). 3.3.1. New Priority parameters can be defined by registering them in the HTTP Priority Parameters Registry. Registration requests are reviewed and approved by a Designated Expert, as per RFC8126, Section 4.5.  A specification document is appreciated, but not required. The Expert(s) should consider the following factors when evaluating requests: Community feedback If the parameters are sufficiently well-defined and adhere to the guidance provided in new-parameters. Registration requests should use the following template: Name: [a name for the Priority Parameter that matches key] Description: [a description of the parameter semantics and value] Reference: [to a specification defining this parameter] See the registry at https://iana.org/assignments/http-priority [4] for details on where to send registration requests. </ins> 4. The Priority HTTP header field can appear in requests and responses.
Code change:
Condensed version of .
Thanks, this looks good to me. It provides a more formal scaffold for the intent that the editors (and design team before them) had in mind for this scheme's extensibility. I do wonder if we might want to name the registry as the slightly more verbose "extensible priority parameters" but since we are not yet establishing a registry it is easy to iterate on that.

Related discussion:
text: This document <ins> Upon publication, please create the HTTP Priority Parameters registry at https://iana.org/assignments/http-priority [5] and populate it with the types defined in parameters; see register for its associated procedures. </ins> 14.  References 14.1.  URIs
Code change:
Condensed version of .
Thanks, this looks good to me. It provides a more formal scaffold for the intent that the editors (and design team before them) had in mind for this scheme's extensibility. I do wonder if we might want to name the registry as the slightly more verbose "extensible priority parameters" but since we are not yet establishing a registry it is easy to iterate on that.

Related discussion:
text: [2] https://httpwg.org/ [3] https://github.com/httpwg/http-extensions/labels/priorities <ins> [4] https://iana.org/assignments/http-priority [5] https://iana.org/assignments/http-priority </ins>
Code change:
Clarifies . 1- + HEAD is used to get a resource checksum 2- no Digest in request for clarity 3- only use sha-256 to focus on the actual example.
Digest can be sent in requests and response Nope, in the example Digest is both in the request and in the response. See the hidden 607 line URL When used in conjuction with signatures, the client that want to certify that no-payload was attached will: compute the Digest of an empty string sign that Digest header with some signature mechanism attach the signature and digest to the request send the request with no payload data The server will then: verify the signature according to the chosen mechanism if no payload is provided, the Digest is the one of an empty string eventually store the signature to prove that the request had no payload Clearly the signature mechanism should provide enough information to define the semantic of the request (eg. the method and all relevant headers). HTH, R.
Well. So the Digest is for the empty request payload. Maybe it would be good to state this in the spec? (That said, this is IMHO a very misleading example, as the HTTP spec is very clear that GET/HEAD request bodies ("A payload within a HEAD request message has no defined semantics; sending a payload body on a HEAD request might cause some existing implementations to reject the request."). It would probably better to have this example on a request that actually can take meaningful payload...
+1
NAME PTAL :)
I'll repeat what I said earlier: "That said, this is IMHO a very misleading example, as the HTTP spec is very clear that GET/HEAD request bodies ("A payload within a HEAD request message has no defined semantics; sending a payload body on a HEAD request might cause some existing implementations to reject the request."). It would probably better to have this example on a request that actually can take meaningful payload..."
In order to make progress here, I suggest we simplify the example to remove the Request digest. That keeps the example focused on it's name "Server Returns No Representation Data".
NAME removed Digest from the HEAD request.
NAME PTAL ;)
NAME PTAL :)
YAY :rocket:
In 10.2 Server Returns No Representation Data: what does the Digest request header field on the HEAD request refer to, and what is the recipient supposed to do with it? there's only one digest in the response, but the prose talks about two
Requests without payload data can still send a field applying the digest-algorithm to an empty representation. The recipient can validate that the digest-value matches the one of an empty representation or not. True. this is confusing, should reference the previous example.:

Related discussion:
text: SEMANTICS) of a resource identified according to Section 6.4.2 of SEMANTICS together with an indication of the algorithm used: <ins> When a message has no representation data it is still possible to assert that no representation data was sent computing the representation digest on an empty string (see usage-in-signatures). </ins> The checksum is computed using one of the digest-algorithms listed in algorithms and then encoded in the associated format.
Code change:
references RFC6515 and 6194 for deprecating md5 and sha1 Since there are RFCs, we could even skip explaining that those algorithms are vulnerable to collisions.
cc: NAME
NAME feel free to PR for the rest of the algorithms :P
In s12.2, should refer (informatively) to and for IETF references that deprecate the use of md5 and sha1, respectively.
Thanks for the pointers, sgtm
You beat me to the PR!

Related discussion:
text: below. Some digest-algorithms, although registered, rely on vulnerable <del> algorithms: the "md5" digest-algorithm MUST NOT be used due to collision attacks CMU-836068 and the "sha" digest-algorithm MUST NOT be used due to collision attacks IACR-2020-014. </del> <ins> algorithms and MUST not be used: "md5", see CMU-836068 and NO-MD5; "sha", see IACR-2020-014 and NO-SHA1. See the references above for further information. </ins>
Code change:
references RFC6515 and 6194 for deprecating md5 and sha1 Since there are RFCs, we could even skip explaining that those algorithms are vulnerable to collisions.
cc: NAME
NAME feel free to PR for the rest of the algorithms :P
In s12.2, should refer (informatively) to and for IETF references that deprecate the use of md5 and sha1, respectively.
Thanks for the pointers, sgtm
You beat me to the PR!

Related discussion:
text: Description: The MD5 algorithm, as specified in RFC1321.  The output of this algorithm is encoded using the base64 encoding RFC4648.  This digest-algorithm MUST NOT be used as it's now <del> vulnerable to collision attacks CMU-836068. </del> <ins> vulnerable to collision attacks.  See NO-MD5 and CMU-836068. </ins> Reference: RFC1321, RFC4648, this document.
Code change:
references RFC6515 and 6194 for deprecating md5 and sha1 Since there are RFCs, we could even skip explaining that those algorithms are vulnerable to collisions.
cc: NAME
NAME feel free to PR for the rest of the algorithms :P
In s12.2, should refer (informatively) to and for IETF references that deprecate the use of md5 and sha1, respectively.
Thanks for the pointers, sgtm
You beat me to the PR!

Related discussion:
text: Description: The SHA-1 algorithm RFC3174.  The output of this algorithm is encoded using the base64 encoding RFC4648.  This digest-algorithm MUST NOT be used as it's now vulnerable to <del> collision attacks IACR-2020-014. </del> <ins> collision attacks.  See NO-SHA1 and IACR-2020-014. </ins> Reference: RFC3174, RFC6234, RFC4648, this document.
Code change:
Signed-off-by: Piotr Sikora
So, what's the difference to , then? Should we just remove perhaps?
can be also sent if the connection is terminated before or when sending HTTP request. is more generic and can be sent in response to other events as well (e.g. read/write timeouts). But more importantly, either can be sent in response to the same event (i.e. connection terminated when receiving HTTP response), depending on the existing proxy implementation or various policies, i.e. "proxy should be as specific as it wants to be" from your last email.

Related discussion:
text: Name: connection_terminated Description: The intermediary's connection to the next hop was <del> closed before any part of the response was received.  If some part was received, see http_response_incomplete. </del> <ins> closed before complete response was received. </ins> Extra Parameters: None. Recommended HTTP status code: 502 <ins> Notes: Responses with this error type might not have been generated by the intermediary. </ins> 2.4.9. Name: connection_timeout
Code change:
This removes the in-document "issues" list and background introduction note paragraph, in line with the document's status as a working group draft backed with an issue tracker. All removed items should have corresponding issues tagged with in this repository's issue tracker (some have already been closed), so keeping them in the document was redundant and artificially inflated the page count.
NAME good idea, note added to the top, following the pattern in other drafts
LGTM. You might want to add a note at the top directing folks to the issues list, etc.; see other drafts.

Related discussion:
text: _RFC EDITOR: please remove this section before publication_ <del> This work was originally based on draft-cavage-http-signatures-12, but has since diverged from it, to reflect discussion since adoption by the HTTP Working Group.  In particular, it addresses issues that have been identified, and adds features to support new use cases.  It is a work-in-progress and not yet suitable for deployment. </del> <ins> Discussion of this draft takes place on the HTTP working group mailing list (ietf-http-wg@w3.org), which is archived at https://lists.w3.org/Archives/Public/ietf-http-wg/ [1]. Working Group information can be found at https://httpwg.org/ [2]; source code and issues list for this draft can be found at https://github.com/httpwg/http-extensions/labels/signatures [3]. </ins> 1.
Code change:
This removes the in-document "issues" list and background introduction note paragraph, in line with the document's status as a working group draft backed with an issue tracker. All removed items should have corresponding issues tagged with in this repository's issue tracker (some have already been closed), so keeping them in the document was redundant and artificially inflated the page count.
NAME good idea, note added to the top, following the pattern in other drafts
LGTM. You might want to add a note at the top directing folks to the issues list, etc.; see other drafts.

Related discussion:
text: complete access to or control over HTTP messages (such as a web browser's JavaScript environment), or may be using libraries that abstract away the details of the protocol (such as the Java <del> HTTPClient library [1]).  These applications need to be able to </del> <ins> HTTPClient library [4]).  These applications need to be able to </ins> generate and verify signatures despite incomplete knowledge of the HTTP message.
Code change:
This removes the in-document "issues" list and background introduction note paragraph, in line with the document's status as a working group draft backed with an issue tracker. All removed items should have corresponding issues tagged with in this repository's issue tracker (some have already been closed), so keeping them in the document was redundant and artificially inflated the page count.
NAME good idea, note added to the top, following the pattern in other drafts
LGTM. You might want to add a note at the top directing folks to the issues list, etc.; see other drafts.

Related discussion:
text: Signature may be verified multiple times, potentially by different entities. <del> The term "Unix time" is defined by POSIX.1 section 4.16 [2]. </del> <ins> The term "Unix time" is defined by POSIX.1 section 4.16 [5]. </ins> This document contains non-normative examples of partial and complete HTTP messages.  To improve readability, header fields may be split
Code change:
This removes the in-document "issues" list and background introduction note paragraph, in line with the document's status as a working group draft backed with an issue tracker. All removed items should have corresponding issues tagged with in this repository's issue tracker (some have already been closed), so keeping them in the document was redundant and artificially inflated the page count.
NAME good idea, note added to the top, following the pattern in other drafts
LGTM. You might want to add a note at the top directing folks to the issues list, etc.; see other drafts.

Related discussion:
text: 7.1.  URIs <del> [1] https://openjdk.java.net/groups/net/httpclient/intro.html </del> <ins> [1] https://lists.w3.org/Archives/Public/ietf-http-wg/ [2] https://httpwg.org/ [3] https://github.com/httpwg/http-extensions/labels/signatures [4] https://openjdk.java.net/groups/net/httpclient/intro.html </ins> <del> [2] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/ </del> <ins> [5] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/ </ins> V1_chap04.html#tag_04_16
Code change:
Use "content" instead of "payload data".
to reference semantics-14, including "payload data" --> "content".

Related discussion:
text: of SEMANTICS. The definitions "representation", "selected representation", <del> "representation data", "representation metadata", and "payload data" in this document are to be interpreted as described in SEMANTICS. </del> <ins> "representation data", "representation metadata", and "content" in this document are to be interpreted as described in SEMANTICS. </ins> Algorithm names respect the casing used in their definition document (eg.  SHA-1, CRC32c) whereas digest-algorithm tokens are quoted (eg.
Code change:
Use "content" instead of "payload data".
to reference semantics-14, including "payload data" --> "content".

Related discussion:
text: The representation digest is an integrity mechanism for HTTP resources which uses a checksum that is calculated independently of <del> the payload data (see Section 6.4 of SEMANTICS).  It uses the </del> <ins> the content (see Section 6.4 of SEMANTICS).  It uses the </ins> representation data (see Section 8.1 of SEMANTICS), that can be fully <del> or partially contained in the payload data, or not contained at all: </del> <ins> or partially contained in the content, or not contained at all: </ins> This takes into account the effect of the HTTP semantics on the <del> messages; for example, the payload data can be affected by Range Requests or methods such as HEAD, while the way the payload data is transferred "on the wire" is dependent on other transformations (e.g. transfer codings for HTTP/1.1 - see Section 6.1 of HTTP11).  To help </del> <ins> messages; for example, the content can be affected by Range Requests or methods such as HEAD, while the way the content is transferred "on the wire" is dependent on other transformations (e.g. transfer codings for HTTP/1.1 - see Section 6.1 of HTTP11).  To help </ins> illustrate how such things affect "Digest", several examples are provided in resource-representation.
Code change:
Use "content" instead of "payload data".
to reference semantics-14, including "payload data" --> "content".

Related discussion:
text: responds with a "Digest" field even though the client did not solicit one using "Want-Digest". <del> Some examples include JSON objects in the payload data.  For presentation purposes, objects that fit completely within the line- length limits are presented on a single line using compact notation with no leading space.  Objects that would exceed line-length limits are presented across multiple lines (one line per key-value pair) with 2 spaced of leading indentation. </del> <ins> Some examples include JSON objects in the content.  For presentation purposes, objects that fit completely within the line-length limits are presented on a single line using compact notation with no leading space.  Objects that would exceed line-length limits are presented across multiple lines (one line per key-value pair) with 2 spaced of leading indentation. </ins> "Digest" is media-type agnostic and does not provide canonicalization algorithms for specific formats.  Examples of "Digest" are calculated
Code change:
Use "content" instead of "payload data".
to reference semantics-14, including "payload data" --> "content".

Related discussion:
text: 10.2. <del> Requests without payload data can still send a "Digest" field applying the digest-algorithm to an empty representation. </del> <ins> Requests without content can still send a "Digest" field applying the digest-algorithm to an empty representation. </ins> The response "Digest" field-value is calculated over the JSON object "{"hello": "world"}", which is not shown because there is no payload
Code change:
Use "content" instead of "payload data".
to reference semantics-14, including "payload data" --> "content".

Related discussion:
text: Response: <del> Note that a "204 No Content" response without payload data but with the same "Digest" field-value would have been legitimate too. </del> <ins> Note that a "204 No Content" response without content but with the same "Digest" field-value would have been legitimate too. </ins> 10.8.
Code change:
Use "content" instead of "payload data".
to reference semantics-14, including "payload data" --> "content".

Related discussion:
text: Response: <del> Note that a "204 No Content" response without payload data but with the same "Digest" field-value would have been legitimate too. </del> <ins> Note that a "204 No Content" response without content but with the same "Digest" field-value would have been legitimate too. </ins> 10.10.
Code change:
Use "content" instead of "payload data".
to reference semantics-14, including "payload data" --> "content".

Related discussion:
text: The following examples demonstrate interactions where a client solicits a "Digest" using "Want-Digest". <del> Some examples include JSON objects in the payload data.  For presentation purposes, objects that fit completely within the line- length limits are presented on a single line using compact notation with no leading space.  Objects that would exceed line-length limits are presented across multiple lines (one line per key-value pair) with 2 spaced of leading indentation. </del> <ins> Some examples include JSON objects in the content.  For presentation purposes, objects that fit completely within the line-length limits are presented on a single line using compact notation with no leading space.  Objects that would exceed line-length limits are presented across multiple lines (one line per key-value pair) with 2 spaced of leading indentation. </ins> "Digest" is media-type agnostic and does not provide canonicalization algorithms for specific formats.  Examples of "Digest" are calculated
Code change:
Use "content" instead of "payload data".
to reference semantics-14, including "payload data" --> "content".

Related discussion:
text: 12.7. When "Digest" is used in trailer fields, the receiver gets the digest <del> value after the payload data and may thus be tempted to process the data before validating the digest value.  It is prefereable that data is only be processed after validating the Digest. </del> <ins> value after the content and may thus be tempted to process the data before validating the digest value.  It is prefereable that data is only be processed after validating the Digest. </ins> If received in trailers, "Digest" MUST NOT be discarded; instead, it MAY be merged in the header section (See Section 6.5.1 of SEMANTICS).
Code change:
Use "content" instead of "payload data".
to reference semantics-14, including "payload data" --> "content".

Related discussion:
text: The representation-data-digest of an encrypted payload can change between different messages depending on the encryption algorithm used; in those cases its value could not be used to provide a proof <del> of integrity "at rest" unless the whole (e.g. encoded) payload data is persisted. </del> <ins> of integrity "at rest" unless the whole (e.g. encoded) content is persisted. </ins> 12.9.