jiebi/CodeConvo huggingface dataset:
Code change:
delivery, leaving only request order and the delivery of responses as sources of timing variability. <del> Ensuring that processing time is not dependent on the value of secrets is the best defense against any form of timing attack. </del> <ins> Ensuring that processing time is not dependent on the value of a secret is the best defense against any form of timing attack. </ins> 11.

Related discussion:
text: Values is correct in the first case, but the second should be "a value" by which it means "any value".
and 10.9: Please confirm that these instances of "value" should not be "values". Original: These include the value of settings, the manner in which flow-control windows are managed, the way priorities are allocated to streams, the timing of reactions to stimulus, and the handling of any features that are controlled by settings. ... Ensuring that processing time is not dependent on the value of secrets is the best defense against any form of timing attack. Possibly: These include the values of settings, the manner in which flow-control windows are managed, the way priorities are allocated to streams, the timing of reactions to stimulus, and the handling of any features that are controlled by settings. ... Ensuring that processing time is not dependent on secret values is the best defense against any form of timing attack.
These should both be "values".
Values is correct in the first case, but the second should be "a value" by which it means "any value".
Code change:
may not be possible if the timestamp token has been obtained outside the processing context in which the COSE object is assembled. <del> The "3161-ctt" unprotected header is defined as follows: Name: 3161-ctt Label: TBD Value Type: bstr Value Registry: Description: RFC 3161 timestamp token Reference: sec-tst-hdr-ctt of RFCthis </del> <ins> The "3161-ctt" unprotected header parameter contains a DER-encoded RFC3161 TimeStampToken wrapped in a CBOR byte string (Major type 2). </ins> 4.

Related discussion:
text: and have pointed out that the current registration requests are rather informal and could be improved using the templates in . All, I have performed a read through of the doc. A few minor language preferences for clarity have been suggested here: URL Otherwise, I was able to implement and test both modes of operation and get the desired results (with stand in labels). That indicates to me that the draft is well formed, concise, and references the other specifications appropriately that I needed to reference. I find this document useful, and we would implement and utilize in production, and support moving this forward. Two minor additional nits below: One question for the group / authors - is there a preferred set of values for the TBDs in the COSE labels section, or should that just be left as is for now? An additional style question, is it better to restate the COSE headers requested in the IANA requested format, or is it fine to reference as is done in the draft currently? e.g. current draft reads: "IANA is requested to add the two COSE header parameters described in Section 3 to the "COSE Header Parameters" subregistry of the [URL] registry." This could obviously be detailed out. Mike Prorock On Tue, Aug 13, 2024 at 11:43 AM Michael Prorock wrote:
Answering Mike P.’s question about IANA registrations, it is strongly preferred to have the IANA Considerations section follow the registration template and contain the exact values to be placed in the registry (with the Label of course, being TBD). An example of such IANA Considerations text is URL Please update the draft to add this content. Thanks, -- Mike From: Michael Prorock Sent: Friday, August 23, 2024 5:40 AM To: Michael Prorock Cc: Michael Jones ; cose Subject: Re: [COSE] Re: WGLC for draft-ietf-cose-tsa-tst-header-parameter All, I have performed a read through of the doc. A few minor language preferences for clarity have been suggested here: URL Otherwise, I was able to implement and test both modes of operation and get the desired results (with stand in labels).
Code change:
may not be possible if the timestamp token has been obtained outside the processing context in which the COSE object is assembled. <del> The "3161-ctt" unprotected header is defined as follows: Name: 3161-ctt Label: TBD Value Type: bstr Value Registry: Description: RFC 3161 timestamp token Reference: sec-tst-hdr-ctt of RFCthis </del> <ins> The "3161-ctt" unprotected header parameter contains a DER-encoded RFC3161 TimeStampToken wrapped in a CBOR byte string (Major type 2). </ins> 4.

