jiebi/CodeConvo huggingface dataset:
Code change:
this is the part of URL related to -semantics
Continueing the discussion from URL Looking at the next text in context: To me it's unclear why we are calling out bare CR here, isn't the situation the same for LF and CRLF?? This also is not a new requirement, the ABNF does not allow CR and friends in field-value, and in 3.2 we say "A sender MUST NOT generate protocol elements that do not match the grammar defined by the corresponding ABNF rules." The subsequent paragraph talks about whitespace, and it may not be clear to everyone which characters we are referring to here (not the ones listed in Section 1.2.1 "Whitespace", correct?)
Proposal:
NAME ?
(forked from )
A bit iffy given the sentence above it, but okay.

Related discussion:
text: request. An origin server that receives an If-Match header field MUST evaluate <del> the condition prior to performing the method (evaluation). </del> <ins> the condition as per evaluation prior to performing the method. </ins> To evaluate a received If-Match header field:
Code change:
this is the part of URL related to -semantics
Continueing the discussion from URL Looking at the next text in context: To me it's unclear why we are calling out bare CR here, isn't the situation the same for LF and CRLF?? This also is not a new requirement, the ABNF does not allow CR and friends in field-value, and in 3.2 we say "A sender MUST NOT generate protocol elements that do not match the grammar defined by the corresponding ABNF rules." The subsequent paragraph talks about whitespace, and it may not be clear to everyone which characters we are referring to here (not the ones listed in Section 1.2.1 "Whitespace", correct?)
Proposal:
NAME ?
(forked from )
A bit iffy given the sentence above it, but okay.

Related discussion:
text: initial representation for the target resource. An origin server that receives an If-None-Match header field MUST <del> evaluate the condition prior to performing the method (evaluation). </del> <ins> evaluate the condition as per evaluation prior to performing the method. </ins> To evaluate a received If-None-Match header field:
Code change:
this is the part of URL related to -semantics
Continueing the discussion from URL Looking at the next text in context: To me it's unclear why we are calling out bare CR here, isn't the situation the same for LF and CRLF?? This also is not a new requirement, the ABNF does not allow CR and friends in field-value, and in 3.2 we say "A sender MUST NOT generate protocol elements that do not match the grammar defined by the corresponding ABNF rules." The subsequent paragraph talks about whitespace, and it may not be clear to everyone which characters we are referring to here (not the ones listed in Section 1.2.1 "Whitespace", correct?)
Proposal:
NAME ?
(forked from )
A bit iffy given the sentence above it, but okay.

Related discussion:
text: transfers to only those changed during the specified window. An origin server that receives an If-Modified-Since header field <del> SHOULD evaluate the condition prior to performing the method (evaluation).  The origin server SHOULD NOT perform the requested </del> <ins> SHOULD evaluate the condition as per evaluation prior to performing the method.  The origin server SHOULD NOT perform the requested </ins> method if the selected representation's last modification date is earlier than or equal to the date provided in the field value; instead, the origin server SHOULD generate a
Code change:
this is the part of URL related to -semantics
Continueing the discussion from URL Looking at the next text in context: To me it's unclear why we are calling out bare CR here, isn't the situation the same for LF and CRLF?? This also is not a new requirement, the ABNF does not allow CR and friends in field-value, and in 3.2 we say "A sender MUST NOT generate protocol elements that do not match the grammar defined by the corresponding ABNF rules." The subsequent paragraph talks about whitespace, and it may not be clear to everyone which characters we are referring to here (not the ones listed in Section 1.2.1 "Whitespace", correct?)
Proposal:
NAME ?
(forked from )
A bit iffy given the sentence above it, but okay.

Related discussion:
text: request. An origin server that receives an If-Unmodified-Since header field <del> MUST evaluate the condition (evaluation) prior to performing the </del> <ins> MUST evaluate the condition as per evaluation prior to performing the </ins> method. If the selected representation has a last modification date, the
Code change:
Status code 308 is missing from the list in paragraph 2 of Section 9.1 of Semantics: "Responses with status codes that are defined as heuristically cacheable (e.g., 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501 in this specification) ..."

Related discussion:
text: replaced by local equivalents without affecting the protocol. Responses with status codes that are defined as heuristically <del> cacheable (e.g., 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501 in this specification) can be reused by a cache with </del> <ins> cacheable (e.g., 200, 203, 204, 206, 300, 301, 308, 404, 405, 410, 414, and 501 in this specification) can be reused by a cache with </ins> heuristic expiration unless otherwise indicated by the method definition or explicit cache controls Caching; all other status codes are not heuristically cacheable.
Code change:
It might be worth checking that clients indeed treat it the same as an unknown value.
That's an interesting question as well; but it seems to be orthogonal to this issue. Handling content codings is tricky (such as wrt ordering, repetition, and unknown encodings), It would indeed be good to have tests.
-> move req into field definitions
fixed by

