jiebi/CodeConvo huggingface dataset:
Code change:
If input_string is empty, fail parsing. <del> No structured data has been found; fail parsing. </del> <ins> No structured data has been found; return items (which is empty). </ins> 4.2.5.

Related discussion:
text: I'd further say that removing an element from a list must result in removing the list once the last one was removed as it is a set. So I think I'm fine with not dealing with empty lists. This then leaves us only with the empty header field alone, likely where a string or a token are expected. I don't see a reason not to support an empty string just like any other string. A header field is not just a value, it's a name+value combination. With a void value the name still serves as a boolean (present or not) and this is exactly how it's used when the field is made mandatory to distinguish between agents generations or as a signal to detect support for something. We've all filled administrative forms where the requested information was irrelevant but mandatory in the form and just left it void so that the person in charge deals with the particular case (on paper) or filled with whatever was accepted (on web forms) hoping it would just be ignored since irrelevant. For me the Accept and Host fields are exactly in this category. My concern is to be certain that a valid HTTP request can be transmitted over SH. And ironically, the only mandatory HTTP header ("Host") is also the one requiring the support for an empty value due to its mandatory nature. Willy
I have lost count of the number of packages I have received from USA where part of the address is "Denmark does not have states" :-)
Again, the purpose of SH is not to allow all possible HTTP header to be represented in the data model -- it's to solidify the 80% case and promote best (and interoperable) practice. Representing a boolean as an empty header field is not good practice.
See PR above.
I've put in the changes for the list-based header fields. It's less clear to me that it's desirable to default a missing or empty item to an empty string (strings and tokens) 0 (integers and floats), False (boolean) or a 0-length binary array (binary data); to me, those are all going to be application-specific defaults that are better specified explicitly. I'm happy to adjust the spec to make that more clear, if folks feel it already isn't.
Code change:
: The authorization server performing the assertion flow MAY <del> leverage claims from the presented authorization grant and include them in the returned access token.  The populated claims SHOULD be namespaced or validated to prevent the injection of invalid claims. </del> <ins> leverage claims from the presented JWT authorization grant and include them in the returned access token.  The populated claims SHOULD be namespaced or validated to prevent the injection of invalid claims. </ins> The representation of transcribed claims and their format is not defined in this specification.

Related discussion:
text: when "authorization grant" refers to the actual JWT being passed around, it is clearer to call it "JWT authorization grant". RFC6749 uses "authorization grant" to refer to the general concept of any grant
Code change:
6.1.1.1. AUTHORIZATION INFO parameter (key 0x02) identifies a track's <del> authorization information in a SUBSCRIBE, SUBSCRIBE_NAMESPACE or </del> <ins> authorization information in a SUBSCRIBE, SUBSCRIBE_ANNOUNCES or </ins> ANNOUNCE message.  This parameter is populated for cases where the authorization is required at the track level.  The value is an ASCII string.

Related discussion:
text: On the call today, people favored renaming to ANNOUNCES over ANNOUNCEMENTS, so I'll do that.
I call it . Because the subscriber is interested in any messages that match the prefix.
I agree with this. It is counterintuitive that SUBSCRIBE_NAMESPACE results in an ANNOUNCE request being sent to RELAY.
Speaking as an individual that came up with the name: It's terrible and anything the group comes up with is better. #sorry I'm fine with ANNOUNCEINTEREST. My suggestion is SUBSCRIBEANNOUNCEMENTS.
I like both ANNOUNCEINTEREST and SUBSCRIBEANNOUNCEMENTS. They are both long by the time we add OK and error to them. I wonder about just calling it INTEREST. I don't feel strongly about any of these names but I do like the idea of improving the name.
+1 This is clearer than ANNOUNCE-INTEREST, which is an ambiguous term for the uninitiated.
Code change:
fig-transparent-statement-edn illustrates a Transparent Statement with a detached payload, and two Receipts in its unprotected header. <del> The label 394 "receipts" in unprotected header can contain multiple Receipts. </del> <ins> The type of label 394 "receipts" in the unprotected header is a CBOR array that can contain one or more Receipts (each entry encoded as a .cbor encoded Receipts). </ins> fig-receipt-edn one of the decoded Receipt from fig-transparent- statement-edn.  The Receipt contains inclusion proofs for verifiable

