jiebi/CodeConvo huggingface dataset:
Code change:
able to interoperate with hosts on other network links in the same infrastructure as well as hosts on the global internet. <del> It may be noted that just as you can plug several Home Gateway devices together in series to form multi-layer NATs, there is nothing </del> <ins> It may be noted that just as you can plug several CE Router devices together in series to form multi-layer NATs, there is nothing </ins> preventing the owner of a stub network router from attaching it to a stub network as if that network were its infrastructure network.  In the case of an IoT wireless network, there may be no way to do this,

Related discussion:
text: And finally there's the DHCPv6 case, where we got a prefix to advertise on the stub network via DHCPv6. In this case, I think we need to write the DHCPv6 prefix to stable storage when we get it, and remove it from stable storage when it expires. We should limit the lifetime we advertise on the stub network to a constant value (e.g. 30 minutes), and then if we find the DHCPv6 prefix recorded in stable storage, we advertise a route to it on infrastructure for 30 minutes after reboot. After 30 minutes, we can erase it from stable storage so that this doesn't repeat. I think if the BR doesn't have stable storage, then if it reboots with a DHCPv6 prefix still valid on the stub network, we just have to hope that it gets the same prefix when it comes back. If it does not, then that prefix may become unreachable while hosts on the stub network are still using it. We could have the stub network snoop source addresses to discover prefixes still in use on the stub network to ameliorate this situation, but that's somewhat problematic because it's a lot of work.
I think the conclusion of the WG is that we need to have an explicit state machine for the stub router on-link prefix because it's actually quite different from the state machine for infrastructure, where for example we do not need to do DHCP. Important to mention that we need to explicitly deprecate the DHCP prefix if we switch to ULA and vice versa.
One of the things that this state machine needs to talk about is what happens if the SNAC router sees an RIO on /its/ stub network that does not have the SNAC router flag bit set. In this case, the SNAC router should treat this network as an infrastructure network and should not perform SNAC router routing functions or service discovery functions between the two networks. Essentially in this case the SNAC router functionality should be completely disabled while such an RA is seen on the stub network.
Code change:
List Provider may be the issuer of the Status List but may also be outsourced to a trusted third party. <del> 10. </del> <ins> 11. </ins> This document specifies no IANA actions.

Related discussion:
text: Defines the HTTP GET API URL
We need to document end to end the validation procedure for a JWT and CWT referencing a status list including resolution of the status list, validation of the status list and how to get the status information for the JWT referencing the status list.
Code change:
client's original signature values. The following is a non-normative example of header fields a reverse <del> proxy sets in addition to the examples in the previous sections.  The original signature is included under the identifier "sig1", and the reverse proxy's signature is included under "proxy_sig".  The proxy uses the key "rsa-test-key" to create its signature using the "rsa- v1_5-sha256" signature value.  This results in a signature input string of: </del> <ins> proxy sets in addition to the examples in the previous sections. The client's request includes a signature value under the label "sig1", which the proxy signs in addition to the "Forwarded" header defined in RFC7239.  Note that since the client's signature already covers the client's "Signature-Input" value for "sig1", this value is transitively covered by the proxy's signature and need not be added explicitly.  This results in a signature input string of: </ins> And a signature output value of: These values are added to the HTTP request message by the proxy.  The <del> different signature values are wrapped onto separate lines to increase human-readability of the result. </del> <ins> original signature is included under the identifier "sig1", and the reverse proxy's signature is included under the label "proxy_sig". The proxy uses the key "test-key-rsa" to create its signature using the "rsa-v1_5-sha256" signature algorithm, while the client's original signature was made using the key id of "test-key-rsa-pss" and an RSA PSS signature algorithm. </ins> The proxy's signature and the client's original signature can be <del> verified independently for the same message, depending on the needs of the application. </del> <ins> verified independently for the same message, based on the needs of the application.  Since the proxy's signature covers the client signature, the backend service fronted by the proxy can trust that the proxy has validated the incoming signature. </ins> 5.

Related discussion:
text: Minor editorial cleanups, including: added client cert example updated multiple signature example prepare for next revision
Code change:
5. <del> As noted above, authors are expected to do a well-rounded evaluation of the pros and cons of congestion control algorithms that are brought to the IETF.  The following guidelines are designed to help authors and the IETF community.  Concerns that fall outside the scope of these guidelines are certainly possible; these guidelines should not be considered an all-encompassing check-list. </del> <ins> Authors are expected to evaluate the congestion control algorithms that they bring to the IETF.  The working group is expecteed to complete a well-rounded evaluation of the pros and cons of an algorithm before it submits the specification for publication by the IETF. The following guidelines are designed to help authors and the IETF community.  Concerns that fall outside the scope of these guidelines are certainly possible; these guidelines should not be considered an all-encompassing check-list. </ins> When considering a proposed congestion control algorithm, the community MUST consider the following criteria.  These criteria will

