jiebi/CodeConvo huggingface dataset:
Code change:
11.1. <del> The Privacy Considerations in Section 12.5 of I-D.ietf-oauth- </del> <ins> The Privacy Considerations in Section 10.1 of I-D.ietf-oauth- </ins> selective-disclosure-jwt apply especially to the claim.

Related discussion:
text: Also note that .well-known has well-known issues with multi-tenancy. Most use cases will delegate the hosting of the information to registries. Also Questions: if schema is https, should the full URL be provided? (no ambiguity with .well-known, you can host schema on github, ...) metadata retrieval category re-consideration: 1) Fetch vct from a remote source: a) URL: HTTPS schema -> full URL that points to a schema b) URN: domain-defined URN that MUST be understood by the wallet; The URN method defines how to map the URN to URL and retrieve the data 2) Fetch vct the metadata locally a) local cache b) Signature (signed or unsigned header); Whether or not metadata is shared in the (un)protected header is defined by the signature format, hence out of scope of this document. 2b: point to consider for the OID4VP: should there be a flag: "archival mode" or similar, that would flag that the wallet needs to provide all the referenced content in an unprotected JWS header?
removes the requirement to insert .well-known (discussion in )
Type Metadata introduced new well-known URI /.well-known/vct/ in "6.3.1. From a URL in the vct" , but this is not reflected in appendix-A.3 Well-Known URI Registry. Additionally, using in sentence "Metadata can be retrieved from the URL URL, i.e., by inserting /.well-known/vct after the authority part of the URL." seems to me a little bit confusing as type is considered to refer to whole URI. Maybe use or (to include also query and fragment URI components)?
Thank you and yes, the registration request is missing and needs to be added. And that sentence could also be improved.
Although the use of .well-known for type metadata is being reconsidered
Current text: Since well-known only applies to HTTPS URLs, we should limit the section to HTTPS URLs although other URLs would be still possible, e.g., . Additionally, also the in is probably not correct since the type refers to the value itself which would not make sense to the full value here which would also include the scheme for instance. I suggest we update the title to "From an HTTPS URL in the claim" and update the language to something like this:
Code change:
11.1. <del> The Privacy Considerations in Section 12.5 of I-D.ietf-oauth- </del> <ins> The Privacy Considerations in Section 10.1 of I-D.ietf-oauth- </ins> selective-disclosure-jwt apply especially to the claim.

Related discussion:
text: and a few others that had gotten out of sync
Section 4.1. Key Binding JWT, says the following: But Section 5.3 does not exist in the referred spec. Instead, it should be Section 4.3
Thanks NAME A couple sections in SD-JWT were consolidated around draft 12 or 13 and other sections were renumbered as a result. We'll fix this reference and check for others that might need updating too.
see including URL
Code change:
replaced by local equivalents without affecting the protocol. Responses with status codes that are defined as heuristically <del> cacheable (e.g., 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501 in this specification) can be reused by a cache with </del> <ins> cacheable (e.g., 200, 203, 204, 206, 300, 301, 308, 404, 405, 410, 414, and 501 in this specification) can be reused by a cache with </ins> heuristic expiration unless otherwise indicated by the method definition or explicit cache controls Caching; all other status codes are not heuristically cacheable.

Related discussion:
text: Status code 308 is missing from the list in paragraph 2 of Section 9.1 of Semantics: "Responses with status codes that are defined as heuristically cacheable (e.g., 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501 in this specification) ..."
Code change:
, and response.cacheability for details of how public affects responses that would normally not be stored, due to their status <del> codes not being defined as cacheable by default; see </del> <ins> codes not being defined as heuristically cacheable; see </ins> heuristic.freshness.) 5.2.2.6.

Related discussion:
text: For .
NAME it didn't so much introduce it as much as it just changed the nature of the example.
Well, before the term "timing attack" did not appear in the spec...
... needs a rewrite. I'm thinking of splitting up into distinct sections, e.g., Cache Poisoning Timing Attacks Caching of Sensitive Information Information Leakage ... with appropriate mitigations in each (e.g., double keying).
This also adds "Timing Attacks", right. Updated change log as well.
Code change:
identical, as is the case for the compression codings defined in compression.codings. <ins> The header field (header.te) uses a pseudo parameter named "q" as rank value when multiple transfer codings are acceptable.  Future registrations of transfer codings SHOULD NOT define parameters called "q" (case-insensitively) in order to avoid ambiguities. </ins> Values to be added to this namespace require IETF Review (see RFC8126), and MUST conform to the purpose of transfer coding defined in this specification.