Related discussion:
text: Assuming URL is merged, that document will register everything that is needed for SCITT Receipts (a profile of COSE Receipts). There is clean up work to do in the architecture. Remove the editorial notes regarding 394. Review IANA considerations (AFAIK, 394 was never requested for registration in the document, despite the editor notes).
I've merged the PR, but we need to publish a new version to the data tracker. Ideally other authors (of COSE Receipts / COMETRE) will do an editorial pass, and then push a new version to the data tracker.
I'd personally prefer to separate the mediatype exclusion (which I agree with removing) to a different PR, but would approve both anyway. LGTM
Code change:
way that is backwards compatible for peers that are unaware of the extended meaning. <ins> For example, if there is a need to provide more granularity than eight urgency levels, it would be possible to subdivide the range using an additional parameter.  Implementations that do not recognize the parameter can safely continue to use the less granular eight levels. Alternatively, the urgency can be augmented.  For example, a graphical user-agent could send a "visible" parameter to indicate if the resource being requested is within the viewport. </ins> 4. The Priority HTTP header field can appear in requests and responses.

Related discussion:
text: We landed a change to remove the semantic meanings of urgency levels but neglected to remove a considerations section that discussed this. This PR moves some of the still relevant text out of the section and nukes the stuff no longer needed.
oops, this will need a rebase...
Code change:
The self-signed JWT MAY contain other claims. <ins> 7.2.2. A requester MAY use an unsigned JSON object as a "subject_token" value.  In that case, the requester MUST set the "subject_token_type" value to: "urn:ietf:params:oauth:token-type:unsigned_json".  The value of the "subject_token" field MUST be the BASE64URL encoded value of the JSON object as described in Section 5 of RFC6848.  The JSON object in the subject token MUST contain the following fields: "sub": The subject for whom the Txn-Token is being requested.  The Txn-Token Service SHALL use this value in determining the "sub" value in the Txn-Token issued in the response to this request. "exp": The expiration time of the unsigned JSON object, which the TTS MAY use as input to determining the lifetime of the Txn-token. The unsigned JSON object MAY contain other fields, and the Txn-Token Service MAY consider them when generating the Txn-Token. </ins> 7.3. When the Transaction Token Service receives a Txn-Token Request it

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:
The self-signed JWT MAY contain other claims. <ins> 7.2.2. A requester MAY use an unsigned JSON object as a "subject_token" value.  In that case, the requester MUST set the "subject_token_type" value to: "urn:ietf:params:oauth:token-type:unsigned_json".  The value of the "subject_token" field MUST be the BASE64URL encoded value of the JSON object as described in Section 5 of RFC6848.  The JSON object in the subject token MUST contain the following fields: "sub": The subject for whom the Txn-Token is being requested.  The Txn-Token Service SHALL use this value in determining the "sub" value in the Txn-Token issued in the response to this request. "exp": The expiration time of the unsigned JSON object, which the TTS MAY use as input to determining the lifetime of the Txn-token. The unsigned JSON object MAY contain other fields, and the Txn-Token Service MAY consider them when generating the Txn-Token. </ins> 7.3. When the Transaction Token Service receives a Txn-Token Request it

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:
ts_identifier: The DID of the Transparency Service that issued the Receipt.  Verifiers MAY use this DID as a key discovery mechanism to verify the Receipt; in this case the verification is the same <del> as for Signed Statment and the signer MAY include the "kid" header parameter.  Verifiers MUST support the "did:web" method, all other methods are optional. </del> <ins> as for Signed Statement and the signer MAY include the "kid" header parameter.  Verifiers MUST support the "did:web" method, all other methods are optional. </ins> We also introduce the following requirements for the COSE signature of the Merkle Root: The SCITT version header MUST be included and its value match the <del> "version" field of the Receipt stucture. </del> <ins> "version" field of the Receipt structure. </ins> The DID of issuer header (like in Signed Statements) MUST be included and its value match the "ts_identifier" field of the

