jiebi/CodeConvo huggingface dataset:
Code change:
defined in Section 5.1 with the additional parameter "auth_session", defined in auth-session. <del> The response MAY include an "auth_session" parameter which the client is expected to include on a subsequent request to the authorization challenge endpoint.  The "auth_session" parameter MAY also be included even if the authorization code was obtained through a traditional OAuth authorization code flow rather than the flow defined by this specification. </del> An example successful token response is below: <ins> The response MAY include an "auth_session" parameter which the client is expected to include on any subsequent requests to the authorization challenge endpoint, as described in auth-session.  The "auth_session" parameter MAY also be included even if the authorization code was obtained through a traditional OAuth authorization code flow rather than the flow defined by this specification. Including the "auth_session" parameter in the token response enables flows such as step-up authentication RFC9470, so that the authorization server can restore the context of a previous session and prompt only for the needed step-up factors.  See step-up-sms- example for an example application. </ins> 6.2. Upon any request to the token endpoint, including a request with a

Related discussion:
text: Sec. 6.1 (in particular the example), what is the meaning of a response with an access token, a refresh token as well as an authsession, what is the client expected to do? How should it use the authsession?
The auth_session should be cached by the client in case it is needed for the stepu-up authentication flow as described in the Appendix (section A.7).
Code change:
a known-length encoding includes length prefixes for all major message components; and <del> an indefinite-length encoding enables efficient generation of </del> <ins> an indeterminate-length encoding enables efficient generation of </ins> messages where lengths are not known when encoding starts. This format is designed to convey the semantics of valid HTTP

Related discussion:
text: Comment by NAME , Figure 1: , Figure 2: For consistency with the rest of Figure 1, you could add a comma after Content(..) and Chunk (..) : Missing word "message" : s/intermediate/indeterminate
Comment by NAME The document uses "indeterminate length" and "indefinite length" interchangeably. I would suggest either using only one, or adding "indeterminate" when the first "indefinite" appear, i.e. in :
Comment by NAME : Should these be "informational" rather than "information"?
Comment by NAME : Please reference RFC-ietf-httpbis-semantics, or , or the IANA registry: URL after "status code".
Comment by NAME : : I think HTTP/2 should be a normative reference.
Comment by NAME : Might be worth clarifying that this integer value does not include the length bytes. My comment comes from the fact that "field section" is the name of the structure containing the length, so "number of bytes in the field section" could be interpreted to include the length bytes itself.
Comment by NAME : : At this point in the text I thought this was missing the optional Informational response field, but you say explain that several paragraph later. Maybe clarify here that this is for messages that are not responses containing informational status codes, or move those paragraphs closer together?
I think that moving the paragraphs works best here.
Code change:
identifiers from the "req_wl" field in the "rctx" claim of the Txn-Token <ins> MUST NOT issue replacement Txn-token with lifetime exceeding the lifetime of the originally presented token </ins> 7.5.2. To request a replacement Txn-Token, the requester makes a Txn-Token

Related discussion:
text: Update Transaction Token Service responsibility when creating replacement tokens. Also contains minor changes for consistent language. Related URL
Code change:
can be scoped to individual end clients.  Authentication and other session information might provide this linkability. <del> 7.1.3. </del> <ins> 8.3. </ins> It is sometimes beneficial to deprioritize the transmission of one connection over others, knowing that doing so introduces a certain