Related discussion:
text: That needs some tweaks ... the action words like SHOULD are supposed to be targeted to implementation roles, not protocol extensions. Can we just copy the same Note from the Accept section?
I can avoid the SHOULD NOT. I used different text because for transfer codings "we" actually own the registry, while for content types we do not...
Heh, I think it's a stretch of the imagination to think that we control the registry even when we define it ... people still deploy first and register later. In any case, a simple should be sufficient.
I actually reverse my opinion about the SHOULD NOT - we already use BCP14 keywords in the paragraphs before and after this one. So please consider again the pull request.
My .02 - acknowledging that 2119 keywords are only intended for implementations roles, I don't think that throwing up our hands and saying "people will do what they will" is productive. While some people ignore (or just don't read) the RFCs, many do, and when they do, we owe it to them to communicate in the clearest, concise way possible. 2119 keywords are a fantastic tool for doing that.
NAME - so are you ok with this change?
I am - although if we come up with a unified way to deal with requirements consistently across the documents, it might change.
Continuing from URL In the current spec, nothing is said about how to handle transfer-parameters. Notably, nothing is said about the case sensitivity of the parameter key. This results in a conflict with the TE header: if you see a "q" token, you cannot know if it is a transfer-parameter vs a t-ranking. It is noted that the "q" token is case insensitive in section 4.3.
See URL
OK. An edge case of an edge case. Note that among the currently registered transfer codings, none defines parameters. Drastic options might be: Disallow parameters on transfer codings (and thus also on content codings) Remove quality values on transfer coding negotiation. More realistic: in the registration procedure for content/transfer codings, note that a parameter "q" is discouraged (forbidden) due to the ambiguity in "TE". Should I make a proposal for this?
Actually, we have a similar situation for Accept:; see :
Not only "q" but also "Q": case sensitivity isn't mentioned for transfer parameters.
Code change:
This section marks the <del> header field registered in RFC7540 as obsoleted.  This capability has been removed: see versioning.  The registration is updated to include the details as required by HTTP: </del> <ins> header field registered by RFC7540 in the Hypertext Transfer Protocol (HTTP) Field Name Registry as obsolete.  This capability has been removed: see versioning.  The registration is updated to include the details as required by HTTP: </ins> 11.2. This section records the <del> upgrade token registered in RFC7540 as obsolete.  This capability has been removed: see versioning.  The registration is updated as </del> <ins> upgrade token registered by RFC7540 in the Hypertext Transfer Protocol (HTTP) Upgrade Token Registry as obsolete.  This capability has been removed: see versioning.  The registration is updated as </ins> follows:

Related discussion:
text: Includes changes from , as that hits the same paragraph.
why is c4d3528 included?
Hmm, poor rebase on my part I think. I made , you made the changes there, then I made a branch for this and then rebased on top of . It should go away when merged.
Code change:
_Sender-constrained refresh tokens:_ the authorization server cryptographically binds the refresh token to a certain client <del> instance, e.g. by utilizing DPoP RFC9449 or mTLS RFC8705. </del> <ins> instance, e.g., by utilizing DPoP RFC9449 or mTLS RFC8705. </ins> _Refresh token rotation:_ the authorization server issues a new refresh token with every access token refresh response.  The

Related discussion:
text: 657c1b620170b7034d0787ef711218c69572dc51 - Changes "eg." to "e.g.,". 5289949541404795e56cea41f688d43c272b2ab4 - Changes "e.g." to "e.g.,"
Code change:
A signed response would be: <ins> 4.4. The two options for protecting the workload's traffic vary with respect to implementation complexity, extensibility and security. Here is a summary of the main differences between dpop-esque-auth and http-sig-auth. The DPoP-inspired solution is less HTTP-specific, making it easier to adapt for other protocols beyond HTTP.  This flexibility is particularly valuable for asynchronous communication scenarios, such as event-driven systems. Message Signatures, on the other hand, benefit from an existing HTTP specific RFC with some established implementations.  This existing groundwork means that this option could be simpler to deploy, to the extent such implementations are available and easily integrated. Given that the WIT (Workload Identity Token) is a type of JWT, the DPoP-inspired approach that also uses JWT is less complex and technology-intensive than Message Signatures.  In contrast, Message Signatures introduce additional layers of technology, potentially increasing the complexity of the overall system. Message Signatures offer superior integrity protection, particularly by mitigating message modification by middleboxes. A key advantage of Message Signatures is that they support response signing.  This opens up the possibility for future decisions about whether to make response signing mandatory, allowing for flexibility in the specification and/or in specific deployment scenarios. In general, Message Signatures provide greater flexibility compared to the DPoP-inspired approach.  The draft (and subsequent implementations) can decide whether specific aspects of message signing, such as coverage of particular fields, should be mandatory or optional.  Covering more fields will constrain the proof so it cannot be easily reused in another context, which is often a security improvement.  The DPoP inspired approach could be designed to include extensibility to sign other fields, but this would make it closer to trying to reinvent Message Signatures. </ins> 5. The WIMSE workload identity may be carried within an X.509

