jiebi/CodeConvo huggingface dataset:
Code change:
client, or the client receives a server version that it did not offer, the corresponding peer MUST close the connection. <del> The SETUP parameters are described in the setup-parameters section. </del> <ins> [[RFC editor: please remove the remainder of this section before publication.]] </ins> <del> 6.1.1. </del> <ins> The version number for the final version of this specification (0x00000001), is reserved for the version of the protocol that is published as an RFC.  Version numbers used to identify IETF drafts are created by adding the draft number to 0xff000000.  For example, draft-ietf-moq-transport-13 would be identified as 0xff00000D. 6.1.2. </ins> Every parameter MUST appear at most once within the SETUP message. The peers SHOULD verify that and close the connection if a parameter

Related discussion:
text: Based on QUIC: URL
Based on call today, sounds like when running over QUIC we should also use an ALPN of "moq-13" for draft 13
When running over web transport, we need to talk to the web transport people to talk about what to do but the ALPN would be H3 (or whatever) so the answer is not ALPN
The conclusion was that we should move version negotiation out of the SETUP message and into an ALPN for native QUIC and an unspecified mechanism for WebTransport. However, I can't think of any replacement for WebTransport that would work today. Query parameters would work for passing the client supported versions but there's no mechanism for replying with the server selected version. The javascript API provides no information about connection establishment (ex. any returned headers), only that it completed. If we moved version negotiation out of SETUP, then it would not be possible to interop until new WebTransport functionality was deployed, assuming W3C agrees in the first place. Could we go ahead with this PR until there's an available alternative? I like the direction of utilizing more of the QUIC/WebTransport handshake, but I don't think we should block interop awaiting this marginally better design.
Can we add in the ALPN text as part of this PR and for now say something like "When QUIC is used, the negotiated alpn MUST match the value in the SETUP message."?
It's time to specify some version numbers so we can attempt interop. We should do something like QUIC, where draft versions are prefixed with 0xff (or something?).
+1 The QUIC guys way over engineered this so I would be fine with just doing the same thing so we don't need to bike shed on it.
For now, will go with lower bits are the draft number and upper bits are some fixed set of bits defined in the draft. Do roughly what QUIC did.
Here's what I propose we copy: URL We don't need semvar yet because each version WILL have breaking changes. I'd be totally fine with semvar for the final RFC, like one byte for the major/minor/revision. Although I also think that negotiating extensions is more flexible for a transport protocol, while semvar seems more useful for something intended for fanout like the catalog.
Code change:
client, or the client receives a server version that it did not offer, the corresponding peer MUST close the connection. <del> The SETUP parameters are described in the setup-parameters section. </del> <ins> [[RFC editor: please remove the remainder of this section before publication.]] </ins> <del> 6.1.1. </del> <ins> The version number for the final version of this specification (0x00000001), is reserved for the version of the protocol that is published as an RFC.  Version numbers used to identify IETF drafts are created by adding the draft number to 0xff000000.  For example, draft-ietf-moq-transport-13 would be identified as 0xff00000D. 6.1.2. </ins> Every parameter MUST appear at most once within the SETUP message. The peers SHOULD verify that and close the connection if a parameter

Related discussion:
text: Per conversation, we've decided to move forward with this and do ALPN as a separate PR.I would want to consider using alpn at some point in time. Want to keep it open for URL version at some point too. This PR is fine to continue the experimentation.Looks fine to me. Sure we might do more complicated stuff later but this seems like good enough for now.
Code change:
Upon publication, please create the HTTP Priority Parameters registry at https://iana.org/assignments/http-priority [2] and populate it <del> with the types defined in parameters; see register for its associated procedures. </del> <ins> with the entries in iana-parameter-table; see register for its associated procedures. </ins> 17.  References

Related discussion:
text: During IANA review of the document it was noted that the instructions for populating the new HTTP Priority Parameters registry with the urgency and incremental parameters was not that clear. So this change lists both and to make it clear what we want.
LGTM. Thank you for the quick work.
Code change:
8.4. <del> Many existing HTTP/1.1 implementations use the presence or absence of TLS in the stack to determine whether requests are for "http" or "https" resources.  This is necessary in many cases because the most common form of an HTTP/1.1 request does not carry an explicit indication of the URI scheme. HTTP/1.1 MUST NOT be used for opportunistically secured requests. </del> Some HTTP/1.1 implementations use ambient signals to determine if a request is for an "https" resource.  For example, implementations <del> might look for TLS on the stack or a port number of 443.  An implementation that supports opportunistically secured requests SHOULD suppress these signals if there is any potential for confusion. </del> <ins> might look for TLS on the stack or a port number of 443.  This is necessary in many cases because the most common form of an HTTP/1.1 request does not carry an explicit indication of the URI scheme.  An implementation that is serving an opportunistically secured request SHOULD suppress these signals for "http" resources. HTTP/1.1 MUST NOT be used to serve opportunistically secured requests.  HTTP/1.1 can be used to discover an opportunistically secured alternative service. </ins> 9.  References

Related discussion:
text: I think that I caught everything in the first round of discussion. There aren't any substantial changes here, but it's a PR so that others can confirm.
Code change:
replaced by pseudonyms.  A sender MUST NOT combine entries that have different received-protocol values. <del> 5.5.2. </del> <ins> 5.6.2. </ins> Some intermediaries include features for transforming messages and their payloads.  A proxy might, for example, convert between image

Related discussion:
text: and with the hope of being useful for quicwg/base-drafts I suspect that we also need to move "Initiating HTTP over TLS" down to the section on Routing, but that can be done separately.
This is now ready to merge, IMO. There is more work to do after merging, specifically taking the old RFC2818 description of initiating HTTP over TLS out and moving just the 1.1-specific bits to Messaging, but I don't want to do that in the same PR.
I agree with Roy. This is big enough that merging and iterating is the right path.
From :
Looks good enough to merge and iterate upon. Will need change notes, of course.
Code change:
11. <del> IANA is requested to register the following media types following the same process in RFC7285: </del> <ins> IANA is requested to register the following media types from the registry available at IANA-Media-Type: </ins> application/alto-tips+json: as described in open-resp;

Related discussion:
text: This will help me fix this part in the writeup: Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see [RFC 8126][11]).
Code change:
in how each Transparency Service is implemented and operates.  Each service MAY enforce its own Registration Policy for authorizing entities to register their Signed Statements to the append-only Log. <del> Some Transparency Services may also enforce role based access control (RBAC) policies limiting who can write, read and audit specific Feeds or the full Registry.  It is critical to provide interoperability for all Transparency Services instances as the composition and configuration of involved supply chain entities and their system components is ever-changing and always in flux. </del> <ins> Some Transparency Services may also enforce authorization policies limiting who can write, read and audit specific Feeds or the full registry.  It is critical to provide interoperability for all Transparency Services instances as the composition and configuration of involved supply chain entities and their system components is ever-changing and always in flux. </ins> A Transparency Services provides visibility into Signed Statements associated with various supply chains and their sub-systems.  These

Related discussion:
text: NAME This is a fundamental bug in the spec, we need to correct it ASAP!
NAME Thank you for the review. I agree with most of your edits.
NAME Thanks, I have done all the required edits, please have a look!
LGTM Line item at 962 could be done later
Code change:
11.7. <del> RFC7540 registered an upgrade token.  This capability has been removed: see versioning. </del> <ins> This section records the upgrade token registered in RFC7540 as obsolete.  This capability has been removed: see versioning.  The registration is updated as follows: </ins>

Related discussion:
text: The HTTP2-Settings header field and the h2c Upgrade token are both obsolete in the same way for the same reason, but it's rendered differently in their respective IANA sections. HTTP2-Settings is marked as Obsolete in the registry, with a reference back to the IANA Considerations of this document h2c gives no instructions to IANA, but includes explanatory text that the capability is removed and refers to Section 3.1. I would suggest that these should be aligned and combined, such that each one does two things: Instructs IANA to mark the entry as Obsolete Add a note that the element was used for Upgrade and reference Section 3.1 for more detail on Upgrade's removal
Code change:
, and <del> may be used.  The type might also indicate that , , , can be selectively disclosable. </del> <ins> may be used.  The type might also indicate that any of the aforementioned claims can be selectively disclosable. </ins> 3.2.2.2.

Related discussion:
text: Type identifiers MUST be collision-resistant names as defined in RFC7515 Changed the example to a URI
Code change:
4.3.1. <del> When sending a conditional request for cache validation, a cache sends one or more precondition header fields containing metadata from its stored response(s), which is then compared by recipients to determine whether a stored response is equivalent to a current representation of the resource. </del> <ins> When generating a conditional request for validation, a cache starts with either a request it is attempting to satisfy, or -- if it is initiating the request independently -- it synthesises a request using a stored response by copying the method, request-target, and request header fields used for identifying the secondary cache key caching.negotiated.responses. It then updates that request with one or more precondition header fields.  These contain validator metadata sourced from stored response(s) that have the same cache key (both primary and secondary, as applicable). The precondition header fields are then compared by recipients to determine whether any stored response is equivalent to a current representation of the resource. </ins> One such validator is the timestamp given in a

Related discussion:
text: Caching : Can the cache send any old entity-tag it has stored for the URL in these headers, or must it only do it for those that can be selected by the incoming request, as per the secondary cache key algorithm? Also, this section uses "selected" in a different meaning; that should probably be changed to avoid confusion.
I think it needs to constrain it to the selected stored responses.
We need to be careful to include the case where an upstream cache (or UA) has sent a conditional request (perhaps with some of its own stored etags) and this cache is forwarding them along.
When sending a conditional request for validation, a cache updates the request it is attempting to satisfy with one or more precondition header fields. These contain validator metadata sourced from the stored response(s) that have the same cache key (both primary and secondary, as applicable). The precondition header fields are then compared by recipients to determine whether any stored response is equivalent to a current representation of the resource. [rest as before]
Isn't this presuming the validation is part of an upstream request? What if the cache is auto-refreshing stored responses during idle time? Maybe we should define these as separate cases?
When generating a conditional request for validation, a cache starts with either a request it is attempting to satisfy, or -- if it is initiating the request independently -- it synthesises a request using a stored response by copying the method, request-target, and request header fields used for identifying the secondary cache key [ref]. It then updates that request with one or more precondition header fields. These contain validator metadata sourced from stored response(s) that have the same cache key (both primary and secondary, as applicable). The precondition header fields are then compared by recipients to determine whether any stored response is equivalent to a current representation of the resource.
Code change:
4. <del> TODO: Fill this in with detail </del> <ins> This section lists requirements for providing real time media streaming over a QUIC connection. 4.1. When initiating a media session, both the sender and receiver should be able to negotiate the codecs, bitrates and other media details based on capabilities and preferences. 4.2. Media should be able to flow in either direction from client to server or vice-versa, either individually or concurrently. 4.3. TODO: Unsure if this should be a requirement.  If it is, we have to consider two things: WebTransport supports HTTP/2, are we going to explicitly exclude it?  Also, WebTransport I-D.draft-ietf-webtrans- overview has normative language around congestion control which may be at odds with our potential requirements. 4.4. The protocol SHOULD have capabilities asides from TLS mutual authentication to allow hosts to authenticate one another, this should be kept simple but robust in nature to prevent attacks like credential brute-forcing. </ins> 5.

Related discussion:
text: This adds a few requirements ripped from my blog post, and cleans out use cases and such.
I have some thoughts about the content of this PR, but let's merge it, and see if my thoughts turn into text :-)
Code change:
The terms "header", "payload", and "to-be-signed bytes" are defined in RFC9052. <ins> The terms claim is defined in RFC8392, and is repeated here for readability: </ins> 3. In this document, the definition of transparency is intended to build

Related discussion:
text: Adjusts text around CDDL and EDN Adjusts text regarding Validation
LGTM, nice and clear changesLGTM
Code change:
The following additional parameter MUST be present in a Txn-Token Request: <del> A parameter named "azc" , whose value is a JSON object.  This object contains any information the Transaction Token Service needs to understand the context of the incoming request. </del> <ins> A parameter named "rctx" , whose value is a JSON object.  This object contains the request context, i.e. any information the Transaction Token Service needs to understand the context of the incoming request. </ins> figtxtokenrequest shows a non-normative example of a Txn-Token Request.

Related discussion:
text: The current draft had a request parameter named "azc" and also the claim within the TraT is called "azc", which leads to confusion whether the request parameter content is directly embedded into the token. So I am renaming the request parameter to "rctx".
Ahh... I think this parameter is for cases where the requestor wants to add some specific authorization data into the overall TxTkn. I would prefer to rename the parameter 'authz_details' which would be a JSON object and then add it as a sub-object in the of the TxTkn.
From Dr. Kelley W. Burgin Section 6.2: What does the AS do with the values in “azc”? Are they included in the transaction token? Can I put anything I want in “azc”?
Code change:
3.1.3. <ins> A congestion control algorithm should try to avoid causing excessively high rates of packet loss.  To accomplish this, it should avoid excessive increases in sending rate, and reduce its sending rate if experiencing high packet loss. The first version of the BBR algorithm BBRv1-draft failed this requirement.  Experimental evaluation BBRv1-Evaluation showed that it caused a sustained rate of packet loss when multiple BBRv1 flows shared a bottleneck and the buffer size was less than roughly one and a half BDP.  This kind of behavior needed to be fixed, and indeed further versions of BBR BBR-draft fixed this issue. This requirement does not imply that the algorithm should react to packet losses in exactly the same way as current standards-track congestion control algorithms (e.g., RFC5681). 3.1.4. </ins> When multiple competing flows all use the same proposed congestion control algorithm, the proposal should explore how the capacity is shared among the competing flows.  Capacity fairness can be important

Related discussion:
text: This is an attempt to address issue
Current version looks good to me as well, FWIW.
Thanks! Looks good to me, FWIW. :-)
I'm satisfied but won't merge until Gorry is satisfied too.This seems fine.
Code change:
state.  This state can be limited by adopting the guidance about concurrency limits described above.  Extensible priorities is subject to a similar consideration because PRIORITY_UPDATE frames may arrive <del> before the request that they reference.  A server could retain the information in order to apply the most up-to-date signal to the request.  However, HTTP/3 implementations might have practical </del> <ins> before the request that they reference.  A server is required to store the information in order to apply the most up-to-date signal to the request.  However, HTTP/3 implementations might have practical </ins> barriers to determining reasonable stream concurrency limits depending on the information that is available to them from the QUIC transport layer.  TODO: so what can we suggest?

Related discussion:
text: Since fairness is being moved out of security considerations, (URL) it makes the section empty. Seems reasonable to add some prose about the considerations of this scheme as compared to HTTP/2. However, this also depends on the outcome of the reprioritization discussion, so I'm being a little weasly with TBD and TODOs. Might want to just hold onto this for a while but WDYT NAME ?
Thank you for working on this. LGTM modulo the point below.
Code change:
3.4.10. <ins> An attacker attempts to access an adminstration portal repeatedly, generating a stream of authorization requests to the network administrator.  The attempts are timed to occur while the administrator is asleep.  The administrator is woken by the incoming requests on their phone, and, in an attempt to stop the notifications, they accidentally approve access and the attacker gains access to the portal. 3.4.11. </ins> In all of the attack scenarios listed above, a user is misled or exploited.  For other attacks, where the user is willingly colluding with the attacker, the threat model, security implications and

Related discussion:
text: Added an example described at OSW 2023 (see issue )
There are two new attacks, the consent bombing and fake helpdesk attacks, that may be added as examples of attacks, or as extensions of existing attacks.
After discussing ith Daniel we agreeed: Add an example for the consent bombing attacks Add a sub-attack to example B.4 (split into two attacks).
Approved with editorial changes.
Code change:
A recipient MAY combine multiple field lines with the same field name into one field line, without changing the semantics of the message, by appending each subsequent field line value to the initial field <del> line value in order, separated by a comma.  The order in which field lines with the same name are received is therefore significant to the interpretation of the field value; a proxy MUST NOT change the order of these field line values when forwarding a message. </del> <ins> line value in order, separated by a comma and optional whitespace. For consistency, use comma SP. The order in which field lines with the same name are received is therefore significant to the interpretation of the field value; a proxy MUST NOT change the order of these field line values when forwarding a message. </ins> This means that, aside from the well-known exception noted below, a sender MUST NOT generate multiple field lines with the same name in a

Related discussion:
text: Fetch and XMLHttpRequest have for the longest time used comma-followed-by-space (0x2C 0x20) as separator when multiple header fields are combined into a single header field. This is also what at least Firefox and Chrome do from code inspection: URL URL I think this is because of URL encouraging values to start with a single space and folks conceptually still seeing it as multiple values. Now URL has a much more explicit definition, which no longer allows for a space as far as I can tell, "breaking" with what implementations are doing. Most of the time this difference is insignificant, but anything with quoted-string or equivalent will be able to tell what was used if those configuring the headers like to play games. I'd like HTTP to either allow 0x2C 0x20 as an alternative separator (and have Fetch mandate it for browsers) or simply adopt 0x2C 0x20 as separator for everyone. I have some tests around this as well, but they only affect APIs, which theoretically could have a different non-HTTP-conformant view, but that'd seem really bad: URL See URL and URL for further context. cc NAME NAME NAME
Whitespace is allowed (and insignificant). Can you point at the actual difference between 2616 and 7230 which makes you think that something changed?
You mean when a quoted-string is broken into several header field instances?
In 2616 the same section states that values can be preceded by whitespace. Whereas in 7230 it only describes how to combine, without any mention of whitespace. Both sections are linked in OP. Yeah, also relevant for structured headers, which is how I started stumbling into this. If one client combines with a space, another without, and another with three spaces, you get subtly different strings and possibly room for security bugs.
This one? That's not specific to recombination.
I know...
Anne, I think what you're suggesting is to change: to: This is meaningful in some admittedly pathological cases, such as a header like this: Because the current text has a combined value of -- whereas most implementations will do .
So I think things are even more broken than I thought. A recipient that knows about URL and knows the header, might drop empty or whitespace values.