Related discussion:
text: and . I've left Security Consideration as TBD, I'll fill that out in a separate PR.
The text in about the client using priority to inform request scheduling is a good one, but it belongs elsewhere.
The whole discussion about fairness is worth having, but it doesn't really go to the usual security concerns. Security concerns might cover things like DoS through over-use of prioritization (see ), or use of priority to starve others (which might cross-reference the fairness text). But I think that the fairness text should be bumped up to the top level.
Code change:
interoperability. The rich flexibility of client-driven HTTP/2 prioritization tree <del> building is rarely exercised; experience shows that clients either choose a single model optimized for a web use case (and don't vary it) or do nothing at all.  But every client builds their prioritization tree in a different way, which makes it difficult for servers to understand their intent and act or intervene accordingly. </del> <ins> building is rarely exercised.  Experience has shown that clients tend to choose a single model optimized for a web use case and experiment within the model constraints, or do nothing at all.  Furthermore, many clients build their prioritization tree in a unique way, which makes it difficult for servers to understand their intent and act or intervene accordingly. </ins> Many HTTP/2 server implementations do not include support for the priority scheme, some favoring instead bespoke server-driven schemes based on heuristics and other hints, like the content type of <del> resources and the order in which requests arrive.  For example, a server, with knowledge of the 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 server to determine how such images should be prioritized against other responses. </del> <ins> resources and the request generation order.  For example, a server, with knowledge of the 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 server to determine how such images should be prioritized against other responses. </ins> The HTTP/2 scheme allows intermediaries to coalesce multiple client trees into a single tree that is used for a single upstream HTTP/2

Related discussion:
text: A few editorial tweaks to improve readability, including some x-refs to the Header / frames. The most contentious change is at L262, the sentence read a bit weird so I juggled it around to make the intent (as I understand it) clearer.
Thank you for the changes. L262 reads better now. Thank you.
Code change:
subscription request is cached and shared among the pending subscribers. <ins> The application SHOULD use a relevant error code in SUBSCRIBE_ERROR, as defined below: </ins> 5.2. Publishing through the relay starts with publisher sending ANNOUNCE

Related discussion:
text: This was previously part of . It allows an object to be sent in a datagram f it fits, and put on a stream if it doesn't.
Linking some feedback raised in the original PR that has not yet been addressed: URL URL
Looks like a great starting point to me.
Code change:
subscription request is cached and shared among the pending subscribers. <ins> The application SHOULD use a relevant error code in SUBSCRIBE_ERROR, as defined below: </ins> 5.2. Publishing through the relay starts with publisher sending ANNOUNCE

Related discussion:
text: Update main to reflect the tx-mode branch after was merged.
Agreed, but I'm not sure there's any normative language there. Is this a case of writing a paragraph cautioning that such limits could cause issues?
Whoa, I've missed some PRs, but LGTMIndividual Review: There was some feedback on previous iterations about this PR lacking guidance when encountering flow control limits (eg: send as datagram, relay converts to stream, but is out of streams or flow control)
Code change:
claims, to make statements about the Subject of the Verifiable Credential. <del> 1.1. </del> <ins> 1.3. </ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 RFC2119. <del> 1.2. </del> <ins> 1.4. </ins> 2.

Related discussion:
text: I believe I addressed all the things except the ones where I created issues for NAME . Please review again NAME .
NAME approved, merging this.
The SD-JWT spec does not define how to construct the HB-JWT. It would be nice if the HB-JWT could bind the signature to the transaction, i.e., the rest of the SD-JWT combined format for presentation. I'd suggest, we define the following payload for the HB-JWT:
Because the HB-JWT does not sign any other disclosures, any non-repudiation attacks are not possible.
Note that also SD-JWT will be more specific on the HB JWT: URL
Section is empty atm
The distinction of VC-SD-JWT and VP-SD-JWT etc. is still not super clean also in terms of what the verifier receives.
Fix references to OAuth SD-JWT
Fix references to RFCs, standards etc.
Code change:
SEMANTICS together with an indication of the algorithm used (and any parameters) <del> The checksum is computed using one of the "digest-algorithms" listed in algorithms and then encoded in the associated format. </del> <ins> The checksum is computed using one of the digest-algorithms listed in algorithms and then encoded in the associated format. </ins> The example below shows the "sha-256" digest-algorithm which uses base64 encoding.

Related discussion:
text: is preliminary to Consistently use instead of . In case we need to further focus on the value, we can say or . Looking at "content-coding" vs "content coding" in URL I think that this choice makes the document more readable.
Code change:
belongs to. Other ways of proving Holder Binding MAY be used when supported by <del> the Verifier, e.g., when the Combined Format for Presentation is itself embedded in a signed JWT.  See enveloping for details. </del> <ins> the Verifier, e.g., when the Combined Format for Presentation without a Holder Binding JWT is itself embedded in a signed JWT.  See enveloping for details. </ins> If no Holder Binding JWT is included, the Combined Format for Presentation ends with the

Related discussion:
text: Addresses issue . enveloping in a single signed JWT more than one Combined Format for Presentation without a Holder Binding JWT.
Code change:
5. <del> Transparency Services are often publicly accessible.  Issuers should treat Signed Statements (rendering them as Transparent Statements) as publicly accessible.  In particular, a Signed Statement Envelope and Statement payload should not carry any private information in plaintext. Transparency Services can have an authorization policy controlling who can access the Append-only Log.  While this can be used to limit who can read the Log, it may also limit the usefulness of the system. Some jurisdictions have a Right to be Forgotten.  However, once a Signed Statement is inserted into the Append-only Log maintained by a Transparency Service, it cannot be removed from the Log. </del> <ins> Transparency Services MAY support anonymous access, Issuers MUST ensure Signed Statements submitted to public access services are acceptable for public disclosure.  In this case, Signed Statements MUST NOT carry confidential information.  Once a Signed Statement is inserted into the Append-only Log maintained by a Transparency Service, it cannot be removed from the Log.  In some deployments, a Relaying Party, such as an Auditor, might require access to Signed Statements and Statements, which can be made available through adjacent services. Transparency Services MUST enforce access control to the Append-only Log. </ins> 6.

Related discussion:
text: NAME NAME PTAL at the latest if they resolve your requested changes.
Suggest we incorporate Option 1 suggestion from Steve!I see this change as constructive, I asked Steve for clarification on his comments too.Changes as of URL improve the previous text. LGTM
Code change:
within the trust domain defined by the "aud" claim. The Transaction Token Service MUST set the "iat" claim to the time of <del> issuance of the Txn-Token.  The Transaction Token Service MUST set the "aud" claim to an identifier representing the Trust Domain of the Transaction Token Service.  If the Transaction Token Service supports multiple trust domains, then it MUST determine the correct "aud" value for this request.  The Transaction Token Service MUST set the "exp" claim to the expiry time of the Txn-Token.  The Transaction Token Service MUST set the "txn" claim to a unique ID specific to this transaction. </del> <ins> issuance of the Txn-Token. The Transaction Token Service MUST set the "aud" claim to an identifier representing the Trust Domain of the Transaction Token Service.  If the Transaction Token Service supports multiple trust domains, then it MUST determine the correct "aud" value for this request. The Transaction Token Service MUST set the "exp" claim to the expiry time of the Txn-Token.  The Txn-Token Service MAY consider any "exp" value present in the "subject_token" parameter of the Txn-Token Request in determining the "exp" value of the resulting Txn-Token. The Transaction Token Service MUST set the "txn" claim to a unique ID specific to this transaction. </ins> The Transaction Token Service MAY set the "iss" claim of the Txn- Token to a value defining the entity that signed the Txn-Token.  This <del> claim MUST be ommitted if not set. </del> <ins> claim MUST be omitted if not set. </ins> The Transaction Token Service MUST evaluate the value specified in the "scope" parameter of the request to determine the "purp" claim of

Related discussion:
text: The notes copy-pasted from the WG notes do say "when", but based on our recollection of the events during that session, the real ask was to clarify that one could use unsigned JSON objects. That is indicated in the action item (i.e. the last line in that issue description)
the following came up in the IETF 120 session about TraTs: "Add an outline on when self-signed may be useful Yaron thought self-signed wil be a footgun Suggest a simple JSON object as replacement." The description of in section 7.1 is too rigid as it only allows an inbound token or a self-signed token. It should make it clear that an implementation may choose to have any different format for the subjecttoken.
Just a few very minor comments
Code change:
within the trust domain defined by the "aud" claim. The Transaction Token Service MUST set the "iat" claim to the time of <del> issuance of the Txn-Token.  The Transaction Token Service MUST set the "aud" claim to an identifier representing the Trust Domain of the Transaction Token Service.  If the Transaction Token Service supports multiple trust domains, then it MUST determine the correct "aud" value for this request.  The Transaction Token Service MUST set the "exp" claim to the expiry time of the Txn-Token.  The Transaction Token Service MUST set the "txn" claim to a unique ID specific to this transaction. </del> <ins> issuance of the Txn-Token. The Transaction Token Service MUST set the "aud" claim to an identifier representing the Trust Domain of the Transaction Token Service.  If the Transaction Token Service supports multiple trust domains, then it MUST determine the correct "aud" value for this request. The Transaction Token Service MUST set the "exp" claim to the expiry time of the Txn-Token.  The Txn-Token Service MAY consider any "exp" value present in the "subject_token" parameter of the Txn-Token Request in determining the "exp" value of the resulting Txn-Token. The Transaction Token Service MUST set the "txn" claim to a unique ID specific to this transaction. </ins> The Transaction Token Service MAY set the "iss" claim of the Txn- Token to a value defining the entity that signed the Txn-Token.  This <del> claim MUST be ommitted if not set. </del> <ins> claim MUST be omitted if not set. </ins> The Transaction Token Service MUST evaluate the value specified in the "scope" parameter of the request to determine the "purp" claim of

Related discussion:
text: The following issue came up during the IETF 120 session on TraTs: There was a comment about some of the processing rules that was the equivalent of NULL with extra processing steps (N_A)
George and Atul recommend that we should drop the sentences after "REQUIRED A unique transaction identifier as defined in Section 2.2 of ]." Since this is a normative section, it need not have any usage guidance in there. If required we can add non-normative usage guidance such as "The txn value MAY be used to identify the call chain"
Code change:
object does not exist at any publisher and it will not be published in the future.  This SHOULD be cached. <del> 0x2 := Indicates Group does not exist.  Indicates that objects with this GroupID do not exist at any publisher and they will not be published in the future.  This SHOULD be cached. </del> 0x3 := Indicates end of Group.  ObjectId is one greater that the largest object produced in the group identified by the GroupID. <del> This is sent right after the last object in the group.  This SHOULD be cached. </del> <ins> This is sent right after the last object in the group.  If the ObjectID is 0, it indicates there are no Objects in this Group. This SHOULD be cached. </ins> 0x4 := Indicates end of Track and Group.  GroupID is one greater than the largest group produced in this track and the ObjectId is

Related discussion:
text: As I observed in this comment: URL, the missing group status seems equivalent to "End of Group" with ObjectId of 0. Additionally, there is no obvious value for ObjectId in Objects with a status of "Group Missing".
makes sense to me
Code change:
purposes, it might be advantageous to split lists into multiple instances. <ins> example-chain-header in example has an example of the "Client-Cert- Chain" header field. </ins> 2.4. This section outlines the applicable processing rules for a TLS

Related discussion:
text: It might help to refer to the example in section 2.2 and/or 2.3.
Makes sense, can add a couple forward refs.
Code change:
Unlike other parts of a message, a processor MAY decide not to validate the value of padding bytes. <ins> Truncation can be used to reduce the size of messages that have no data in trailing field sections or content.  If the trailers of a message is empty, it MAY be omitted by the encoder in place of adding a length field equal to zero.  An encoder MAY omit empty content in the same way if the trailers are also empty.  A message that is truncated at any other point is invalid; see invalid. Decoders MUST treat missing truncated fields as equivalent to having been sent with the length field sent to zero. </ins> Padding is compatible with truncation of empty parts of the messages. Zero-valued bytes will be interpreted as zero-length part, which is semantically equivalent to the part being absent.

Related discussion:
text: Basically, it saves the effort of writing stuff that you know to be empty. It's not a critical feature, but it turns out to be a simple way to deal with not sending trailers or a body. In the extreme, you can also drop headers to produce the simplest and shortest HTTP message ever: 0x0140c8. CLoses .
Hey David, I've made some larger edits here to factor the truncation text better. I've included your normative language.
The draft mentions that messages can be truncated in some places, but not in others. I think it would help to explain why one would want to truncated a message.
This is really just a neat way to avoid having to write out all of the pieces of a message. So if you don't have trailers, it's OK not to say "I have 0 trailers". The decoder is required to deal with it. Before you say "that's hard", you don't need to change the parser to deal with truncation. Adding three zero-valued bytes to the end of any message you receive does the job just fine. If it isn't truncated, those will be treated as padding.
Thanks
Code change:
5. <del> The "zstd-d" content encoding identifies a resource that is a </del> <ins> The "dcz" content encoding identifies a resource that is a </ins> "Dictionary-Compressed Zstandard" stream. <del> A "Dictionary-Compressed Zstandard" stream is a Zstandard RFC8878 stream for a response that has been compressed with an external dictionary. </del> <ins> A "Dictionary-Compressed Zstandard" stream is a binary stream that starts with a 40-byte fixed header and is followed by a Zstandard RFC8878 stream of the response that has been compressed with an external dictionary. The 40-byte header consists of a fixed 8-byte sequence followed by the 32-byte SHA-256 hash of the external dictionary that was used to compress the resource: The 40-byte header is a Zstandard skippable frame (little-endian 0x184D2A5E) with a 32-byte length (little-endian 0x00000020) that is compatible with existing Zstandard decoders. </ins> <del> Clients that announce support for zstd-d content encoding MUST be able to decompress resources that were compressed with a window size of at least 8 MB or 1.25 times the size of the dictionary, which ever is greater, up to a maximum of 128 MB. </del> <ins> Clients that announce support for dcz content encoding MUST be able to decompress resources that were compressed with a window size of at least 8 MB or 1.25 times the size of the dictionary, which ever is greater, up to a maximum of 128 MB. </ins> The window size used will be encoded in the content (currently, this can be expressed in powers of two only) and it MUST be lower than

Related discussion:
text: doesn't appear to be pre-image resistant, so I'd be concerned if we were relying on the pre-image resistance properties of SHA-2. Can we be confident that this is not now subject to potential ployglot attacks if we relied on that hash alone? That is, could two clients think that they have the same resource, but do not?
I wouldn't be comfortable switching hashes given the wider and proven use of SHA-256 and agree on the lookup case to allow content-encoding with different and multiple dictionary negotiations. Looks like a separate header is still the cleanest so the main remaining question is if we use the same style of header for both or a skippable frame for Zstandard. I also need to update the brotli citations to point to the shared dictionary draft format instead of the original brotli format. On Sun, May 12, 2024 at 7:58 PM Martin Thomson NAME wrote: >
Sorry for the late comment. It seems to me that conveying this information in the content eases the integration with Signatures and Digest. It is not clear to me if there are still possible cases where the response does not contain all the information required for processing.
Thanks
Looks like you just need to update the PR summary to reflect this change.LGTMOverall, I like this. I want to flag for others that it doesn't use the skippable frame concept.