jiebi/CodeConvo huggingface dataset:
Code change:
SUBSCRIBE of either SUBSCRIBE_OK or SUBSCRIBE_ERROR. For successful subscriptions, the publisher maintains a list of <del> subscribers for each full track name.  Each new OBJECT belonging to the track is forwarded to each active subscriber, 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 SUBSCRIBE_RST (see message-subscribe-rst). </del> <ins> subscribers for each track.  Each new OBJECT belonging to the track within the subscription range is forwarded to each active subscriber, 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 SUBSCRIBE_RST (see message-subscribe-rst). </ins> Relays MAY aggregate authorized subscriptions for a given track when multiple subscribers request the same track.  Subscription

Related discussion:
text: It's only used a few times and now that Namespace and Name are an opaque sequence of bytes, it's even less compelling.
Take the line from your drafts that says There is no valid way to parse the right hand of this. We have things like "Full Track Name Length" and "Full Track Name". I do not think we should have ambiguous syntax for things that require precision. I think it would also be good to have things that can be directly mapped to common programming languages. This moves beyound simply editorial, or specification is underspecified and ambiguous until we fix this.
One possible solution would be use underscore or CamelCase
Oh, and the longer we leave this dumpster fire, the more painful it will be to fix.
love it
Code change:
The HEADERS frame (type=0x1) is used to StreamStates, and additionally carries a header block fragment.  HEADERS frames can be <del> sent on a stream in the "open" or "half closed (remote)" states. </del> <ins> sent on a stream in the "idle", "reserved (local)", "open" or "half closed (remote)" states. </ins> The HEADERS frame payload has the following fields:

Related discussion:
text: LGTM
Merged by RFC editor.
Minor bug that needs to be tracked... I assume the text in section 6.2 needs to be modified to add "idle"?
Code change:
and scheme of the request URI derived from the proxy's URI Template. <del> From this point on, the request and response SHALL conform to all the usual requirements for classic CONNECT proxies in this HTTP version (see RFC9113 and RFC9114). </del> A templated TCP proxying request that does not conform to all of these requirements represents a client error (see RFC9110) and may be malformed (see RFC9113 and RFC9114).

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:
A header list is an ordered collection of header fields that are encoded jointly, and can contain duplicate header fields.  A <del> complete list of key-value pairs contained in a HTTP/2 header </del> <ins> complete list of key-value pairs contained in an HTTP/2 header </ins> block is a header list. A header field can be represented in encoded form either as a

Related discussion:
text: I think "an" is correct.
An is generally used only before a vowel. As in, "A, E, I, O, and U". An can be used before a "vowel sound" as well. But "h" in "http" is neither in my book. See URL for more info.
In (British?) English, 'h' can be pronounced either as 'aytch' or as 'haytch' so I would say that both 'a' and 'an' HTTP something should be considered fine.
Let's at least be consistent.
If you pronounce 'a' as 'ahh' then "a HTTP" sounds ok. If you pronounce 'a' as 'aye' then it sounds wrong as you have two 'aye' sounds in a row unless you pronounce your 'h' as 'haytch'. American English would generally expect "an" to be used here, I think. Dialects might disagree. RFC 2616 & RFC 7230 use "an".
We had this fight (almost verbatim) for bis; "an" won. As Martin says, let's be consistent.
Code change:
. A recipient MUST ignore the If-Unmodified-Since header field if the <del> received field value is not a valid HTTP-date, or if the field value has more than one member. </del> <ins> received field value is not a valid HTTP-date (including when the field value appears to be a list of dates). </ins> A recipient MUST interpret an If-Unmodified-Since field value's timestamp in terms of the origin server's clock.

