jiebi/CodeConvo huggingface dataset:
Code change:
The "3161-ttc" protected header parameter contains a DER-encoded RFC3161 TimeStampToken wrapped in a CBOR byte string (Major type 2). <ins> To minimize dependencies, the hash algorithm used for signing the COSE message SHOULD be the same as the algorithm used in the RFC3161 MessageImprint. </ins> 3.2. The "3161-ctt" COSE

Related discussion:
text: URL [ ] In section 3.2, there is language about minimizing dependencies by using the same hash for the timestamp and the signature. This suggestion does not seem to be unique to CTT, so I’d either repeat the language in 3.1 or move the language to a more general location that covers both use cases. [ ] In section 4, I suggest changing “the receiver MUST make sure that the message imprint in the embedded timestamp token matches either the payload or the signature fields, depending on the mode of use” to something like “the receiver MUST make sure that the message imprint in the embedded timestamp token matches a hash of the payload, signature, or signatures field, depending on the mode of use and type of COSE structure” The draft looks good to me. I have two minor suggestions. In section 3.2, there is language about minimizing dependencies by using the same hash for the timestamp and the signature. This suggestion does not seem to be unique to CTT, so I’d either repeat the language in 3.1 or move the language to a more general location that covers both use cases. In section 4, I suggest changing “the receiver MUST make sure that the message imprint in the embedded timestamp token matches either the payload or the signature fields, depending on the mode of use” to something like “the receiver MUST make sure that the message imprint in the embedded timestamp token matches a hash of the payload, signature, or signatures field, depending on the mode of use and type of COSE structure” From: Michael Jones Date: Tuesday, July 30, 2024 at 1:53 PM 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:
This specification is designed for use with HTTP (RFC2616).  The use of OAuth over any protocol other than HTTP is out of scope. <del> The OAuth 1.0 protocol (RFC5849), published as an informational document, was the result of a small ad hoc community effort.  This Standards Track specification builds on the OAuth 1.0 deployment experience, as well as additional use cases and extensibility requirements gathered from the wider IETF community.  The OAuth 2.0 protocol is not backward compatible with OAuth 1.0.  The two versions may co-exist on the network, and implementations may choose to support both.  However, it is the intention of this specification that new implementations support OAuth 2.0 as specified in this document and that OAuth 1.0 is used only to support existing deployments.  The OAuth 2.0 protocol shares very few implementation details with the OAuth 1.0 protocol.  Implementers familiar with OAuth 1.0 should approach this document without any assumptions as to its structure and details. </del> <ins> Since the publication of the OAuth 2.0 Authorization Framework (RFC6749) in October 2012, it has been updated by OAuth 2.0 for Native Apps (RFC8252) and OAuth Security Best Current Practice (I- D.ietf-oauth-security-topics).  The OAuth 2.0 Authorization Framework: Bearer Token Usage (RFC6750) has also been updated with (I-D.ietf-oauth-security-topics).  This Standards Track specification consolidates the information in all of these documents and removes features that have been found to be insecure in I-D.ietf-oauth- security-topics. </ins> 1.1.

Related discussion:
text: Edited intro to reflect what this document is about changed some OAuth 2.0 references to OAuth 2.1 when referring to this document changed document name to follow ID standard name (repo and filename should be updated as well?) pulled out acknowledgments as this doc will be different
Code change:
result of running Parsing a String (parse-string) with input_string. <del> If the first character of input_string is "*", return the result </del> <ins> If the first character of input_string is ":", return the result </ins> of running Parsing a Byte Sequence (parse-binary) with input_string. If the first character of input_string is "?", return the result of running Parsing a Boolean (parse-boolean) with input_string. <del> If the first character of input_string is an ALPHA, return the result of running Parsing a Token (parse-token) with input_string. </del> <ins> If the first character of input_string is an ALPHA or "*", return the result of running Parsing a Token (parse-token) with input_string. </ins> Otherwise, the item type is unrecognized; fail parsing.

