jiebi/CodeConvo huggingface dataset:
Code change:
Similarly, clients MUST NOT employ the "Client-Cert" or "Client-Cert- Chain" header field in requests. <ins> When the value of the "Client-Cert" request header field is used to select a response (e.g., the response content is access-controlled), the response MUST either be uncacheable (e.g., by sending "Cache- Control: no-store") or be designated for selective reuse only for subsequent requests with the same "Client-Cert" header value by sending a "Vary: Client-Cert" response header.  If a TTRP encounters a response with a "client-cert" field name in the "Vary" header field, it SHOULD prevent the user agent from caching the response by transforming the value of the "Vary" response header field to "*". </ins> 3. 3.1.

Related discussion:
text: Attempt to cover client-cert and caching interactions per mnot's guidance in issue
Thanks Mark, accepted all your suggested changes
Origin servers might select a response based upon the value of the request header. This might impact caches in these situations: When an intermediary that's generating also has a cache When an intermediary between the generator of and the origin has a cache (e.g., as part of a CDN hierarchy or a server-side reverse proxy) When the client on the other side of the TLS connection has a cache (e.g., the browser or other user agent) and the UA's use of client certs varies (e.g., different certs are used, or no cert is used) Some guidance about this is probably necessary. In cases (1) and (2), it's just a matter of adding to all responses for an access-controlled resource. (3) is more subtle, because the browser/UA doesn't see the client cert in the request, since it's generated downstream. From its perspective, will always select a non-existent header field, and so it'll match whatever the certificate used actually is. The most straightforward thing to do for (3) is to advise that an intermediary generating MUST/SHOULD transform on responses (when it occurs) to . There need to be some detail work around how this should happen, to make sure that parsing corner cases are caught.
Thanks NAME and apologies that I somehow missed seeing this issue when you initially submitted it. I think I can put together a bit of text with guidance along the lines of your suggestions. Is it okay or preferred to use vs. ? , which isn't a standard I know but it does show up near the top of search results. And on trying to educate myself more I found that says 'A proxy MUST NOT generate a Vary field with a "" value.' I think RFC 7231 means proxy only in the forward proxy notion of proxy so it's okay for a reverse proxy / gateway. And draft-ietf-httpbis-semantics-19 has a more explicit definition of proxy as such. But it did give me pause.
Ignore MDN, it's often wrong (will file a PR there when I get a chance). is the most semantically correct, but making it uncacheable works too.
Thanks Mark. I took a pass at this with PR
Looks pretty good, a couple of nits
Code change:
mechanism for low-latency requests, with a single method (GET) to request transfer of a presumed hypertext document identified by a given pathname.  This original protocol is now referred to as <del> HTTP/0.9. </del> <ins> HTTP/0.9 (see HTTP09). </ins> HTTP's version number consists of two decimal digits separated by a "." (period or decimal point).  The first digit ("major version")

Related discussion:
text: The practice of combining list-form fields into a single value is widespread, and the document addresses this pretty clearly. However it never really says that this combination needs to be limited to a single field section. It's pretty clear that trailers need to be kept discrete, but there is nothing so direct. It's probably worth adding "within a field section" somewhere.
Agree, but I can't find the definition of "field section" neither in MESSAGING nor in SEMANTICS :)
I was pointed to URL which is good, but it doesn't really say that this combining only applies to a single field section (and yes, that is not a term that is defined in the document as far as I can see).
Thanks, this works nicely. Shame that you had to add a new term, but we already got that in QUIC.
Code change:
mechanism for low-latency requests, with a single method (GET) to request transfer of a presumed hypertext document identified by a given pathname.  This original protocol is now referred to as <del> HTTP/0.9. </del> <ins> HTTP/0.9 (see HTTP09). </ins> HTTP's version number consists of two decimal digits separated by a "." (period or decimal point).  The first digit ("major version")

Related discussion:
text: NAME - is Oct 1999 correct? (taken from Last-Modified)
Last edit is 1999 but was just a markup fix, original document is dated 1996-10-03. HTH,
This seems out of place, although I understand that versioning is very message-based. I'd suggest putting it in 15. Extending HTTP?
It's not about extending HTTP. The version number literally exists as a field of the message, or at least inherited by the context of the connection, and must be retained by recipients because of version-specific requirements. That's why we need to define both cases as part of the message abstraction.
Fair enough. Can we open the section with a sentence or two that says that it's a field of the message, to give that context? The current text is pretty abstract.
Code change:
Indicates that the exported authenticator spans more than one frame. <ins> Indicates that the exported authenticator does not contain a Request-ID. </ins> The frame contains the following fields: "Cert-ID" is a 16-bit opaque identifier used to correlate other certificate- related frames with this exported authenticator fragment. <ins> "Request-ID" is an optional 16-bit opaque identifier used to correlate this exported authenticator with the request which triggered it, if any.  This field is present only if the "UNSOLICITED" flag is not set. </ins> A portion of the opaque data returned from the TLS connection exported authenticator "authenticate" API.  See exp-auth for more details on the input to this API.

Related discussion:
text: Takes a dependency on URL
I think that it would be better to explicitly reference CERTIFICATE_REQUEST in the cases where a CERTIFICATE is generated directly in response to one. Using the "get context" API from exported authenticators is ugly. This is more important now that exported authenticators folds the request into the response. We probably want to use a flag for whether this is spontaneous so that we can avoid reserving a Request-ID for spontaneous CERTIFICATE messages.
I'm a little dubious about this. Having the same value transported in two different fields and then checking that they're equal seems potentially more error-prone than just transporting it in one place, even if that one place is by calling into a library to interpret for you.
For posterity, discussion in Montreal: Nice not to have to dig out the Request-ID. However, if you duplicate it, then you have to compare and check that they're equal, so you're still calling into TLS. There is an existing duplication in the CERTIFICATE_REQUEST, where the Request-ID is carried outside the EA.
Code change:
Signed Statement can be tampered with by a malicious Transparency Service (e.g., one that does not incorporate remote attestation), which may replace the intermediate certificates and ultimately <del> connect to an unexpected root.  This modification can allow malicious TS to forge Claims that look genuine except for the wrong trust anchor.  Auditors MUST perform certification path validation in accordance with PKIX rules specified in RFC5280.  In particular, Auditors MUST verify that certification paths chain to one or more trust anchors (often represented as root certificates). </del> <ins> connect to an unexpected root.  This modification helps protect against person-in-the-middle attacks, but not denial-of-service. Auditors MUST perform certification path validation in accordance with PKIX rules specified in RFC5280.  In particular, Auditors MUST verify that certification paths chain to one or more trust anchors (often represented as root certificates). </ins> 6.1.

Related discussion:
text: Here is the status: I do not believe there is a security problem. Roy says that Antoine thinks there is a problem. Antoine is, however, not at the meeting.
Antoine can object in the next iteration or during WGLC
The replacement loses the security issue and adds a new one. The modification of removing the certificate chain, which will save space in the ledger, opens up a problem of building the chain dynamically may result in the wrong trust anchor.LGTM
Code change:
7.1. Various attacks might be amplified by being stored in a shared cache. <del> Such "cache poisoning" attacks use the cache to distribute a malicious payload to many clients, and are especially effective when an attacker can use implementation flaws, elevated privileges, or other techniques to insert such a response into a cache. </del> <ins> Such "cache poisoning" attacks use the cache to distribute malicious content to many clients, and are especially effective when an attacker can use implementation flaws, elevated privileges, or other techniques to insert such a response into a cache. </ins> One common attack vector for cache poisoning is to exploit differences in message parsing on proxies and in user agents; see

Related discussion:
text: ... it's just deployments of very very old caches that would be of concern here. Given how unlikely this is in 2020, how broken they would be for other reasons, and the prevalence of HTTPS, it seems safe to modify these statements.
Is this warning still relevant? If we want to keep it, I think we need to qualify it; e.g., "A few old HTTP/1.0 caches that are unlikely to be used on the open Internet..." Similar text in cc: no-cache.
I think the warnings can be removed.
Code change:
The hash algorithm identifier MUST be a hash algorithm value from the "Hash Name String" column in the IANA "Named Information Hash <del> Algorithm" registry IANA.Hash.Algorithms. </del> <ins> Algorithm" registry IANA.Hash.Algorithms or a value defined in another specification and/or profile of this specification. </ins> To promote interoperability, implementations MUST support the SHA-256 hash algorithm.

Related discussion:
text: A bit more in security considerations for Choice of a Hash Algorithm (1st & 2nd preimage resistant and not majorly truncated) for issue
While looking at this I noticed URL only allows hash algs from the registry. URL removed the JOSE HMAC stuff but also removed allowing the hash alg to be "a value defined in another specification and/or profile of this specification" which I thought we wanted to have - for Christian's type use cases and extensibility in general. This isn't the right place for a discussion but wanted to note it somewhere before our call.
I think we intentionally removed “a value defined in another specification and/or profile of this specification” Because using that would require a separate profile and not just defining an identifier.
from this PR URL
Code change:
Another example use is concurrent multipath, where the transport protocol simultaneously schedules flows to aggregate the capacity <del> across multiple paths.  The Internet provides no guarantee that different paths (e.g., using different endpoint addresses) are disjoint.  This has additional implications: A proposed congestion control algorithm MUST evaluate the potential harm to other flows when the multiple paths share a common congested bottleneck (or share resources that are coupled between different paths, such as an overall capacity limit), and SHOULD consider the potential for harm to other flows.  Synchronisation of congestion control mechanisms (e.g., where multiple flows change their behaviour on similar timeframes) can also contribute to harm and/or reduce fairness, these effects also ought to be evaluated.  At the time of writing, there are no IETF standards for concurrent multipath congestion control in the general Internet. </del> <ins> across multiple paths. The Internet provides no guarantee that different paths (e.g., using different endpoint addresses) are disjoint.  This has additional implications: A proposed congestion control algorithm MUST evaluate the potential harm to other flows when the multiple paths share a common congested bottleneck (or share resources that are coupled between different paths, such as an overall capacity limit), and SHOULD consider the potential for harm to other flows. Synchronisation of congestion control mechanisms (e.g., where multiple flows change their behaviour on similar timeframes) can also contribute to harm and/or reduce fairness, these effects also ought to be evaluated. At the time of writing, there are currently no Standards Track RFCs, but there is an Experimental RFC RFC6356 that specifies a concurrent multipath congestion control algorithm for TCP (MP-TCP). </ins> 6.9.

Related discussion:
text: Proposed text to add MP-TCP RFCs.
From NAME review: Section 5.8: What is the verdict on RFC 6356? Is it not worth bringing this up in relation to concurrent usage? RFC 8041 do bring up additional experience with also other algorithms for MP-TCP that have been tried. I would at least claim “At the time of writing, there are no IETF standards for concurrent multipath congestion control in the general Internet.” that this sentence is factual wrong as RFC 6356 is an IETF experimental specification. I do think this section brings up important aspects to consider. However, it also point to some interesting challenges in reasoning and responsibility between functionalities when managing different paths. Looking at the text I think we have scheduler application data, path availability checks as well as congestion control all impacting what is happening. What is truly congestion control here?
Code change:
6.2. The "CLIENT_SETUP" and "SERVER_SETUP" messages are the first messages <del> exchanged by the client and the server; they allows the peers to </del> <ins> exchanged by the client and the server; they allow the endpoints to </ins> establish the mutually supported version and agree on the initial configuration before any objects are exchanged.  It is a sequence of key-value pairs called Setup parameters; the semantics and format of which can vary based on whether the client or server is sending.  To <del> ensure future extensibility of MOQT, the peers MUST ignore unknown </del> <ins> ensure future extensibility of MOQT, endpoints MUST ignore unknown </ins> setup parameters.  TODO: describe GREASE for those. The wire format of the Setup messages are as follows:

Related discussion:
text: One small normative change: I relaxed a SHOULD to a MAY when discussing relays writing data out of order. No one is implementing this right now.
Here are some editorial notes on the document Line 72. “MOQT is a generic protocol is designed to work” Line 91-93. “The development of MOQT is driven by goals in a number of areas - specifically latency, the robustness of QUIC, workflow efficiency and relay support.” This sentence is intriguing. What does the robustness of QUIC mean? Latency, workflow efficiency, relay support are not “areas” or maybe area should be defined. (side note on the missing Oxford comma in this sentence) The Section 1.1.1. Latency as a whole is very confusing. HTTP-based streaming is not designed for low latency mostly due to the essential request-response paradigm. Queuing on the path has a insignificant impact on the end-to-end latency for HAS. The “speed at which a protocol can detect queuing” is not related to the relatively high latency issues of HAS. Overall, I see a mix of unrelated subjects here, which makes the paragraph overall meaningless. I would recommend starting the paragraph with a topic sentence (which may be the last one of the current paragraph). Line 120. “Applying QUIC to HAS …” (and the following sentences) is not necessary. The reasons for which QUIC does not bring advantages to HAS are still debatable on many points. This QUIC-on-HAS remark could raise unnecessary questions although the beginning of Section 1.1.2 is clear and sufficient to convey the message. Line 125. “Universal” has a too broad sense. Do you mean “Unicity of protocol in the whole pipeline” (or something like this)? Line 127. “Internet delivered media today has protocols optimized for ingest…” I don’t understand this sentence. Line 127. Some examples of protocols could be good to support these claims. Note that WHIP is an attempt to unify the protocol. Line 146. “to treat relays as first-class citizens of the protocol” is an excellent marketing message but it does not mean anything in a technical norm. Furthermore, see my two reserves above. I’d claim that the current draft is not making relay first-class, on the contrary.
Code change:
6.2. The "CLIENT_SETUP" and "SERVER_SETUP" messages are the first messages <del> exchanged by the client and the server; they allows the peers to </del> <ins> exchanged by the client and the server; they allow the endpoints to </ins> establish the mutually supported version and agree on the initial configuration before any objects are exchanged.  It is a sequence of key-value pairs called Setup parameters; the semantics and format of which can vary based on whether the client or server is sending.  To <del> ensure future extensibility of MOQT, the peers MUST ignore unknown </del> <ins> ensure future extensibility of MOQT, endpoints MUST ignore unknown </ins> setup parameters.  TODO: describe GREASE for those. The wire format of the Setup messages are as follows:

Related discussion:
text: Line 179. “a join point” joint? Line 231. “The application is solely responsible for the content of the object payload.” What is the application? It is a bit confusing. It has not been defined. Line 269 .“within a single MOQT scope, subscribing to the same full track name would result in the subscriber receiving the data for the same track.” I am not sure to understand this sentence. Is a single MOQT scope a scope with only one server or do you mean “within a MOQT scope”? the two “same” adjectives are confusing too. Line 273. It would be better to stick to “servers” or to “connection URIs” to refer to the elements of the scope. Line 339. “The portion MUST NOT contain a non-empty portion.” Is it a double negation to say that the ‘authority’ MUST contain an empty ‘host’ portion? Line 357. This sentence may require a MUST. Line 359. “for exchanging …” and following sentences are not related to session initialization. They are rather remarks that would be a fit with the draft Section 4. +1 to the TODO remarks on line 381. This should be in Section 4. Line 654. “it allows the peers…” The term “peer” is used 7 times. It is supposed to be an “endpoint” (as defined Line 173), unless peer and endpoint have different meaning (in which case peer must be defined) Line 693. “A relay that reads from a stream and writes to stream in order will introduce head-of-line blocking.” I don’t understand this claim.
Thanks for the feedback. I'm going to mark this as Editorial, but there are a number of points here. If you believe any of them are not editorial (ie: "Line 357. This sentence may require a MUST."), please split into a separate issue.
Will assign to Mo.
NAME Please go through these and fix any that still apply.
Code change:
5.3.5. <del> Providing priority information is optional.  Streams are assigned a non-exclusive dependency on stream 0x0 by default.  PushResources initially depend on their associated stream.  In both cases, streams are assigned a default weight of 16. </del> <ins> All streams are initially assigned a non-exclusive dependency on stream 0x0.  PushResources initially depend on their associated stream.  In both cases, streams are assigned a default weight of 16. </ins> 5.4.

Related discussion:
text: Only if it makes sense to do so. It's a perfectly good word that has been spoiled by an unnecessary inclusion in some popular RFC (2119, I think).
Code change:
3.2.1. <del> Confidential clients or other clients issued client credentials MUST authenticate with the authorization server as described in client- authentication when making requests to the token endpoint.  Client authentication is used for: </del> <ins> Confidential or credentialed clients MUST authenticate with the authorization server as described in client-authentication when making requests to the token endpoint.  Client authentication is used for: </ins> Enforcing the binding of refresh tokens and authorization codes to the client they were issued to.  Client authentication is critical

Related discussion:
text: consistently use "confidential or credentialed"
Some editorial improvements [x] definition of user agent ( is an abnf syntax)
Code change:
The first stream opened is a client-initiated bidirectional control stream where the peers exchange SETUP messages (message-setup).  All <del> messages defined in this draft are sent on the control stream after the SETUP message.  Control messages MUST NOT be sent on any other stream, and a peer receiving a control message on a different stream closes the session as a 'Protocol Violation'.  Objects MUST NOT be sent on the control stream, and a peer receiving an Object on the control stream closes the session as a 'Protocol Violation'. </del> <ins> messages defined in this draft except OBJECT and OBJECT_WITH_LENGTH are sent on the control stream after the SETUP message.  Control messages MUST NOT be sent on any other stream, and a peer receiving a control message on a different stream closes the session as a 'Protocol Violation'.  Objects MUST NOT be sent on the control stream, and a peer receiving an Object on the control stream closes the session as a 'Protocol Violation'. </ins> This draft only specifies a single use of bidirectional streams. Objects are sent on unidirectional streams.  Because there are no

Related discussion:
text: I think the intent of the draft was clear but this makes it explicit not to open a uni stream before setup exchange is done.
It's unclear what messages are allowed to be sent or received during the SETUP handshake. Here's my intuition: Until receiving the SETUP, the client: MUST NOT send messages MUST buffer any received messages. Until receiving the SETUP, the server: MUST NOT send messages. MUST NOT receive messages. The client needs to buffer messages because the server is unaware of when the client receives the SETUP. There's no equivalent to HANDSHAKE_DONE, and adding something like that would add an RTT anyway.
A potential optimization exists if the message encoding if the same for all supported versions (invariants). For example, if the client only advertises support for versions 1,2,3 and those versions share the same SUBSCRIBE encoding and meaning. This seems unlikely, given a separate version was created in the first place, and seems very brittle. If this was the case, then the client could process any invariant messages immediately and buffer the others. However, the client still couldn't send messages unless the server buffered any received messages.
The most flexible optimization would be the one where you could encode the SUBSCRIBE_REQUEST for every version you offer as a field in SETUP parameters. TLS does not do exactly that, but there are some things in ClinetHello that are only applicable for certain versions.