jiebi/CodeConvo huggingface dataset:
Code change:
Encodes query parameter names to match values, to avoid non-ascii or otherwise problematic values.
In 2.2.8: What if the query parameter contains non-ASCII characters? I think this needs to say that the name parameter needs to contain the raw (percent-encoded) name.
Good catch, I believe you're correct.

Related discussion:
text: The resulting values are encoded as follows: <del> If the encoding were not applied, the resultant value would be: </del> <ins> If the encoding were not applied, the resultant values would be: </ins> <del> This base string violates the constraints on component values, and is therefore invalid. </del> <ins> This base string contains characters that violate the constraints on component names and values, and is therefore invalid. </ins> 2.2.9.
Code change:
Encodes query parameter names to match values, to avoid non-ascii or otherwise problematic values.
In 2.2.8: What if the query parameter contains non-ASCII characters? I think this needs to say that the name parameter needs to contain the raw (percent-encoded) name.
Good catch, I believe you're correct.

Related discussion:
text: 2.5. <del> The signature base is a US-ASCII (STD80) string containing the canonicalized HTTP message components covered by the signature.  The input to the signature base creation algorithm is the ordered set of covered component identifiers and their associated values, along with any additional signature parameters discussed in signature-params. </del> <ins> The signature base is a ASCII string containing the canonicalized HTTP message components covered by the signature.  The input to the signature base creation algorithm is the ordered set of covered component identifiers and their associated values, along with any additional signature parameters discussed in signature-params. </ins> Component identifiers are serialized using the strict serialization rules defined by STRUCTURED-FIELDS.  The component identifier has a
Code change:
Encodes query parameter names to match values, to avoid non-ascii or otherwise problematic values.
In 2.2.8: What if the query parameter contains non-ASCII characters? I think this needs to say that the name parameter needs to contain the raw (percent-encoded) name.
Good catch, I believe you're correct.

Related discussion:
text: field value with parameters Produce an error if the output string contains any non-ASCII <del> (STD80) characters. </del> <ins> (ASCII) characters. </ins> Return the output string.
Code change:
LGTM
On the list, Rob Sayre asked: I agree it seems we can improve the text here a little. Maybe NAME or NAME can elaborate as to why a digest trailer is not suitable in this case?
The reason is that in order to produce a MICE hash, you need to process the content in reverse order. Therefore, there is no reason not to put the hash in the header. The advantage you get in return is that you can process the response in natural order.
Thanks martin. We should just say it that way, because it is clearer to the reader. I'll follow up with a PR.

Related discussion:
text: the trailer section prevents digest validation, possibly leading to processing of invalid data. <del> Not every hashing algorithm is suitable for use in the trailer section, some may require to preprocess the whole content before sending a message (e.g., see I-D.thomson-http-mice). </del> <ins> One of the benefits of using Integrity fields in a trailer section is that it allows hashing of bytes as they are sent.  However, it is possible to design a hashing algorithm that requires processing of content in such a way that would negate these benefits.  For example, Merkle Integrity Content Encoding I-D.thomson-http-mice requires content to be processed in reverse order.  This means the complete data needs to be available, which means there is negligible processing difference in sending an Integrity field in a header or trailer section. </ins> 6.5.
Code change:
The "" set includes ".", but we actually need to escape "." to avoid attacks.
Hm, my impression is that this attack is about making a period within a label look like a label separator. By the time that you have a string for a name, it would already need this kind of escaping done. Put another way, the "." characters we have in the string are indeed label separators already.
The draft doesn't specify how to construct the DNS name string (and in general there is not a great specification for this). The most common convention (noted in RFC 1035 Section 5.1) is to precede "." inside a label with a backslash. This draft would then percent-escape the backslash, but not the ".", so there would indeed be a "." character that is not a label separator in the final header field value. Whatever escaping convention you choose, this is sufficiently non-obvious that I think a very clear specification and some examples are probably in order. (This whole rigmarole is normally not a problem because URIs are restricted to contain only "hostnames", which cannot have weird characters in the labels.)
NAME can you look at URL
I realize that this is now resolved, but isn't it also possible that we could say "this field cannot be used to express names that include a literal period (".") in labels" ?
NAME yeah that’s an option, although it could theoretically incentivize using dots in labels as a way to hide the CNAME from being reported
Sure. But you can add another attribute called "this-site-is-abusing-this-mechanism" for use when that happens.