Related discussion:
text: Proposed resolutions
Appears ready to merge - but has conflicts I do not know how to resolve.
You could merge it as is, but I don't like the remaining passive form too much.
Code change:
Implementers SHOULD support Client Hints opt-in mechanisms and MUST clear persisted opt-in preferences when any one of site data, <del> browsing history, browsing cache, or similar, are cleared. </del> <ins> browsing history, browsing cache, cookies, or similar, are cleared. </ins> 5.

Related discussion:
text: NAME - can you review?
The client hint spec does not seem to specify if there's a maximum lifetime for the origin opt-in preferences. There seem to be spec that the data should be cleared when site data, cookies, cache, etc. are cleared, but barring that should there be some sort of reasonable limit?
I'm new to this process; I'm not sure how to add the "client-hints" label
NAME thoughts? You were the one pushing for an implicit lifetime. Do we want to cap it?
I think that what you should say is that the browser can discard this state, but it should do so only when it drops all other state for the origin (e.g., when clearing cookies). Modeling this as part of origin-bound state like that is far easier to reason about and more reliable for sites.
We already have "Implementers SHOULD support Client Hints opt-in mechanisms and MUST clear persisted opt-in preferences when any one of site data, browsing history, browsing cache, or similar, are cleared." Do we need to also add something around origin-bound state to that?
As Safari is already capping script-set storage lifetime to 7 days (Brave does w/ cookies, plans to do for all storage too), and some other vendors have hinted at the same, I suggest a max lifetime of 7 days. Especially given the possibility that these values can be tracking vectors (discussed in the fingerprinting conversation).
The text above means that browsers that choose to set max lifetime to storage/cookies will MUST do the same for Client Hints. I don't think we need to bake in the specific max age that some UAs chose into an IETF draft.
I hear what you're saying, but the purpose of a standard is not to say "some people will act X and some folks will act Y", its to bring X and Y as close as possible. What is the use case for a lifetime of > 7 days? Like any cache value, its perf utility decreases as life time increases, but the privacy risk stays constant. Put differently, what is the concern w/ a maximum value, to at least partially constrain the privacy risk?
Sounds like the restriction you're talking about is of larger scope than Client Hints, and applies the origin storage in general. I suggest you'd try to enforce those specific values e.g.
Code change:
Implementers SHOULD support Client Hints opt-in mechanisms and MUST clear persisted opt-in preferences when any one of site data, <del> browsing history, browsing cache, or similar, are cleared. </del> <ins> browsing history, browsing cache, cookies, or similar, are cleared. </ins> 5.

Related discussion:
text: on session cookies, and Client Hints will follow out of that. At the same time, I was under the impressions that when we , we tied the lifetime of Client-Hints persistence to session cookies, but looks like we did not. I'll submit a PR on that front.
Code change:
protocols for standards -based authorization and authentication flows.  If FIDO2/WebAuthn support is not available, Client Initiated Backchannel Authentication (CIBA) provides an alternative, provided <del> that there is a channel through which the authorizations server can </del> <ins> that there is a channel through which the authorization server can </ins> contact the end user.  Examples of such a channel include device push notifications, e-mail or text messages which the user can access from their device.  If CIBA is used, additional mitigations to enforce

Related discussion:
text: Corrected typo (related to )
In the first sentence of section 3.3 you say "authorizations" instead of "authorization"
Code change:
processing. The JWT MAY contain an "iat" (issued at) claim that identifies the <del> time at which the JWT was issued.  Note that the authorization server may reject JWTs with an "iat" claim value that is unreasonably far in the past. </del> <ins> time at which the JWT was issued. </ins> The JWT MAY contain a "jti" (JWT ID) claim that provides a unique identifier for the token.  The authorization server MAY ensure

Related discussion:
text: The following changes are encapsulated in this PR: Update references from RFC7523 to RFC7521. Added a recommendation around order of validation for the two JWTs in the client_assertion parameter. Removed the note from the exp and iat claims for the client key Attestation JWT that imply this cannot be re-used across multiple requests. Removed the ability to use MAC based algorithms when producing the client key Attestation JWT. Updated the requirements around the presence of the JTI claim for the client key attestation PoP to be a MUST inline with DPoP PoPs for reliable basic replay attack detection mechanism. Added references to the JWT RFC. Added an implementation consideration that highlights a client instance can re-use a client key attestation JWT in multiple AS interactions/requests. Added aud as a required claim in the client attestation pop JWT. Add IANA registration request for the new client assertion type and token endpoint authentication method.
Code change:
any encryption mechanism. Implementers MUST ensure that the transport protocol provides <del> confidentiality if the privacy of End-User data or correlation attacks by passive observers are a concern. </del> <ins> confidentiality if the privacy of user data or correlation attacks by passive observers are a concern. </ins> To encrypt the SD-JWT when transmitted over an insecure channel, implementers MAY use JSON Web Encryption (JWE) RFC7516 by nesting the

