jiebi/TextFlow huggingface dataset:
Original text:
2.2.2. When a dictionary is stored as a result of a "Use-As-Dictionary" <del> directive, it includes "match", "match-search" and "match-dest" strings that are used to match an outgoing request from a client to the available dictionaries. </del>  To see if an outbound request matches a given dictionary, the following algorithm will return TRUE for a successful match and FALSE

Reviewer comments:
This changes the URLPattern match to use a single match pattern to be consistent with other uses of URLPattern.
NAME NAME this is an attempt at a change to have it use a single string for pattern construction. I don't feel great about the same-origin check part of the validation but I don't see why it wouldn't work. It still allows for people to waste bytes by not using path-relative patterns so I may have to re-open the issue around that but should provide the consistency you were asking for. This would be instead of PR .
a couple nitpicks while passing by

Revised text:
2.2.2. When a dictionary is stored as a result of a "Use-As-Dictionary"  <ins> directive, it includes "match" and "match-dest" strings that are used to match an outgoing request from a client to the available dictionaries. Dictionaries MUST have been served from the same {Origin} as the outgoing request to match. </ins> To see if an outbound request matches a given dictionary, the following algorithm will return TRUE for a successful match and FALSE
Original text:
If DEST is not an empty string and If DEST and REQUEST_DEST are not the same value, return FALSE <del> Let PATH be the value of "match" for the given dictionary. </del>  <del> Let SEARCH be the value of "match-search" for the given dictionary. </del>  <del> Let BASEURL be the request URL of the given dictionary. </del>  <del> Let PATTERN be a URLPattern constructed by setting pathname=PATH, search=SEARCH, baseURL=BASEURL (https://urlpattern.spec.whatwg.org/). </del>  <del> LET URL represent the request URL being checked. </del>  <del> Return the result of running the URLPattern "match" algorithm (https://urlpattern.spec.whatwg.org/#match) </del>  2.2.3.

Reviewer comments:
This changes the URLPattern match to use a single match pattern to be consistent with other uses of URLPattern.
NAME NAME this is an attempt at a change to have it use a single string for pattern construction. I don't feel great about the same-origin check part of the validation but I don't see why it wouldn't work. It still allows for people to waste bytes by not using path-relative patterns so I may have to re-open the issue around that but should provide the consistency you were asking for. This would be instead of PR .
a couple nitpicks while passing by

Revised text:
If DEST is not an empty string and If DEST and REQUEST_DEST are not the same value, return FALSE  <ins> Let BASEURL be the URL of the dictionary request. </ins>  <ins> Let URL represent the URL of the outbound request being checked. </ins>  <ins> If the {Origin} of BASEURL and the {Origin} of URL are not the same, return FALSE. </ins>  <ins> Let MATCH be the value of "match" for the given dictionary. </ins>  <ins> Let PATTERN be a URLPattern constructed by setting input=MATCH, and baseURL=BASEURL (https://urlpattern.spec.whatwg.org/). </ins>  <ins> Return the result of running the "test" method of PATTERN with input=URL (https://urlpattern.spec.whatwg.org/#ref-for-dom- urlpattern-test) </ins> 2.2.3.
Original text:
specifies and matches a "match-dest" takes precedence over a match that does not use a destination.  1.  Given equivalent destination precedence, the dictionary with the longest "match" takes precedence. <del> 1.  Given equivalent destination and path precedence, the dictionary with the longest "match-search" takes precedence.  1.  Given equivalent destination, path and search precedence, the most recently fetched dictionary takes precedence. </del>  2.3.

Reviewer comments:
This changes the URLPattern match to use a single match pattern to be consistent with other uses of URLPattern.
NAME NAME this is an attempt at a change to have it use a single string for pattern construction. I don't feel great about the same-origin check part of the validation but I don't see why it wouldn't work. It still allows for people to waste bytes by not using path-relative patterns so I may have to re-open the issue around that but should provide the consistency you were asking for. This would be instead of PR .
a couple nitpicks while passing by

Revised text:
specifies and matches a "match-dest" takes precedence over a match that does not use a destination.  1.  Given equivalent destination precedence, the dictionary with the longest "match" takes precedence.  <ins> 1.  Given equivalent destination and match length precedence, the most recently fetched dictionary takes precedence. </ins> 2.3.
Original text:
usual requirements for classic CONNECT proxies in this HTTP version (see RFC9113 and RFC9114).  4. This section discusses some behaviors that are permitted or

Reviewer comments:
After looking harder, I found that RFC 9110 that a proxy "is usually identified by an "http" or "https" URI". I'm not sure that's 100% accurate, but it conveniently resolves the wording problem, and who am I to argue with RFC 9110?
At the moment, section 1.2 (Problems) start with the following sentence: I totally get what it tries to say, but it is confusing if not incorrect. states that a CONNECT request is handled by a "proxy" and the target specified by the "host:port" tuple is the "origin." Therefore, HTTP CONNECT proxies are not identified by an origin. Rather, they are identified by the user's proxy settings. I think we'd better update the problem statement, and might also consider pointing out that the definition of "origin" will be different between CONNECT and connect-tcp (or use different terms to identify the CONNECT target and the entity that creates a tunnel in order to avoid confusion, maybe?).
PS. Practical example showcasing the side effect of the change to the definition is that the way to authenticate becomes different; when a client tries to establish a CONNECT tunnel with authentication, it uses "proxy-authorization" header, whereas when a client tries to establish a connect-tcp tunnel, it uses "authorization." I think it's worth noting.
I'm realizing that this spec has the opportunity to fix the origin issues present in regular CONNECT. While we're there it'd be great to clarify how connect-tcp interacts with Alt-Svc because it's unclear for CONNECT. I sent some more about why it's unclear for CONNECT.
Thanks for the discussion!

Revised text:
usual requirements for classic CONNECT proxies in this HTTP version (see RFC9113 and RFC9114). <ins> 3.3. A templated TCP proxy has an unambiguous origin of its own.  Origin- scoped HTTP header fields such as "Alt-Svc" RFC7838 and "Strict- Transport-Security" RFC6797 apply to this origin when they are associated with a templated TCP proxy request or response. </ins> 4. This section discusses some behaviors that are permitted or
Original text:
2.2. Clients MUST NOT send "http" requests and "https" requests on the <del> same connection. </del>  2.3.

Reviewer comments:
This is kinda silly, but it seems like adding support for coalescing is something we could fix later. with the nuclear option.
the pull request is fine by me. I do wonder if we shouldn't make the json a tad more complicated to allow for a reasonable mixed definition in the future. But an unreasonable one is obviously possible :)
Can we coalesce http and https? The implication from everything we've said is "yes", but Erik remains reluctant.

Revised text:
2.2. Clients MUST NOT send "http" requests and "https" requests on the  <ins> same connection.  Similarly, clients MUST NOT send "http" requests for multiple origins on the same connection. </ins> 2.3.
Original text:
serialization. Let byte_array be the result of applying UTF-8 encoding (Section 3 <del> of UTF8) to input_sequence. </del>  Let encoded_string be a string containing "%" followed by DQUOTE.

Reviewer comments:
I guess that's the best we can do, considering that Unicode is a minefield. :-/
... in a swamp.
Is it worth dealing with the fact that 3629 doesn't actually define how to encode a sequence of characters, but we're calling it with one? We'd need to add something to this text, like "for each character (or code point?) in inputsequence, append the result of applying UTF-8 encoding to character to bytearray".
currently does not consider what happens when UTF8 serialization fails, although this could happen with surrogate points. I believe it should explicitly say that. Alternatively, the introduction of display strings could say that only unicode scalars (URL) are allowed (but even then I'd add the extra precaution in the serializer). Finally, we may want to add an example because all of this is far from obvious.
NAME and NAME pointed out that URL doesn't define the and operations that this draft uses. RFC 3629 only defines a character at a time. RFC 3629 also doesn't say to fail encoding or decoding in any particular situations. It says "The definition of UTF-8 prohibits encoding character numbers between U+D800 and U+DFFF", but its definition of encoding doesn't actually prohibit those characters. It also says "MUST protect against decoding invalid sequences", but the definition of decoding doesn't fail in that case. URL is more explicit on these questions and might therefore be a better reference.
Note that the recommended entry points for other specs are URL which are clear about how to handle BOMs as well.
Seems reasonable - will try to work up a PR. I'm likely to keep the general reference to 3629 for UTF-8, and use encoding for the specifics.
I would very very very much prefer not to have a normative reference on a "living" document here. Let's just add the missing needed on top of RFC 3629 to this spec. (and yes, I can make a concrete proposal)
We were clear how to handle BOMs, but what you suggest is a change on top of that.
See minimal PR.
(Posted on the PR by accident:) Is it worth dealing with the fact that 3629 doesn't actually define how to encode a sequence of characters, but we're calling it with one? We'd need to add something to 4.1.11, like "for each character (or code point?) in inputsequence, append the result of applying UTF-8 encoding to character to bytearray".

Revised text:
serialization. Let byte_array be the result of applying UTF-8 encoding (Section 3  <ins> of UTF8) to input_sequence.  If encoding fails, fail serialization. </ins> Let encoded_string be a string containing "%" followed by DQUOTE.
Original text:
confirms receipt of a request at the proxy without waiting for the proxy-destination TCP handshake to succeed or fail.  This might be particularly helpful when the destination host is not responding, as <del> TCP handshakes can hang for several minutes before failing. Implementation of "100 (Continue)" support is OPTIONAL for clients and REQUIRED for proxies. </del>  Proxies implementing this specification SHOULD include a "Proxy- Status" response header RFC9209 in any success or failure response

Reviewer comments:
The draft says "Implementation of "100 (Continue)" support is OPTIONAL for clients and REQUIRED for proxies." What does that mean? Is the client allowed to fall over if it receives 100? (This is not a theoretical concern, many HTTP libraries stop listening for header blocks after the first one.)
I've posted to reduce ambiguity here. RFC 9110 I think that makes it pretty clear that clients are supposed to tolerate unexpected 100s.

Revised text:
confirms receipt of a request at the proxy without waiting for the proxy-destination TCP handshake to succeed or fail.  This might be particularly helpful when the destination host is not responding, as  <ins> TCP handshakes can hang for several minutes before failing.  Clients MAY send "Expect: 100-continue", and proxies MUST respect it by returning "100 (Continue)" if the request is not immediately rejected. </ins> Proxies implementing this specification SHOULD include a "Proxy- Status" response header RFC9209 in any success or failure response
Original text:
The "id" value of the Use-As-Dictionary header is a sf-string value that specifies a server identifier for the dictionary.  If an "id" <del> value is present then it MUST be sent to the server in a "Dictionary- ID" request header when the dictionary is advertised as being available. </del>  The server identifier MUST be treated as an opaque string by the client.

Reviewer comments:
This treats empty dictionary strings as the same as there being no dictionary and reqires all ID's have a non-zero length for the Dictionary-ID header to be sent.
NAME could you PTAL and see if this handles the case you were concerned about?
Dictionary-ID was introduced to the Compression Dictionary Transport specification by . However, it is unclear whether empty string dictionary IDs are allowed. I don't think there is any use case for an empty string dictionary ID. So how about explicitly disallowing empty string dictionary IDs in the spec? NAME
I'll make a zero-length string the default and have that mean "no ID". The dictionary ID will only be sent if it has a length > 0.
Thanks. lgtm.

Revised text:
The "id" value of the Use-As-Dictionary header is a sf-string value that specifies a server identifier for the dictionary.  If an "id"  <ins> value is present and has a string length longer than zero then it MUST be sent to the server in a "Dictionary-ID" request header when the dictionary is advertised as being available. </ins> The server identifier MUST be treated as an opaque string by the client.
Original text:
The "id" value string length (after any decoding) supports up to 1024 characters. <del> The "id" value is optional. </del>  2.1.4.

Reviewer comments:
This treats empty dictionary strings as the same as there being no dictionary and reqires all ID's have a non-zero length for the Dictionary-ID header to be sent.
NAME could you PTAL and see if this handles the case you were concerned about?
Dictionary-ID was introduced to the Compression Dictionary Transport specification by . However, it is unclear whether empty string dictionary IDs are allowed. I don't think there is any use case for an empty string dictionary ID. So how about explicitly disallowing empty string dictionary IDs in the spec? NAME
I'll make a zero-length string the default and have that mean "no ID". The dictionary ID will only be sent if it has a length > 0.
Thanks. lgtm.

Revised text:
The "id" value string length (after any decoding) supports up to 1024 characters.  <ins> The "id" value is optional and defaults to the empty string. </ins> 2.1.4.
Original text:
2.1.2. <del> The "match-dest" value of the Use-As-Dictionary header is a sf-string value that provides a request destination (https://fetch.spec.whatwg.org/#concept-request-destination). </del>  <del> An empty string for "match-dest" MUST match all destinations. </del>  <del> For clients that do not support request destinations or if the value of "match-dest" is a value that is not supported by the client then the client MUST treat it as an empty string and match all destinations. </del>  <del> The "match-dest" value is optional and defaults to the empty string. </del>  2.1.3.

Reviewer comments:
This changes the field to be a list of destination strings to allow for matching multiple destinations (i.e. document and frame). This allows for matching an empty destination explicitly using an empty string. e.g.
NAME could you PTAL and see if this looks OK for the destination matching?
The spec of compression dictionary transport says: But an empty "" is used for some features such as , , , , , Cache API, Download, prefetch and prerender. (See this ). So currently there is no way to set up a dictionary for such destinations. For example, I want to use a dictionary for fetch() API, but I don't want to use the dictionary for HTML documents. NAME How about using a string "empty" for such empty destination? We are already using "empty" for header of empty destination request. URL Also if we don't need to use an empty string "" for , I think should be a instead of a . We don't need to use double quotes.
Having special values feels a bit strange, particularly since it's only defined in the internal processing part of the w3c spec. If we use a list of strings we can use for an explicit empty destination and use an empty list for matching everything (and as the default). Does that seem reasonable?
OK, sounds reasonable. Thanks.
option was introduced in the Compression Dictionary Transport spec by . But if my understanding is correct, currently it is not allowed to setting multiple types of destinations. So if I want to use a dictionary for HTML files including top frame, and , I need to download the dictionary three times. NAME How about allowing setting multiple types of destinations? Example:
Sounds good (though document/frame is probably the only practical use case). I'll switch it to an inner-list of tokens.
lgtm Sorry for the late reply.

Revised text:
2.1.2.  <ins> The "match-dest" value of the Use-As-Dictionary header is an inner list of sf-string values that provides a list of request destinations for the dictionary to match (https://fetch.spec.whatwg.org/#concept- request-destination). </ins>  <ins> An empty list for "match-dest" MUST match all destinations. </ins>  <ins> For clients that do not support request destinations, the client MUST treat it as an empty list and match all destinations. </ins>  <ins> The "match-dest" value is optional and defaults to an empty list. </ins> 2.1.3.
Original text:
Let REQUEST_DEST be the value of the destination for the current request. <del> If DEST is not an empty string and If DEST and REQUEST_DEST are not the same value, return FALSE </del>  Let BASEURL be the URL of the dictionary request.

Reviewer comments:
This changes the field to be a list of destination strings to allow for matching multiple destinations (i.e. document and frame). This allows for matching an empty destination explicitly using an empty string. e.g.
NAME could you PTAL and see if this looks OK for the destination matching?
The spec of compression dictionary transport says: But an empty "" is used for some features such as , , , , , Cache API, Download, prefetch and prerender. (See this ). So currently there is no way to set up a dictionary for such destinations. For example, I want to use a dictionary for fetch() API, but I don't want to use the dictionary for HTML documents. NAME How about using a string "empty" for such empty destination? We are already using "empty" for header of empty destination request. URL Also if we don't need to use an empty string "" for , I think should be a instead of a . We don't need to use double quotes.
Having special values feels a bit strange, particularly since it's only defined in the internal processing part of the w3c spec. If we use a list of strings we can use for an explicit empty destination and use an empty list for matching everything (and as the default). Does that seem reasonable?
OK, sounds reasonable. Thanks.
option was introduced in the Compression Dictionary Transport spec by . But if my understanding is correct, currently it is not allowed to setting multiple types of destinations. So if I want to use a dictionary for HTML files including top frame, and , I need to download the dictionary three times. NAME How about allowing setting multiple types of destinations? Example:
Sounds good (though document/frame is probably the only practical use case). I'll switch it to an inner-list of tokens.
lgtm Sorry for the late reply.

Revised text:
Let REQUEST_DEST be the value of the destination for the current request.  <ins> If DEST is not an empty list and if REQUEST_DEST is not in the DEST list of destinations, return FALSE </ins> Let BASEURL be the URL of the dictionary request.
Original text:
dictionary usage and registers media types for content encoding Brotli and Zstandard using a negotiated dictionary.  This document uses the line folding strategies described in FOLDING.  2. 2.1.

Reviewer comments:
Switched from using the ABNF field types to the human names (i.e. sf-dictionary to Dictionary) for all of the Structured Field header values. Switched dictionary "type" to a Token (from String).
NAME could you PTAL at the change in referencing the header field types? Specifically, I wasn't sure if I should capitalize the types or not (I did since that's how the structured fields RFC referred to them).
Yep, this looks good. It's common to add something to you Notational Conventions section (or whatever) that says roughly "This specification uses the following terms from [ref to SF]: String, Byte Sequence, Token, ..."

Revised text:
dictionary usage and registers media types for content encoding Brotli and Zstandard using a negotiated dictionary. <ins> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. This document uses the following terminology from STRUCTURED-FIELDS to specify syntax and parsing: Dictionary, String, Inner List, Token, and Byte Sequence. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. </ins> This document uses the line folding strategies described in FOLDING. <ins> This document also uses terminology from HTTP and HTTP-CACHING. </ins> 2. 2.1.
Original text:
header. The Use-As-Dictionary response header is a Structured Field <del> STRUCTURED-FIELDS with values for "match", "match-dest", "id", and "type". </del>  2.1.1. <del> The "match" value of the Use-As-Dictionary header is a sf-string value that provides the URLPattern to use for request matching </del>  (https://urlpattern.spec.whatwg.org/). The URLPattern used for matching does not support using Regular

Reviewer comments:
Switched from using the ABNF field types to the human names (i.e. sf-dictionary to Dictionary) for all of the Structured Field header values. Switched dictionary "type" to a Token (from String).
NAME could you PTAL at the change in referencing the header field types? Specifically, I wasn't sure if I should capitalize the types or not (I did since that's how the structured fields RFC referred to them).
Yep, this looks good. It's common to add something to you Notational Conventions section (or whatever) that says roughly "This specification uses the following terms from [ref to SF]: String, Byte Sequence, Token, ..."

Revised text:
header. The Use-As-Dictionary response header is a Structured Field  <ins> STRUCTURED-FIELDS Dictionary with values for "match", "match-dest", "id", and "type". </ins> 2.1.1.  <ins> The "match" value of the Use-As-Dictionary header is a String value that provides the URLPattern to use for request matching </ins> (https://urlpattern.spec.whatwg.org/). The URLPattern used for matching does not support using Regular