Related discussion:
text: name in the "next-hop-aliases" list would be the name that ultimately resolved to one or more addresses. <del> The list of DNS names in "next-hop-aliases" use a comma (",") as a separator between names.  DNS names normally just contain alphanumeric characters and hyphens ("-"), although they are allowed to contain any character RFC1035, Section 3.1, including a comma.  To prevent commas or other special characters in names leading to incorrect parsing, any characters that appear in names in this list that do not belong to the set of URI Unreserved Characters RFC3986, Section 2.3 MUST be percent-encoded as defined in RFC3986, Section 2.1. </del> <ins> The list of DNS names in "next-hop-aliases" uses a comma (",") as a separator between names.  Note that if a comma is included in a name itself, the comma must be encoded as described in encoding. </ins> For example, consider a proxy "proxy.example.net" that receives the following records when performing DNS resolution for the next hop
Code change:
The "" set includes ".", but we actually need to escape "." to avoid attacks.
Hm, my impression is that this attack is about making a period within a label look like a label separator. By the time that you have a string for a name, it would already need this kind of escaping done. Put another way, the "." characters we have in the string are indeed label separators already.
The draft doesn't specify how to construct the DNS name string (and in general there is not a great specification for this). The most common convention (noted in RFC 1035 Section 5.1) is to precede "." inside a label with a backslash. This draft would then percent-escape the backslash, but not the ".", so there would indeed be a "." character that is not a label separator in the final header field value. Whatever escaping convention you choose, this is sufficiently non-obvious that I think a very clear specification and some examples are probably in order. (This whole rigmarole is normally not a problem because URIs are restricted to contain only "hostnames", which cannot have weird characters in the labels.)
NAME can you look at URL
I realize that this is now resolved, but isn't it also possible that we could say "this field cannot be used to express names that include a literal period (".") in labels" ?
NAME yeah that’s an option, although it could theoretically incentivize using dots in labels as a way to hide the CNAME from being reported
Sure. But you can add another attribute called "this-site-is-abusing-this-mechanism" for use when that happens.

Related discussion:
text: aliases" to indicate that no CNAME records were encountered when resolving the next hop's name. <ins> 2.1. DNS names commonly just contain alphanumeric characters and hyphens ("-"), although they are allowed to contain any character RFC1035, Section 3.1, including a comma.  To prevent commas or other special characters in names leading to incorrect parsing, any characters that appear in names in this list that do not belong to the set of URI Unreserved Characters RFC3986, Section 2.3 MUST be percent-encoded as defined in RFC3986, Section 2.1. For example, consider the DNS name "name,with,commas.example.com". This name would be encoded within a "next-hop-aliases" parameter as follows: It is also possible for a DNS name to include a period character (".") within a label, instead of as a label separator.  In this case, the period character MUST be first escaped as "\.".  Since the "\" character itself will be percent-encoded, the name "dot\.label.example.com" would be encoded within a "next-hop-aliases" parameter as follows: Upon parsing this name, "dot%5C.label" MUST be treated as a single label. Similarly the "\" character in a label MUST be escaped as "\\". Other uses of "\" MUST NOT appear in the label after percent- decoding. </ins> 3. In order to include the "next-hop-aliases" parameter, a proxy needs
Code change:
NAME please take a look!
Without going through a proxy, clients implement CNAME cloaking mitigations on the basis of DNS information they see during resolution, which is totally reasonable. If resolution is subverted (or whatever) and the CNAME information is modified, these client checks might not work. When going through a proxy, the proxy is the one doing DNS resolution, so it seems like any sort of funny business that one might do to DNS answers for the proxy might affect the client's ability to implement cloaking mitigations correctly. The security considerations might benefit from a bit of expansion to cover this additional aspect of the threat model.