Related discussion:
text: evaluating false on a duplicate change request sending 2xx without validator for reasons unknown.
Hmm, of course, now I found another related message in my archives that prompted me to remember why the requirement was added. I should probably rewrite the paragraph (without that requirement) and describe the edge case as a note.
RFC7232 in URL has the following clause: It doesn't really explain what security or performance considerations are leading to such a requirement, but it calls for a lot of infrastructure and design work to implement it because that logic can be implemented only if the server is stateful. The stateless server cannot comply with such a requirement. See related mail list thread: URL Either RFC should explain why such logic MUST be implemented or relax "MUST" into "SHOULD" in that clause or remove that clause completely.
Should I submit an errata proposing to remove the following clause from RFC 7232, section 3.1: " In the latter case, the origin server MUST NOT send a validator header field in the response unless it can verify that the request is a duplicate of an immediately prior change made by the same user agent" It seems like nobody can recall/explain why this clause is there.
I finally found the original commit 303b82b12a53c170f6f755aaaf8840ac1240aa77
And the discussion motivating the change is under . Certainly the intent was to remove the constraint that an error be sent when a duplicate request is made, so the extra limitations were to reduce edge cases.
It is not an errata. This is the right place to discuss it and either find a better wording or strike the text.
Thanks, NAME for finding the original commit and your response! Sending response for repeating requests makes total sense. My issue is about a sub-condition of response that is stated in the RFC7232. In the original commit that you referenced that sub-condition is stated as: I think I understand the original recommendation not to send back. It would be better to replace with there though. But in RFC7232 that sub-condition clause is changed to: The reason of not sending with back is not explained in RFC7232 and nobody can remember why it is there or explain this requirement. Complying with this requires dev effort and extra infra since we would need to track immediate previous requests from each agent.
Code change:
. A recipient MUST ignore the If-Unmodified-Since header field if the <del> received field value is not a valid HTTP-date, or if the field value has more than one member. </del> <ins> received field value is not a valid HTTP-date (including when the field value appears to be a list of dates). </ins> A recipient MUST interpret an If-Unmodified-Since field value's timestamp in terms of the origin server's clock.

Related discussion:
text: Our API servers are light-weight and stateless so this is a huge requirement for us. Instead, we would prefer a way simpler approach of always sending back along with responses, but we need to comply with RFC7232 thus this discussion. So, the proposal is to do one of the following (preferred) Remove the following clause from RFC7232: (If aforementioned clause is kept) Explain the reason of not sending in that sub-condition (at least) Change to in that clause.
These requirements were motivated by a tiny edge case related to protecting partial updates after two clients simultaneously try a PUT. However, I can't remember if it was when one succeeds and one fails, or one or both responses are lost and they try again, or something like that, nor can I remember what difference was made by not sending ETag. Hence, I intend to remove the requirement as being too obscure to implement in a testable way.
Code change:
. A recipient MUST ignore the If-Unmodified-Since header field if the <del> received field value is not a valid HTTP-date, or if the field value has more than one member. </del> <ins> received field value is not a valid HTTP-date (including when the field value appears to be a list of dates). </ins> A recipient MUST interpret an If-Unmodified-Since field value's timestamp in terms of the origin server's clock.

Related discussion:
text: We decided to move the version-independent parts of the definition of Content-Length to Semantics, but that calls for some new text to explain its semantics in general. For now, we have added (in crefs) the following text to the section on "Content-Length" in Semantics:
s/representation/representation data/?
Code change:
10.1.1. <del> 10.1.1.1. 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. 10.1.1.2. </del> The "Date" header field represents the date and time at which the message was originated, having the same semantics as the Origination Date Field (orig-date) defined in RFC5322.  The field value is an

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:
Authentication MAY be implemented for this endpoint.  See notes on detached payloads below. <ins> This endpoint is used to register a Signed Statement with a Transparency Service. </ins> The following is a non-normative example of a HTTP request to register a Signed Statement:

