jiebi/CodeConvo huggingface dataset:
Code change:
A means of determining the context for derivation of message components from an HTTP message and its application context. While this is normally the target HTTP message itself, the context <del> could include additional information known to the application, such as an external host name. </del> <ins> could include additional information known to the application through configuration, such as an external host name. If binding between a request and response is needed using the mechanism in content-request-response, all elements of the request and response message that would be required to provide properties of such a binding. </ins> The error messages and codes that are returned from the verifier to the signer when the signature is invalid, the key material is

Related discussion:
text: Reframe use cases that had previously signed signature values to avoid problems with this approach.
This looks good to me! Summary of the changes: Explicitly flagging that the application / implementer must specify how request-response binding is to be achieved (if desired). Removed all references to request-response binding in the main body. Removed all signatures of signatures from the examples Added guidance that applications SHOULD sign all signed components of a request when generating a signed response. Added guidance that generating signatures of signatures is NOT RECOMMENDED when generating responses. Added guidance that generating signatures of signatures is NOT RECOMMENDED when acting as a proxy between a request / response.
Code change:
HTTP/2 does not use the "Connection" header field to indicate connection-specific header fields; in this protocol, connection- specific metadata is conveyed by other means.  An endpoint MUST NOT <del> generate a HTTP/2 message containing connection-specific header </del> <ins> generate an HTTP/2 message containing connection-specific header </ins> fields; any message containing connection-specific header fields MUST be treated as malformed.

Related discussion:
text: I think "an" is correct.
An is generally used only before a vowel. As in, "A, E, I, O, and U". An can be used before a "vowel sound" as well. But "h" in "http" is neither in my book. See URL for more info.
In (British?) English, 'h' can be pronounced either as 'aytch' or as 'haytch' so I would say that both 'a' and 'an' HTTP something should be considered fine.
Let's at least be consistent.
If you pronounce 'a' as 'ahh' then "a HTTP" sounds ok. If you pronounce 'a' as 'aye' then it sounds wrong as you have two 'aye' sounds in a row unless you pronounce your 'h' as 'haytch'. American English would generally expect "an" to be used here, I think. Dialects might disagree. RFC 2616 & RFC 7230 use "an".
We had this fight (almost verbatim) for bis; "an" won. As Martin says, let's be consistent.
Code change:
5.1.1. <del> This document requests IANA to add new values to the 'COSE Algorithms' and to the 'COSE Header Algorithm Parameters' registries in the 'Standards Action With Expert Review category. </del> <ins> This document requests IANA to add the following new value to the 'Tree Algorithms' registry: Identifier: TBD_1 Tree Algorithm: ccf_ledger Reference: This document </ins>

Related discussion:
text: Thanks for the reviews, I have addressed all the comments.
NAME I don't see any reason not to merge.
okay to merge after all suggestions are accepted and remaining comments are acknowledged
Code change:
figtxtokenresponse shows a non-normative example of a Txn-Token Response. <del> 7.4. </del> <ins> 7.5. </ins> A workload within a call chain may request the Transaction Token Server to replace a Txn-Token.