Related discussion:
text: The "next-hop-aliases" parameter does not include any DNSSEC information or imply that DNSSEC was used.  The information included in the parameter can only be trusted to be valid insofar as the <del> client trusts its proxy to provide accurate information.  This </del> <ins> client trusts the proxy to provide accurate information.  This </ins> information is intended to be used as a hint, and SHOULD NOT be used for making security decisions about the identity of a resource accessed through the proxy. <ins> Inspecting CNAME chains can be used to detect cloaking of trackers or malicious hosts.  However, the CNAME records could be omitted by a recursive or authoritative resolver that is trying to hide this form of cloaking.  In particular, recursive or authoritative resolvers can omit these records for both clients directly performing DNS name resolution and proxies performing DNS name resolution on behalf of client.  A malicious proxy could also choose to not report these CNAME chains in order to hide the cloaking.  In general, clients can trust information included (or not included) in the "next-hop- aliases" parameter to the degree that the proxy and any resolvers used by the proxy are trusted. </ins> 5. This document registers the "next-hop-aliases" parameter in the "HTTP
Code change:
We've been circling an answer to this for a while. The entire gamut of possible solutions is broad, and we haven't had much luck in reaching clarity here. One the one end of the scale, it should be perfectly OK to send a request for an origin over an authenticated TLS connection. But we still have the (entirely legitimate) concern there is that some servers might get themselves confused by this. The other end of the scale is the bells and whistles JSON stuff. NAME seemed OK with this based on his implementation experience, but it is a little complicated. We found too many corner cases for me to be happy that it implementations wouldn't end up busted. And now that we insist on authentication for the server, many of the features didn't make sense. We've also considered an HTTP/2 setting. That's appealing, but it does limit the applicability a little. This change aims more to the conservative end of that scale. It keeps the resource, but simplifies it, reducing it to a flat list of origins. The client only needs to acquire this from the authenticated server. This doesn't defend against Alt-Svc attacks mounted by attackers with the ability to both send header fields and run an authenticated server, but we're in a very strange place if this is the sort of capabilities we ascribe to our attackers in our threat models. I've explicitly added here. I believe that's reflective of consensus, but that part is easy to revert. The text about client certificates is now clearer.

Related discussion:
text: An origin server that supports the resolution of "http" URIs can indicate support for this specification by providing an alternative service advertisement RFC7838 for a protocol identifier that uses <del> TLS, such as "h2" RFC7540. </del> <ins> TLS, such as "h2" RFC7540, or "http/1.1" RFC7301.  Note that HTTP/1.1 requests MUST use the absolute form (see Section 5.3.2 of RFC7230). </ins> A client that receives such an advertisement MAY make future requests intended for the associated origin (RFC6454) to the identified
Code change:
We've been circling an answer to this for a while. The entire gamut of possible solutions is broad, and we haven't had much luck in reaching clarity here. One the one end of the scale, it should be perfectly OK to send a request for an origin over an authenticated TLS connection. But we still have the (entirely legitimate) concern there is that some servers might get themselves confused by this. The other end of the scale is the bells and whistles JSON stuff. NAME seemed OK with this based on his implementation experience, but it is a little complicated. We found too many corner cases for me to be happy that it implementations wouldn't end up busted. And now that we insist on authentication for the server, many of the features didn't make sense. We've also considered an HTTP/2 setting. That's appealing, but it does limit the applicability a little. This change aims more to the conservative end of that scale. It keeps the resource, but simplifies it, reducing it to a flat list of origins. The client only needs to acquire this from the authenticated server. This doesn't defend against Alt-Svc attacks mounted by attackers with the ability to both send header fields and run an authenticated server, but we're in a very strange place if this is the sort of capabilities we ascribe to our attackers in our threat models. I've explicitly added here. I believe that's reflective of consensus, but that part is easy to revert. The text about client certificates is now clearer.

