jiebi/CodeConvo huggingface dataset:
Code change:
Inspired by some discussion on : while just the word "security" is indeed used in marketing literature for proxies, it's meaning to different parties is so varied so as to not really convey much useful information. In the IETF we try hard to be clear about what security provides we need and/or provide, avoiding the vague catch-all term. However (as I am reminded out of band), the audience of this document is not exactly security experts, and it is easy to go overboard trying to be precise, at least in this instance. [actual commit message body retained below] The mere act of inserting a proxy into the chain does not, in and of itself, do much of anything for the security of the system (and a badly implemented proxy can make the security of the system much worse). A proxy can, however, provide security services such as auditing access, annotating content from untrustworthy sources, exfiltration avoidance, etc. It is these services that are the security-related motivation for using a proxy, so say that "security services", rather than just "security", are being provided by the proxy.

Related discussion:
text: for proxy requests for "http" URIs, whereas other requests might require translation to and from entirely different application-level protocols.  Proxies are often used to group an organization's HTTP <del> requests through a common intermediary for the sake of security, annotation services, or shared caching.  Some proxies are designed to apply transformations to selected messages or content while they are being forwarded, as described in message.transformations. </del> <ins> requests through a common intermediary for the sake of security services, annotation services, or shared caching.  Some proxies are designed to apply transformations to selected messages or content while they are being forwarded, as described in message.transformations. </ins> A
Code change:
It may or may not be useful to have an HTTP extension in order to perform reactive negotiation -- one possible approach that does not require an extension would be policy in the user-agent. In the spirit of "less is more", and to not overly constrain our forward-looking statement, just remove the phrase "as an extension". (inspired by follow-up discussions on )
I almost made the same edit earlier.

Related discussion:
text: request to obtain an alternate representation.  Furthermore, this specification does not define a mechanism for supporting automatic selection, though it does not prevent such a mechanism from being <del> developed as an extension. </del> <ins> developed. </ins> 12.3.
Code change:
The current text of "ought to ... where possible" is easy to read as saying "if you have the technical capability, do it". There are, however, some subtleties, such as if you get the 308 response over http-not-s, in which case the question of whether or not to re-link is not so clear-cut. Change from "where possible" to "where appropriate" to hint that there is some logic needed here beyond "blindly accept". (inspired by follow-up discussions from )
I like Roy's version better than mine :) I guess I was too conservative...
I think that begs a follow-on question about when it is appropriate. I would be more comfortable with changing the entire sentence to be The change itself is good, but it needs to be done for 301 as well.

Related discussion:
text: status code indicates that the has been assigned a new permanent URI and any future references to <del> this resource ought to use one of the enclosed URIs.  Clients with link-editing capabilities ought to automatically re-link references to the target URI to one or more of the new references sent by the server, where possible. </del> <ins> this resource ought to use one of the enclosed URIs.  The server is suggesting that a user agent with link-editing capability can permanently replace references to the target URI with one of the new references sent by the server.  However, this suggestion is usually ignored unless the user agent is actively editing references (e.g., engaged in authoring content), the connection is secured, and the origin server is a trusted authority for the content being edited. </ins> The server SHOULD generate a
Code change:
The current text of "ought to ... where possible" is easy to read as saying "if you have the technical capability, do it". There are, however, some subtleties, such as if you get the 308 response over http-not-s, in which case the question of whether or not to re-link is not so clear-cut. Change from "where possible" to "where appropriate" to hint that there is some logic needed here beyond "blindly accept". (inspired by follow-up discussions from )
I like Roy's version better than mine :) I guess I was too conservative...
I think that begs a follow-on question about when it is appropriate. I would be more comfortable with changing the entire sentence to be The change itself is good, but it needs to be done for 301 as well.

