jiebi/TextFlow huggingface dataset:
Original 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>  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

Reviewer comments:
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.

Revised text:
transfers to only those changed during the specified window. An origin server that receives an If-Modified-Since header field  <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
Original text:
request. An origin server that receives an If-Unmodified-Since header field <del> MUST evaluate the condition (evaluation) prior to performing the </del>  method. If the selected representation has a last modification date, the

Reviewer comments:
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.

Revised text:
request. An origin server that receives an If-Unmodified-Since header field  <ins> MUST evaluate the condition as per evaluation prior to performing the </ins> method. If the selected representation has a last modification date, the
Original 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>  heuristic expiration unless otherwise indicated by the method definition or explicit cache controls Caching; all other status codes are not heuristically cacheable.

Reviewer comments:
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) ..."

Revised text:
replaced by local equivalents without affecting the protocol. Responses with status codes that are defined as heuristically  <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.
Original 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>  Unlike Transfer-Encoding (field.transfer-encoding), the codings listed in Content-Encoding are a characteristic of the

Reviewer comments:
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

Revised 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  <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
Original 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>  <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>  Three examples of TE use are below.

Reviewer comments:
These are just the cherry picked moves from that are moving sections to Semantics.
created issue for this
See

Revised text:
7.4.  <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>  <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.
Original text:
request-target T <del> TE header field </del> Transfer-Encoding header field <del> U Upgrade header field </del> X x-compress (transfer coding) x-gzip (transfer coding)

Reviewer comments:
These are just the cherry picked moves from that are moving sections to Semantics.
created issue for this
See

Revised text:
request-target T  Transfer-Encoding header field  X x-compress (transfer coding) x-gzip (transfer coding)
Original text:
field.components defines some generic syntactic components for field values. <del> The rules below are defined in Messaging: </del>  This specification uses the terms "character", "character encoding scheme", "charset", and "protocol element" as they are defined in

Reviewer comments:
These are just the cherry picked moves from that are moving sections to Semantics.
created issue for this
See

Revised text:
field.components defines some generic syntactic components for field values.  <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
Original text:
header field in the header section of that message to indicate which fields might be present in the trailers.  4.7. See field.names for a general requirements for field names, and

Reviewer comments:
These are just the cherry picked moves from that are moving sections to Semantics.
created issue for this
See

Revised 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
Original text:
production can be transmitted either as a token or within a quoted- string.  The quoted and unquoted values are equivalent.  4.5. A #rule extension to the ABNF rules of RFC5234 is used to improve

Reviewer comments:
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.

Revised 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
Original 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

Reviewer comments:
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.

Revised text:
10.1.1.  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
Original text:
The If-Match header field can be ignored by caches and intermediaries because it is not applicable to a stored response.  8.2.4. The "If-None-Match" header field makes the request method conditional

Reviewer comments:
... 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.

Revised 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
Original text:
Requirements on cache handling of a received If-None-Match header field are defined in validation.received.  8.2.5. The "If-Modified-Since" header field makes a GET or HEAD request

Reviewer comments:
... 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.

Revised 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
Original 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>  For example, a response that contains

Reviewer comments:
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

Revised 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  <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
Original text:
Conformance criteria and considerations regarding error handling are defined in conformance. <del> 1.2. </del>  This specification uses the Augmented Backus-Naur Form (ABNF) notation of RFC5234, extended with the notation for case-sensitivity

Reviewer comments:
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!

Revised text:
Conformance criteria and considerations regarding error handling are defined in conformance.  <ins> 1.6. </ins> This specification uses the Augmented Backus-Naur Form (ABNF) notation of RFC5234, extended with the notation for case-sensitivity
Original text:
scheme", "charset", and "protocol element" as they are defined in RFC6365. <del> 1.2.1. </del>  This specification uses three rules to denote the use of linear whitespace: OWS (optional whitespace), RWS (required whitespace), and

Reviewer comments:
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!

Revised text:
scheme", "charset", and "protocol element" as they are defined in RFC6365.  <ins> 1.6.1. </ins> This specification uses three rules to denote the use of linear whitespace: OWS (optional whitespace), RWS (required whitespace), and
Original 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>  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

Reviewer comments:
Vary is described as: 'Host header field' is redundant; the target URI has that information already (and correctly) included.

Revised text:
11.1.4. The "Vary" header field in a response describes what parts of a  <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