Related discussion:
text: Client certificates are not meaningful for URLs with the "http" scheme, and therefore clients creating new TLS connections to alternative services for the purposes of this specification MUST NOT <del> present them.  Established connections with client certificates MAY be reused, however. </del> <ins> present them.  Connections that use client certificates for other reasons MAY be reused, though client certificates MUST NOT affect the responses to requests for "http" resources. </ins> 2.1.
Code change:
We've been circling an answer to this for a while. The entire gamut of possible solutions is broad, and we haven't had much luck in reaching clarity here. One the one end of the scale, it should be perfectly OK to send a request for an origin over an authenticated TLS connection. But we still have the (entirely legitimate) concern there is that some servers might get themselves confused by this. The other end of the scale is the bells and whistles JSON stuff. NAME seemed OK with this based on his implementation experience, but it is a little complicated. We found too many corner cases for me to be happy that it implementations wouldn't end up busted. And now that we insist on authentication for the server, many of the features didn't make sense. We've also considered an HTTP/2 setting. That's appealing, but it does limit the applicability a little. This change aims more to the conservative end of that scale. It keeps the resource, but simplifies it, reducing it to a flat list of origins. The client only needs to acquire this from the authenticated server. This doesn't defend against Alt-Svc attacks mounted by attackers with the ability to both send header fields and run an authenticated server, but we're in a very strange place if this is the sort of capabilities we ascribe to our attackers in our threat models. I've explicitly added here. I believe that's reflective of consensus, but that part is easy to revert. The text about client certificates is now clearer.

Related discussion:
text: both "http" and "https" URIs might use the same connection, because HTTP/2 permits requests for multiple origins on the same connection. <del> Because of the risk of server confusion about individual requests' schemes (see confuse), clients MUST NOT send "http" requests on a connection that has previously been used for "https" requests, unless the http-opportunistic origin object well-known fetched over that connection has a "mixed-scheme" member whose value is "true". </del> <ins> Because of the potential for server confusion about the scheme of requests (see confuse), clients MUST NOT send "http" requests on a connection prior to successfully retrieving a valid http- opportunistic resource that contains the origin (see well-known). The primary purpose of this check is to provide a client with some assurance that a server understands this specification and has taken steps to avoid being confused about request scheme. </ins> 2.3.
Code change:
We've been circling an answer to this for a while. The entire gamut of possible solutions is broad, and we haven't had much luck in reaching clarity here. One the one end of the scale, it should be perfectly OK to send a request for an origin over an authenticated TLS connection. But we still have the (entirely legitimate) concern there is that some servers might get themselves confused by this. The other end of the scale is the bells and whistles JSON stuff. NAME seemed OK with this based on his implementation experience, but it is a little complicated. We found too many corner cases for me to be happy that it implementations wouldn't end up busted. And now that we insist on authentication for the server, many of the features didn't make sense. We've also considered an HTTP/2 setting. That's appealing, but it does limit the applicability a little. This change aims more to the conservative end of that scale. It keeps the resource, but simplifies it, reducing it to a flat list of origins. The client only needs to acquire this from the authenticated server. This doesn't defend against Alt-Svc attacks mounted by attackers with the ability to both send header fields and run an authenticated server, but we're in a very strange place if this is the sort of capabilities we ascribe to our attackers in our threat models. I've explicitly added here. I believe that's reflective of consensus, but that part is easy to revert. The text about client certificates is now clearer.

