jiebi/TextFlow huggingface dataset:
Original text:
Let URL represent the URL of the outbound request being checked. <del> If the {Origin} of BASEURL and the {Origin} of URL are not the same, return FALSE. </del>  Let MATCH be the value of "match" for the given dictionary.

Reviewer comments:
This addresses the reference issues, comments and nits from the AD review (see )
NAME would you mind taking a quick look before I publish a new draft?
(tried using ietf-comments but ran into issues so just tracking manually in one combined issue)... cc NAME Thank you for the work on this document. Almost all my comments are about references. I think a new version is necessary before starting IETF Last Call, to avoid process issues along the way. Francesca The boilerplate is duplicate, please remove the second occurrence. Can you please update the reference to 8941 to draft-ietf-httpbis-sfbis ? That doc is with the RFC Editor so should not be holding this document up. Also, I believe the reference to draft-ietf-httpbis-sfbis should be normative, not informative, since terminology from that doc is used. Alternatively, if you want to keep the ref informative, you can import the part of the terminology that is necessary for this doc. I think that's a uglier solution, so I highly prefer sfbis to be made normative, but won't block on it. [URLPattern] "URL Pattern Standard", March 2024, URL needs to be indicated as Living standard (see RFC 9110 or 9421 for eample of whatwg specs references). Please fix this so that the Fetch spec is properly referenced (normatively is needed, I believe). RFC 8792 should be (informatively) referenced. I agree with Mark's write up, 5861 should really be informative. There is several occurrences of {Origin}, please fix. Please add a reference. It would be good to have an informative reference to 6265 (or even 6265bis). This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [ tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: URL [ICT]: URL

Revised text:
Let URL represent the URL of the outbound request being checked.  <ins> If the Origin of BASEURL and the Origin of URL are not the same, return FALSE. </ins> Let MATCH be the value of "match" for the given dictionary.
Original text:
9.2. <del> The CRIME attack shows that it's a bad idea to compress data from mixed (e.g. public and private) sources - the data sources include not only the compressed data but also the dictionaries.  For example, if you compress secret cookies using a public-data-only dictionary, you still leak information about the cookies. </del>  Not only can the dictionary reveal information about the compressed data, but vice versa, data compressed with the dictionary can reveal

Reviewer comments:
This addresses the reference issues, comments and nits from the AD review (see )
NAME would you mind taking a quick look before I publish a new draft?
(tried using ietf-comments but ran into issues so just tracking manually in one combined issue)... cc NAME Thank you for the work on this document. Almost all my comments are about references. I think a new version is necessary before starting IETF Last Call, to avoid process issues along the way. Francesca The boilerplate is duplicate, please remove the second occurrence. Can you please update the reference to 8941 to draft-ietf-httpbis-sfbis ? That doc is with the RFC Editor so should not be holding this document up. Also, I believe the reference to draft-ietf-httpbis-sfbis should be normative, not informative, since terminology from that doc is used. Alternatively, if you want to keep the ref informative, you can import the part of the terminology that is necessary for this doc. I think that's a uglier solution, so I highly prefer sfbis to be made normative, but won't block on it. [URLPattern] "URL Pattern Standard", March 2024, URL needs to be indicated as Living standard (see RFC 9110 or 9421 for eample of whatwg specs references). Please fix this so that the Fetch spec is properly referenced (normatively is needed, I believe). RFC 8792 should be (informatively) referenced. I agree with Mark's write up, 5861 should really be informative. There is several occurrences of {Origin}, please fix. Please add a reference. It would be good to have an informative reference to 6265 (or even 6265bis). This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [ tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: URL [ICT]: URL