Related discussion:
text: status code indicates that the has been assigned a new permanent URI and any future references to <del> this resource ought to use one of the enclosed URIs.  Clients with link editing capabilities ought to automatically re-link references to the target URI to one or more of the new references sent by the server, where possible. </del> <ins> this resource ought to use one of the enclosed URIs.  The server is suggesting that a user agent with link-editing capability can permanently replace references to the target URI with one of the new references sent by the server.  However, this suggestion is usually ignored unless the user agent is actively editing references (e.g., engaged in authoring content), the connection is secured, and the origin server is a trusted authority for the content being edited. </ins> The server SHOULD generate a
Code change:
Inspired by follow-up discussions on , make a concrete proposal for how the RFC 3986 security considerations might be mentioned in our own security considerations. I understand the editors' stance on adding substantial new text at this point, and will defer to them on whether this constitutes "substantial".

Related discussion:
text: concerns related to HTTP semantics are about securing server-side applications (code behind the HTTP interface), securing user agent processing of content received via HTTP, or secure use of the <del> Internet in general, rather than security of the protocol.  Various organizations maintain topical information and links to current research on Web application security (e.g., OWASP). </del> <ins> Internet in general, rather than security of the protocol.  The security considerations for URIs, which are fundamental to HTTP operation, are discussed in URI.  Various organizations maintain topical information and links to current research on Web application security (e.g., OWASP). </ins> 17.1.
Code change:
note in message-headers registry above move of HTTP registry in message-headers registry, remove obsolete note about HTTP field name registry note in new http field registry

Related discussion:
text: new registration procedure and moving HTTP field definitions into a separate registry. <del> Please create a new registry as outlined in fields.registry. </del> <ins> Please create a new registry as outlined in fields.registry, and let that registry link to this specification (e.g., "See section fields.extensibility of [this document] for information on defining and registering new HTTP Header Fields."). </ins> After creating the registry, all entries in the Permanent and Provisional Message Header Registries with the protocol 'http' are to
Code change:
note in message-headers registry above move of HTTP registry in message-headers registry, remove obsolete note about HTTP field name registry note in new http field registry

Related discussion:
text: Please annotate the Permanent and Provisional Message Header registries to indicate that HTTP field name registrations have moved, <del> with an appropriate link. </del> <ins> with an appropriate link (such as: "HTTP field name registrations have been moved to <https://www.iana.org/assignments/http-fields> per [this document].") and furthermore remove the existing note pointing to RFC7231 ("See section 8.3.1 of [RFC7231] for information on registering new HTTP Header Fields."). </ins> After that is complete, please update the new registry with the field names listed in the following table.
Code change:
NAME - can you review?
The client hint spec does not seem to specify if there's a maximum lifetime for the origin opt-in preferences. There seem to be spec that the data should be cleared when site data, cookies, cache, etc. are cleared, but barring that should there be some sort of reasonable limit?
I'm new to this process; I'm not sure how to add the "client-hints" label
NAME thoughts? You were the one pushing for an implicit lifetime. Do we want to cap it?
I think that what you should say is that the browser can discard this state, but it should do so only when it drops all other state for the origin (e.g., when clearing cookies). Modeling this as part of origin-bound state like that is far easier to reason about and more reliable for sites.
We already have "Implementers SHOULD support Client Hints opt-in mechanisms and MUST clear persisted opt-in preferences when any one of site data, browsing history, browsing cache, or similar, are cleared." Do we need to also add something around origin-bound state to that?
As Safari is already capping script-set storage lifetime to 7 days (Brave does w/ cookies, plans to do for all storage too), and some other vendors have hinted at the same, I suggest a max lifetime of 7 days. Especially given the possibility that these values can be tracking vectors (discussed in the fingerprinting conversation).
The text above means that browsers that choose to set max lifetime to storage/cookies will MUST do the same for Client Hints. I don't think we need to bake in the specific max age that some UAs chose into an IETF draft.
I hear what you're saying, but the purpose of a standard is not to say "some people will act X and some folks will act Y", its to bring X and Y as close as possible. What is the use case for a lifetime of > 7 days? Like any cache value, its perf utility decreases as life time increases, but the privacy risk stays constant. Put differently, what is the concern w/ a maximum value, to at least partially constrain the privacy risk?
Sounds like the restriction you're talking about is of larger scope than Client Hints, and applies the origin storage in general. I suggest you'd try to enforce those specific values e.g. on session cookies, and Client Hints will follow out of that. At the same time, I was under the impressions that when we , we tied the lifetime of Client-Hints persistence to session cookies, but looks like we did not. I'll submit a PR on that front.