Related discussion:
text: That indicates to me that the draft is well formed, concise, and references the other specifications appropriately that I needed to reference. I find this document useful, and we would implement and utilize in production, and support moving this forward. Two minor additional nits below: One question for the group / authors - is there a preferred set of values for the TBDs in the COSE labels section, or should that just be left as is for now? An additional style question, is it better to restate the COSE headers requested in the IANA requested format, or is it fine to reference as is done in the draft currently? e.g. current draft reads: "IANA is requested to add the two COSE header parameters described in Section 3 to the "COSE Header Parameters" subregistry of the [URL] registry." This could obviously be detailed out. Mike Prorock On Tue, Aug 13, 2024 at 11:43 AM Michael Prorock > wrote: Thanks for the additional time Mike and Ivo. I support moving this along, but I would like to perform a detailed read through. I have some time set aside for this and will have comments back next week. Mike Prorock founder - URL Ivo and I reviewed the results of the WGLC and there have been no responses whatsoever – even from the authors. We are therefore extending the WGLC for another two weeks until Tuesday, August 27th. Unless multiple people support progressing the draft, we will not request publication. Please send your reviews and feedback on the draft. Thank you, -- Mike and Ivo From: Michael Jones > Sent: Tuesday, July 30, 2024 10:53 AM To: EMAIL Subject: [COSE] WGLC for draft-ietf-cose-tsa-tst-header-parameter Hi all, This message starts the Working Group Last Call (WGLC) for URL The WGLC will run for two weeks, ending on Tuesday, August 13, 2024. Please review and send any comments or feedback to the working group. Even if your feedback is “this is ready for publication”, please let us know. Thank you, -- Mike and Ivaylo, COSE Chairs COSE mailing list -- EMAIL To unsubscribe send an email to EMAIL
Code change:
Impact on Standard TCP, SCTP RFC2960, and DCCP RFC4340. <del> Proposed congestion control mechanisms should be evaluated when competing with standard IETF congestion control RFC2581, RFC2960, RFC4340.  Alternate congestion controllers that have a significantly negative impact on traffic using standard congestion control may be suspect and this aspect should be part of the community's decision making with regards to the suitability of the alternate congestion control mechanism. </del> <ins> Evaluation of proposed congestion control mechanisms should include test cases competing with standard IETF congestion control RFC2581, RFC2960, RFC4340.  Alternate congestion controllers that have a significantly negative impact on traffic using standard congestion control may be suspect and this aspect should be part of the community's decision making with regards to the suitability of the alternate congestion control mechanism. </ins> We note that this bullet is not a requirement for strict TCP- friendliness as a prerequisite for an alternate congestion control

Related discussion:
text: The guidelines section as discussion of "Difficult Environments", starting with "The proposed algorithms should be assessed in difficult environments such as paths containing wireless links." Opinion may vary, but wireless links are probably now part of something between "a vast majority" and "a plurality" of the paths on the Internet.
I agree. Wireless serves the vast majority and are still increasing.
Gorry and Martin: wireless constraints deserve their own section. Three different phenomena to discuss Non-congestion loss Variable bandwidth on the path Jitter due to media access and link-layer retransmission
I changed based on the thread with Christian, and agreed to these insights. I think this ready.
Code change:
The "next-hop" parameter's value is an sf-string or sf-token that identifies the intermediary or origin server selected (and used, if <del> contacted) for this response.  It might be a hostname, IP address, or alias. </del> <ins> contacted) to obtain this response.  It might be a hostname, IP address, or alias. </ins> For example:

Related discussion:
text: I noticed that parameters are generally defined in terms of what happened to generate this response, whether or not the next hop was actually contacted. The exception is , which says: I think it's potentially valuable for a response to indicate what protocol it was fetched over even if it comes from cache. The remedy would be to remove that statement and align this with the other parameters by talking about 'this response'. Probably also making that more prominent in . Thoughts, NAME
Thanks!
Code change:
Many RFC 7540 server implementations do not act on HTTP/2 priority signals.  Some instead favor custom server-driven schemes based on heuristics or other hints, such as resource content type or request <del> generation order.  For example, a server, with knowledge of the </del> <ins> generation order.  For example, a server, with knowledge of an HTML </ins> document structure, might want to prioritize the delivery of images that are critical to user experience above other images, but below the CSS files.  Since client trees vary, it is impossible for the