Related discussion:
text: That response has the media type "application/json", and That response's payload, when parsed as JSON RFC7159, contains an <del> object as the root, and The root object contains a member whose name is a case-insensitive character-for-character match for the origin in question, serialised into Unicode as per Section 6.1 of RFC6454, and whose value is an object (hereafter, the "origin object"), The origin object has a "lifetime" member, whose value is a number indicating the number of seconds which the origin object is valid for (hereafter, the "origin object lifetime"), and </del> <ins> array as the root, and </ins> <del> The origin object lifetime is greater than the "current_age" (as per RFC7234, Section 4.2.3). </del> <ins> The array contains a string that is a case-insensitive character- for-character match for the origin in question, serialised into Unicode as per Section 6.1 of RFC6454. </ins> <del> Note that origin object lifetime might differ from the freshness lifetime of the response. </del> <ins> A client MAY treat an "http-opportunistic" resource as invalid if the contains values that are not strings. </ins> 3.
Code change:
This PR tracks changes under discussion with the RFC editor. (Note that I haven't renamed the file to the RFC number, because that hasn't been done in other drafts in this repo.) When AUTH48 completes, I will add the commit moving this draft to the archive and merge it.

Related discussion:
text: The ORIGIN Extension in HTTP/3 <del> draft-ietf-httpbis-origin-h3-latest </del> Abstract <del> The ORIGIN frame for HTTP/2 is equally applicable to HTTP/3, but </del> <ins> The ORIGIN frame for HTTP/2 is equally applicable to HTTP/3, but it </ins> needs to be separately registered.  This document describes the ORIGIN frame for HTTP/3. 1. <del> Existing RFCs define extensions to HTTP/2 HTTP2 which remain useful in HTTP/3.  HTTP3 describes the required updates for HTTP/2 frames to be used with HTTP/3. </del> <ins> Existing RFCs define extensions to HTTP/2 RFC9113 that remain useful in HTTP/3.  RFC9114 describes the required updates for HTTP/2 frames to be used with HTTP/3. </ins> ORIGIN defines the HTTP/2 ORIGIN frame, which indicates what origins are available on a given connection.  It defines a single HTTP/2
Code change:
This PR tracks changes under discussion with the RFC editor. (Note that I haven't renamed the file to the RFC number, because that hasn't been done in other drafts in this repo.) When AUTH48 completes, I will add the commit moving this draft to the archive and merge it.

Related discussion:
text: BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <del> Frame diagrams in this document use the format defined in QUIC- </del> <ins> The frame diagram in this document uses the format defined in QUIC- </ins> TRANSPORT to illustrate the order and size of fields. 2. <del> The ORIGIN HTTP/3 frame allows a server to indicate what origin(s) (RFC6454) the server would like the client to consider as members of the Origin Set (ORIGIN) for the connection within which it occurs. </del> <ins> The ORIGIN HTTP/3 frame allows a server to indicate what origin or origins RFC6454 the server would like the client to consider as one or more members of the Origin Set (ORIGIN) for the connection within which it occurs. </ins> The semantics of the frame payload are identical to those of the <del> HTTP/2 frame defined in ORIGIN.  Where HTTP/2 reserves Stream 0 for </del> <ins> HTTP/2 frame defined in ORIGIN.  Where HTTP/2 reserves stream 0 for </ins> frames related to the state of the connection, HTTP/3 defines a pair of unidirectional streams called "control streams" for this purpose. <del> Where ORIGIN indicates that the ORIGIN frame should be sent on Stream 0, this should be interpreted to mean the HTTP/3 control stream.  The ORIGIN frame is sent from servers to clients on the server's control stream. </del> <ins> Where ORIGIN indicates that the ORIGIN frame is sent on stream 0, this should be interpreted to mean the HTTP/3 control stream: that is, the ORIGIN frame is sent from servers to clients on the server's control stream. </ins> HTTP/3 does not define a Flags field in the generic frame layout.  As no flags have been defined for the ORIGIN frame, this specification