jiebi/CodeConvo huggingface dataset:
Code change:
wouldn't the "Proxy-Status" header field require an action in the IANA considerations section to register the header field itself? currently, the only things in this section are the creation of new registries required for the header field.
a la rewriting, invalidation controls, etc. See

Related discussion:
text: 2.3. <ins> HTTP caching has a single, end-to-end freshness model defined in Section 4.2 of I-D.ietf-httpbis-cache.  When additional freshness mechanisms are only available to some caches along a request path (for example, using targeted fields), their interactions need to be carefully considered.  In particular, a targeted cache might have longer freshness lifetimes available to it than other caches, causing it to serve responses that appear to be prematurely (or even immediately) stale to them, negatively impacting cache efficiency. For example, a response stored by a CDN cache might be served with the following headers: From the CDN's perspective, this response is still fresh after being cached for 30 minutes, while from other caches' standpoint, this response is already stale.  See AGE-PENALTY for more discussion. When the targeted cache has a strong coherence mechanism (e.g., the origin server has the ability to proactively invalidate cached responses), it is often desirable to mitigate these effects.  Some techniques seen in deployments include: Removing the Age header field Updating the Date header field value to the current time Updating the Expires header field value to the current time, plus any Cache-Control: max-age value This specification does not place any specific requirements on implementations to mitigate these effects, but definitions of targeted fields can do so. 2.4. </ins> A targeted field for a particular class of cache can be defined by requesting registration in the Hypertext Transfer Protocol (HTTP) Field Name Registry https://www.iana.org/assignments/http-fields/
Code change:
I think that I caught everything in the first round of discussion. There aren't any substantial changes here, but it's a PR so that others can confirm.

Related discussion:
text: This document describes a use of HTTP Alternative Services I-D.ietf- httpbis-alt-svc to decouple the URI scheme from the use and configuration of underlying encryption, allowing a "http" URI RFC7230 <del> to be accessed using TLS RFC5246 opportunistically. </del> <ins> to be accessed using Transport Layer Security (TLS) RFC5246 opportunistically. </ins> Serving "https" URIs require acquiring and configuring a valid certificate, which means that some deployments find supporting TLS
Code change:
I think that I caught everything in the first round of discussion. There aren't any substantial changes here, but it's a PR so that others can confirm.

Related discussion:
text: Normally, users will not be able to tell that it is in use (i.e., there will be no "lock icon"). <del> By its nature, this technique is vulnerable to active attacks.  A mechanism for partially mitigating them is described in commit. </del> <ins> A mechanism for partially mitigating active attacks is described in commit. </ins> 1.1.
Code change:
I think that I caught everything in the first round of discussion. There aren't any substantial changes here, but it's a PR so that others can confirm.

Related discussion:
text: As defined in that specification, one way of establishing this is using a TLS-based protocol with the certificate checks defined in <del> RFC2818.  Clients MAY impose additional criteria for establishing reasonable assurances. </del> <ins> RFC2818.  Clients are permitted to impose additional criteria for establishing reasonable assurances. </ins> For the purposes of this specification, an additional way of establishing reasonable assurances is available when the alternative
Code change:
I think that I caught everything in the first round of discussion. There aren't any substantial changes here, but it's a PR so that others can confirm.

Related discussion:
text: the alternative service can provide any certificate, or even select TLS cipher suites that do not include authentication. <del> When the client has a valid http-opportunistic response for an origin, it MAY consider there to be reasonable assurances when: </del> <ins> A client acquires an http-opportunistic response by making a GET request to the "http-opportunistic" well-known URI.  When the client has a valid http-opportunistic response for an origin, it MAY consider there to be reasonable assurances when: </ins> The origin and alternative service's hostnames are the same when compared in a case-insensitive fashion, and
Code change:
I think that I caught everything in the first round of discussion. There aren't any substantial changes here, but it's a PR so that others can confirm.