Related discussion:
text: and This is an editorial set of changes to the intro text. The first paragraph in the "motivation for replacement" section is actually broadly applicable motivation for any priority scheme. So we can move that up and highlight that H2 and H3 are multiplexed protocols that have the need of something. This helps us to clarify that mention of HTML document loading is only an example. We also give greater exposition about the actors involved in signalling, highlighting early that servers treat signals as a suggestion and they might follow some of the guidance provided later in the document.
To avoid bitrot, I'm merging.
The introductory material tries to be general, but routinely fails to be, falling back on talking about rendering web pages. If this is the best example, it could be more direct about that. Or, if this is general, it could try to be more careful about limiting its use of "document" and so forth to examples. For example, this lacks sufficient context: And this launches into talking about HTML without saying HTML:
good catch. I do think this is the best example and therefore will take your first suggestion. I'll follow up with a PR.
I have an unpushed branch for this that conflicts with other things, but I believe solves the matter.
says in part: In the first sentence, the endpoint is the one that is applying priority based on signals (or lack thereof) from its peer. In the second, the endpoint is the one providing signals when the peer is the one that acts upon it. This is confusing.
I see what you mean but I don't have a quick fix to hand. Would "one side operates in ignorance of the needs of the other" work?
Possibly. In the first you might say a sender might operate in ignorance of the needs of a receiver; the second might then say that a receive can communicate its view of priority to inform sender behaviour. Not that prioritization is exclusively about prioritization of sending, of course.
the terms in the second sentence were written intentionally fuzzy to accommodate intermediaries in the general statement. IIRC Robin elsewhere suggested just saying client and server but that risks over simplifying or misleading.
I think it might be a good idea to using terms "sender", "receiver", as suggested by NAME
To me, that risks conflating signal sender vs data sender. Someone want to propose a PR?
Code change:
An implementer should choose sane-profile whenever cookies are created and will be sent to a user agent, such as a web browser. <del> These implementations are frequently referred to as Servers by the </del> <ins> These implementations are frequently referred to as servers by the </ins> spec but that term includes anything which primarily produces cookies.  Some potential examples:

Related discussion:
text: A number of minor misc changes and corrections to improve readability, usability, and consistency throughout the spec.
6265bis is nearly ready, but after years of changes there are probably some minor editorial issues that should be corrected. Someone (me) should proofread it and fix any problems found.
The RFC Editor will help with that.
Ah, good to know. I'll still give it a first pass to clean it up a bit.
LGTM.
Code change:
that implementations advertising only HTTP/1.0 support will not understand how to process a transfer-encoded payload.  A client MUST NOT send a request containing Transfer-Encoding unless it knows the <del> server will handle HTTP/1.1 (or later) requests; such knowledge might be in the form of specific user configuration or by remembering the version of a prior received response.  A server MUST NOT send a response containing Transfer-Encoding unless the corresponding request indicates HTTP/1.1 (or later). </del> <ins> server will handle HTTP/1.1 requests (or later minor revisions); such knowledge might be in the form of specific user configuration or by remembering the version of a prior received response.  A server MUST NOT send a response containing Transfer-Encoding unless the corresponding request indicates HTTP/1.1 (or later minor revisions). </ins> A server that receives a request message with a transfer coding it does not understand SHOULD respond with