Related discussion:
text: If one or more encodings have been applied to a representation, the sender that applied the encodings MUST generate a Content-Encoding header field that lists the content codings in the order in which <del> they were applied.  Additional information about the encoding parameters can be provided by other header fields not defined by this specification. </del> <ins> they were applied.  Note that the coding named "identity" is reserved for its special role in , and thus SHOULD NOT be included. Additional information about the encoding parameters can be provided by other header fields not defined by this specification. </ins> Unlike Transfer-Encoding (field.transfer-encoding), the codings listed in Content-Encoding are a characteristic of the
Code change:
These are just the cherry picked moves from that are moving sections to Semantics.
created issue for this
See

Related discussion:
text: 7.4. <del> The "TE" header field in a request indicates what transfer codings, besides chunked, the client is willing to accept in response, and whether or not the client is willing to accept trailer fields in a chunked transfer coding. </del> <ins> The TE field (field.te) is used in HTTP/1.1 to indicate what transfer-codings, besides chunked, the client is willing to accept in the response, and whether or not the client is willing to accept trailer fields in a chunked transfer coding. </ins> <del> The TE field-value consists of a list of transfer coding names, each allowing for optional parameters (as described in transfer.codings), and/or the keyword "trailers".  A client MUST NOT send the chunked transfer coding name in TE; chunked is always acceptable for HTTP/1.1 recipients. </del> <ins> A client MUST NOT send the chunked transfer coding name in TE; chunked is always acceptable for HTTP/1.1 recipients. </ins> Three examples of TE use are below.
Code change:
These are just the cherry picked moves from that are moving sections to Semantics.
created issue for this
See

Related discussion:
text: field.components defines some generic syntactic components for field values. <del> The rules below are defined in Messaging: </del> <ins> The rule below is defined in Messaging; </ins> This specification uses the terms "character", "character encoding scheme", "charset", and "protocol element" as they are defined in
Code change:
These are just the cherry picked moves from that are moving sections to Semantics.
created issue for this
See

Related discussion:
text: header field in the header section of that message to indicate which fields might be present in the trailers. <ins> 4.6.4. The "TE" header field in a request can be used to indicate that the sender will not discard trailer fields when it contains a "trailers" member, as described in trailer.fields. Additionally, specific HTTP versions can use it to indicate the transfer codings the client is willing to accept in the response. The TE field-value consists of a list of tokens, each allowing for optional parameters (as described in parameter). </ins> 4.7. See field.names for a general requirements for field names, and
Code change:
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.

Related discussion:
text: 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
Code change:
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.

Related discussion:
text: 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
Code change:
... for If-Match and If-None-Match.
URL to special-case "*" as top-level construct.
Also need to fix things like to something like
Discussed; intent is to add a note at the end of each section pointing out that the behaviour of multiple/mixed stars is undefined, and that this is a lame way to specify a field.

Related discussion:
text: The If-Match header field can be ignored by caches and intermediaries because it is not applicable to a stored response. <ins> Note that an If-Match header field with a list value containing "*" and other values (including other instances of "*") is unlikely to be interoperable. </ins> 8.2.4. The "If-None-Match" header field makes the request method conditional
Code change:
... for If-Match and If-None-Match.
URL to special-case "*" as top-level construct.
Also need to fix things like to something like
Discussed; intent is to add a note at the end of each section pointing out that the behaviour of multiple/mixed stars is undefined, and that this is a lame way to specify a field.

Related discussion:
text: Requirements on cache handling of a received If-None-Match header field are defined in validation.received. <ins> Note that an If-None-Match header field with a list value containing "*" and other values (including other instances of "*") is unlikely to be interoperable. </ins> 8.2.5. The "If-Modified-Since" header field makes a GET or HEAD request
Code change:
Leaves registration of "" for .
Yes, seems to be a bug in bap. Will check.
it uses "" / #vary but "vary" is a token, and token allows "" anyway. Also, see .
In particular, "" is a valid field name. We probably should reserve it in the registry.
(CORS has an issue like that as well, including for a method; see the note at URL)
Proposal: vary-by = "" / field-name Vary = 1#vary-by Then state that if "" appears, no "real" field-name is allowed to appear as well (for backwards compat). Do we need to discuss cases like Vary: , ?
I don't see why that is an improvement.
I thought we were going to reserve and define its meaning in prose...
I.e., it should just be
which implies registering "*" as reserved field name, right?
Yes. That's
Discussed; will create a PR to move ABNF and prose to list-based.
Do we need to list that as change from 7230?
Probably a good idea; will commit to master and link here.
hit the wrong option