Related discussion:
text: is initially created for "http" URIs without authenticating the server cannot be used for "https" URIs until the server certificate is successfully authenticated.  Section 3.1 of RFC2818 describes the <del> basic mechanism, though the authentication considerations in I- D.ietf-httpbis-alt-svc also apply. </del> <ins> basic mechanism, though the authentication considerations in Section 2.1 of I-D.ietf-httpbis-alt-svc also apply. </ins> Connections that are established without any means of server <del> authentication (for instance, the purely anonymous TLS cipher suites), cannot be used for "https" URIs. </del> <ins> authentication (for instance, the purely anonymous TLS cipher suites) cannot be used for "https" URIs. </ins> 5.
Code change:
I think that I caught everything in the first round of discussion. There aren't any substantial changes here, but it's a PR so that others can confirm.

Related discussion:
text: 5.1. An origin can reduce the risk of attacks on opportunistically secured <del> connections by committing to provide an secured, authenticated </del> <ins> connections by committing to provide a secured, authenticated </ins> alternative service.  This is done by including the optional "commit" member in the http-opportunistic well-known resource (see well- known).  This feature is optional due to the requirement for server
Code change:
I think that I caught everything in the first round of discussion. There aren't any substantial changes here, but it's a PR so that others can confirm.

Related discussion:
text: The "origins" member of the root object has a value of an array of strings, one of which is a case-insensitive character-for- character match for the origin in question, serialised into <del> Unicode as per RFC6454, Section 6.1, and </del> <ins> Unicode as per Section 6.1 of RFC6454. </ins> This specification defines one additional, optional member of the root object, "commit" in commit.  Unrecognised members MUST be
Code change:
I think that I caught everything in the first round of discussion. There aren't any substantial changes here, but it's a PR so that others can confirm.

Related discussion:
text: 7. <del> This specification registers a Well-known URI RFC5785: </del> <ins> This specification registers a Well-Known URI RFC5785: </ins> URI Suffix: http-opportunistic Change Controller: IETF <del> Specification Document(s): [this specification] </del> <ins> Specification Document(s): well-known of [this specification] </ins> Related Information:
Code change:
I think that I caught everything in the first round of discussion. There aren't any substantial changes here, but it's a PR so that others can confirm.

Related discussion:
text: 8.2. A downgrade attack against the negotiation for TLS is possible.  With <del> commitment commit, this is limited to occasions where clients have no prior information (see privacy), or when persisted commitments have expired. </del> <ins> commitment (see commit), this is limited to occasions where clients have no prior information (see privacy), or when persisted commitments have expired. </ins> For example, because the "Alt-Svc" header field I-D.ietf-httpbis-alt- svc likely appears in an unauthenticated and unencrypted channel, it
Code change:
I think that I caught everything in the first round of discussion. There aren't any substantial changes here, but it's a PR so that others can confirm.

Related discussion:
text: 8.4. <del> Many existing HTTP/1.1 implementations use the presence or absence of TLS in the stack to determine whether requests are for "http" or "https" resources.  This is necessary in many cases because the most common form of an HTTP/1.1 request does not carry an explicit indication of the URI scheme. HTTP/1.1 MUST NOT be used for opportunistically secured requests. </del> Some HTTP/1.1 implementations use ambient signals to determine if a request is for an "https" resource.  For example, implementations <del> might look for TLS on the stack or a port number of 443.  An implementation that supports opportunistically secured requests SHOULD suppress these signals if there is any potential for confusion. </del> <ins> might look for TLS on the stack or a port number of 443.  This is necessary in many cases because the most common form of an HTTP/1.1 request does not carry an explicit indication of the URI scheme.  An implementation that is serving an opportunistically secured request SHOULD suppress these signals for "http" resources. HTTP/1.1 MUST NOT be used to serve opportunistically secured requests.  HTTP/1.1 can be used to discover an opportunistically secured alternative service. </ins> 9.  References
Code change:
I noticed that parameters are generally defined in terms of what happened to generate this response, whether or not the next hop was actually contacted. The exception is , which says: I think it's potentially valuable for a response to indicate what protocol it was fetched over even if it comes from cache. The remedy would be to remove that statement and align this with the other parameters by talking about 'this response'. Probably also making that more prominent in . Thoughts, NAME
Thanks!

Related discussion:
text: The "error" parameter's value is an sf-token that is a Proxy Error Type.  When present, it indicates that the intermediary encountered <del> an issue when obtaining a response. </del> <ins> an issue when obtaining this response. </ins> The presence of some Proxy Error Types indicates that the response was generated by the intermediary itself, rather than being forwarded
Code change:
I noticed that parameters are generally defined in terms of what happened to generate this response, whether or not the next hop was actually contacted. The exception is , which says: I think it's potentially valuable for a response to indicate what protocol it was fetched over even if it comes from cache. The remedy would be to remove that statement and align this with the other parameters by talking about 'this response'. Probably also making that more prominent in . Thoughts, NAME
Thanks!

Related discussion:
text: The "next-hop" parameter's value is an sf-string or sf-token that identifies the intermediary or origin server selected (and used, if <del> contacted) for this response.  It might be a hostname, IP address, or alias. </del> <ins> contacted) to obtain this response.  It might be a hostname, IP address, or alias. </ins> For example:
Code change:
I noticed that parameters are generally defined in terms of what happened to generate this response, whether or not the next hop was actually contacted. The exception is , which says: I think it's potentially valuable for a response to indicate what protocol it was fetched over even if it comes from cache. The remedy would be to remove that statement and align this with the other parameters by talking about 'this response'. Probably also making that more prominent in . Thoughts, NAME
Thanks!

Related discussion:
text: The "next-protocol" parameter's value indicates the ALPN protocol identifier RFC7301 of the protocol used by the intermediary to <del> connect to the next hop.  This is only applicable when that connection was actually established. </del> <ins> connect to the next hop when obtaining this response. </ins> The value MUST be either an sf-token or sf-binary, representing a TLS Application-Layer Protocol Negotiation (ALPN) Protocol ID (see
Code change:
I noticed that parameters are generally defined in terms of what happened to generate this response, whether or not the next hop was actually contacted. The exception is , which says: I think it's potentially valuable for a response to indicate what protocol it was fetched over even if it comes from cache. The remedy would be to remove that statement and align this with the other parameters by talking about 'this response'. Probably also making that more prominent in . Thoughts, NAME
Thanks!

Related discussion:
text: 2.1.4. The "received-status" parameter's value indicates the HTTP status <del> code that the intermediary received from the next hop server. </del> <ins> code that the intermediary received from the next hop server when obtaining this response. </ins> The value MUST be an sf-integer.
Code change:
The changes here are relatively small, but please ensure I didn't miss anything. Because not all HTTP/3 streams are framed, I restated "on any other stream" to specify "request and push streams," language which I believe remains appropriate for HTTP/2. In order to keep the frames as identical as possible, I haven't restructured the H3 version with varints, but that's certainly an option. It would require defining the frame payloads separately, but that's possible.
LGTM. Nice and simple. Suggestions are all things you can ignore.

Related discussion:
text: location that is more local to the client. An origin server might wish to offer access to its resources using <del> a new protocol, such as HTTP/2 HTTP2, or one using improved </del> <ins> a new protocol, such as HTTP/3 HTTP3, or one using improved </ins> security, such as Transport Layer Security (TLS) RFC5246. An origin server might wish to segment its clients into groups of
Code change:
The changes here are relatively small, but please ensure I didn't miss anything. Because not all HTTP/3 streams are framed, I restated "on any other stream" to specify "request and push streams," language which I believe remains appropriate for HTTP/2. In order to keep the frames as identical as possible, I haven't restructured the H3 version with varints, but that's certainly an option. It would require defining the frame payloads separately, but that's possible.
LGTM. Nice and simple. Suggestions are all things you can ignore.

Related discussion:
text: There are many ways that a client could discover the alternative service(s) associated with an origin.  This document describes two such mechanisms: the "Alt-Svc" HTTP header field (alt-svc-field) and <del> the "ALTSVC" HTTP/2 frame type (ALTSVC-frame). </del> <ins> the "ALTSVC" frame type for HTTP/2 and HTTP/3 (ALTSVC-frame). </ins> The remainder of this section describes requirements that are common to alternative services, regardless of how they are discovered.
Code change:
The changes here are relatively small, but please ensure I didn't miss anything. Because not all HTTP/3 streams are framed, I restated "on any other stream" to specify "request and push streams," language which I believe remains appropriate for HTTP/2. In order to keep the frames as identical as possible, I haven't restructured the H3 version with varints, but that's certainly an option. It would require defining the frame payloads separately, but that's possible.
LGTM. Nice and simple. Suggestions are all things you can ignore.

Related discussion:
text: 4. <del> The ALTSVC HTTP/2 frame (Section 4 of HTTP2) advertises the availability of an alternative service to an HTTP/2 client. </del> <ins> The ALTSVC frame advertises the availability of an alternative service to an HTTP/2 or HTTP/3 client. </ins> <del> The ALTSVC frame is a non-critical extension to HTTP/2.  Endpoints that do not support this frame will ignore it (as per the extensibility rules defined in Section 4.1 of HTTP2). </del> <ins> The ALTSVC frame is a separate non-critical extension in each protocol.  Endpoints that do not support this frame will ignore it (as per the extensibility rules defined in Section 4.1 of HTTP2 and Section 4.1 of HTTP3). </ins> <del> An ALTSVC frame from a server to a client on a stream other than stream 0 indicates that the conveyed alternative service is </del> <ins> An ALTSVC frame from a server to a client on a request stream or a push stream indicates that the conveyed alternative service is </ins> associated with the origin of that stream. <del> An ALTSVC frame from a server to a client on stream 0 indicates that </del> <ins> An ALTSVC frame from a server to a client on the control stream (stream 0 in HTTP/2 or a stream of type 0 in HTTP/3) indicates that </ins> the conveyed alternative service is associated with the origin contained in the Origin field of the frame.  An association with an origin that the client does not consider authoritative for the current connection MUST be ignored. <del> The ALTSVC frame type is 0xa (decimal 10). </del> <ins> The ALTSVC frame type is 0xa (decimal 10) in both protocols. </ins> The ALTSVC frame contains the following fields:
Code change:
The changes here are relatively small, but please ensure I didn't miss anything. Because not all HTTP/3 streams are framed, I restated "on any other stream" to specify "request and push streams," language which I believe remains appropriate for HTTP/2. In order to keep the frames as identical as possible, I haven't restructured the H3 version with varints, but that's certainly an option. It would require defining the frame payloads separately, but that's possible.
LGTM. Nice and simple. Suggestions are all things you can ignore.

Related discussion:
text: identical to the Alt-Svc field value defined in alt-svc-field (ABNF production "Alt-Svc"). <del> The ALTSVC frame does not define any flags. </del> <ins> The ALTSVC frame does not define any flags in HTTP/2; there is no generic flag field for HTTP/3 frames. </ins> The ALTSVC frame is intended for receipt by clients.  A device acting as a server MUST ignore it. <del> An ALTSVC frame on stream 0 with empty (length 0) "Origin" </del> <ins> An ALTSVC frame on the control stream with empty (length 0) "Origin" </ins> information is invalid and MUST be ignored.  An ALTSVC frame on a <del> stream other than stream 0 containing non-empty "Origin" information is invalid and MUST be ignored. </del> <ins> request or push stream containing non-empty "Origin" information is invalid and MUST be ignored. </ins> The ALTSVC frame is processed hop-by-hop.  An intermediary MUST NOT forward ALTSVC frames, though it can use the information contained in
Code change:
The changes here are relatively small, but please ensure I didn't miss anything. Because not all HTTP/3 streams are framed, I restated "on any other stream" to specify "request and push streams," language which I believe remains appropriate for HTTP/2. In order to keep the frames as identical as possible, I haven't restructured the H3 version with varints, but that's certainly an option. It would require defining the frame payloads separately, but that's possible.
LGTM. Nice and simple. Suggestions are all things you can ignore.

Related discussion:
text: 7.3. <ins> This document registers the ALTSVC frame type in the "HTTP/3 Frame Type" registry (Section 11.2.1 of HTTP3). ALTSVC 0xa ALTSVC-frame of this document 7.4. </ins> The "Hypertext Transfer Protocol (HTTP) Alt-Svc Parameter Registry" defines the name space for parameters.  It has been created and will be maintained at <http://www.iana.org/assignments/http-alt-svc- parameters>. <del> 7.3.1. </del> <ins> 7.4.1. </ins> A registration MUST include the following fields:
Code change:
The changes here are relatively small, but please ensure I didn't miss anything. Because not all HTTP/3 streams are framed, I restated "on any other stream" to specify "request and push streams," language which I believe remains appropriate for HTTP/2. In order to keep the frames as identical as possible, I haven't restructured the H3 version with varints, but that's certainly an option. It would require defining the frame payloads separately, but that's possible.
LGTM. Nice and simple. Suggestions are all things you can ignore.

Related discussion:
text: Values to be added to this name space require Expert Review (see Section 4.1 of RFC5226). <del> 7.3.2. </del> <ins> 7.4.2. </ins> The "Hypertext Transfer Protocol (HTTP) Alt-Svc Parameter Registry" has been populated with the registrations below:
Code change:
add registration policy cc: NAME and NAME to URL Using RFC policy avoids the issues we had to face to refresh the current table. See
NAME now it's Specification Required :)
This specification obsoletes 3230 and updates the IANA registry to point to it, but doesn't specify what the registration policy actually is.
Related to NAME says
See
NAME do we need ? [x] 5. 'The IANA acts a registry' reads oddly; it maintains the registry. Also, saying 'the registry contains the tokens listed below' is misleading; these are initial registrations, which can be modified and added to after the RFC is published. Also, these might be better placed in IANA Considerations.[x] 5. There should not be RFC2219-MUSTs in IANA registry text. This can be addressed by having a requirement similar to "Deprecated digest algorithms MUST NOT be used."[ ] 5. The ability to have a digest algorithm that ignores content-codings is something of a surprise after reading section 2; it needs to be at least mentioned up there.
I'm sure I made this comment somewhere but I've lost it. I don't think we should mandate RFC required, that a very high bar for algorithms (and their users) that most likely developed the algoithm elsewhere already. Instead seem like a better option here
NAME imho registering new algos should be done via an RFC, this doesn't imply that those algorithms should be defined in an RFC. While it is fair to delegate the registration to an external specification, I think the approach of an RFC (eg URL ) is a lot more clean and improves the overall interoperability. It is important to note that any type of RFC is sufficient (currently Standards Track, BCP, Informational, Experimental, or Historic). In any case, I don't think this should be a game-stopper, so if there's general consensus on "Specification Required", that's ok.
I don't think running an RFC process can provide any meaningful value to the registration requirements. I mean, that's going to add like a year of overhead to something as simple as "use algorithm $foo with token , the output is encoded using base64".
The key to Specification Required is the Designated Experts. If they do they job you basically get what you need. If there's any question from the DEs they can always kick it back out for further review.
NAME Seems that NAME is on the same page URL ;) So let it be Specification Required! Move on :)

Related discussion:
text: representation digest on an empty string (see usage-in-signatures). The checksum is computed using one of the digest-algorithms listed in <del> algorithms and then encoded in the associated format. </del> <ins> the HTTP Digest Algorithm Values Registry (see algorithms) and then encoded in the associated format. </ins> 3.