Related discussion:
text: Implementers SHOULD support Client Hints opt-in mechanisms and MUST clear persisted opt-in preferences when any one of site data, <del> browsing history, browsing cache, or similar, are cleared. </del> <ins> browsing history, browsing cache, cookies, or similar, are cleared. </ins> 5.
Code change:
An alternative to - removes HTAB everywhere, replaces with .
Right now we use OWS, and suggests moving from SP to RWS for inner list separation. Should we allow tabs in SH? Error on them? If we want to allow them, 983 makes sense, as it's more consistent. However, we'll need to test for tabs...
What's the reason to allow tabs? Compatibility with current headers? Do actual tab characters show up in the wild that often?
We had them in there because we were reusing OWS, not purposefully. AFAICT they don't appear in the wild much at all. So +1 for .
LGTMThank you for working on this. LGTM.

Related discussion:
text: behaviours, and the Augmented Backus-Naur Form (ABNF) notation of RFC5234 to illustrate expected syntax in HTTP header fields.  In doing so, uses the VCHAR, SP, DIGIT, ALPHA and DQUOTE rules from <del> RFC5234.  It also includes the OWS and tchar rules from RFC7230. </del> <ins> RFC5234.  It also includes the tchar rule from RFC7230. </ins> When parsing from HTTP header fields, implementations MUST follow the algorithms, but MAY vary in implementation so as the behaviours are
Code change:
An alternative to - removes HTAB everywhere, replaces with .
Right now we use OWS, and suggests moving from SP to RWS for inner list separation. Should we allow tabs in SH? Error on them? If we want to allow them, 983 makes sense, as it's more consistent. However, we'll need to test for tabs...
What's the reason to allow tabs? Compatibility with current headers? Do actual tab characters show up in the wild that often?
We had them in there because we were reusing OWS, not purposefully. AFAICT they don't appear in the wild much at all. So +1 for .
LGTMThank you for working on this. LGTM.

Related discussion:
text: Append the result of running Serializing an Item (ser-item) with (member_value, parameters) to output. <del> If more values remain in inner_list, append a single WS to </del> <ins> If more values remain in inner_list, append a single SP to </ins> output. Append ")" to output.
Code change:
An alternative to - removes HTAB everywhere, replaces with .
Right now we use OWS, and suggests moving from SP to RWS for inner list separation. Should we allow tabs in SH? Error on them? If we want to allow them, 983 makes sense, as it's more consistent. However, we'll need to test for tabs...
What's the reason to allow tabs? Compatibility with current headers? Do actual tab characters show up in the wild that often?
We had them in there because we were reusing OWS, not purposefully. AFAICT they don't appear in the wild much at all. So +1 for .
LGTMThank you for working on this. LGTM.

Related discussion:
text: Append a COMMA to output. <del> Append a single WS to output. </del> <ins> Append a single SP to output. </ins> Return output.
Code change:
An alternative to - removes HTAB everywhere, replaces with .
Right now we use OWS, and suggests moving from SP to RWS for inner list separation. Should we allow tabs in SH? Error on them? If we want to allow them, 983 makes sense, as it's more consistent. However, we'll need to test for tabs...
What's the reason to allow tabs? Compatibility with current headers? Do actual tab characters show up in the wild that often?
We had them in there because we were reusing OWS, not purposefully. AFAICT they don't appear in the wild much at all. So +1 for .
LGTMThank you for working on this. LGTM.