Related discussion:
text: should prob add something in history just for posterity - even just a -14 with a "stuff from WGLC part deux"
Code change:
references a Status List Token.  Status Lists may be composed for expressing a range of Status Types.  This document defines basic Status Types for the most common use cases as well as an <del> extensibility mechanism for custom Status Types.  The Status List Token may be used by an issuer in the Issuer-Holder-Verifier model to express the status of verifiable credentials (Referenced Tokens) issued by an issuer. The following diagram depicts the basic conceptual relationship. </del> <ins> extensibility mechanism for custom Status Types. An example for the usage of a Status List is to manage the status of issued access tokens as defined in section 1.4 of RFC6749.  Token Introspection RFC7662 defines another way to determine the status of an issued access token, but it requires the party trying to validate an access tokens status to directly contact the token issuer, whereas the mechanism defined in this specification does not have this limitation. Another possible use case for the Status List is to express the status of verifiable credentials (Referenced Tokens) issued by an issuer in the Issuer-Holder-Verifier model.  The following diagram depicts the basic conceptual relationship. </ins> 1.1.

Related discussion:
text: Adds access token as an example use-case for status list.
Aaron says that there are zero mentions of the term access token and proposes to mention JWT accesstokens as a possible usecase
Code change:
upload's final size.  If they do not match, the server MUST reject the request with a "400 (Bad Request)" status code. <ins> The following example shows an upload append.  The client transfers the next 100 bytes at an offset of 100 and does not indicate that the upload is then completed.  The server acknowledges the new offset: </ins> The client MAY automatically attempt upload resumption when the connection is terminated unexpectedly, or if a server error status code between 500 and 599 (inclusive) is received.  The client SHOULD

Related discussion:
text: This PR adds descriptions to all message exchange examples in the draft. It should make their purpose clearer and also help distinguish the two separate examples in section 4, as pointed out in .
Thank you all!
نزت
I think there's two different creation examples being shown in URL but the presentation of them isn't great and could be a source of confusion. If so, lets break them apart by having a short sentence before each example expliaining it.
Yes, these are two separate examples, which are confusing. Most of the example are in need of a proper description. I can open a PR to address this. Thank you!
Code change:
A Receipt is a Signed Statement, (cose-sign1), with addition claims in its protected header related to verifying the inclusion proof in <del> its unprotected header.  See I-D.draft-steele-cose-merkle-tree- proofs. </del> <ins> its unprotected header.  See I-D.draft-ietf-cose-merkle-tree-proofs. </ins> fig-signed-statement-cddl illustrates a normative CDDL definition for of the protected header for Signed Statements and Receipts.

Related discussion:
text: Revisit ### Validation {#validation} section fully: After refactor Originally posted by NAME in URL
Please propose a new PR.
Code change:
5.2. <del> Historically, HTTP field line values could be extended over multiple </del> <ins> Historically, HTTP/1.x field values could be extended over multiple </ins> lines by preceding each extra line with at least one space or horizontal tab (obs-fold).  This specification deprecates such line folding except within the message/http media type

Related discussion:
text: … (now entirely handled by HTTP/1.1 messaging). Include LF in discussion of what characters are invalid in field values. Require obs-fold to be processed when consuming message/http data.
Citing Ben Kaduk (URL): (i.e., that has any field line value that contains a match to the obs-fold rule) unless [...] other production, and field-value excludes CRLF, it seems that any such field line value would already be in violation of the ABNF and thus forbidden. I don't really want to advocate for including obs-fold in the field-value production in -semantics, though, so maybe accepting this nit is the least bad choice here. In RFC723x, field-value allowed obs-fold. We need to: tune the prose above, and somehow properly allow it in message/http (maybe by modifying the field-value for that specific case???)
see also URL
This is a good change. A few things that might be worth considering, when comparing this to recent HTTP/2 changes. HTTP/2 prohibits additional things in field names: SP (0x20), COLON (0x3a), 0x01-0x1f, and 0x7f-0xff (inclusive), specifically. The other things in h2 are specific to that. That includes leading and trailing space in values (you just say "A field value does not include leading or trailing whitespace") and uppercase field characters are version-specific.
Code change:
Clients can send representation metadata (see HTTP) in the request that starts an upload.  Servers MAY interpret this metadata or MAY ignore it.  The "Content-Type" header field (HTTP) can be used to <del> indicate the media type of the file.  The content coding of the representation is specified using the "Content-Encoding" header field and is retained throughout the entire upload.  When resuming an interrupted upload, the same content coding is used for appending to the upload, producing a representation of the upload resource with one consistent content coding.  The "Content-Disposition" header field (RFC6266) can be used to transmit a filename; if included, the parameters SHOULD be either "filename", "filename*" or "boundary". </del> <ins> indicate the media type of the file.  The applied content codings are specified using the "Content-Encoding" header field and are retained throughout the entire upload.  When resuming an interrupted upload, the same content codings are used for appending to the upload, producing a representation of the upload resource.  The "Content- Disposition" header field (RFC6266) can be used to transmit a filename; if included, the parameters SHOULD be either "filename", "filename*" or "boundary". </ins> 4.1.

Related discussion:
text: Proposal for optimistic: The client needs to adapt to the header provided in the intermediate response and fail the request if the file is larger than the maximum allowed size. Proposal for Careful: The client can use the header provided in the to verify that the file is allowed to be uploaded before sending any data.Some editorial suggestions, but one big question: What is the material difference between the first and third strategy? Could these be the same strategy?
Code change:
connection and send the ConnectionHeader followed by HTTP/2 frames. Servers can identify these connections by the presence of the connection preface.  This only affects the establishment of HTTP/2 <del> connections over cleartext TCP; implementations that support HTTP/2 over TLS MUST use TLS-ALPN. </del> <ins> connections over cleartext TCP; HTTP/2 connections over TLS MUST use TLS-ALPN. </ins> Likewise, the server MUST send a ConnectionHeader.

Related discussion:
text: This text wasn't actually changed in , but I noticed it while reviewing. This says that implementations which support TLS MUST use ALPN, but that's not really tied to what the implementation supports -- it's tied to what the current connection is doing. If you support TLS but are using cleartext TCP for the current connection (regardless of why), you're not required to use ALPN.
Code change:
When an intermediary coalesces HTTP requests coming from multiple clients into one HTTP/2 or HTTP/3 connection going to the backend <del> server, requests that originate from one client might carry priority signals indicating higher precedence than those coming from others. </del> <ins> server, requests that originate from one client might carry signals indicating higher priority than those coming from others. </ins> It is sometimes beneficial for the server running behind an intermediary to obey Priority header field values.  As an example, a resource-constrained server might defer the transmission of software update files that would have the background urgency being associated. <del> However, in the worst case, the asymmetry between the precedence </del> <ins> However, in the worst case, the asymmetry between the priority </ins> declared by multiple clients might cause responses going to one user agent to be delayed totally after those going to another.

Related discussion:
text: Replace use of "precedence" that could be confusing with something better. With this PR, there are still two remaining occurrences of "precedence," in , and . I think that those two are fine, as they are surrounded by other text explaining the context. I think it'd be clear to readers that we are using the term to describe difference of importance between multiple responses. FIxes Ea of .
Thank you, this looks good. I agree with your rationale about why we don't need to remove all instances.
Code change:
dependent on the congestion response.  A subscription remains active until it expires, until the publisher of the track terminates the track with a SUBSCRIBE_FIN (see message-subscribe-fin) or a <del> SUBSCRIBE_RST (see message-subscribe-rst). </del> <ins> SUBSCRIBE_RESET (see message-subscribe-reset). </ins> A relay MUST not reorder or drop objects received on a multi-object stream when forwarding to subscribers, unless it has application

Related discussion:
text: QUIC uses RESET, we should too.
Teeechnically, QUIC uses STOP for receiver-initiated closes. But RESET is better than RST.
Code change:
feeds, traffic cameras, real-time ad selectors, and video-on-demand platforms. <del> 3.6. </del> Most HTTP communication consists of a retrieval request (GET) for a representation of some resource identified by a URI.  In the simplest case, this might be accomplished via a single bidirectional connection (===) between the user agent (UA) and the origin server (O). <del> The following example illustrates a typical message exchange for a GET request (GET) on the URI "http://www.example.com/hello.txt": Client request: Server response: 3.7. </del> <ins> 3.6. </ins> HTTP enables the use of intermediaries to satisfy requests through a chain of connections.  There are three common forms of HTTP

Related discussion:
text: seems very out of place. I could almost see it as content in 3, as a kind of introduction to the terminology. There are of course other places it could go, but the current location doesn't make much sense.
I moved the ascii art diagram back to the origin server section (where it came from in 7230) since it leads into the other diagrams.