Related discussion:
text: Issue
In the case of a government end point, why must client authentication be implemented. The signature on the statement is the authentication for the content and is ultimately who is making a reputation statement.
Agreed. In addition to this I think there are several places where we need to clean up seemingly helpful implementation comments which are actually harmful. For instance the mention of using auth for rate limiting is a fine thing to say but it's nothing to do with SCITT and will be done in other layers by any sensible implementation.
Resolved by
The optional API endpoints have intent statements that outline the goal of the Endpoints for example 2.2.1 (Issue Signed Statement Endpoint) has this intent statement: Such a statement is currently missing from both: (Transparency Configuration) and 2.1.2 (Signed Statement Registration).
I'll take this one and put a PR up with consistency for all the endpoints
This was fixed in
LGTM
Code change:
Let MATCH be the value of "match" for the given dictionary. <del> Let PATTERN be a URLPattern constructed by setting input=MATCH, and baseURL=BASEURL (https://urlpattern.spec.whatwg.org/). </del> <ins> Let PATTERN be a URL Pattern URLPattern constructed by setting input=MATCH, and baseURL=BASEURL. </ins> Return the result of running the "test" method of PATTERN with <del> input=URL (https://urlpattern.spec.whatwg.org/#ref-for-dom- urlpattern-test) </del> <ins> input=URL. </ins> 2.2.3.

Related discussion:
text: Changed it to a proper normative reference. For
Merging this. Can always clean it up more if it is still a concern.
For example: Usually, we add something like URLPattern to the references, then that.
Sorry, didn't mean to close the issue. Feel free to close this out if the current language looks OK (also happy to update it if it needs some more tweaking).
Going to close this out now. Thanks for taking the time on this.
Code change:
cache entry cache key <del> D Disconnected Operation (warn-text) </del> E Expires header field explicit expiration time

Related discussion:
text: I'll have to update extract-header-URL so that it can generate entries with status "obsoleted".
NAME Go ahead and merge after you update extract-header-URL
Isn't implemented, generated, used or surfaced to users; can we deprecate?
Proposal: Replace 5.5 Warning with a section noting that the Warning header is deprecated, and should be ignored. Remove all requirements to generate Remove Warning-specific requirements in 3.3 Combining Partial Content Remove Warning-specific requirements in 4.3.4 Freshening Stored Responses upon Validation Remove Warning-specific requirements in 4.3.5 Freshening Responses via HEAD
+1, with big notes in the Changes section.
Just curious if anyone has any background, what would be a good alternative to the Warning header for cache limit warnings?
This isn't a good place for general discussion. You might want to ask the mailing list, though I am not aware of any cache limit warnings within HTTP because they are only relevant to the cache admin (who typically has an email or phone number stored for such notifications).
Code change:
portion of the request-target (e.g. "https") All header field names MUST be lowercased, and the definitions of <del> all header fields names defined by HTTP/1.1 are updated to be all </del> <ins> all header field names defined by HTTP/1.1 are updated to be all </ins> lowercase. The Connection, Host, Keep-Alive, Proxy-Connection, and Transfer-

Related discussion:
text: Additionally, section 4.2.3 contains a lot of text that is similar to 4.2.2, but there may be a reason for that.
I'll try to remember to fix the content-length thing.
Code change:
want-fields defines the Want-Digest and Want-Content-Digest request and response header and trailer field, <del> algorithms and deprecate-contentMD5 describe algorithms and their relation to Digest, </del> <ins> algorithms describes algorithms and their relation to Digest, </ins> state-changing-requests details computing representation digests, <del> obsolete-parameters obsoletes Digest field parameters, and </del> examples-unsolicited and examples-solicited provide examples of using Digest and Want-Digest.

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:
SETTINGS frame.  Detection of a change by a receiver MUST be treated as a connection error of type PROTOCOL_ERROR. <ins> The SETTINGS frame precedes any HTTP/2 priority signal sent from a client, so a server can determine if it needs to allocate any resource to signal handling before they arrive.  A server that receives SETTINGS_NO_RFC7540_PRIORITIES with value of 1 MUST ignore HTTP/2 priority signals. 2.1.1. </ins> Until the client receives the SETTINGS frame from the server, the client SHOULD send both the HTTP/2 priority signals and the signals of this prioritization scheme (see header-field and h2-update-frame).

Related discussion:
text: The context here is that the document defines independent elements a) the means to deprecate RFC 7540 stream priority using a setting b) the extensible priorities scheme. This text removes conflating those elements and making it appear that Extensible priorities is mandatory. Where someone chooses to use Extensible priorities (good choice!) there is some specific guidance about how to process settings and inform signal setting.
Above, you indicate any scheme can be used, with this being just one option. This does make guidance about PRIOUPDATE frames/header field more difficult later, so maybe some other textual adjustment is needed earlier: e.g., for the remainder of this text ,we assume the use of the scheme defined in this document as the alternate Or, move the following text from below up and adjust a bit send this scheme's priority signal Originally posted by NAME in URL
The text isn't amazingly clear if endpoints have to use Extensible priority when they explicitly disable H2 priority. I suggest we state they do. If anyone really wants to invent a new scheme, they will need to deal with negotiation.
Yeah I see two somewhat contradicting statements: Endpoints are expected to use an alternative, such as the scheme defined in this specification. Until the client receives the SETTINGS frame from the server, the client SHOULD send both the HTTP/2 priority signals and the signals of this prioritization scheme (see Section 5 and Section 7.1). I would argue that the former is precise, and that the latter is a bit misleading in recommending endpoints send Extensible Priorities rather than any alternative to H2 priorities. The rationale is as follows. In principle, negotiation is a hop-by-hop mechanism and therefore cannot be used for negotiating the use of an end-to-end signal, which includes the header-field variant of Extensible Priorities. To paraphrase, in a world where end-to-end signals are used for prioritization, multiple signals are expected to co-exist. IMO, SETTINGSDEPRECATERFC7540_PRIORITIES is no more than an optimization, that allows clients to conserve bandwidth (by omitting the PRIORITY frames), servers to reduce complexity (by ignoring PRIORITY frames being received). These benefits are stated correctly in the section.
Thanks Kazuho. I tend to agree. The thing I also wanted to avoid is endpoints disabling RFC 7550 stream priority and then not providing any suitable replacement by accident.
Code change:
SETTINGS frame.  Detection of a change by a receiver MUST be treated as a connection error of type PROTOCOL_ERROR. <ins> The SETTINGS frame precedes any HTTP/2 priority signal sent from a client, so a server can determine if it needs to allocate any resource to signal handling before they arrive.  A server that receives SETTINGS_NO_RFC7540_PRIORITIES with value of 1 MUST ignore HTTP/2 priority signals. 2.1.1. </ins> Until the client receives the SETTINGS frame from the server, the client SHOULD send both the HTTP/2 priority signals and the signals of this prioritization scheme (see header-field and h2-update-frame).