Related discussion:
text: Chrome and Safari treat it as LF in those places, but they do not allow two CRs to end the header block (network error in Safari, empty body in Chrome). It does seem that a stricter stance is possible here, given the intersection of the results. cc NAME NAME
If we can be stricter here and just fail on CRs in headers, that sounds good to me. That having been said, I think changing behavior to anything but just rejecting the response would be worse than the status quo (Treating CRs as part of header values, for instance).
Yeah, it seems like CR CR could be treated as a network error at least. CR "after" reason phrase or individual header is less clear. But I agree that making CR part of the value isn't good.
Regarding at the end of the line, we currently say?
Code change:
that implementations advertising only HTTP/1.0 support will not understand how to process a transfer-encoded payload.  A client MUST NOT send a request containing Transfer-Encoding unless it knows the <del> server will handle HTTP/1.1 (or later) requests; such knowledge might be in the form of specific user configuration or by remembering the version of a prior received response.  A server MUST NOT send a response containing Transfer-Encoding unless the corresponding request indicates HTTP/1.1 (or later). </del> <ins> server will handle HTTP/1.1 requests (or later minor revisions); such knowledge might be in the form of specific user configuration or by remembering the version of a prior received response.  A server MUST NOT send a response containing Transfer-Encoding unless the corresponding request indicates HTTP/1.1 (or later minor revisions). </ins> A server that receives a request message with a transfer coding it does not understand SHOULD respond with

Related discussion:
text: These "(or laters)" don't seem to be accurate.
Suggest "(or later minor revisions of HTTP/1)"
Code change:
The receiver of a frame sends a WINDOW_UPDATE frame as it consumes data and frees up space in flow-control windows.  Separate WINDOW_UPDATE frames are sent for the stream- and connection-level <del> flow-control windows. </del> <ins> flow-control windows.  Receivers are advised to have mechanisms in place to avoid sending WINDOW_UPDATE frames with very small increments; see RFC1122. </ins> A sender that receives a WINDOW_UPDATE frame updates the corresponding window by the amount specified in the frame.

Related discussion:
text: For .
[x] Section 5.1.1., 3rd para: When a stream transitions out of the "idle" state, all streams that might have been initiated by that peer with a lower-valued stream identifier are implicitly transitioned to "closed". Should one say "that might have been but were not initiated by that peers" to make clear that this applies only to un-used streams? [x] Section 5.3.1 Maybe update the section heading to read "Background on Priority in HTTP/2 as per RFC7540"? [x] Section 6.5: The document implies that SETTINGS frames are ACKed in the order they are sent. Should one make this explicit? [x] Last para of 6.5, top of page 37: "If the sender of a SETTINGS frame does not receive an acknowledgement within a reasonable amount of time, it MAY issue a connection error (Section 5.4.1) of type SETTINGSTIMEOUT." Should one provide some intuition on what "reasonable" could mean? An example? It seems, an HTTP/2 sender of a SETTINGS frame could know when this was passed to the TCP layer and may have some insights on application layer RTTs. [x] Section 6.9.1: Concerning flow control, should one say something about avoiding silly windows? [x] Section 8.1.1, p52 1st para: Probably just me, but I am mildly confused by the statement about messages having a non-zero content-length field but still no data in the data frames. The reference section 6.4 of the HTTP semantics draft didn't resolve that. [x] Section 8.2.1, p53: parse error? "When a request message violates one of these requirements, an implementation SHOULD generate a Section 15.5.1 of 400 (Bad Request) status code [HTTP], [...]" [x] Section 8.4.2, 4th para: "A client can use the SETTINGSMAXCONCURRENTSTREAMS setting to limit the number of responses that can be concurrently pushed by a server. Advertising a SETTINGSMAXCONCURRENTSTREAMS value of zero disables server push by preventing the server from creating the necessary streams.
Code change:
The receiver of a frame sends a WINDOW_UPDATE frame as it consumes data and frees up space in flow-control windows.  Separate WINDOW_UPDATE frames are sent for the stream- and connection-level <del> flow-control windows. </del> <ins> flow-control windows.  Receivers are advised to have mechanisms in place to avoid sending WINDOW_UPDATE frames with very small increments; see RFC1122. </ins> A sender that receives a WINDOW_UPDATE frame updates the corresponding window by the amount specified in the frame.