Related discussion:
text: Convert input_bytes into an ASCII string input_string; if conversion fails, fail parsing. <del> Discard any leading OWS from input_string. </del> <ins> Discard any leading SP characters from input_string. </ins> If header_type is "list", let output be the result of running Parsing a List (parse-list) with input_string.
Code change:
An alternative to - removes HTAB everywhere, replaces with .
Right now we use OWS, and suggests moving from SP to RWS for inner list separation. Should we allow tabs in SH? Error on them? If we want to allow them, 983 makes sense, as it's more consistent. However, we'll need to test for tabs...
What's the reason to allow tabs? Compatibility with current headers? Do actual tab characters show up in the wild that often?
We had them in there because we were reusing OWS, not purposefully. AFAICT they don't appear in the wild much at all. So +1 for .
LGTMThank you for working on this. LGTM.

Related discussion:
text: If header_type is "item", let output be the result of running Parsing an Item (parse-item) with input_string. <del> Discard any leading OWS from input_string. </del> <ins> Discard any leading SP characters from input_string. </ins> If input_string is not empty, fail parsing.
Code change:
An alternative to - removes HTAB everywhere, replaces with .
Right now we use OWS, and suggests moving from SP to RWS for inner list separation. Should we allow tabs in SH? Error on them? If we want to allow them, 983 makes sense, as it's more consistent. However, we'll need to test for tabs...
What's the reason to allow tabs? Compatibility with current headers? Do actual tab characters show up in the wild that often?
We had them in there because we were reusing OWS, not purposefully. AFAICT they don't appear in the wild much at all. So +1 for .
LGTMThank you for working on this. LGTM.

Related discussion:
text: Append the result of running Parsing an Item or Inner List (parse-item-or-list) with input_string to members. <del> Discard any leading OWS from input_string. </del> <ins> Discard any leading SP characters from input_string. </ins> If input_string is empty, return members. Consume the first character of input_string; if it is not COMMA, fail parsing. <del> Discard any leading OWS from input_string. </del> <ins> Discard any leading SP characters from input_string. </ins> If input_string is empty, there is a trailing comma; fail parsing.
Code change:
An alternative to - removes HTAB everywhere, replaces with .
Right now we use OWS, and suggests moving from SP to RWS for inner list separation. Should we allow tabs in SH? Error on them? If we want to allow them, 983 makes sense, as it's more consistent. However, we'll need to test for tabs...
What's the reason to allow tabs? Compatibility with current headers? Do actual tab characters show up in the wild that often?
We had them in there because we were reusing OWS, not purposefully. AFAICT they don't appear in the wild much at all. So +1 for .
LGTMThank you for working on this. LGTM.

Related discussion:
text: While input_string is not empty: <del> Discard any leading OWS from input_string. </del> <ins> Discard any leading SP characters from input_string. </ins> If the first character of input_string is ")":
Code change:
An alternative to - removes HTAB everywhere, replaces with .
Right now we use OWS, and suggests moving from SP to RWS for inner list separation. Should we allow tabs in SH? Error on them? If we want to allow them, 983 makes sense, as it's more consistent. However, we'll need to test for tabs...
What's the reason to allow tabs? Compatibility with current headers? Do actual tab characters show up in the wild that often?
We had them in there because we were reusing OWS, not purposefully. AFAICT they don't appear in the wild much at all. So +1 for .
LGTMThank you for working on this. LGTM.

Related discussion:
text: Add name this_key with value member to dictionary. <del> Discard any leading OWS from input_string. </del> <ins> Discard any leading SP characters from input_string. </ins> If input_string is empty, return dictionary. Consume the first character of input_string; if it is not COMMA, fail parsing. <del> Discard any leading OWS from input_string. </del> <ins> Discard any leading SP characters from input_string. </ins> If input_string is empty, there is a trailing comma; fail parsing.
Code change:
An alternative to - removes HTAB everywhere, replaces with .
Right now we use OWS, and suggests moving from SP to RWS for inner list separation. Should we allow tabs in SH? Error on them? If we want to allow them, 983 makes sense, as it's more consistent. However, we'll need to test for tabs...
What's the reason to allow tabs? Compatibility with current headers? Do actual tab characters show up in the wild that often?
We had them in there because we were reusing OWS, not purposefully. AFAICT they don't appear in the wild much at all. So +1 for .
LGTMThank you for working on this. LGTM.

