jiebi/CodeConvo huggingface dataset:
Code change:
(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.

Related discussion:
text: representations of error or processing status, and potentially even the miscellaneous text strings that might appear within the protocol. <ins> For each of these header fields, a request that does not contain it implies that the user agent has no preference on that axis of negotiation.  If the header field is present in a request and none of the available representations for the response can be considered acceptable according to it, the origin server can either honor the header field by sending a response or disregard the header field by treating the response as if it is not subject to content negotiation for that request header field.  This does not imply, however, that the client will be able to use the representation. Sending these header fields makes it easier for a server to identify an individual by virtue of the user agent's request characteristics (fingerprinting). Each of these header fields defines a wildcard value (often, "*") to select unspecified values.  If no wildcard is present, all values not explicitly mentioned in the field are considered "not acceptable" to the client. In practice, using wildcards in content negotiation has limited practical value, because it is seldom useful to say, for example, "I prefer image/* more or less than (some other specific value)". Clients can explicitly request a response if a more preferred format is not available by sending Accept: */*;q=0, but they still need to be able to handle a different response, since the server is allowed to ignore their preference. </ins> 8.4.1. Many of the request header fields for
Code change:
(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.

Related discussion:
text: 8.4.2. <del> The "Accept" header field can be used by user agents to specify response media types that are acceptable.  Accept header fields can be used to indicate that the request is specifically limited to a small set of desired types, as in the case of a request for an in- line image. </del> <ins> The "Accept" header field can be used by user agents to specify their preferences regarding response media types.  For example, Accept header fields can be used to indicate that the request is specifically limited to a small set of desired types, as in the case of a request for an in-line image. </ins> The asterisk "*" character is used to group media types into ranges, with "*/*" indicating all media types and "type/*" indicating all
Code change:
(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.

Related discussion:
text: is interpreted as "I prefer audio/basic, but send me any audio type if it is the best available after an 80% markdown in quality". <del> A request without any Accept header field implies that the user agent will accept any media type in response.  If the header field is present in a request and none of the available representations for the response have a media type 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 response as if it is not subject to content negotiation. </del> A more elaborate example is Verbally, this would be interpreted as "text/html and text/x-c are
Code change:
(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.

Related discussion:
text: 8.4.3. The "Accept-Charset" header field can be sent by a user agent to <del> indicate what charsets are acceptable in textual response content. This field allows user agents capable of understanding more comprehensive or special-purpose charsets to signal that capability to an origin server that is capable of representing information in those charsets. </del> <ins> indicate its preferences for charsets in textual response content. For example, this field allows user agents capable of understanding more comprehensive or special-purpose charsets to signal that capability to an origin server that is capable of representing information in those charsets. </ins> Charset names are defined in charset.  A user agent MAY associate a quality value with each charset to indicate the user's relative
Code change:
(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.

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

Related discussion:
text: For example, <del> A request without an Accept-Encoding header field implies that the user agent has no preferences regarding content-codings.  Although this allows the server to use any content-coding in a response, it does not imply that the user agent will be able to correctly process all encodings. </del> A server tests whether a content-coding for a given representation is acceptable using these rules:
Code change:
(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.

Related discussion:
text: would mean: "I prefer Danish, but will accept British English and other types of English". <del> A request without any Accept-Language header field implies that the user agent will accept any language in response.  If the header field is present in a request and none of the available representations for the response have a matching language tag, the origin server can either disregard the header field by treating the response as if it is not subject to content negotiation or honor the header field by sending a response.  However, the latter is not encouraged, as doing so can prevent users from accessing content that they might be able to use (with translation software, for example). </del> Note that some recipients treat the order in which language tags are listed as an indication of descending priority, particularly for tags that are assigned equal quality values (no value is the same as q=1).
Code change:
This one is almost trivial. Except: previously, the ABNF sort-of ruled out parameters in the ABNF (at least that was the intent) this is now done in prose - we need to say though what to do when parameters are present - is "SHOULD treat as error" correct?
Should not enumerate the actual coding names. Make the ABNF generic and point out that the predefined encodings do not have parameters.
See URL
Instead of saying in each encoding that the presence of an undefined parameter should be treated as an error, it would be better to say that once in the main section for any encoding that does not define its own parameters. But +1 anyway.

Related discussion:
text: A recipient MUST be able to parse and decode the chunked transfer coding. <ins> The chunked encoding does not define any parameters.  Their presence SHOULD be treated as an error. </ins> 7.1.1. The chunked encoding allows each chunk to include zero or more chunk
Code change:
This one is almost trivial. Except: previously, the ABNF sort-of ruled out parameters in the ABNF (at least that was the intent) this is now done in prose - we need to say though what to do when parameters are present - is "SHOULD treat as error" correct?
Should not enumerate the actual coding names. Make the ABNF generic and point out that the predefined encodings do not have parameters.
See URL
Instead of saying in each encoding that the presence of an undefined parameter should be treated as an error, it would be better to say that once in the main section for any encoding that does not define its own parameters. But +1 anyway.

Related discussion:
text: The following transfer coding names for compression are defined by the same algorithm as their corresponding content coding: <ins> The compression codings do not define any parameters.  Their presence SHOULD be treated as an error. </ins> 7.3. The "HTTP Transfer Coding Registry" defines the namespace for
Code change:
I think this is ready.
I think the registry is supposed to reference the obsolete spec where it was last defined, not the spec that mentions it briefly in a change note. In this case, it should be referring to RFC2616 Section 14.15.
NAME - I think the IANA registry should point to both - pull request updated.

Related discussion:
text: sending a payload body on a DELETE request might cause some existing implementations to reject the request. <del> Responses to the DELETE method are not cacheable.  If a DELETE request passes through a cache that has one or more stored responses for the effective request URI, those stored responses will be invalidated (see invalidation). </del> <ins> Responses to the DELETE method are not cacheable.  If a successful DELETE request passes through a cache that has one or more stored responses for the effective request URI, those stored responses will be invalidated (see invalidation). </ins> 7.3.6.
Code change:
I think this is ready.
I think the registry is supposed to reference the obsolete spec where it was last defined, not the spec that mentions it briefly in a change note. In this case, it should be referring to RFC2616 Section 14.15.
NAME - I think the IANA registry should point to both - pull request updated.

Related discussion:
text: registries to indicate that HTTP header field registrations have moved, with an appropriate link. <del> After that is complete, please update the registry with the header field names listed in the table of field.names. </del> <ins> After that is complete, please update the new registry with the header field names listed in the table of field.names. Finally, please update the "Content-MD5" entry in the new registry to have a status of 'obsoleted' with references to RFC2616 (for the definition of the header field) and RFC7231 (which removed the field definition from the updated specification). </ins> 13.5.
Code change:
I think this is ready.
I think the registry is supposed to reference the obsolete spec where it was last defined, not the spec that mentions it briefly in a change note. In this case, it should be referring to RFC2616 Section 14.15.
NAME - I think the IANA registry should point to both - pull request updated.

Related discussion:
text: Content-Language header field Content-Length header field Content-Location header field <ins> Content-MD5 header field </ins> Content-Range header field Content-Type header field cache
Code change:
() work in progress, feedback appreciated. is the actual rule mapping correct? prose in the convered ABNF, should I add the cardinality as comment?
re 3) turns out to be hard as long as we have productions that mix list with something else (see separate issue), because we can't inline comments inside and ABNF production
NAME - your turn to review...
See . Mailing list discussion starts here:
See also
A simple fix for this would be to simplify the list expansion to just map , and to put all other constraints in prose (the current approach doesn't work anyway due to the rules for empty list elements which are not counted).
Proposal for recipient list rule mapping: More eyes requested :-) NAME NAME
The current proposal is incorrect as it does not allow a singleton element.
Maybe: better... for readability:
PR updated
And maybe 1#element => element *( OWS "," OWS [ element ] ) right?
NAME that'd outlaw , which seems wrongish?
Closed by commit e475f36 for the recipient case. Note that this may become obsolete if we switch to only providing ABNF for what is good to send.

Related discussion:
text: A client that generates an OPTIONS request containing a payload body MUST send a valid <del> header field describing the representation media type.  Although this specification does not define any use for such a payload, future extensions to HTTP might use the OPTIONS body to make more detailed queries about the target resource. </del> <ins> header field describing the representation media type.  Note that this specification does not define any use for such a payload. </ins> Responses to the OPTIONS method are not cacheable.
Code change:
() work in progress, feedback appreciated. is the actual rule mapping correct? prose in the convered ABNF, should I add the cardinality as comment?
re 3) turns out to be hard as long as we have productions that mix list with something else (see separate issue), because we can't inline comments inside and ABNF production
NAME - your turn to review...
See . Mailing list discussion starts here:
See also
A simple fix for this would be to simplify the list expansion to just map , and to put all other constraints in prose (the current approach doesn't work anyway due to the rules for empty list elements which are not counted).
Proposal for recipient list rule mapping: More eyes requested :-) NAME NAME
The current proposal is incorrect as it does not allow a singleton element.
Maybe: better... for readability:
PR updated
And maybe 1#element => element *( OWS "," OWS [ element ] ) right?
NAME that'd outlaw , which seems wrongish?
Closed by commit e475f36 for the recipient case. Note that this may become obsolete if we switch to only providing ABNF for what is good to send.

Related discussion:
text: and for n >= 1 and m > 1: <del> For compatibility with legacy list rules, a recipient MUST parse and ignore a reasonable number of empty list elements: enough to handle common mistakes by senders that merge values, but not so much that they could be used as a denial-of-service mechanism.  In other words, a recipient MUST accept lists that satisfy the following syntax: </del> <ins> Empty elements do not contribute to the count of elements present.  A recipient MUST parse and ignore a reasonable number of empty list elements: enough to handle common mistakes by senders that merge values, but not so much that they could be used as a denial-of- service mechanism.  In other words, a recipient MUST accept lists that satisfy the following syntax: Note that because of the potential presence of empty list elements, the RFC 5234 ABNF cannot enforce the cardinality of list elements, and consequently all cases are mapped is if there was no cardinality specified. </ins> <del> Empty elements do not contribute to the count of elements present. </del> For example, given these ABNF productions: Then the following are valid values for example-list (not including