Revised text:
9.2.  <ins> The compression attacks in RFC7457 show that it's a bad idea to compress data from mixed (e.g. public and private) sources - the data sources include not only the compressed data but also the dictionaries.  For example, if you compress secret cookies using a public-data-only dictionary, you still leak information about the cookies. </ins> Not only can the dictionary reveal information about the compressed data, but vice versa, data compressed with the dictionary can reveal
Original text:
In browser terms, that means that both are either same-origin to the context they are being fetched from or that the response is cross- <del> origin and passes the CORS check (https://fetch.spec.whatwg.org/#cors-check). </del>  9.3.3.

Reviewer comments:
This addresses the reference issues, comments and nits from the AD review (see )
NAME would you mind taking a quick look before I publish a new draft?
(tried using ietf-comments but ran into issues so just tracking manually in one combined issue)... cc NAME Thank you for the work on this document. Almost all my comments are about references. I think a new version is necessary before starting IETF Last Call, to avoid process issues along the way. Francesca The boilerplate is duplicate, please remove the second occurrence. Can you please update the reference to 8941 to draft-ietf-httpbis-sfbis ? That doc is with the RFC Editor so should not be holding this document up. Also, I believe the reference to draft-ietf-httpbis-sfbis should be normative, not informative, since terminology from that doc is used. Alternatively, if you want to keep the ref informative, you can import the part of the terminology that is necessary for this doc. I think that's a uglier solution, so I highly prefer sfbis to be made normative, but won't block on it. [URLPattern] "URL Pattern Standard", March 2024, URL needs to be indicated as Living standard (see RFC 9110 or 9421 for eample of whatwg specs references). Please fix this so that the Fetch spec is properly referenced (normatively is needed, I believe). RFC 8792 should be (informatively) referenced. I agree with Mark's write up, 5861 should really be informative. There is several occurrences of {Origin}, please fix. Please add a reference. It would be good to have an informative reference to 6265 (or even 6265bis). This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [ tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: URL [ICT]: URL

Revised text:
In browser terms, that means that both are either same-origin to the context they are being fetched from or that the response is cross-  <ins> origin and passes the CORS check as defined in FETCH. </ins> 9.3.3.
Original text:
dictionary to turn it into a tracking cookie. To mitigate any additional tracking concerns, clients MUST treat <del> dictionaries in the same way that they treat cookies.  This includes partitioning the storage as cookies are partitioned as well as clearing the dictionaries whenever cookies are cleared. </del> 

Reviewer comments:
This addresses the reference issues, comments and nits from the AD review (see )
NAME would you mind taking a quick look before I publish a new draft?
(tried using ietf-comments but ran into issues so just tracking manually in one combined issue)... cc NAME Thank you for the work on this document. Almost all my comments are about references. I think a new version is necessary before starting IETF Last Call, to avoid process issues along the way. Francesca The boilerplate is duplicate, please remove the second occurrence. Can you please update the reference to 8941 to draft-ietf-httpbis-sfbis ? That doc is with the RFC Editor so should not be holding this document up. Also, I believe the reference to draft-ietf-httpbis-sfbis should be normative, not informative, since terminology from that doc is used. Alternatively, if you want to keep the ref informative, you can import the part of the terminology that is necessary for this doc. I think that's a uglier solution, so I highly prefer sfbis to be made normative, but won't block on it. [URLPattern] "URL Pattern Standard", March 2024, URL needs to be indicated as Living standard (see RFC 9110 or 9421 for eample of whatwg specs references). Please fix this so that the Fetch spec is properly referenced (normatively is needed, I believe). RFC 8792 should be (informatively) referenced. I agree with Mark's write up, 5861 should really be informative. There is several occurrences of {Origin}, please fix. Please add a reference. It would be good to have an informative reference to 6265 (or even 6265bis). This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [ tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: URL [ICT]: URL

Revised text:
dictionary to turn it into a tracking cookie. To mitigate any additional tracking concerns, clients MUST treat  <ins> dictionaries in the same way that they treat cookies RFC6265.  This includes partitioning the storage as cookies are partitioned as well as clearing the dictionaries whenever cookies are cleared. </ins>
Original text:
policy" used by web browsers isolates content retrieved via different ports. <del> There are two audiences for this specification: developers of cookie- generating servers and developers of cookie-consuming user agents. </del>  To maximize interoperability with user agents, servers SHOULD limit themselves to the well-behaved profile defined in sane-profile when

Reviewer comments:
A number of minor misc changes and corrections to improve readability, usability, and consistency throughout the spec.
6265bis is nearly ready, but after years of changes there are probably some minor editorial issues that should be corrected. Someone (me) should proofread it and fix any problems found.
The RFC Editor will help with that.
Ah, good to know. I'll still give it a first pass to clean it up a bit.
LGTM.

Revised text:
policy" used by web browsers isolates content retrieved via different ports.  <ins> This specification applies to developers of both cookie-producing servers and cookie-consuming user agents. implementation-advisory helps to clarify the intended target audience for each implementation type. </ins> To maximize interoperability with user agents, servers SHOULD limit themselves to the well-behaved profile defined in sane-profile when
Original text:
An implementer should choose sane-profile whenever cookies are created and will be sent to a user agent, such as a web browser. <del> These implementations are frequently referred to as Servers by the </del>  spec but that term includes anything which primarily produces cookies.  Some potential examples:

Reviewer comments:
A number of minor misc changes and corrections to improve readability, usability, and consistency throughout the spec.
6265bis is nearly ready, but after years of changes there are probably some minor editorial issues that should be corrected. Someone (me) should proofread it and fix any problems found.
The RFC Editor will help with that.
Ah, good to know. I'll still give it a first pass to clean it up a bit.
LGTM.

Revised text:
An implementer should choose sane-profile whenever cookies are created and will be sent to a user agent, such as a web browser.  <ins> These implementations are frequently referred to as servers by the </ins> spec but that term includes anything which primarily produces cookies.  Some potential examples:
Original text:
requests.  If the "SameSite" attribute's value is something other than these three known keywords, the attribute's value will be subject to a default enforcement mode that is equivalent to "Lax".  The "SameSite" attribute affects cookie creation as well as delivery. Cookies which assert "SameSite=Lax" or "SameSite=Strict" cannot be

Reviewer comments:
A number of minor misc changes and corrections to improve readability, usability, and consistency throughout the spec.
6265bis is nearly ready, but after years of changes there are probably some minor editorial issues that should be corrected. Someone (me) should proofread it and fix any problems found.
The RFC Editor will help with that.
Ah, good to know. I'll still give it a first pass to clean it up a bit.
LGTM.

Revised text:
requests.  If the "SameSite" attribute's value is something other than these three known keywords, the attribute's value will be subject to a default enforcement mode that is equivalent to "Lax". <ins> If a user agent uses "Lax-allowing-unsafe" enforcement (See lax- allowing-unsafe) then this default enforcement mode will instead be equivalent to "Lax-allowing-unsafe". </ins> The "SameSite" attribute affects cookie creation as well as delivery. Cookies which assert "SameSite=Lax" or "SameSite=Strict" cannot be
Original text:
The normative requirements for the prefixes are detailed in the storage model algorithm defined in storage-model. <del> This is because some servers will process cookie case-insensitively, </del>  resulting in them unintentionally miscapitalizing and accepting miscapitalized prefixes.

Reviewer comments:
A number of minor misc changes and corrections to improve readability, usability, and consistency throughout the spec.
6265bis is nearly ready, but after years of changes there are probably some minor editorial issues that should be corrected. Someone (me) should proofread it and fix any problems found.
The RFC Editor will help with that.
Ah, good to know. I'll still give it a first pass to clean it up a bit.
LGTM.

Revised text:
The normative requirements for the prefixes are detailed in the storage model algorithm defined in storage-model.  <ins> This is because some servers will process cookies case-insensitively, </ins> resulting in them unintentionally miscapitalizing and accepting miscapitalized prefixes.
Original text:
attribute-name of "Path", and the cookie's path is "/". If the cookie-name is empty and either of the following conditions <del> are true, abort these steps and ignore the cookie: </del>  the cookie-value begins with a case-insensitive match for the string "__Secure-"

Reviewer comments:
A number of minor misc changes and corrections to improve readability, usability, and consistency throughout the spec.
6265bis is nearly ready, but after years of changes there are probably some minor editorial issues that should be corrected. Someone (me) should proofread it and fix any problems found.
The RFC Editor will help with that.
Ah, good to know. I'll still give it a first pass to clean it up a bit.
LGTM.

Revised text:
attribute-name of "Path", and the cookie's path is "/". If the cookie-name is empty and either of the following conditions  <ins> are true, abort these steps and ignore the cookie entirely: </ins> the cookie-value begins with a case-insensitive match for the string "__Secure-"
Original text:
NOTE: The notion of a "secure" connection is not defined by this document.  Typically, user agents consider a connection secure if the connection makes use of transport-layer security, <del> such as SSL or TLS, or if host is trusted.  For example, most user agents consider "https" to be a scheme that denotes a </del>  secure protocol and "localhost" to be trusted host. If the cookie's http-only-flag is true, then exclude the cookie

Reviewer comments:
A number of minor misc changes and corrections to improve readability, usability, and consistency throughout the spec.
6265bis is nearly ready, but after years of changes there are probably some minor editorial issues that should be corrected. Someone (me) should proofread it and fix any problems found.
The RFC Editor will help with that.
Ah, good to know. I'll still give it a first pass to clean it up a bit.
LGTM.

Revised text:
NOTE: The notion of a "secure" connection is not defined by this document.  Typically, user agents consider a connection secure if the connection makes use of transport-layer security,  <ins> such as SSL or TLS, or if the host is trusted.  For example, most user agents consider "https" to be a scheme that denotes a </ins> secure protocol and "localhost" to be trusted host. If the cookie's http-only-flag is true, then exclude the cookie
Original text:
be enforced in set-cookie. Servers SHOULD use as few and as small cookies as possible to avoid <del> reaching these implementation limits and to minimize network bandwidth due to the Cookie header field being included in every request. </del>  Servers SHOULD gracefully degrade if the user agent fails to return one or more cookies in the Cookie header field because the user agent

Reviewer comments:
A number of minor misc changes and corrections to improve readability, usability, and consistency throughout the spec.
6265bis is nearly ready, but after years of changes there are probably some minor editorial issues that should be corrected. Someone (me) should proofread it and fix any problems found.
The RFC Editor will help with that.
Ah, good to know. I'll still give it a first pass to clean it up a bit.
LGTM.

Revised text:
be enforced in set-cookie. Servers SHOULD use as few and as small cookies as possible to avoid  <ins> reaching these implementation limits, minimize network bandwidth due to the Cookie header field being included in every request, and to avoid reaching server header field limits (See server-syntax). </ins> Servers SHOULD gracefully degrade if the user agent fails to return one or more cookies in the Cookie header field because the user agent
Original text:
Understanding how and when a request is considered same-site is also important in order to properly design a site for SameSite cookies. <del> For example, if a top-level request is made to a sensitive page that request will be considered cross-site and SameSite cookies won't be sent; that page's sub-resources requests, however, are same-site and would receive SameSite cookies.  Sites can avoid inadvertently allowing access to these sub-resources by returning an error for the initial page request if it doesn't include the appropriate cookies. </del>  Developers are strongly encouraged to deploy the usual server-side defenses (CSRF tokens, ensuring that "safe" HTTP methods are

Reviewer comments:
A number of minor misc changes and corrections to improve readability, usability, and consistency throughout the spec.
6265bis is nearly ready, but after years of changes there are probably some minor editorial issues that should be corrected. Someone (me) should proofread it and fix any problems found.
The RFC Editor will help with that.
Ah, good to know. I'll still give it a first pass to clean it up a bit.
LGTM.

Revised text:
Understanding how and when a request is considered same-site is also important in order to properly design a site for SameSite cookies.  <ins> For example, if a cross-site top-level request is made to a sensitive page that request will be considered cross-site and "SameSite=Strict" cookies won't be sent; that page's sub-resources requests, however, are same-site and would receive "SameSite=Strict" cookies.  Sites can avoid inadvertently allowing access to these sub-resources by returning an error for the initial page request if it doesn't include the appropriate cookies. </ins> Developers are strongly encouraged to deploy the usual server-side defenses (CSRF tokens, ensuring that "safe" HTTP methods are
Original text:
Integer. The "min-size" key specifies a minimum size for a resumable <del> upload, counted in bytes.  The server will not create an upload </del>  resource if the client indicates that the uploaded data is smaller <del> than the minimum size.  The value is an Integer. </del>  The "max-append-size" key specifies a maximum size counted in bytes for the request content in a single upload append request

Reviewer comments:
This PR clarifies a few things around the Upload-Limit field from : The last upload append request may now be smaller than the minimum append size specified in . For example, if a 510 MB upload is split into 100 MB requests, the last request can just be 10 MB. It clarified how a client can indicate the entire upload length when creating a new upload via the Content-Length header. The PR also mentions that no resumable upload resource may be created if the minimum size is not met, but the server might still accept and process the data (although without offering resumability) The Upload-Limit header is added to informational response in an example

Revised text:
Integer. The "min-size" key specifies a minimum size for a resumable  <ins> upload, counted in bytes.  The server MAY NOT create an upload </ins> resource if the client indicates that the uploaded data is smaller  <ins> than the minimum size by including the "Content-Length" and "Upload-Complete: ?1" fields, but the server MAY still accept the uploaded data.  The value is an Integer. </ins> The "max-append-size" key specifies a maximum size counted in bytes for the request content in a single upload append request
Original text:
The "min-append-size" key specifies a minimum size counted in bytes for the request content in a single upload append request <del> (upload-appending).  The server MAY reject requests below this limit and a client SHOULD NOT send smaller upload append requests. The value is an Integer. </del>  The "expires" key specifies the remaining lifetime of the upload resource in seconds counted from the generation of the response by

Reviewer comments:
This PR clarifies a few things around the Upload-Limit field from : The last upload append request may now be smaller than the minimum append size specified in . For example, if a 510 MB upload is split into 100 MB requests, the last request can just be 10 MB. It clarified how a client can indicate the entire upload length when creating a new upload via the Content-Length header. The PR also mentions that no resumable upload resource may be created if the minimum size is not met, but the server might still accept and process the data (although without offering resumability) The Upload-Limit header is added to informational response in an example

Revised text:
The "min-append-size" key specifies a minimum size counted in bytes for the request content in a single upload append request  <ins> (upload-appending) that does not complete the upload by setting the "Upload-Complete: ?1" field.  The server MAY reject non- completing requests below this limit and a client SHOULD NOT send smaller non-completing upload append requests.  A server MUST NOT reject an upload append request due to smaller size if the request includes the "Upload-Complete: ?1" field.  The value is an Integer. </ins> The "expires" key specifies the remaining lifetime of the upload resource in seconds counted from the generation of the response by
Original text:
"ORIGIN", to allow servers to indicate what origins a connection is usable for.  1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

Reviewer comments:
Relax DNS requirements when ORIGIN is received Change the initial origin set to just SNI
wait - no. You wouldn't send the alternative in the ORIGIN frame, you would send the origin that you are the alternative for, right? that would make sense - if you want to use an alternative you can't rely on the SNI default.
this is indeed looking goodminor nitsThis is looking good.

Revised text:
"ORIGIN", to allow servers to indicate what origins a connection is usable for. <ins> Additionally, experience has shown that HTTP/2's requirement to establish server authority using both DNS and the server's certificate is onerous.  This specification relaxes the requirement to check DNS when the ORIGIN frame is in use. </ins> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",