Related discussion:
text: Yup. Thanks. I realized I forgot to add the IANA section after I sent out the PR. I'll update it soon.
NAME Regarding your comment about wrong approach: I mentioned something along those lines as well. I personally don't think that a new token type is actually necessary. A JWT is a good fit as it can carry the necessary data, but whether it should be signed by the workload (or what additional claims and associated checks should be incorporated) could be a decision by the individual TTS/trust domain.
NAME My point is that even the JWT structure/encoding is not needed. No need to sign anything, no need to encode stuff in base64 (and either of them adds potential security issues). All the semantics we need can be carried in a simple JSON object.
I tend to agree with Yaron, that perhaps self-signed JWTs aren't the best way to express this. We can discuss this on the call tomorrow.
Given the requirement that the TTS/AS always has to authenticate the identity of the requesting workload, conveying this info in an unsigned thing (the subject token could even contain just plain JSON) would probably be okay. Though it seems like the kind of thing that might lead to mistakes in deployment and resultant security issues.
Letting the input be any kind of JSON structure feels problematic - not least because of interop. Using a JWT as the container and then putting constraints on it (i.e. a minimal set of supported claims) will help transaction token services in parsing and making some basic determinations about security. Self-signing has pros and cons - we can make it optional for those deployments that have a risk profile that would get additional assurances from it, but as Brian notes, signing is easy to get wrong.
Well, you'd put some constraints on the JSON content too. I don't see how that'd be any more problematic from an interop perspective.
As long as there are some constraints on the format and contents that everyone would expect. Why not just use a JWT at that point though (there are libraries that support it etc)?
NAME On we discussed this topic, and while there are valid opinions on both approaches, for now I am keeping the request as a self-signed JWT unless we think this approach is problematic.
Let's go ahead and merge and then file issues if there is stuff we want to change.
Code change:
3.3.5. <ins> To sign using this algorithm, the signer applies the "ECDSA" algorithm defined in FIPS186-4 using curve P-384 with the signer's private signing key and the signature base (create-sig-input).  The hash SHA-384 RFC6234 is applied to the signature base to create the digest content to which the digital signature is applied, ("M").  The signature algorithm returns two integer values, "r" and "s".  These are both encoded as big-endian unsigned integers, zero-padded to 48-octets each.  These encoded values are concatenated into a single 96-octet array consisting of the encoded value of "r" followed by the encoded value of "s".  The resulting concatenation of "(r, s)" is byte array of the HTTP message signature output used in sign. To verify using this algorithm, the verifier applies the "ECDSA" algorithm defined in FIPS186-4 using the public key portion of the verification key material and the signature base re-created as described in verify.  The hash function SHA-384 RFC6234 is applied to the signature base to create the digest content to which the signature verification function is applied, ("M").  The verifier extracts the HTTP message signature to be verified ("S") as described in verify.  This value is a 96-octet array consisting of the encoded values of "r" and "s" concatenated in order.  These are both encoded in big-endian unsigned integers, zero-padded to 48-octets each.  The resulting signature value "(r, s)" is used as input to the signature verification function.  The results of the verification function indicate if the signature presented is valid. Note that the output of ECDSA algorithms are non-deterministic, and therefore it is not correct to re-calculate a new signature on the signature base and compare the results to an existing signature. Instead, the verification algorithm defined here needs to be used. See security-nondeterministic. Use of this algorithm can be indicated at runtime using the "ecdsa- p384-sha384" value for the "alg" signature parameter. 3.3.6. </ins> To sign using this algorithm, the signer applies the "Ed25519" algorithm defined in RFC8032 with the signer's private signing key and the signature base (create-sig-input).  The signature base is

Related discussion:
text: Define a signature algorithm named that indicates the use of ECDSA using curve P-384 DSS and SHA-384. The algorithm description is probably just 3.3.4 with "256" replaced with "384", but should validate that assumption with actual crypto folks.
What's the push for this specific curve to be included here? The reason I ask is that we shouldn't necessarily try to define ALL known algorithms in here, when it's extensible.
I agree with not defining every possible algorithm; however we should include those with known use cases, and AWS intends to use -384. Since the spec isn't finalized and the addition is trivial, it seems reasonable to add it here rather than punting it to an extension spec.
Code change:
2.2.9. If a request target URI uses HTML form parameters in the query string <del> as defined in HTMLURL, the "@query-params" component identifier allows addressing of individual query parameters.  The query parameters MUST be parsed according to HTMLURL, resulting in a list of ("nameString", "valueString") tuples.  The REQUIRED "name" parameter of each input identifier contains the "nameString" of a single query parameter as an "sf-string" value.  Several different named query parameters MAY be included in the covered components. Single named parameters MAY occur in any order in the covered components. </del> <ins> as defined in HTMLURL, the "@query-param" component identifier allows addressing of individual query parameters.  The query parameters MUST be parsed according to HTMLURL, resulting in a list of ("nameString", "valueString") tuples.  The REQUIRED "name" parameter of each input identifier contains the "nameString" of a single query parameter as an "sf-string" value.  Several different named query parameters MAY be included in the covered components.  Single named parameters MAY occur in any order in the covered components. </ins> The component value of a single named parameter is the the "valueString" of the named query parameter defined by HTMLURL, which

Related discussion:
text: If it wasn't your thinking already, I'd like to suggest that the derived component be the singular instead. When canonicalizing individual query parameters, each component identifier references a single query parameter name/value pair. The use of singular feels more appropriate to me: In the rare case where there are multiple query parameters with the same name, each one's canonical representation is still referring to a single name/value pair, so the singular still feels more appropriate: When used in the list of covered components, we still include the parameter, so each component identifier is usually [1] referring to a single query parameter name/value pair: [1]: However, in that rare case of multiple query parameters having the same name, one instance of would cover all instances of that repeated query parameter named . Perhaps the plural does make more sense for this scenario. But if there must be a singular/plural mismatch somewhere, I'd rather see it in the more rare and exceptional case. So I would propose using the name instead of . In , I see that a recent addition implemented it as the singular . I wonder if drafters already had this change in mind or if it might have been an oversight that organically tended toward what feels more natural.
Thank you for bringing this up, I think this is a valid point. I don't think there's wide support for this derived component yet so now's a good time to change it for all the good reasons you mention.
Looks good to me, will leave for a beat to get feedback from others.
Code change:
server accepts early data multiple times (though this would be in violation of requirements in TLS). <del> Clients that use early data MUST retry requests upon receipt of a 4NN </del> <ins> Clients that use early data MUST retry requests upon receipt of a 425 </ins> (Too Early) status code; see status. An intermediary MUST NOT use early data when forwarding a request

