jiebi/CodeConvo huggingface dataset:
Code change:
The special value "*", if present in the Accept-Charset field, matches every charset that is not mentioned elsewhere in the Accept- <del> Charset field.  If no "*" is present in an Accept-Charset field, then any charsets not explicitly mentioned in the field are considered "not acceptable" to the client. A request without any Accept-Charset header field implies that the user agent will accept any charset in response.  Most general-purpose user agents do not send Accept-Charset, unless specifically configured to do so, because a detailed list of supported charsets makes it easier for a server to identify an individual by virtue of the user agent's request characteristics (fingerprinting). If an Accept-Charset header field is present in a request and none of the available representations for the response has a charset that is listed as acceptable, the origin server can either honor the header field, by sending a response, or disregard the header field by treating the resource as if it is not subject to content negotiation. </del> <ins> Charset field. </ins> 8.4.4. The "Accept-Encoding" header field can be used by user agents to <del> indicate what response content-codings (content.codings) are acceptable in the response.  An "identity" token is used as a synonym for "no encoding" in order to communicate when no encoding is preferred. </del> <ins> indicate their preferences regarding response content-codings (content.codings).  An "identity" token is used as a synonym for "no encoding" in order to communicate when no encoding is preferred. </ins> Each codings value MAY be given an associated quality value representing the preference for that encoding, as defined in

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:
Extra Parameters: None. <del> Recommended HTTP status code: </del> <ins> Recommended HTTP status code: 503 </ins> 3.13.

Related discussion:
text: Rationale for 503 is that the service is unavailable due to too many connections. 429 could potentially be an option as well, but that seems more specific to a single user hitting a rate limit, while seems more related to a global limit. /cc NAME NAME
Code change:
production can be transmitted either as a token or within a quoted- string.  The quoted and unquoted values are equivalent. <ins> 4.4.1.5. Prior to 1995, there were three different formats commonly used by servers to communicate timestamps.  For compatibility with old implementations, all three are defined here.  The preferred format is a fixed-length and single-zone subset of the date and time specification used by the Internet Message Format RFC5322. An example of the preferred format is Examples of the two obsolete formats are A recipient that parses a timestamp value in an HTTP field MUST accept all three HTTP-date formats.  When a sender generates a field that contains one or more timestamps defined as HTTP-date, the sender MUST generate those timestamps in the IMF-fixdate format. An HTTP-date value represents time as an instance of Coordinated Universal Time (UTC).  The first two formats indicate UTC by the three-letter abbreviation for Greenwich Mean Time, "GMT", a predecessor of the UTC name; values in the asctime format are assumed to be in UTC.  A sender that generates HTTP-date values from a local clock ought to use NTP (RFC5905) or some similar protocol to synchronize its clock to UTC. Preferred format: Obsolete formats: HTTP-date is case sensitive.  A sender MUST NOT generate additional whitespace in an HTTP-date beyond that specifically included as SP in the grammar.  The semantics of , , , , and are the same as those defined for the Internet Message Format constructs with the corresponding name (RFC5322). Recipients of a timestamp value in rfc850-date format, which uses a two-digit year, MUST interpret a timestamp that appears to be more than 50 years in the future as representing the most recent year in the past that had the same last two digits. Recipients of timestamp values are encouraged to be robust in parsing timestamps unless otherwise restricted by the field definition.  For example, messages are occasionally forwarded over HTTP from a non- HTTP source that might generate any of the date and time specifications defined by the Internet Message Format. </ins> 4.5. A #rule extension to the ABNF rules of RFC5234 is used to improve

Related discussion:
text: is a bit odd; unlike its peer sections, it's not a field name, it's a general concept. Then 10.1.1.1 goes on to specify how date formats in HTTP work generally, while 10.1.1.2 is the Date header. Given that we now have a section for generic syntax, I think it makes sense to promote 10.1.1.2 up a level, moving 10.1.1.1 out to an item in 4.4.1 (Common Field Value Components).
Discussed; makes sense.
Code change:
305 Use Proxy (status code) 306 (Unused) (status code) 307 Temporary Redirect (status code) <ins> 308 Permanent Redirect (status code) </ins> 3xx Redirection (status code class) 4

Related discussion:
text: Good catch.
...currently defined in RFC 7538.
This would obsolete 7538?
Yes. Now the good question is how much of RFC 7538 include. My proposal would be just to include parts of URL, but to point back to RFC 7538 for additional information (non-normatively).
Seems reasonable to me.
Maybe we should also add the table from URL somewhere.
Possibly at the top of the 3xx section.
Code change:
A prefix is not considered a usable on-link prefix if it is advertised on the link as on-link, but the 'm' bit is set in the Router Advertisement message header (RFC4861) that contains the <del> Prefix option.  This indicates that node addressibility is being </del> <ins> Prefix option.  This indicates that node addressability is being </ins> managed using DHCPv6.  Nodes are not required to use DHCPv6 to acquire addresses, so a prefix that requires the use of DHCPv6 can't be considered "usable"&#151;not all hosts can actually use it.