Related discussion:
text: Missed in
I'm running my SH implementation against the HTTP Archive dumps (400,000,000+ HTTP requests) to see how the from BSH parse in something like the real world. It looks like some headers are failing because AcceptAccess-Control-Allow-Origin`. If we were to use a different character to delimit Byte Sequences, we could include in Token (necessarily as a first character, as well as in the rest, I assume). Worthwhile? If so, what should we use for Byte Sequences?
(via ) already allows , but not as a first character. '%' is short in HPACK and unlikely to trigger funny handling, but maybe it will conflict with pct-encoding to start. '=' has the virtue of being already allowed. It has the drawback of causing byte array parameters to look funny ( for instance). Interestingly, it makes removal of padding easier (base64 padding is silly).
How about ? I don't' think is a good idea; if an implementation enforces padding (which we caution against, but do not prohibit), it's confusing.
Checking with NAME NAME - any issues changing byte sequence delimiters from to ?
(the only conflicting use that comes to mind ATM for is that if someone wants to refer to H2 pseudo-headers like in a field that uses tokens, they'll be out of luck. I think that's OK, because existing fields that take header names as a list-of-tokens don't refer to pseudo-headers, and new fields can be defined as lists of tokens-or-strings.)
is free
Code change:
Note that this message abstraction is a generalization across many versions of HTTP, including features that might not be found in some versions.  For example, trailers were introduced within the HTTP/1.1 <del> chunked transfer coding as a single trailer section after the content.  An equivalent feature is present in HTTP/2 and HTTP/3 within the header block that terminates each stream.  However, multiple trailer sections interleaved with content have only been deployed as frame extensions. </del> <ins> chunked transfer coding as a trailer section after the content.  An equivalent feature is present in HTTP/2 and HTTP/3 within the header block that terminates each stream. </ins> 6.1.

Related discussion:
text: I think it would be better to separate this into the purely editorial changes (all except TRACE), and then give the change to TRACE the full treatment separately (it's a normative change after all). Will work on the former first.
Sorry for this being a question. I answered the same question for -caching by searching through and realizing that while caching might be a version-independent extension, a practical consequence of the structure of documents is that it is inextricably linked to -semantics. That's cool. Having the definition of HTTP/N rely on -caching is eminently sensible. There is a normative reference to -messaging though. Why would HTTP/3 care about that? If this were software, I'd be horrified by pulling in a dependency like that. Most of the references to -messaging are strictly examples. I could only see two cases where there was a potentially normative dependency: recommends "message/http" and . These seem like they could be broken (the second easier than the first, certainly) and the reference made normative.
I agree that this would be good.
A SHOULD-level requirement to use message/http. Moving the media type definition over is not going to help, because it essentially defines the HTTP/1.1 wire format as media type. It seems the only way to fix this would be to relax the SHOULD. That one could probably be replaced with a reference to the transfer coding registry (which is what counts here), and the pointer to the spec text would then become informative.
History in and linked issues.
Concrete recommendation for 1: a server (intermediary) responding to TRACE MUST generate a representation of the request that it received in any format. The message/http is one possible way to represent a request message, so that can be an informative reference instead.
Code change:
Note that this message abstraction is a generalization across many versions of HTTP, including features that might not be found in some versions.  For example, trailers were introduced within the HTTP/1.1 <del> chunked transfer coding as a single trailer section after the content.  An equivalent feature is present in HTTP/2 and HTTP/3 within the header block that terminates each stream.  However, multiple trailer sections interleaved with content have only been deployed as frame extensions. </del> <ins> chunked transfer coding as a trailer section after the content.  An equivalent feature is present in HTTP/2 and HTTP/3 within the header block that terminates each stream. </ins> 6.1.

Related discussion:
text: Trailers that come after the body has well-defined semantics (i.e. metadata applicable to the entire body). Interleaved, mid-stream trailers are considered and implemented as extensions, and maybe we should delay adding them to the core semantics. This is however an important topic for HTTPAPI, IMO.
See related mailing list thread at .
Discussed at Feb 21 interim; sentiment is to remove it; NAME to create a PR.
WFM, thanks.
Code change:
2.1. <del> The field-values of the HTTP header defined herein utilize the </del> <ins> The field-values of the HTTP header field defined herein utilize the </ins> following encoded form. A certificate is represented in text as an "EncodedCertificate",

Related discussion:
text: This was languishing in a PR within my repo, but since we've merged the actual draft, we can promote this to a PR in the main repo as well. (Yes, I'll rename the tag if we merge this as-is.)
Code change:
1.3.3. <del> The client credentials or other forms of client authentication (e.g. </del> <ins> The client credentials or other forms of client authentication (e.g., </ins> a private key used to sign a JWT, as described in RFC7523) can be used as an authorization grant when the authorization scope is limited to the protected resources under the control of the client,

Related discussion:
text: 657c1b620170b7034d0787ef711218c69572dc51 - Changes "eg." to "e.g.,". 5289949541404795e56cea41f688d43c272b2ab4 - Changes "e.g." to "e.g.,"
Code change:
Please update the "Hypertext Transfer Protocol (HTTP) Field Name Registry" at <https://www.iana.org/assignments/http-fields> with the <del> field names listed in the two tables of header.field.definitions. </del> <ins> field names listed in the table in header.field.definitions. </ins> 8.2.

Related discussion:
text: : I think that MAY should be prose, and should also list retrying the request as an option.
Code change:
Beyond the trusted components, Transparency Services may operate additional endpoints for auditing, for instance to query for the <del> history of Transparent Statements registered by a given Issuer via a </del> <ins> history of Signed Statements registered by a given Issuer via a </ins> certain Feed.  Implementations of Transparency Services SHOULD avoid using the service identity and extending the Registry in auditing endpoints; as much as practical, the Registry SHOULD contain enough

Related discussion:
text: NAME This is a fundamental bug in the spec, we need to correct it ASAP!
NAME Thank you for the review. I agree with most of your edits.
NAME Thanks, I have done all the required edits, please have a look!
LGTM Line item at 962 could be done later
Code change:
9. <del> We would like to thank ... </del> <ins> We would like to thank Alen Horvat, Brian Campbell, Christian Paquin, Fabian Hauck, Giuseppe De Marco, Kushal Das, Mike Jones, Nat Sakimura, Pieter Kasselman, and Torsten Lodderstedt for their contributions (some of which substantial) to this draft and to the initial set of implementations. The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway. </ins> 10.

Related discussion:
text: In this PR, I generalized the examples: Right now, there is a lot of repetition in the code for each of the three examples. With more examples (W3C VC) and more example code (claims merging) to come, things will get more complicated. I therefore moved the examples into a separate directory as YAML files. I used YAML, because this means that we can store all data required for each example as separate JSON documents in one YAML file (JSON is a subset of YAML). The code can now be called with a YAML file as the input and will run the demo for the example defined in the file. This will make it easier for us to add more examples in the future. Also in this pull request: Cleaned up the code to produce just one example each time - there is no need to calculate all examples when only one is used in each run Cleaned up the code to produce both the CLI output and the spec examples from the same set of data to avoid repetitions This means that placeholders in URL are now strictly named as follows: , where refers to the identifier of the data produced in the example run (see file). Fix for example output: serialized SVC was not shown, but serialized SD-JWT twice Renamed to (not sure what was meant to say) Fix for norandomness: RNG was seeded to static value even when no_randomness was not used
Yes, it was in my backlog, thanx. This first proposal was to get all the examples in a single shot, we can add a CLI parameter, I'll have a look for that This means that placeholders in URL are now strictly named as follows: example-{exampleid}-{artifactid}, where artifactid refers to the identifier of the data produced in the example run (see sdjwt file). Thank you, I wanted to make a proposal for this, you did it My bad it was "selected example" but artifacts is better anyway OK!
Code change:
5. <del> This document defines the "Accept-CH" and "Accept-CH-Lifetime" HTTP response fields, and registers them in the Permanent Message Header Fields registry. </del> <ins> This document defines the "Accept-CH" HTTP response field, and registers it in the Permanent Message Header Fields registry. </ins> 5.1.

Related discussion:
text: Based on discussion at IETF 105, removing explicit lifetime in favor of implicit opt-in registration and persistence. NAME can you please take a look? In particular, current language states the preference should be persisted but doesn't explicitly state for what the lifetime is.. Modulo, in privacy section we do talk about MUST criteria for clearing it. Any suggestions or recommendations for how to best approach this?
LGTM
Code change:
learn what range the server has currently available and initiate an indeterminate-length transfer.  For example: <del> With the Content-Range response header field indicating the (or </del> <ins> With the Content-Range response header field indicating the range (or </ins> ranges) available.  For example: The client can then issue a request for a range starting at the end

Related discussion:
text: Note this was manually incorporated into draft-ietf-httpbis-rand-access-live-03
Code change:
The default track operation is 'add'.  This value does not need to be declared in the track object. <del> 3.2.12. </del> <ins> 3.2.13. </ins> A string defining a human-readable label for the track.  Examples might be "Overhead camera view" or "Deutscher Kommentar".  Note that the JSON spec requires UTF-8 support by decoders. <del> 3.2.13. </del> <ins> 3.2.14. </ins> An integer specifying a group of tracks which are designed to be rendered together.  Tracks with the same group number SHOULD be

Related discussion:
text: Add a new root object to hold inheritable track fields. Update all examples.
I am not a big fan of this approach. This led to all sort of problems with SDP Session Level attributes. My main concerns How do we ensure the field that goes in this are not of type that represent aggregated values for all the tracks. Things like BW is easy to fall in this trap What problem is it solving other than moving these to per track level. May be I am missing something here . open to learn more, Thanks
There are no aggregated fields currently defined. All track selection properties, such as 'Bitate" apply only to that track. If multiple tracks have the same bitrate value, then that bitrate value can be placed inside a SelectionProperties object which is placed inside the Common Track Fields object. This is not moving anything to a per track level. Rather, it is providing a clear location to place track properties which are intended to be inherited by all tracks. IN the future, we may wish to add fields to the root which are not intended to be inherited, something for which the prior design left no mechanism for accomplishing.
makes sense and understand. We want to careful and not end up adding aggregates . How about we rename it "Inherirted Fields" instead and be explicit about it
In the current design, any track fields such as selectionParams, initTrack, renderGroup, packaging etc can be added at the root level. This design does not promote extensibility as it prohibits adding future fields to the root that should not be interpreted as inheritable track fields. Proposal is to add a new root object called "commonTrackFields" to explicitly hold fields intended to be inherited by all tracks. Example:
Code change:
Convert input_bytes into an ASCII string input_string; if conversion fails, fail parsing. <del> Discard any leading OWS from input_string. </del> <ins> Discard any leading SP characters from input_string. </ins> If header_type is "list", let output be the result of running Parsing a List (parse-list) with input_string.

Related discussion:
text: An alternative to - removes HTAB everywhere, replaces with .
Right now we use OWS, and suggests moving from SP to RWS for inner list separation. Should we allow tabs in SH? Error on them? If we want to allow them, 983 makes sense, as it's more consistent. However, we'll need to test for tabs...
What's the reason to allow tabs? Compatibility with current headers? Do actual tab characters show up in the wild that often?
We had them in there because we were reusing OWS, not purposefully. AFAICT they don't appear in the wild much at all. So +1 for .
LGTMThank you for working on this. LGTM.
Code change:
base64 encoding without padding encoding as defined in Section 2 of RFC7515 and stored as a string. <del> Example of a two byte status list representing 16 statuses (1-bit status list) with indices 0 to 16 (2 bytes): </del> <ins> Example of a Status List representing the statuses of 16 Referenced Tokens (1-bit status type) with indices 0 to 15 (2 bytes): These bits are concatenated: After compression and Base64URL encoding the generated Status List is: </ins> Example of a more complex status list of length 12 using 2 bit statuses (3 bytes): <ins> These bits are concatenated: byte 0 1 2 bit 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ values |1|1|0|0|1|0|0|1| |0|1|0|0|0|1|0|0| |1|1|1|1|1|0|0|1| +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / status 3 0 2 1 1 0 1 0 3 3 2 1 index 3 2 1 0 7 6 5 4 11 10 9 8 _ __/ 0xC9 0x44 0xF9 This results in the byte array: After compression and Base64URL encoding the generated Status List is: </ins> 5. This document defines the possible statuses of Referenced Tokens as

Related discussion:
text: after writing this I figured out changing the byte ordering, i.e. starting with byte 0 on the left might be a little more intuitive?
Yeah with fresh eyes I definately think that would be better.
reversed byte order and added the index to the ascii art
Code change:
The HEADERS+PRIORITY frame is identical to the HEADERS, preceded by a single reserved bit and a 31-bit priority; see StreamPriority. <del> No type-specific flags are defined. </del> <ins> HEADERS+PRIORITY uses exactly the same flags as the HEADERS frame. See HEADERS for any flags. </ins> HEADERS+PRIORITY frames MUST be associated with a stream.  If a HEADERS+PRIORITY frame is received whose stream identifier field is

Related discussion:
text: Replaced 'body' with 'payload' in instances where it would be confusing. Added a flag in the HEADERS frame for header continuations. Added pointers in HEADERS+PRIORITY and PUSH_PROMISE which reference the flags in the HEADERS frame. This should
The continuation bit is inverted with respect to the FINAL flag. Is HEADER_END a better choice? Also, if an unbounded number of frames are permitted, then you need some way to place an upper bound on size. Especially since this requires* that all frames be assembled before processing. Currently, there isn't a default maximum, a setting or an error code.
It could be. I chose this polarity so that it was immediately compatible with what implementations do today for SPDY/2/3 (they don't know about such a bit). If I recall correctly, there currently isn't an explicit limit on header size in HTTP. Unless we're willing to impose such, it is up to the implementation to reject things which are too large by RESETTING the stream. That case probably does need more expounding, though.
Let's move this discussion to the list.
NAME suggested that his header compression () would include the ability to continue header blocks across frames. We should track this as a separate issue. Important consideration is the way that header blocks mutate session state (for header compression). Interleaving of continued header frames will cause issues if we don't address this. We should also consider whether this is a general facility or not.
I believe we should fix this by declaring that, if there is a continuation happening, no new headers frame is allowed to be sent until the continuation is finished. It just gets too difficult to deal with otherwise. , martinthomson EMAIL:
To clarify - you mean that no headers frame on a different stream can be sent?
yes. It isn't the only possible solution, but it is relatively simple and it seems like it should be a rare enough case... -=R , Mark Nottingham EMAIL:
Code change:
If the "payload" is detached, the Transparency Service depends on the authentication context of the client in the Registration Policy.  If the "payload" is attached, the Transparency Service depends on both <del> the authentication context of the client, and the verification of the Signed Statement in the Registration Policy.  The details of Registration Policy are out of scope for this document. </del> <ins> the authentication context of the client (if present), and the verification of the Signed Statement in the Registration Policy.  The details of Registration Policy are out of scope for this document. </ins> If registration succeeds the following identifier MAY be used to refer to the Signed Statement that was accepted:

Related discussion:
text: Issue Also harmonize title with other endpoints
In the case of a government end point, why must client authentication be implemented. The signature on the statement is the authentication for the content and is ultimately who is making a reputation statement.
Agreed. In addition to this I think there are several places where we need to clean up seemingly helpful implementation comments which are actually harmful. For instance the mention of using auth for rate limiting is a fine thing to say but it's nothing to do with SCITT and will be done in other layers by any sensible implementation.
Resolved by
On internal or truly public instances this could be MAY