Related discussion:
text: (I accidentally put this on master without noticing earlier, sorry.)
Can we just have 425 now that it's official-ish? From martinthomson/http-replay
Code change:
can cause deployment issues, and is therefore bad practice in standards. <del> Instead of statically defining URL components like paths, it is </del> <ins> Instead of statically defining URI components like paths, it is </ins> RECOMMENDED that applications using HTTP define links in payloads, to allow flexibility in deployment.

Related discussion:
text: This change switches from "URL" to "URI" specifically for two contexts: URI schemes URI syntax (It might be good to also add an explanation somewhere in the Introduction; I can make a proposal if needed)
It is a PR, no?
Weird, it didn't show the UX for PRs before, but does now. shrug
See URL
Code change:
Specification document(s): accept-ch-lifetime of this document Related information: for Client Hints <del> 5.  References </del> <ins> 6.  References </ins> <del> 5.1.  URIs </del> <ins> 6.1.  URIs </ins> [1] https://lists.w3.org/Archives/Public/ietf-http-wg/

Related discussion:
text: NAME - can you take a look and see if that clarifies things?
This seems helpful given what's currently in the spec. However, I think some of the material I was talking about when I filed is no longer there. But I suspect that material may now be in other specs, and could perhaps still gain from being clarified at its current location.
I've been reading Client Hints (both and the ), and I'm having a little trouble understanding how things fit together in terms of which header fields are sent when and lead to what. My confusion started when I looked at the section and noticed (to my surprise) that was being registered as both a request header field and a response header field (when, having read the spec quickly, I was expecting it to be only a response header field, and wasn't sure what it would mean as a request header field). Then I looked back over the spec, and noticed that section 2 of the spec is called but that the entirety of the section appears (I think) to be about response header fields. I think it would help the spec be easier to understand if it: more carefully distinguished between request header fields and response header fields, and more clearly explained what the request header field is.
lgtm, thank you!
Code change:
If more member_values remain in input_list: <del> Append a COMMA to output. </del> <ins> Append "," to output. </ins> Append a single SP to output.

Related discussion:
text: The term COMMA is not defined anywhere in this document, or in any of the documents it imports. But we can just use the literal instead.
Thanks.
The structured headers draft imports and uses a number of productions from RFC 5234 for typographically awkward characters and character classes (, , etc), but there is no definition of provided anywhere. Similar to the way that , , , , and are used without special treatment, can probably be replaced with wherever it occurs.
Code change:
response, as per constructing.responses.from.caches, the cache SHOULD evaluate any applicable conditional header field preconditions received in that request with respect to the corresponding validators <del> contained within the selected response. </del> <ins> contained within the stored response. </ins> A cache MUST NOT evaluate conditional header fields that only apply to an origin server, occur in a request with semantics that cannot be

Related discussion:
text: Me confused. Which PR is relevant now? Both?
The other one is an evolution of this one.
We use the phrases 'selected representation' and 'selected response' in Semantics and Caching (respectively) to refer to two completely different concepts. Can we do better?
No
I think the two concepts match pretty well (and are used correctly in the four sentences). However, I also think that "chosen response" would be okay given it is only used in four places. I really don't think it needs a separate definition, since it means what the two words mean. So, maybe.
It was actually used in a few more places as the response selected. I think I found all of them.
See .
Code change:
Reason Phrase: Provides the reason for subscription error. <ins> ContentExists: 1 if an object has been published for this subscription, 0 if not.  If 0, then the Final Group and Final Object fields will not be present. </ins> Final Group: The largest Group ID sent by the publisher in an OBJECT message in this track.

Related discussion:
text: by adding an explicit bool indicating whether any Objects were published for a subscription, similar to the explicit bool added to SUBSCRIBE_OK in .
and define: However, what happens if no objects were ever produced/sent?
Individual Comment: Oops. Two possible ways to handle this: 1) Flag indicating presence of these fields (Use Location now that is defined elsewhere?) 2) Change the semantics of the fields to be exclusive (eg: it is the first object NOT sent), so 0/0 means none.
I'm inclined towards 0/0, because optional fields are more complex to parse and I would expect the existing logic to work correctly with 0/0.
Let's say the last object delivered by the relay is . Does the relay send RESET or ? Is the subscriber able to infer the presence of future objects? What if either of those objects actually exist in the cache?
Individual Comment: If we use exclusive encoding then I'd say that the receiver shouldn't infer the existence of non-existence of the named object, and either 5/30 or 6/0 works, but 5/30 is preferable?
If you define there will be no objects greater than or equal to these, then 0/0 makes total sense. So 0/0 for null case and say the last group ID of the last object publish was 10 then the value in SUB_FIN would be 11.
In we went with an explicit flag, so I'm inclined to do the same here for consistency.
Code change:
Reason Phrase: Provides the reason for subscription error. <ins> ContentExists: 1 if an object has been published for this subscription, 0 if not.  If 0, then the Final Group and Final Object fields will not be present. </ins> Final Group: The largest Group ID sent by the publisher in an OBJECT message in this track.

Related discussion:
text: To allow subscribers to indicate that no new subscriptions will be routed to the publisher for a given namespace. Happy to bikeshed on the name and whether we really need another frame for this.
The problem is not possible for the subscriber to reject an ANNOUNCE afterwards. This would be very useful, for example to inform a publisher that no more subscriptions will be routed to them for whatever reason. Examples: The auth parameter in ANNOUNCE has expired. Another publisher has sent an overriding ANNOUNCE (reconnect?) The broadcast has been closed remotely, ex. some moderation tool. Without this message, the only recourse for the subscriber is to close the connection. This won't work if multiple ANNOUNCE messages are pooled over the same connection, nor is it clean.
I propose two options: can be sent after . We add and to mirror . I personally hate 3 separate messages for a subscriber to close an announce, or a publisher to close a subscription. See
very trivial bikeshed comment ... I would prefer to call it something other RESET ( and also other places we use RESET ). I get the TCP analogy but I think that is the wrong way to think about this. I would prefer something like REVOKE.
how about ANNOUNCE_CANCEL to cancel an open announce ?
Conclusion is that we do need to add a new frame to end an ANNOUNCE. Additionally, there was a principle stated that we should not rely on closing the session as the typical or optimal way to close state and close either an ANNOUNCE or SUBSCRIBE.
On the call today, people tend to prefer ANNOUNCECLOSE over ANNOUNCECANCEL as a name. They also prefer merging SUBSCRIBERESET and SUBSCRIBEFIN into a single message, possibly SUBSCRIBE_CLOSE.
On an editorial note, it'd be nice to have subsections for publisher/subscriber to make it clearer to the reader.
If we're going to combine and , then we should just combine and now. My desire is to have four messages: publisher create: ANNOUNCE publisher close: UNANNOUNCE subscriber accept: ANNOUNCEOK subscriber close: ANNOUNCESTOP The same goes for subscriptions: subscriber create: SUBSCRIBE subscriber close: UNSUBSCRIBE publisher accept: SUBSCRIBEOK publisher close: SUBSCRIBESTOP
Code change:
Reason Phrase: Provides the reason for subscription error. <ins> ContentExists: 1 if an object has been published for this subscription, 0 if not.  If 0, then the Final Group and Final Object fields will not be present. </ins> Final Group: The largest Group ID sent by the publisher in an OBJECT message in this track.

Related discussion:
text: PR updated, PTAL
This came out of discussion on When a relay receives an SUBSCRIBE it may need to issue its own SUBSCRIBE to a publisher that has previously ANNOUNCE'd a namespace matching that track. The current draft doesn't specify how this match is done. A relay could implement an exact match on Track Namespace (requires a tweak to SUBSCRIBE), or could do a longest prefix match on track name vs all ANNOUNCE'd namespaces, or possibly something else. Is it ok to leave this up to implementations or should the draft specify this behavior more exactly? If more than one matching type is allowed, does it need to be negotiated, and by whom (publisher, subscriber, or both)?
An issue that came up in interop that is somewhat related - NAME relay was implemented to take the namespace from the connect URL, because in his use-case, ANNOUNCE can be made redundant with the connect URL (eg it contains a namespace and enough auth). However, this caused an interop problem because my chat application assumes a certain functionality from relays, and that includes supporting ANNOUNCE messages to determine routing to publishers. Do we need to be more prescriptive about relay behavior?
ANNOUNCE is what my implementation expects as well. A producer can announce track namespaces at any point (after being connected). Overloading connect URL with track info is limiting
This is going to be a slightly long comment but this is how I think this should work. The catalog has two fields for the track namespace , and track name. We also specify in the catalog a way to form a URL from these two fields. See Teds proposal and that is catalog specific. The things we put in these track namespaces and track name fields are already canonicalized in a way defined by the catalog and URL. When the application using the moq transport puts these two fields into message, they are treated as just a bunch of bits and any comparison of them is done with bitwise compare. A relay that needs to check if a namespace matches another does not need to worry about string prep or escape encoding of the bits, the will all have been done when the catalog was formed. This allows the relays to work faster by just doing bitwise compare yet at the same time allows us to use URI at the application level. The transport draft just needs to deal with a bag of bits.