Related discussion:
text: AIL is used as an acronym in multiple places but not defined. also put colons on the glossary terms
I don't think there was consensus (even close) on the use of CPE router, unfortunately. I don't really agree with s/need/needs to/, but maybe s/need take no action/does not need to take action/ for better clarity?
Code change:
Optional parameters: n/a <del> Encoding considerations: binary; A CBOR-based Status List is a CBOR Object. </del> <ins> Encoding considerations: See status-list-cbor of this specification </ins> <del> Security considerations: See (#Security) of [ this specification ] </del> <ins> Security considerations: See Security of this specification </ins> Interoperability considerations: n/a <del> Published specification: [ this specification ] </del> <ins> Published specification: this specification </ins> <del> Applications that use this media type: Applications using [ this specification ] for updated status information of tokens </del> <ins> Applications that use this media type: Applications using this specification for updated status information of tokens </ins> Fragment identifier considerations: n/a <del> Additional information: File extension(s): n/a Macintosh file type code(s): n/a </del> <ins> Additional information: n/a </ins> Person & email address to contact for further information: Paul Bastian, paul.bastian@posteo.de

Related discussion:
text: fixes the list rendering (missing newline) clarifies IANA text to just reference other tokens Rendered version: URL
I did further fixes on media types
Code change:
8.1. <del> IF APPROVED, IANA is requested to add the following entries to the HTTP Upgrade Token Registry: </del> <ins> IF APPROVED, IANA is requested to add the following entry to the HTTP Upgrade Token Registry: </ins> For interoperability testing of this draft version, implementations <del> SHALL use the values "connect-tcp-06" and "connect-tcp-capsule-06. </del> <ins> SHALL use the value "connect-tcp-07". </ins> 8.2.

Related discussion:
text: This leaves only the Capsule Protocol mode
I do think we should add FINAL_DATA, but I'm fine with merging this first and then discussing that in
As of draft-ietf-httpbis-connect-tcp-05, connect-tcp now optionally supports the capsule protocol. However, this optionality adds non-trivial complexity to implementations. As currently written, if a client wishes to use capsules, the server can reject the use of capsules, and now the client needs to cache that this server doesn't support them. However it's undefined for how long the client should cache this information, and within what scope. We could potentially figure out recommendations for all these questions, but fundamentally it might be best to instead make capsules mandatory for connect-tcp, like they are for connect-udp and connect-ip. That would simplify implementations and improve consistency.
Individually, I think it would be interesting to try out this direction — probably based on implementation experience for how easy it is to add. On one hand, this makes connect-tcp less of a trivial drop-in. On the other, it opens up more possible use cases.
I heard a good deal of support for this direction in the HTTPBIS meeting.
Thanks!
Code change:
4.1. <del> An important function of a Transparency Service is to maintain Registration Policies for the Append-only Log.  The Append-only Log is the verifiable data structure which registers Signed Statements and supports the production of Receipts. </del> <ins> Transparency Services MUST feature an Append-only Log.  The Append- only Log is the verifiable data structure that registers Signed Statements and supports the production of Receipts. </ins> All Transparency Services MUST expose APIs for the registration of Signed Statements and issuance of Receipts.

Related discussion:
text: Retains the concepts and many of the same words as before, but addresses concerns form the mailing list and interim call
I've merged in suggestions. Please re-review, with LGTM or actionable suggestions.
yesLGTM
Code change:
The example belows shows how the client in trust domain A presents an authorization grant to the authorization server in trust domain B <del> (https://b.org/auth) to receive an access token for a protected </del> <ins> (https://as.b.org/auth) to receive an access token for a protected </ins> resource in trust domain B. 2.6.

Related discussion:
text: Replaces examples and add response examples
Feedback from Brian Campbell Seeing curl commands in the examples is sort of unexpected. Typically these kinds of drafts try to show the "on the wire" HTTP message -something like this [URL] for example or this [URL] or [URL] etc
Code change:
3.5. The control data for a response message consists of the status code. <del> The status code is encoded as a variable length integer, not a </del> <ins> The status code (HTTP) is encoded as a variable length integer, not a </ins> length-prefixed decimal string. The format of final response control data is shown in format-

Related discussion:
text: Comment by NAME , Figure 1: , Figure 2: For consistency with the rest of Figure 1, you could add a comma after Content(..) and Chunk (..) : Missing word "message" : s/intermediate/indeterminate
Comment by NAME The document uses "indeterminate length" and "indefinite length" interchangeably. I would suggest either using only one, or adding "indeterminate" when the first "indefinite" appear, i.e. in :
Comment by NAME : Should these be "informational" rather than "information"?
Comment by NAME : Please reference RFC-ietf-httpbis-semantics, or , or the IANA registry: URL after "status code".
Comment by NAME : : I think HTTP/2 should be a normative reference.
Comment by NAME : Might be worth clarifying that this integer value does not include the length bytes. My comment comes from the fact that "field section" is the name of the structure containing the length, so "number of bytes in the field section" could be interpreted to include the length bytes itself.
Comment by NAME : : At this point in the text I thought this was missing the optional Informational response field, but you say explain that several paragraph later. Maybe clarify here that this is for messages that are not responses containing informational status codes, or move those paragraphs closer together?
I think that moving the paragraphs works best here.
Code change:
by a secondary key for the values of the original request's selecting header fields (caching.negotiated.responses). <ins> A cache is when it cannot contact the origin server or otherwise find a forward path for a given request.  A disconnected cache can serve stale responses in some circumstances (serving.stale.responses). </ins> 3. A cache MUST NOT store a response to any request, unless:

Related discussion:
text: For .
Caching still refers to a "disconnected" state, as well as "cannot reach" and similar states. This needs to be rationalised. See thread: URL
Should wait for resolution of .
I'm inclined to move the definition of "disconnected" up into "overview of cache operation" and refer to it consistently -- including when "cannot be reached" is used.
Wow, that is a bad choice of word for that definition in the old text, but +1 to the change. I used to know what the right term was for that ... drawing a blank at the moment. I think it was something like "origin unreachable" or "upstream unavailable". Bah.
Code change:
they consider implementation and deployment of systems that rely on the MOQ protocol. <del> *Note: the initial high-level organization for this section is taken from Suhas Nandakumar's presentation, "Progressing MOQ" Prog-MOQ, at the October 2022 MOQ virtual interim meeting, which was in turn taken from the MOQ working group charter MOQ-charter.  We think this is a reasonable starting point.  We won't be surprised to see the high- level structure change a bit as things develop, but we didn't want to have this section COMPLETELY blank when we request working group adoption. TODO: Describe overall, high level requirements that we previously stated in earlier versions of this document. </del> 4.2. <ins> 4.2.1. 4.2.2. 4.2.3. 4.2.4. 4.2.5. 4.3. </ins> Many of the use cases have bi-directional flows of media, with clients both sending and receiving media concurrently, thus the protocol should have a unified approach in connection negotiation and

Related discussion:
text: NAME could you take a look at this? I know everyone's thinking has changed on details, but we can capture those changes as the working group converges.
The subsections should be Publishing Media Naming or Identification Packaging Media Media Consumption Relays/Caches End to End Security This is only a starting point, of course, but , and it's easier to keep track of them if the document subsections match, at least for now.
NAME - ISTM that the contain a lot of material that might better be put in another section. I'll work through that before we talk (next week, right?), but please keep this note in mind, so we can fix what I get wrong. Also - ISTM that we really do need a "specific protocol considerations" requirement section, to capture things like streams/datagrams, WebTransport/H3/QUIC, one MOQ protocol, etc. I'll add that in the PR for this issue as well.
NAME most of the sections had some beginning text (and I can't remember who wrote it - was it you?). I'm copying the bullets from NAME slides into each section as a starting point. I'm not sure whether deleting the beginning text is the right thing to do, because it might or might not match the resulting subsections' contents, and of course the new subsections don't have beginning text because they didn't exist before, but let's talk about that, next week.
Code change:
corresponding to the other keys could be returned, or the request could be forwarded towards the origin. <ins> 4.3.1. If the selected variants-header was: And a request comes in with the following headers: Then sorted-variants in cache is: If the cache contains responses with the following Variant-Keys: Then the cache needs to forward the request to the origin server, since Variants indicates that "de" is available, and that is acceptable to the client. 4.3.2. If the selected variants-header was: And a request comes in with the following headers: Then sorted-variants in cache are: This allows the cache to return a "Variant-Key: en" response even though it's not in the set the client prefers. </ins> 5. Origin servers that wish to take advantage of Variants will need to

Related discussion:
text: I've also added examples of the new behavior. This is an attempt to
URL shows an example of an origin server that contains English, French, and German versions of a resource, a cache that has cached the English and French versions, a request that asks for German or Spanish, and, I believe, permission in the spec for the cache to return the English version instead of asking the origin server for the German version. This happens because URL appends the first Variant to the list of requested languages even if the list of requested languages overlaps with the available variants. Is this a mistake in the algorithm, or intentional for some reason?
The language algorithm does that so that an origin can denote a 'default' language -- i.e., what to serve if there isn't any overlap between the client's preferences and what's available. For example, if a user configures their browser to send and the page is only available in English and French, there needs to be a way to say "send English by default." I don't know of any use case where someone would want to serve a hard error when the language doesn't match, but if that's in scope, we could figure something out. If you're looking for something more deterministic in caches (here, the distinction between "these ar the responses that are available and preferred" and "here's the default" is blurred), I'm interested. P.S. in that diff, the line with the comment "prefers French, will accept English(?)" seems wrong.
I think establishes the default language without confusing it with the responses that are available and preferred. I am also not interested in a hard error when the language doesn't match. And thanks, I've fixed the example.
I'm not entirely happy with the optionality of behaviour on the cache's part with those MAYs. The most explicit thing we could do would be to break this information out into a separate header (e.g., ), but sticking with the current syntax for the moment, what if we had special values that, when occurring in that first slot, indicate that the default should NOT match? E.g., where does the magic.
I'm personally happy with turning those MAYs into MUSTs. They're MAYs because that's what was in the older RFCs, but I agree that I don't like making things optional.
Code change:
corresponding to the other keys could be returned, or the request could be forwarded towards the origin. <ins> 4.3.1. If the selected variants-header was: And a request comes in with the following headers: Then sorted-variants in cache is: If the cache contains responses with the following Variant-Keys: Then the cache needs to forward the request to the origin server, since Variants indicates that "de" is available, and that is acceptable to the client. 4.3.2. If the selected variants-header was: And a request comes in with the following headers: Then sorted-variants in cache are: This allows the cache to return a "Variant-Key: en" response even though it's not in the set the client prefers. </ins> 5. Origin servers that wish to take advantage of Variants will need to

Related discussion:
text: If I do this in my update tomorrow morning, do you still want to explore the token? I don't really like it because it seems like always the wrong thing for a client to send. I also don't see a particular need to pull the defaults out to a separate header.
I'm a bit interested in , but not adamant. I think it'd be fine if they flipped to MUST as long as the implications were noted.
Code change:
has evolved since RFC3230 was published.  The concept of "instance" has been superseded by "selected representation". <del> This document replaces RFC3230.  The "Digest" and "Want-Digest" field definitions are updated to align with the terms and notational conventions in SEMANTICS.  Changes are intended to be semantically compatible with existing implementations but note that negotiation of "Content-MD5" is deprecated deprecate-contentMD5 and has been replaced by "Content-Digest" negotiation via "Want-Content-Digest". "Digest" field parameters are obsoleted obsolete-parameters and the algorithm table has been updated to reflect the current state of the art. </del> <ins> This document replaces RFC3230.  The changes described in the following paragraphs are intended to be semantically compatible with existing implementations where possible. The "Digest" and "Want-Digest" field definitions are updated to align with the terms and notational conventions in SEMANTICS. Negotiation of "Content-MD5" is deprecated and has been replaced by "Content-Digest" negotiation via "Want-Content-Digest". Sections 4.1.1 and 4.2 of RFC3230 defined field parameters.  This document obsoletes the usage of parameters with "Digest" because this feature has not been widely deployed and complicates field-value processing.  RFC3230 intended field parameters to provide a common way to attach additional information to a representation-data-digest. However, if parameters are used as an input to validate the checksum, an attacker could alter them to steer the validation behavior.  A digest-algorithm can still be parameterized by defining its own way to encode parameters into the representation-data-digest, in such a way as to mitigate security risks related to its computation. The algorithm table has been updated to reflect the current state of the art, (see algorithms). </ins> 1.4.

Related discussion:
text: This editorial change combines most references to how this document relates to RFC 3230. By dropping the appendix, it makes the flow of the document more smooth, which is reflected in the ToC.
LGTM
Code change:
4.1. <del> The REQUIRED "k" (key ID) parameter is a byte sequence that </del> <ins> The REQUIRED "k" (key ID) Parameter is a byte sequence that </ins> identifies which key the client wishes to use to authenticate.  This can, for example, be used to point to an entry in a server-side database of known keys. 4.2. <del> The REQUIRED "a" (public key) parameter is a byte sequence that </del> <ins> The REQUIRED "a" (public key) Parameter is a byte sequence that </ins> specifies the public key used by the server to validate the signature provided by the client.  This avoids key confusion issues (see SEEMS- LEGIT).  The encoding of the public key is described in public-key-

Related discussion:
text: The five authentication parameters are offset in various ways throughout the document. Examples: using the Parameter (Section 3.3) using the v Parameter (Section 3.2) The REQUIRED "p" (proof) parameter (Section 4.3) Additionally, the word "directive" is used instead of parameter in Section 4.4. It might be advisable to align the document on always using one of these, with a possible difference where the parameter is being defined.
Agreed. I'll write a PR that standardizes on parameter and not directive "p" when defining a new parameter when referencing the parameter