jiebi/CodeConvo huggingface dataset:
Code change:
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".

Related discussion:
text: serialization. Let byte_array be the result of applying UTF-8 encoding (Section 3 <del> of UTF8) to input_sequence. </del> <ins> of UTF8) to input_sequence.  If encoding fails, fail serialization. </ins> Let encoded_string be a string containing "%" followed by DQUOTE.
Code change:
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.

Related discussion:
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> <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
Code change:
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.

Related discussion:
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> <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.
Code change:
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.

Related discussion:
text: The "id" value string length (after any decoding) supports up to 1024 characters. <del> The "id" value is optional. </del> <ins> The "id" value is optional and defaults to the empty string. </ins> 2.1.4.
Code change:
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.

Related discussion:
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> <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> <del> An empty string for "match-dest" MUST match all destinations. </del> <ins> An empty list for "match-dest" MUST match all destinations. </ins> <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> <ins> For clients that do not support request destinations, the client MUST treat it as an empty list and match all destinations. </ins> <del> The "match-dest" value is optional and defaults to the empty string. </del> <ins> The "match-dest" value is optional and defaults to an empty list. </ins> 2.1.3.
Code change:
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.

Related discussion:
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> <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.
Code change:
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, ..."

Related discussion:
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.
Code change:
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, ..."

Related discussion:
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> <ins> STRUCTURED-FIELDS Dictionary with values for "match", "match-dest", "id", and "type". </ins> 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> <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
Code change:
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, ..."

Related discussion:
text: Return True. The "match" value is required and MUST be included in the Use-As- <del> Dictionary sf-dictionary for the dictionary to be considered valid. </del> <ins> Dictionary Dictionary for the dictionary to be considered valid. </ins> 2.1.2. <del> 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 </del> <ins> The "match-dest" value of the Use-As-Dictionary header is an Inner List of String values that provides a list of request destinations </ins> for the dictionary to match (https://fetch.spec.whatwg.org/#concept- request-destination).
Code change:
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, ..."

Related discussion:
text: 2.1.3. <del> 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" 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. </del> <ins> The "id" value of the Use-As-Dictionary header is a String value that specifies a server identifier for the dictionary.  If an "id" 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.
Code change:
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, ..."

Related discussion:
text: 2.1.4. <del> The "type" value of the Use-As-Dictionary header is a sf-string value </del> <ins> The "type" value of the Use-As-Dictionary header is a Token value </ins> that describes the file format of the supplied dictionary. "raw" is the only defined dictionary format which represents an
Code change:
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, ..."

Related discussion:
text: If a client receives a dictionary with a type that it does not understand, it MUST NOT use the dictionary. <del> The "type" value is optional and defaults to "raw". </del> <ins> The "type" value is optional and defaults to raw. </ins> 2.1.5.
Code change:
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, ..."

Related discussion:
text: dictionary available to use for compression. The "Available-Dictionary" request header is a Structured Field <del> STRUCTURED-FIELDS sf-binary SHA-256 hash of the contents of a single available dictionary. </del> <ins> STRUCTURED-FIELDS Byte Sequence containing the SHA-256 hash of the contents of a single available dictionary. </ins> The client MUST only send a single "Available-Dictionary" request header with a single hash value for the best available match that it
Code change:
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, ..."

Related discussion:
text: echo the stored "id" in a "Dictionary-ID" request header. The "Dictionary-ID" request header is a Structured Field STRUCTURED- <del> FIELDS sf-string of up to 1024 characters (after any decoding) and MUST be identical to the server-provided "id". </del> <ins> FIELDS String of up to 1024 characters (after any decoding) and MUST be identical to the server-provided "id". </ins> For example:
Code change:
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, ..."

Related discussion:
text: used in the "Content-Dictionary" response header. The "Content-Dictionary" response header is a Structured Field <del> STRUCTURED-FIELDS sf-dictionary SHA-256 hash of the contents of the dictionary that was used to encode the response. </del> <ins> STRUCTURED-FIELDS Byte Sequence containing the SHA-256 hash of the contents of the dictionary that was used to encode the response. </ins> If the HTTP response contains a "Content-Dictionary" response header with the hash of a dictionary that the client does not have available