Related discussion:
text: I think there is agreement that not doing scheduling is pretty bad. But we also highlight that other inputs, beyond this scheme and beyond anything that would be standardised are fine to use too. I'm getting an idea of how we could change the text to address the points made on this issue.
Reading again the current text send this scheme's priority signal. Handling of omitted signals is described in {{parameters}}. This is effectively a differently worded restatement of the guidance for implementers of Extensible Priorities receiving an HTTP request that does not carry these priority parameters, a server SHOULD act as if their default values were specified. That is, imagine both endpoints send SETTINGSDEPRECATERFC7540PRIORITIES and a client wants the default prioritization for a request (u=3,i). It can omit the Priority header field and have some expectation that a server implementing Extensible priorities will interpret that as a signal to apply the default. The simple action here is to make SETTINGSDEPRECATERFC7540PRIORITIES independent from any advice to use a specific alternative.
LGTM. I like how you've split the section.
Code change:
Abstract <del> This document describes HPACK, a format adapted to efficiently represent HTTP header fields in the context of HTTP/2. </del> <ins> This specification defines HPACK, a compression format for efficiently representing HTTP header fields in the context of HTTP/2. </ins> Editorial Note (To be removed by RFC Editor)

Related discussion:
text: Editorial changes through Section 3.1.2. Further updates forthcoming.
Rebased onto current master.
Code change:
that is not currently in the "idle" state. The total number of padding octets is determined by the value of the <del> Pad Length field.  Padding that exceeds the size remaining for the field block fragment MUST be treated as a PROTOCOL_ERROR. </del> <ins> Pad Length field.  If the length of the padding is the length of the frame payload or greater, the recipient MUST treat this as a ConnectionErrorHandler of type PROTOCOL_ERROR. </ins> 6.7.

Related discussion:
text: by copying the text from DATA
says: I think the intended reading is that when the parser reaches the point that only the FBF and the Padding remain, the length of Padding is given by Pad Length and the fragment is the balance. If Pad Length exceeds the remaining length of the frame, it's an error. There is a less-likely reading also allowed by the current phrasing, that Pad Length can't be more than half the remaining bytes (else Padding would exceed the size of the field block fragment). That's very unlikely to be the intended reading, but we should be clear here. I'd suggest simply taking the note from the end of DATA and putting it here verbatim.
LGTM, will let NAME take a read as well.