Related discussion:
text: Consume a ";" character from the beginning of input_string. <del> Discard any leading OWS from input_string. </del> <ins> Discard any leading SP characters from input_string. </ins> let param_name be the result of running Parsing a Key (parse- key) with input_string.
Code change:
... and allow token to start with "*".
I'm running my SH implementation against the HTTP Archive dumps (400,000,000+ HTTP requests) to see how the from BSH parse in something like the real world. It looks like some headers are failing because AcceptAccess-Control-Allow-Origin`. If we were to use a different character to delimit Byte Sequences, we could include in Token (necessarily as a first character, as well as in the rest, I assume). Worthwhile? If so, what should we use for Byte Sequences?
(via ) already allows , but not as a first character. '%' is short in HPACK and unlikely to trigger funny handling, but maybe it will conflict with pct-encoding to start. '=' has the virtue of being already allowed. It has the drawback of causing byte array parameters to look funny ( for instance). Interestingly, it makes removal of padding easier (base64 padding is silly).
How about ? I don't' think is a good idea; if an implementation enforces padding (which we caution against, but do not prohibit), it's confusing.
Checking with NAME NAME - any issues changing byte sequence delimiters from to ?
(the only conflicting use that comes to mind ATM for is that if someone wants to refer to H2 pseudo-headers like in a field that uses tokens, they'll be out of luck. I think that's OK, because existing fields that take header names as a list-of-tokens don't refer to pseudo-headers, and new fields can be defined as lists of tokens-or-strings.)
is free

Related discussion:
text: Note that a Structured Header token allows the characters as the "token" ABNF rule defined in RFC7230, with the exceptions that the <del> first character is required to be ALPHA, and ":" and "/" are also allowed. </del> <ins> first character is required to be either ALPHA or "*", and ":" and "/" are also allowed in subsequent characters. </ins> 3.3.5.
Code change:
... and allow token to start with "*".
I'm running my SH implementation against the HTTP Archive dumps (400,000,000+ HTTP requests) to see how the from BSH parse in something like the real world. It looks like some headers are failing because AcceptAccess-Control-Allow-Origin`. If we were to use a different character to delimit Byte Sequences, we could include in Token (necessarily as a first character, as well as in the rest, I assume). Worthwhile? If so, what should we use for Byte Sequences?
(via ) already allows , but not as a first character. '%' is short in HPACK and unlikely to trigger funny handling, but maybe it will conflict with pct-encoding to start. '=' has the virtue of being already allowed. It has the drawback of causing byte array parameters to look funny ( for instance). Interestingly, it makes removal of padding easier (base64 padding is silly).
How about ? I don't' think is a good idea; if an implementation enforces padding (which we caution against, but do not prohibit), it's confusing.
Checking with NAME NAME - any issues changing byte sequence delimiters from to ?
(the only conflicting use that comes to mind ATM for is that if someone wants to refer to H2 pseudo-headers like in a field that uses tokens, they'll be out of luck. I think that's OK, because existing fields that take header names as a list-of-tokens don't refer to pseudo-headers, and new fields can be defined as lists of tokens-or-strings.)
is free

Related discussion:
text: The ABNF for a byte sequence in HTTP headers is: <del> In HTTP headers, a byte sequence is delimited with asterisks and encoded using base64 (RFC4648, Section 4).  For example: </del> <ins> In HTTP headers, a byte sequence is delimited with colons and encoded using base64 (RFC4648, Section 4).  For example: </ins> Parsers MUST support byte sequences with at least 16384 octets after decoding.