Related discussion:
text: This does not prohibit a server from sending PUSHPROMISE frames; clients need to reset any promised streams that are not wanted. Confused: it disables server push, but the server can send PUSHPROMISE frames and then the client is supposed to reset a stream it wasn't willing to accept or capable of accepting? Which stream number would the server legitimately put into the PUSHPROMISE? [ ] There are a few cases where I am wondering if normative language should be used. Examples include [ ] -- 5.4.2, 2nd para, "sends an RST_STREAM frame" [x] -- 6.8, p43, 1st para, "the server can send another GOAWAY" [ ] -- 6.8, p43, 2nd para, "the sender can discard frames" [ ] -- 9.1, 3rd para, "clients can create" [ ] There may be further occurrences of "can" or similar.
FYI NAME I've updated this post to have a list of checkboxes for "addressed".
I've reviewed the changes here and I'm happy with 9/14. The others I don't think need to be addressed.
Code change:
metadata.  If these values are not identical, the data contained in the response MUST NOT be used. <ins> If the protected resource metadata was retrieved from a URL returned by the protected resource via the WWW-Authenticate "resource_metadata" parameter, then the "resource" value returned MUST be identical to the URL that the client used to make the request to the resource server.  If these values are not identical, the data contained in the response MUST NOT be used. </ins> 4. To support use cases in which the set of legitimate protected

Related discussion:
text: Should the header return the full path to the Resource Metadata document, or return the resource identifier? RS Metadata document: the client fetches the exact URL returned Resource Identifier: the client builds the metadata URL by appending .well-known... and then fetches the URL What are the implications of this for resources that differ by path? (see mailing list thread about path-based resources that require different scopes)
I'm increasingly of the view that the resource identifier should be returned, which is what the draft already does. This aligns with the value in URL , which we normatively use. I propose that we say that during IETF 118 in Prague. If we get consensus on this, it will close our last remaining issue.
I'm wondering why the ended up the other route (advertising the URI of the resource metadata instead). Advertising the resource identifier in the would be more consistent with existing OAuth specifications as you pointed out. Advertising the resource identifier in the would make it possible for the client application to fetch an application-specific metadata documents () if it can handle it and the generic one () otherwise.
Code change:
because user-agent can validate that resource retrieval succeeded before handing off to a HTML parser, video player etc. for parsing. <del> Identity digest-algorithms (e.g. "id-sha-256" and "id-sha-512") are particularly useful for end-to-end integrity because they allow piecing together a resource from different sources with different HTTP messaging characteristics.  For example, different servers that apply different content codings. </del> Note that using digest fields alone does not provide end-to-end integrity of HTTP messages over multiple hops, since metadata could be manipulated at any stage.  Methods to protect metadata are

Related discussion:
text: strip out id-* algorithms from this specid- are complex to address in this document they will be better addressed in URL
Fix typo. Thx NAME I'll wait a couple of days to allow further feedback :)
LGTM modulo the comment I made
Code change:
5.2.1. <ins> The "purp" claim captures the exact purpose of this particular transaction.  This is often much narrower than a scope value issued to an external client.  This is due to the fact that in most cases, the authorization model within the trust domain is quite different than the authorization model used with clients external to the trust domain.  To that end, it is intentional to separate the concept of scope (often fairly coarse-grained) used with external clients from the purpose of the transaction used within the trust domain.  How a given deployment represents the authorization model within the trust domain is out of scope for this specification. 5.2.2. </ins> The Txn-Token SHOULD contain an "rctx" claim.  This MAY include the IP address information of the originating user, as well as information about the computational entity that requested the Txn-

Related discussion:
text: Added a section to clarify the intent of the claim and how it is different from scope values addressing issue .
From Yaron's : need a lot more discussion of this claim, also it may be OPTIONAL too. Also, why not call it "scope" if that's what it is?
From NAME In an external to internal flow, the scopes tend to be broad. The TraT can be set to a more specific to narrow the use of the TraT. We could call it scope, but it could be confused with the OAuth scope One could set the value to the actual API that was called to be very specific We should add a sub-section to describe the above in the draft.