Related discussion:
text: sorry about the trailing spaces ...
Some editorial things, content-wise I'm happy.
Code change:
using spare capacity is discussed in Sections 6, 11.1, and 12 of RFC3649. <ins> Wireless links While the early Internet was dominated by wired links, the properties of wireless links have become extremely important to Internet performance.  In particular, congestion controllers should be evaluated in situations where some packet losses are due to radio effects, rather than router queue drops; the link capacity varies over time due to changing link conditions; and media access delays and link-layer retransmission lead to increased jitter in round-trip times.  See RFC3819 and Section 16 of Tools for further discussion of wireless properties. </ins> Difficult Environments. The proposed algorithms should be assessed in difficult <del> environments such as paths containing wireless links. Characteristics of wireless environments are discussed in RFC3819 and in Section 16 of Tools.  Other difficult environments can include those with multipath routing within a connection.  We note that there is still much to be desired in terms of the performance of TCP in some of these difficult environments.  For congestion control mechanisms with explicit feedback from routers, difficult environments can include paths with non-IP queues at layer-two, IP tunnels, and the like.  A minimum goal for experimental mechanisms proposed for widespread deployment in the Internet should be that they do not perform significantly worse than TCP in these environments. </del> <ins> environments.  We note that there is still much to be desired in terms of the performance of TCP in some of these difficult environments.  For congestion control mechanisms with explicit feedback from routers, difficult environments can include paths with non-IP queues at layer-two, IP tunnels, and the like.  A minimum goal for experimental mechanisms proposed for widespread deployment in the Internet should be that they do not perform significantly worse than TCP in these environments. </ins> While it is impossible to enumerate all the possible "difficult environments", we note that the IETF has previously grappled with

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:
A server tests whether a content-coding for a given representation is acceptable using these rules: <ins> A representation could be encoded with multiple content codings. However, most content codings are alternative ways to accomplish the same purpose (e.g., data compression).  When selecting between multiple content codings that have the same purpose, the acceptable content coding with the highest non-zero qvalue is preferred. </ins> An Accept-Encoding header field with a field value that is empty implies that the user agent does not want any content-coding in response.  If an Accept-Encoding header field is present in a request