Related discussion:
text: A number of markdown formatting errors caused to fail processing and rendering. As an example, see
LGTM - nobody loves broken markdown :-)
Code change:
complete access to or control over HTTP messages (such as a web browser's JavaScript environment), or may be using libraries that abstract away the details of the protocol (such as the Java <del> HTTPClient library [1]).  These applications need to be able to </del> <ins> HTTPClient library [4]).  These applications need to be able to </ins> generate and verify signatures despite incomplete knowledge of the HTTP message.

Related discussion:
text: This removes the in-document "issues" list and background introduction note paragraph, in line with the document's status as a working group draft backed with an issue tracker. All removed items should have corresponding issues tagged with in this repository's issue tracker (some have already been closed), so keeping them in the document was redundant and artificially inflated the page count.
NAME good idea, note added to the top, following the pattern in other drafts
LGTM. You might want to add a note at the top directing folks to the issues list, etc.; see other drafts.
Code change:
8.4.2. <del> The "Accept" header field can be used by user agents to specify response media types that are acceptable.  Accept header fields can be used to indicate that the request is specifically limited to a small set of desired types, as in the case of a request for an in- line image. </del> <ins> The "Accept" header field can be used by user agents to specify their preferences regarding response media types.  For example, Accept header fields can be used to indicate that the request is specifically limited to a small set of desired types, as in the case of a request for an in-line image. </ins> The asterisk "*" character is used to group media types into ranges, with "*/*" indicating all media types and "type/*" indicating all

Related discussion:
text: (alternative approach)
AcceptAccept-CharsetAccept-Encoding`](URL) request headers is of very limited use, because: With a qvalue higher than another value, it says "send anything in preference to something specific", which isn't useful With a qvalue lower than another media type, it says "send a more specific value in preference to something else", which is already implied by HTTP With a qvalue of 0, it says "don't ever send other value" -- but a server can always ignore that, because this is an optional-to-implement extension In media types (e.g., ), it has been cargo culted a lot, but doesn't actually give the server information it can use. Can we deprecate in these headers, or at least restrict its use / give better guidance?
Discussed in Montreal; support for documenting limitations / caveats.
We can't deprecate it. We can explain when and where it isn't useful.
+1 to generalize this. However, we may want to still reference these rules from each individual header field definition.I think the first sentence needs some editorial work, but +1 to committing this first.
Code change:
If two objects belong to the same group of the same track received through the same subscription, the one with <del> (for tracks with delivery preference Peep), or </del> <ins> (for tracks with delivery preference Subgroup), or </ins> (for tracks with delivery preference Datagram) is sent first.

Related discussion:
text: (recently merged) uses "Peep" where the rest of the draft now uses "SubGroup" Personally, I wouldn't mind going back to "Peep" since we seem to keep using that term conversationally, but either way, the draft should use one name or the other, not both.
Chairs do you want to reopen this ?
Chair Comment: The working group has aligned on subgroup as the nomenclature in the document. Of course mistakes happen but let's just correct them and move on.
Oops, that was an error.
LGTM
Code change:
that seek to send at different rates or when some of the flows do not last sufficiently long to approach asymptotic behavior. <del> 3.1.4. </del> <ins> 3.1.5. </ins> A great deal of congestion control analysis concerns the steady-state behavior of long flows.  However, many Internet flows are relatively

Related discussion:
text: This is an attempt to address issue
Current version looks good to me as well, FWIW.
Thanks! Looks good to me, FWIW. :-)
I'm satisfied but won't merge until Gorry is satisfied too.This seems fine.
Code change:
capabilities.  Such an approach could support transitions away from weaker algorithms (see sec-agility). <del> A recipient MAY ignore any or all digests.  This allows the recipient to choose which hashing algorithm(s) to use for validation instead of verifying every digest. </del> <ins> A recipient MAY ignore any or all digests.  Application-specific behavior or local policy MAY set additional constraints on the processing and validation practices of the conveyed digests.  For example, validation of a subset of received digests is one approach to protection against resource exhaustion; see resource-exhaustion. </ins> A sender MAY send a digest without knowing whether the recipient supports a given hashing algorithm, or even knowing that the

Related discussion:
text: Roman Danyliw made some comments during IESG review related to receiver validation behaviour. RFC 3230 was quite relaxed about stating receiver requirements and we've followed suit by carrying over that normative langauge almost verbatim for Content-Digest and Repr-Digest. The intention has always been that applications are responsible for deciding what integrity checks are important and what validation failure means to them. Roman suggests that we make this intention more concrete by adding explicit statements. This seems like a good idea and I'll prepare a PR to this effect. Its a restatement of intent but it is new normative language, so I'll cross post to the HTTP WG list for any additional input.
Code change:
frame (WINDOW_UPDATE).  This document does not stipulate how a receiver decides when to send this frame or the value that it <del> sends.  Nor does it specify how a sender chooses to send packets. </del> <ins> sends, nor does it specify how a sender chooses to send packets. </ins> Implementations are able to select any algorithm that suits their needs.

Related discussion:
text: A couple nitpicky things that jumped out at me in another readthrough. 3.2.1: Says that the SETTINGS parameters don't need defaults because of HTTP2-Settings, but they have defaults. Removing this claim. 3.3: Says that ALPN is used for HTTPS if you don't have prior knowledge, but 3.4 says you have to use ALPN even if you do have prior knowledge. Removing the caveat in 3.3 to reconcile. 5.1: Allowing WINDOW_UPDATE to be send in reserved (remote) state. This has been discussed in-person and on-list as a reasonable client strategy (low initial window, unchoke the pushes you want), but per the current text this is actually prohibited until after receiving the HEADERS frame. 5.2.1: Fixing sentence fragment. 5.3.2: Possibly just a personal/regional style, but from/to or between/and works for me; between/to doesn't. 6.1 and 6.2 use different definitions of the padding field. Copied 6.1's to 6.2.
Thanks Mike.
Code change:
to identify clients.  The Basic authentication scheme RFC7617 MUST NOT be used unless the underlying transport is authenticated, integrity-protected and confidential (e.g., as provided the "HTTPS" <del> URL scheme, or another using TLS).  The Digest scheme RFC7616 MUST </del> <ins> URI scheme, or another using TLS).  The Digest scheme RFC7616 MUST </ins> NOT be used unless the underlying transport is similarly secure, or the chosen hash algorithm is not "MD5".

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:
authorization request.  The exact value received from the client. OPTIONAL.  The identifier of the authorization server which the <del> client can use to prevent mixup attacks, if the client interacts with more than one authorization server.  See RFC9207 for additional details on when this parameter is necessary, and how the client can use it to prevent mixup attacks. </del> <ins> client can use to prevent mix-up attacks, if the client interacts with more than one authorization server.  See mix-up and RFC9207 for additional details on when this parameter is necessary, and how the client can use it to prevent mix-up attacks. </ins> For example, the authorization server redirects the user agent by sending the following HTTP response:

Related discussion:
text: Most of the text is copied from the security BCP and only slightly adjusted. I am not sure if 2.1 needs to contain the detailed description of mix-up attacks and variants (56b6b6cdcfccf30baa124d37597d18a7cecf032e) or if it would be sufficient to add mix-up mitigations (2d07d10b9787d3798fab0913ff67ea1cd2e29d89).
Thank you, in general we have been erring on the side of leaving the detailed discussion of the security considerations in the Security BCP, and only moving the mitigation recommendations in 2.1. Would you be able to remove the detailed description from this PR?
Finally had the time for this quick revert of my latest commit. Do you think the description of mix-up is fine now? Should we add a reference to the detailed description of mix-up attacks in the security BCP?
Thanks, I added a reference to the security BCP in that section
Code change:
operators might prefer only integrity protected content be made transparent. <del> 5.1. </del> <ins> 6.1. </ins> In cases where a single merkle root and multiple inclusion paths are used to prove inclusion for multiple payloads.  There is a risk that

Related discussion:
text: This PR attempts to generalize "merkle tree alg" and associated tags for "merkle tree proof types", to: "verifiable data structure" and associated "verifiable data structure proof types". This is intended to support similar structures that provide similar proof types, but that are not based on merkle trees. We are specifically thinking of cryptographic accumulators, and the merkle^2 paper.
I'm not attached to "verifiable data structure" or "verifiable data structure proof types", just needed a word that didn't imply "trees".
The overall "verifiable data structure" generalization is fine, and doesn't impact the structure of the document too much. However, I am not fully satisfied with generalization of proof types. It seems very strange that TBD1 ("binary merkle tree using sha256", a tag that appears in the protected header of the COSE signed root) and TBD2 ("binary merkle tree using sha256, inclusion proof", a tag that appears in the CBOR type for inclusion proof associated with TBD1). It seems clear that TBD2 and TBD3 are refinements of TBD1 that should ideally be in a separate registry. Furthermore, as discussed last week, the notion of proof type (inclusion proof, consistency proof, freshness proof...) is a lot more meaningful than the notion of verfiable data structure type for protocols that build on COMETRE. Therefore, it may be natural to define either a universal type for each proof type, or at least agree on the convention that proofs for all verifiable data structures must be CBOR tagged with the same proof type, which is then defined as a separate registry. Each RFC that extends COMETE must define a new verifiable data structure but may or may not extend the proof type registry. For instance, it would allow the CCF_ledger to use the same CBOR tags for inclusion proof and consistency proof instead of having to define 3 tags with different semantics.