Related discussion:
text: The "Vary" header field in a response describes what parts of a request message, aside from the method, Host header field, and target URI, might influence the origin server's process for selecting and <del> representing this response.  The value consists of either a single asterisk ("*") or a list of header field names (case-insensitive). A Vary field value of "*" signals that anything about the request might play a role in selecting the response representation, possibly including elements outside the message syntax (e.g., the client's network address).  A recipient will not be able to determine whether this response is appropriate for a later request without forwarding the request to the origin server.  A proxy MUST NOT generate a Vary field with a "*" value. A Vary field value consisting of a list of field names indicates that the named request header fields, known as the selecting header fields, might have a role in selecting the representation.  The potential selecting header fields are not limited to those defined by this specification. </del> <ins> representing this response. A Vary field value is a list of request field names, known as the selecting header fields, that might have a role in selecting the representation for this response.  Potential selecting header fields are not limited to those defined by this specification. If the list contains "*", it signals that other aspects of the request might play a role in selecting the response representation, possibly including elements outside the message syntax (e.g., the client's network address).  A recipient will not be able to determine whether this response is appropriate for a later request without forwarding the request to the origin server.  A proxy MUST NOT generate "*" in a Vary field value. </ins> For example, a response that contains
Code change:
I got distracted by old text and revised the introduction of semantics.
The introduction should reference the currently defined wire formats (1.1 and 2, also 1.0 maybe). We also need to figure out whether and where to mention differences: expect/continue transfer codings status phrase
Also, the current introduction to all three documents says: That needs to be adjusted to something like:
HTTP/1.2? Is there something you need to share with the working group, NAME
I think (but am not sure) that this has been covered by the changes made in Maybe NAME and NAME could have a look and see if the short HTTP/2 and HTTP/3 descriptions need more flowers.
I think that the number of flowers (->0) is entirely appropriate and I would be happy with those descriptions, with maybe a small tweak to the HTTP/3 text.
I left a review; once we resolve comments on the PR, I think this can be closed.
Some nits, but I like the direction generally.Awesome!

Related discussion:
text: Conformance criteria and considerations regarding error handling are defined in conformance. <del> 1.2. </del> <ins> 1.6. </ins> This specification uses the Augmented Backus-Naur Form (ABNF) notation of RFC5234, extended with the notation for case-sensitivity
Code change:
I got distracted by old text and revised the introduction of semantics.
The introduction should reference the currently defined wire formats (1.1 and 2, also 1.0 maybe). We also need to figure out whether and where to mention differences: expect/continue transfer codings status phrase
Also, the current introduction to all three documents says: That needs to be adjusted to something like:
HTTP/1.2? Is there something you need to share with the working group, NAME
I think (but am not sure) that this has been covered by the changes made in Maybe NAME and NAME could have a look and see if the short HTTP/2 and HTTP/3 descriptions need more flowers.
I think that the number of flowers (->0) is entirely appropriate and I would be happy with those descriptions, with maybe a small tweak to the HTTP/3 text.
I left a review; once we resolve comments on the PR, I think this can be closed.
Some nits, but I like the direction generally.Awesome!

Related discussion:
text: scheme", "charset", and "protocol element" as they are defined in RFC6365. <del> 1.2.1. </del> <ins> 1.6.1. </ins> This specification uses three rules to denote the use of linear whitespace: OWS (optional whitespace), RWS (required whitespace), and
Code change:
Vary is described as: 'Host header field' is redundant; the target URI has that information already (and correctly) included.

Related discussion:
text: 11.1.4. The "Vary" header field in a response describes what parts of a <del> request message, aside from the method, Host header field, and target URI, might influence the origin server's process for selecting and representing this response. </del> <ins> request message, aside from the method and target URI, might influence the origin server's process for selecting and representing this response. </ins> A Vary field value is a list of request field names, known as the selecting header fields, that might have a role in selecting the
Code change:
As part of the discussion about the Encryption specification we discussed how Content-Encodings can or should take parameters from HTTP headers. The consensus was that they shouldn't. Whatever information a C-E may need should be inside the body of the object, just like the GZIP header etc. We should document this as a rule, if we ever do a HTTP[1].ter
+1, except for the constraint: "when possible". In the case of the encryption coding, it's clearly necessary to have the actual key information needed for description outside the payload.
we can add something to URL
I'm fine with this, but I'm also fine with closing with no action. I'm not sure what value it's really adding, since it's so vague, but I'm not sure what else can be said.

Related discussion:
text: RFC8126) and MUST conform to the purpose of content coding defined in content.codings. <ins> New content codings ought to be self-descriptive whenever possible, with optional parameters discoverable within the coding format itself, rather than rely on external metadata that might be lost during transit. </ins> 7.1.3. A language tag, as defined in RFC5646, identifies a natural language
Code change:
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/?

Related discussion:
text: 7.2.4. <ins> The "Content-Length" header field indicates the associated representation's data length as a decimal non-negative integer number of octets.  When transferring a representation in a message, Content- Length refers specifically to the amount of data enclosed so that it can be used to delimit framing of the message body (e.g., body.content-length).  In other cases, Content-Length indicates the selected representation's current length, which can be used by recipients to estimate transfer time or compare to previously stored representations. </ins> An example is A sender MUST NOT send a Content-Length header field in any message