Related discussion:
text: …levant when some of the acceptable ones are redundant (
However, from item 4 implies otherwise. I think that this only applies if the server wishes to choose between codings, as opposed to apply them all. Compression codings are usually mutually exclusive, but other codings are not necessarily. Splitting this point into a paragraph might be the way to resolve this:
See also URL
Code change:
publishers for advertising their output and for subscribers in consuming that output.  The payload of the Catalog object is opaque to Relays and can be end-to-end encrypted.  The Catalog provides the <del> names and namespaces of the tracks being produced, along with the relationship between tracks, properties of the tracks that consumers may use for selection and any relevant initialization data. </del> <ins> names and namespaces of the tracks being produced, along with therelationship between tracks, properties of the tracks that consumers may use for selection and any relevant initialization data. </ins> The catalog track MUST have a case-sensitive Track Name of "catalog".

Related discussion:
text: Fixing table references and reformatting certain sections to 80 chars line width.
Table 2 is declared twice, as is Table 3.
Code change:
"OAuth Token Endpoint Authentication Methods" registry established by OAuth 2.0 Dynamic Client Registration Protocol RFC7591. <del> o Token Endpoint Authentication Method Name: "attest_jwt_client_auth" o Change Controller: IESG o Specification Document(s): TBC </del> <ins> Token Endpoint Authentication Method Name: "attest_jwt_client_auth" Change Controller: IESG Specification Document(s): TBC </ins>

Related discussion:
text: In the Terminology section, the term names and term definitions are run together with no punctuation between them. For example: I suggest emulating the formatting in URL
Code change:
largely independent of each other, so a blocked or stalled request or response does not prevent progress on other streams. <del> Flow control and prioritization ensure that it is possible to efficiently use multiplexed streams.  FlowControl helps to ensure that only data that can be used by a receiver is transmitted. StreamPriority ensures that limited resources can be directed to the most important streams first. </del> <ins> Effective use of multiplexing depends on flow control and prioritization.  FlowControl ensures that it is possible to efficiently use multiplexed streams by restricting data that is transmitted to what the receiver is able to handle.  StreamPriority ensures that limited resources are used most effectively.  This revision of HTTP/2 deprecates the priority signaling scheme from RFC7540. </ins> Because HTTP fields used in a connection can contain large amounts of redundant data, frames that contain them are FieldBlock.  This has

Related discussion:
text: The Priorities section itself has been replaced with a discussion of why priorities aren't there, which is all well and good (). So I found this still being in the introduction a bit odd: If we're talking about the structure of the protocol, I'd think either we don't talk about a feature that's no longer in the protocol, or we explicitly mention it's been cut out.
Code change:
act as a client on some connections and a server on others. HTTP is defined as a stateless protocol, meaning that each request <del> message can be understood in isolation.  Many implementations depend on HTTP's stateless design in order to reuse proxied connections or dynamically load balance requests across multiple servers.  Hence, a server MUST NOT assume that two requests on the same connection are from the same user agent unless the connection is secured and specific to that agent.  Some non-standard HTTP extensions (e.g., RFC4559) have been known to violate this requirement, resulting in security and interoperability problems. </del> <ins> message's semantics can be understood in isolation, and that the relationship between connections and messages on them has no impact on the interpretation of those messages.  For example, a CONNECT request (CONNECT) or a request with the Upgrade header field (field.upgrade) can occur at any time, not just in the first message on a connection.  Many implementations depend on HTTP's stateless design in order to reuse proxied connections or dynamically load balance requests across multiple servers. As a result, a server MUST NOT assume that two requests on the same connection are from the same user agent unless the connection is secured and specific to that agent.  Some non-standard HTTP extensions (e.g., RFC4559) have been known to violate this requirement, resulting in security and interoperability problems. </ins> 3.4.

Related discussion:
text: though I do wonder if HPACK/QPACK needs to be explained as well, since the order in which messages are processed does impact their compression, but not their interpretation.
I would probably say that as the semantics are still stateless, this document probably doesn't need to say anything about that. But that's a weak preference only.
The change looks good to me. That said, it might indeed be good to mention the impact of header compression.
I clarified that this was about semantics. I'm hesitant to talk about header compression, as that's likely to just confuse the matter.
I thought that was already clear. We might need to mention HPACK/QPACK anyway because they are only stateful with regard to the in-transit encoding between peers, and thus deliver stateless messages at the HTTP layer. Or something.
Clarify if the request needs to be the 1st request after a connection is opened.
Is there a reason why you ask? Are there problems when it's not the 1st request?
I'm not aware of any such problem, and for example in haproxy we do support upgrades anywhere.
Just a question I had .. which I feel the spec may want to call it out, either 1st request only or no such restriction.
Nothing in HTTP depends on where a request is placed upon a connection, because it's a stateless protocol. see last paragraph (this is likely to move to soon, which is more appropriate. Should we spell this out more clearly there?
Probably, it never hurts to remind it.
I see the case for proxies to reuse and upgrade an existing connection to the server. Mentioning this will encourage correct server implementations.
Code change:
7.1.1. <ins> Request: Response: </ins> 7.1.2. As there is no content coding applied, the "sha-256" and the "id-sha- 256" digest-values are the same. <ins> Request: Response: </ins> 7.1.3. <ins> Request: Response: </ins> 7.1.4. Digest can be used in requests too.  Returned value depends on the representation metadata header fields. <ins> Request: Response: </ins> 7.1.5. Request "Digest" value is calculated on the enclosed payload.

Related discussion:
text: Fixes artwork formatting.
[x] requests and responses to use different artworks [x] artworks not containing trailing/heading carriages
Code change:
field and to any request message that contains more than one Host header field or a Host header field with an invalid field-value. <del> 5.5. </del> <ins> 5.6. </ins> As described in intermediaries, intermediaries can serve a variety of roles in the processing of HTTP requests and responses.  Some

Related discussion:
text: and with the hope of being useful for quicwg/base-drafts I suspect that we also need to move "Initiating HTTP over TLS" down to the section on Routing, but that can be done separately.
This is now ready to merge, IMO. There is more work to do after merging, specifically taking the old RFC2818 description of initiating HTTP over TLS out and moving just the 1.1-specific bits to Messaging, but I don't want to do that in the same PR.
I agree with Roy. This is big enough that merging and iterating is the right path.
From :
Looks good enough to merge and iterate upon. Will need change notes, of course.
Code change:
An HTTP request/response exchange fully consumes a single stream.  A request starts with the HEADERS frame that puts the stream into an <del> "open" state.  The request ends with a frame bearing END_STREAM, which causes the stream to become "half-closed (local)" for the </del> <ins> "open" state.  The request ends with a frame with the END_STREAM flag set, which causes the stream to become "half-closed (local)" for the </ins> client and "half-closed (remote)" for the server.  A response stream starts with zero or more interim responses in HEADERS frames or a HEADERS frame containing a final status code.

Related discussion:
text: Going to let NAME have a look at this as well.
(Warning, I may have reached peak pedantry.) In Section 5.1, there are two references to frames which "contain" an ENDSTREAM flag. All HEADERS, CONTINUATION, and DATA frames contain this flag, which might be set or not. Most other references in the document are to the flag being set, which is more precise. There are also two references to frames "bearing" ENDSTREAM, which could be taken either way.
If you care enough to write the issue, maybe you also care enough to offer a pull request.