jiebi/CodeConvo huggingface dataset:
Code change:
this will cause parsing to fail, but it is not possible to reliably fail in all such circumstances. <del> The Display String type conveys a Unicode string without any form of sanitization.  Applications using these values need to perform their own checks on their content; for example, they might contain escape sequences, or NUL.  Mitigation strategies include escaping untrusted content before displaying it. </del> <ins> The Display String type can convey any possible Unicode code point without sanitization; for example, they might contain unassigned code points, control points (including NUL), or noncharacters.  Therefore, applications consuming Display Strings need to consider strategies such as filtering or escaping untrusted content before displaying it. See also UNICODE-SECURITY and I-D.draft-bray-unichars. </ins>

Related discussion:
text: Implementing Date in Python as a object has an issue -- Python dates are limited to a specific range. Given that it's good to expose SF as idiomatic data structures wherever possible, I poked around a bit for limits on date/time objects in libraries, and found (all expressed as limits on years, as that's the most significant bit): Python - Rust - Go - PHP - JavaScript - Ruby - Java - Should we specify a minimum range of dates that an implementation should support (likely 1-9999) so that developers can be confident of them (as we've done for other data types)?
Hm. Do these differences affect other parts of HTTP as well, such as processing the "Date" field (or fields specific to caching...?).
One would imagine that people put HTTP dates into these structures from time to time, yes.
(it's just that HTTP dates rarely go outside the range 1970 - "forseeable future")
Restricting to a year-based range would IMHO make sense if we actually would be using calendar dates (which we do not).
To be clear, I'm not proposing we restrict it -- just require implementations to support at least a particular range of values, just as we do with many other types. Don't get stuck on years, that's just a rough sizing to get an idea of what we're looking at. I think we'd express it in integer values.
I've commented in the PR that I dont like this, but let me add a bit of context: Handling of time, in real life and in computers, is incredibly messy and one of the most unreadable scientific books of all time is "Calendrical Calculations" which is our best shot at that subject matter. I really do not want us to wade into this tarpit, because everybody who has ever done so, has just added more tar in the process. My really strong preference is if Date was defined as "Seconds since Epoch" according to POSIX" with the full range of signed 15 decimal digits we inherit from Integer, so that we in no way adds any further complexity.
That's effectively what we have, even with this addition. This text is just requiring implementations to support at least a certain range, so that it can be relied upon for interoperability.
Code change:
This document defines two digest integrity mechanisms for HTTP. First, representation data integrity, which acts on representation <del> data (Section 3.2 of SEMANTICS).  Second, content digest integrity, which acts on conveyed content (Section 6.4 of SEMANTICS).  Both mechanisms operate independent of transport integrity, offering the potential to detect programming errors and corruption of data in flight or at rest.  They can be used across multiple hops in order to provide end-to-end integrity guarantees, which can aid fault diagnosis when resources are transferred across hops and system boundaries.  Finally, they can be used to validate integrity when reconstructing a resource fetched using different HTTP connections. </del> <ins> data (Section 3.2 of SEMANTICS).  Second, content integrity, which acts on conveyed content (Section 6.4 of SEMANTICS).  Both mechanisms operate independent of transport integrity, offering the potential to detect programming errors and corruption of data in flight or at rest.  They can be used across multiple hops in order to provide end- to-end integrity guarantees, which can aid fault diagnosis when resources are transferred across hops and system boundaries. Finally, they can be used to validate integrity when reconstructing a resource fetched using different HTTP connections. </ins> This document obsoletes RFC3230.

Related discussion:
text: Consistent use of "checksum".
From NAME WGLC review: Personally, I think the use of both terms is ok. Mainly because digest is overloaded in the document. But it wouldn't hurt us to review the document for usages and perhaps add a note in notational conventions about the use of terms.
is a generic checksum computation, should be the actual digest algoritm computation. We need to clarify this and probably introduce new terminology.
Code change:
6. It is not always the case that the client has the best understanding <del> of how the HTTP responses deserve to be prioritized.  For example, use of an HTML document might depend heavily on one of the inline images.  Existence of such dependencies is typically best known to the server. </del> <ins> of how the HTTP responses deserve to be prioritized.  The server might have additional information that can be combined with the client's indicated priority in order to improve the prioritization of the response.  For example, use of an HTML document might depend heavily on one of the inline images; existence of such dependencies is typically best known to the server.  Or, a server that receives requests for a font RFC8081 and images with the same urgency might give higher precedence to the font, so that a visual client can render textual information at an early moment. </ins> An origin can use the Priority response header field to indicate its view on how an HTTP response should be prioritized.  An intermediary

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:
This document is structured as follows: <del> content-digest defines the Content-Digest request and response header and trailer field, </del> <ins> New request and response header and trailer field definitions. </ins> <del> representation-digest defines the Repr-Digest request and response header and trailer field, </del> <ins> content-digest (Content-Digest), </ins> <del> want-fields defines the Want-Repr-Digest and Want-Content-Digest request and response header and trailer field, </del> <ins> representation-digest (Repr-Digest), and </ins> <del> algorithms describes algorithms and their relation to the fields defined in this document, </del> <ins> want-fields (Want-Content-Digest and Want-Repr-Digest). </ins> <del> state-changing-requests details computing representation digests, </del> <ins> Considerations specific to representation data integrity. </ins> <del> examples-unsolicited and examples-solicited provide examples of using Repr-Digest and Want-Repr-Digest. </del> <ins> state-changing-requests (State-changing requests), digest-and-content-location (Content-Location), resource-representation contains worked examples of Representation data in message exchanges, and examples-unsolicited and examples-solicited contain worked examples of Repr-Digest and Want-Repr-Digest fields in message exchanges. algorithms bootstraps a new IANA registry hash algorithms and defines registration procedures for future entries. </ins> 1.2.

Related discussion:
text: Section 1.1 is currently a bit confusing, because it leaves out sections, and does not present them in order (likely the cause of a recent re-org).
NAME do we need it?
it should either make sense, or should be removed.
NAME if it's not required, I think that the document is fine without.
mnot asked us to add one a while back, which I think helped at that point. Editorial changes in the meantime have had an effect though, so I tried to add some colour to the structure in URL Preview at URL The intention is that people can launch of from here to focus on bits they might need, like the field definitions or example. Since security and IANA sections are standard, mentioning them seems superfluous. If the opinion is that the proposal doesn't help, let's just remove the section.
Code change:
the namespace for HTTP field names. Any party can request registration of a HTTP field.  See <del> considerations.for.new.field.values for considerations to take into account when creating a new HTTP field. </del> <ins> considerations.for.new.fields for considerations to take into account when creating a new HTTP field. </ins> The "Hypertext Transfer Protocol (HTTP) Field Name Registry" is located at <https://www.iana.org/assignments/http-fields/>.

Related discussion:
text: Including a re-org of Considerations for New Fields
I think it should be mentioned as an aside in the section on common rules for defining field values.
maybe wait until RFC is out...
Code change:
JWT, besides proving Key Binding, protects the integrity of the set of Disclosures the Holder disclosed. <del> 10.12. </del> <ins> 10.11. </ins> Section 3.11 of RFC8725 describes the use of explicit typing to prevent confusion attacks in which one kind of JWT is mistaken for

Related discussion:
text: Attempt to better explain how salt in the Disclosure makes guessing the preimage of the digest infeasible Consolidate salt entropy and length security consideration subsections
question from an email, my response: The exchange makes me think a brief mention/explanation what salt does/provides in the SD-JWT context would be a worthwhile addition. Maybe just add or modify a sentence or two in sec 10.3. And/or something in URL where the salt value in the Disclosure is introduced/described.
Hi Brian, just check for understanding: does the issuer send the clear text values of the disclosed claims to the holder and verifier or does the issuer only send the salted hashes? +------------+ +------------+ | Issues SD-JWT including all Disclosures | v +------------+ +------------+ | Presents SD-JWT including selected Disclosures | v +-------------+ + + +-------------+ +-------------+| +-------------+
I'm sorry but I don't quite understand the question or how it relates to the small change I'm suggesting in this issue.
FYI, I was asked what the salt does by an IETF attendee yesterday. I support explaining this in the draft.
PR has some proposed text
Code change:
and <del> status codes include information about the available representations so that the user or user agent can react by making a selection. </del> <ins> status codes include information about available representations so that the user or user agent can react by making a selection. </ins> Reactive negotiation is advantageous when the response would vary over commonly used dimensions (such as type, language, or encoding),

Related discussion:
text: … in that the request must be understood in order to parse and interpret the response.
Well, the simple version is a normative statement in sheep's clothing. Let's just make it normative.
Section 6 claims that . It uses the word "intended", which is an intention that is broadly achieved, with only one exception that I'm aware of at the syntactic level. Having recently implemented message/http, I discovered that some response messages cannot be processed without knowledge of the corresponding request. This is pretty annoying and might be worth noting as a possible exception here. As noted in the response to a HEAD request might include Content-Length, but the content of the response is always empty. At a semantic level, I don't think that any response can be considered without knowledge of the request, so I don't think that self-descriptiveness can possibly apply there. Besides, this section is clearly intended to provide an abstract definition of the syntax and not semantics.
See also
Code change:
and <del> status codes include information about the available representations so that the user or user agent can react by making a selection. </del> <ins> status codes include information about available representations so that the user or user agent can react by making a selection. </ins> Reactive negotiation is advantageous when the response would vary over commonly used dimensions (such as type, language, or encoding),

Related discussion:
text: in Section 12.2 uses "representation of the response", which I can't find a definition for. I think this should be "representation data" or "representation data contained in the response".
Much simpler, thanks.This is fine, but "a preferred kind of content" doesn't read well.
Code change:
header fields (or lack thereof) as determining factors while choosing the content for this response. <del> An origin server might send Vary with a list of header fields for two purposes: An origin server SHOULD send a Vary header field when its algorithm for selecting a representation varies based on aspects of the request message other than the method and target URI, unless the variance cannot be crossed or the origin server has been deliberately configured to prevent cache transparency.  For example, there is no need to send the Authorization field name in Vary because reuse across users is constrained by the field definition (field.authorization).  Likewise, an origin server might use Cache- Control response directives (field.cache-control) to supplant Vary if it considers the variance less significant than the performance cost of Vary's impact on caching. </del> <ins> A Vary field containing selecting field names has two purposes: An origin server SHOULD generate a Vary header field on a cacheable response when it wishes that response to be selectively reused for subsequent requests.  Generally, that is the case when the response content has been tailored to better fit the preferences expressed by those selecting header fields, such as when an origin server has selected the response's language based on the request's header field. Vary might be elided when an origin server considers variance in content selection to be less significant than Vary's performance impact on caching, particularly when such variance is already being limited by Cache-Control response directives (field.cache-control). Cached content selection is only improved by Vary if there is some chance that the origin server's selection algorithm might prefer a different representation for the recipient in a subsequent request. For example, there is no need to send the Authorization field name in Vary because reuse of that response for a different user is prohibited by the field definition (field.authorization).  Likewise, if the response content has been selected by network region but the origin server wants the cached response to be reused even if recipients move from one region to another, then there is no need for the origin server to indicate such variance in Vary. </ins> 13.

Related discussion:
text: Note that this also rephrases the SHOULD requirement, but doesn't change its effect.
As mentioned in ... >Section 12.5.5
Code change:
echo the stored "id" in a "Dictionary-ID" request header. The "Dictionary-ID" request header is a Structured Field STRUCTURED- <del> FIELDS sf-string of up to 1024 characters (after any decoding) and MUST be identical to the server-provided "id". </del> <ins> FIELDS String of up to 1024 characters (after any decoding) and MUST be identical to the server-provided "id". </ins> For example:

Related discussion:
text: Switched from using the ABNF field types to the human names (i.e. sf-dictionary to Dictionary) for all of the Structured Field header values. Switched dictionary "type" to a Token (from String).
NAME could you PTAL at the change in referencing the header field types? Specifically, I wasn't sure if I should capitalize the types or not (I did since that's how the structured fields RFC referred to them).
Yep, this looks good. It's common to add something to you Notational Conventions section (or whatever) that says roughly "This specification uses the following terms from [ref to SF]: String, Byte Sequence, Token, ..."
Code change:
indicated by the method definition or explicit cache controls (see heuristic.freshness). <ins> In 200 responses to GET or HEAD, an origin server SHOULD send any available validator fields (response.validator) for the , with both a strong entity-tag and a date being preferred. In 200 responses to state-changing methods, any validator fields (response.validator) sent in the response convey the current validators for the new representation formed as a result of successfully applying the request semantics.  Note that the PUT method (PUT) has additional requirements that might preclude sending such validators. </ins> 15.3.2. The

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:
FIELDS that contains one or more DNS names in a comma-separated list. The items in the list include all alias names and canonical names received in CNAME records DNS during the course of resolving the next <del> hop's hostname using DNS, not including the original requested </del> <ins> hop's hostname using DNS, and MAY include the original requested </ins> hostname itself.  The names SHOULD appear in the order in which they were received in DNS.  If there are multiple CNAME records in the chain, the first name in the "next-hop-aliases" list would be the

Related discussion:
text: Allow the original name of the next hop to be the start of the list, and add an example.
NAME NAME please review!
LGTM
I understand that the current draft is specifically targeting forward proxies, but as currently described, the is missing some information when used by reverse proxies, and it's not self-contained anymore (i.e. the requested/configured next hop is not part of the field), making debugging much harder. I find the fact that is not included here a bit confusing. While operators or clients connecting directly to might know that it's a forward proxy and could infer that was the requested hostname, the clients that are a few hops away from it, won't know this, and might be surprised how the and other aliases got in there. Furthermore, in a similar scenario with a client connecting to the reverse proxy and requesting , which is configured to use as the backend, that response is missing the most critical piece of information, and instead of helping, it adds more confusion. As such, I'd suggest that the requested/configured hostname should be included as the first entry in , especially when points to the resolved IP address. cc NAME NAME
This is a good point, especially for reverse proxies. The name of the next hop could be in the next-hop parameter itself, but then there is a choice between the address and the name there. For forward proxies, the name is known and the address is interesting. For reverse proxies, i imagine the name of the next hop is more useful than the address, but I can see why both could be wanted. In such case, perhaps we can allow the aliases list to include the next hop name if it differs from the authority requested by the client.
Yes, that's unfortunate. I'm not sure how we've missed this in RFC 9209. Perhaps we could allow both and use for the configured next hop name, and for the resolved IP address... which actually matches what I'm suggesting we do here by including the requested/configured name as the first entry in . But that's only true on the first hop, right? The authority could be changed along the way by intermediaries, and then the original client wouldn't know what started the resolution which resulted in the received . How would the original client know if that happened in a long chain of proxies?
Code change:
FIELDS that contains one or more DNS names in a comma-separated list. The items in the list include all alias names and canonical names received in CNAME records DNS during the course of resolving the next <del> hop's hostname using DNS, not including the original requested </del> <ins> hop's hostname using DNS, and MAY include the original requested </ins> hostname itself.  The names SHOULD appear in the order in which they were received in DNS.  If there are multiple CNAME records in the chain, the first name in the "next-hop-aliases" list would be the

Related discussion:
text: The authority requested by the client connecting to is not included in the header, and therefore it's not known to the original client. It's impossible to tell if that entry was generated by a proxy that was configured to connect to , which also happens to be the authority it received and therefore it's not included in , or if it was configured to connect to . Basically, I'm trying to avoid adding ambiguity and guesswork to the debugging process that uses this header.
Upon discussing in person: Good to add to an example The text should make it clear that the original name is allowed to be at the start of the list (but doesn't strictly need to be included)
Code change:
4.3. <ins> Some use-cases MAY require holder binding. Information about the key material controlled by the holder MUST be communicated in SD-JWT.  How the public key is included in SD-JWT is out of scope of this document.  It can be passed by value or by reference.  Examples in this document use Claim to include raw public key by value in SD-JWT. Holder MUST sign SD-JWT-R using the private key associated with the public key included in SD-JWT. Verifier MUST verify that the signature on SD-JWT-R using the public key information in SD-JWT. 4.4. </ins> A verifier checks that The detailed algorithm is described below.

Related discussion:
text: Issue and . Describing the concept of holder binding and giving minimum directions on: find pubKey in SD-JWT Sign SD-JWT-R using privKey bound to a pubKey in SD-JWT but leaving details to the profiles and implementations.
Code change:
infrastructure.  However, current gateways might need modifications to support TCP proxy services.  To be compatible, a gateway must: <del> support Extended CONNECT. </del> <ins> support Extended CONNECT (if acting as an HTTP/2 or HTTP/3 server). support HTTP/1.1 Upgrade to "connect-tcp" (if acting as an HTTP/1.1 server) only after forwarding the upgrade request to the origin and observing a success response. </ins> <del> convert HTTP/1.1 Upgrade requests into Extended CONNECT. </del> <ins> forward the "connect-tcp" protocol to the origin. </ins> <del> allow the Extended CONNECT method to pass through to the origin. </del> <ins> convert "connect-tcp" requests between all supported HTTP server and client versions. </ins> <del> forward Proxy-* request headers to the origin. </del> <ins> allow any "Proxy-Status" headers to traverse the gateway. </ins> 8.

Related discussion:
text: However, I'm happy to say that "WWW-Authenticate" is the winner here, and "Proxy-Authenticate" does not traverse "connect-tcp" (or "connect-udp") gateways.
Looks good! :+1: