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

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

Revised text:
8.4.  Some HTTP/1.1 implementations use ambient signals to determine if a request is for an "https" resource.  For example, implementations  <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
Original 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>  The presence of some Proxy Error Types indicates that the response was generated by the intermediary itself, rather than being forwarded

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

Revised text:
The "error" parameter's value is an sf-token that is a Proxy Error Type.  When present, it indicates that the intermediary encountered  <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
Original 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>  For example:

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

Revised 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  <ins> contacted) to obtain this response.  It might be a hostname, IP address, or alias. </ins> For example:
Original 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>  The value MUST be either an sf-token or sf-binary, representing a TLS Application-Layer Protocol Negotiation (ALPN) Protocol ID (see

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

Revised text:
The "next-protocol" parameter's value indicates the ALPN protocol identifier RFC7301 of the protocol used by the intermediary to  <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
Original 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>  The value MUST be an sf-integer.

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

Revised text:
2.1.4. The "received-status" parameter's value indicates the HTTP status  <ins> code that the intermediary received from the next hop server when obtaining this response. </ins> The value MUST be an sf-integer.
Original 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>  security, such as Transport Layer Security (TLS) RFC5246. An origin server might wish to segment its clients into groups of

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

Revised text:
location that is more local to the client. An origin server might wish to offer access to its resources using  <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
Original 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>  The remainder of this section describes requirements that are common to alternative services, regardless of how they are discovered.

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

Revised 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  <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.
Original 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>  <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>  <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>  associated with the origin of that stream. <del> An ALTSVC frame from a server to a client on stream 0 indicates that </del>  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>  The ALTSVC frame contains the following fields:

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

Revised text:
4.  <ins> The ALTSVC frame advertises the availability of an alternative service to an HTTP/2 or HTTP/3 client. </ins>  <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>  <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.  <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.  <ins> The ALTSVC frame type is 0xa (decimal 10) in both protocols. </ins> The ALTSVC frame contains the following fields:
Original 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>  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>  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>  The ALTSVC frame is processed hop-by-hop.  An intermediary MUST NOT forward ALTSVC frames, though it can use the information contained in

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

Revised text:
identical to the Alt-Svc field value defined in alt-svc-field (ABNF production "Alt-Svc").  <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.  <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  <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
Original text:
7.3.  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>  A registration MUST include the following fields:

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

Revised 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>.  <ins> 7.4.1. </ins> A registration MUST include the following fields:
Original text:
Values to be added to this name space require Expert Review (see Section 4.1 of RFC5226). <del> 7.3.2. </del>  The "Hypertext Transfer Protocol (HTTP) Alt-Svc Parameter Registry" has been populated with the registrations below:

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

Revised text:
Values to be added to this name space require Expert Review (see Section 4.1 of RFC5226).  <ins> 7.4.2. </ins> The "Hypertext Transfer Protocol (HTTP) Alt-Svc Parameter Registry" has been populated with the registrations below:
Original 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>  3.

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

Revised text:
representation digest on an empty string (see usage-in-signatures). The checksum is computed using one of the digest-algorithms listed in  <ins> the HTTP Digest Algorithm Values Registry (see algorithms) and then encoded in the associated format. </ins> 3.
Original text:
is preferred; digest-algorithm token values MUST be compared in a case-insensitive fashion.  The "HTTP Digest Algorithm Values Registry", maintained by IANA at https://www.iana.org/assignments/http-dig-alg/ [3] registers digest- algorithm values.  Registrations MUST include the following fields:

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

Revised text:
is preferred; digest-algorithm token values MUST be compared in a case-insensitive fashion. <ins> Every digest-algorithm defines its computation procedure and encoding output.  Unless specified otherwise, comparison of encoded output is case-sensitive. </ins> The "HTTP Digest Algorithm Values Registry", maintained by IANA at https://www.iana.org/assignments/http-dig-alg/ [3] registers digest- algorithm values.  Registrations MUST include the following fields: