jiebi/CodeConvo huggingface dataset:
Change:
Some stream types are reserved (stream-grease).  Two stream types are defined in this document: control streams (control-streams) and push <del> streams (push-streams).  Other stream types can be defined by extensions to HTTP/3; see extensions for more details. </del> <ins> streams (push-streams).  QPACK defines two additional stream types. Other stream types can be defined by extensions to HTTP/3; see extensions for more details. </ins> The performance of HTTP/3 connections in the early phase of their lifetime is sensitive to the creation and exchange of data on

Discussion:
The Stream Types registry (URL) currently lists two types only (0 - control, 1 - push). While working on a dissector for the base HTTP/3 protocol, I ran across 2 and 3. It turns out these are defined in the QPACK document (URL) with 2 - QPACK Encoder Stream, 3 - QPACK Decoder Stream. Since QPACK has already been referenced multiple times from the -http document, what about mentioning (or registering) the two codepoints in the -http document and reference to the -qpack document for the definition?
We can, and as QPACK is a required component of HTTP/3, you'd probably need to support QPACK for that to work. However, this is an extensible space and your dissector would need to tolerate other types it might not recognize, or that are added by future extensions. So the fact that there are definitions in other documents not mentioned by HTTP/3 is to be expected.
Change:
""index"" (index-section) <del> ""primary"" (primary-section) </del> ""manifest"" (manifest-section) ""critical"" (critical-section)

Discussion:
This PR removes the primary URL section. The motivation is to factor the "core" Web Bundles specification to include just the minimal amount needed to support cases like subresource loading. This and other removed sections can be defined in other documents in the future.
The subresource loading doesn't need a primary URL, but I think "Navigate to Bundle" use case still needs it. URL NAME NAME Please correct me if I am wrong. I'm assuming "Navigate to Bundle" uses a primary URL as a main resource URL.
That's correct. For a bundle to be navigable into, it needs to be possible to specify its main resource URL.
Yes, to open the web bundle file in the browser (eg: Drag and drop) we need either the primary URL or the manifest's . So, we need to keep either as an optional section.
The idea of this PR is that a primary URL could be defined in a separate section. However, it is outside the scope of the "core" bundle specification to define this section.
Thanks for making a PR! Could we see a path to having other document more clearly? Since we need a primary URL defined somewhere, it might be difficult to remove a primary URL section without a clear path how a primary URL is defined.
(Just in case if someone missed it) It seems this PR is one of agenda points at IETF 111 Wpack. URL
NAME : I just opened URL to discuss the possibility of creating an extension of the spec as a separate document.
LGTM (just for record). Thanks for working on this. Hello WPACK, My name is Felipe Erias. I am working on Web bundles at Igalia together with Dan Ehrenberg. I have just created several PRs at wpack-wg/bundled-responses and I am writing this email to request the addition of a point to discuss them to the agenda for the group's upcoming meeting at the end of July. These PRs address the removal of the primary URL section, the manifest section, and content negotiation. Most of this has been adapted from previous work by Dan on the WICG/webpackage repo. The overarching goal is to simplify the "core" Web Bundles specification so it includes just the minimal amount needed to support use cases like subresource loading. The removed sections may be defined in other documents in the future. These are the PRs: URL URL URL Best, Felipe
Change:
If an ICE candidate policy is specified, it functions as described in sec.ice-candidate-policy, causing the browser to only surface the <del> permitted candidates to the application, and only use those candidates for connectivity checks.  The set of available policies is as follows: </del> <ins> permitted candidates (including any internal browser filtering) to the application, and only use those candidates for connectivity checks.  The set of available policies is as follows: </ins> <del> All candidates will be gathered and used. Candidates with private IP addresses [RFC1918] will be filtered out.  This prevents exposure of internal network details, at the cost of requiring relay usage even for intranet calls, if the NAT does not allow hairpinning as described in [RFC4787], section 6. </del> <ins> All candidates permitted by browser policy will be gathered and used. </ins>

Discussion:
LGTM
lgtm
From URL "public" is probably something the browser should control, not the application. "none" was previously removed, but apparently Firefox has implemented it.
Keep in mind that anything less than all means that mobile apps will work better than browser apps. Public tries to just reveal what is already revealed simply by browsing the web with no webrtc.
Right, but that's what "all" does when the browser is configured as recommended by draft-rtcweb-shieh-ip-handling. It's not clear why a "public" mode also needs to exist; the point of this draft is to protect the user from the application, so we can't really give the app the ability to choose whether it wants non-public addresses. I think the real remaining question is whether "none" is worth keeping.
I think the motivation for "none" was a lot stronger when we had automatic gathering prior to setLD() in some situations. Now, it seems like you can just get the same effect by deferring setLD(). I agree that "public" is silly.
Change:
4.5. <ins> In brief, the keys used by any given endpoints are determined in the following way: </ins> 4.5.1. <del> The procedures defined in DTLS Tunnel for PERC I-D.ietf-perc-dtls- tunnel establish one or more TLS tunnels between the Media Distributor and Key Distributor, making it is possible for the Media Distributor to facilitate the establishment of a secure DTLS </del> <ins> The Media Distributor maintains a tunnel with the Key Distrubutor (e.g., using I-D.ietf-perc-dtls-tunnel), making it possible for the Media Distributor to facilitate the establishment of a secure DTLS </ins> association between each endpoint and the Key Distributor as shown the following figure.  The DTLS association between endpoints and the Key Distributor will enable each endpoint to generate E2E and HBH

Discussion:
This looks good to me
Minor nits “hadnshake” —> “handshake” “Each E2E key that an endpoint uses to receive SRTP media is set by receiving a Full EKT Field from another endpoints.” —> from other endpoints.
Change:
9.3. This section describes invariants that TLS endpoints and middleboxes <del> MUST follow.  It also applies to earlier versions, which assumed these rules but did not document them. </del> <ins> MUST follow.  It also applies to earlier versions of TLS. </ins> TLS is designed to be securely and compatibly extensible.  Newer clients or servers, when communicating with newer peers, should

Discussion:
ClientHello, etc., processing rules are in earlier versions too. We're just calling out some corollaries of it all.
Change:
6.6. <ins> The ISO 19770-2:2015 SWID specification describes use of the "swid" and "swidpath" URI schemes, which are currently in use in implementations.  This document continues this use for CoSWID.  The following subsections provide registrations for these schemes in to ensure that a registration exists for these schemes that is suitable for use in the SWID and CoSWID specifications.  URI schemes are registered within the "Uniform Resource Identifier (URI) Schemes" registry maintained at IANA.uri-schemes. 6.6.1. IANA is requested to register the URI scheme "swid".  This registration request complies with RFC7595. 6.6.2. IANA is requested to register the URI scheme "swidpath".  This registration request complies with RFC7595. 6.7. </ins> The Software Inventory Message and Attributes (SWIMA) for PA-TNC specification RFC8412 defines a standardized method for collecting an endpoint device's software inventory.  A CoSWID can provide evidence

Discussion:
Added back IANA registrations (as provisional) for swid and swidpath URI schemes. Slight re-wording of the intro paragraph to section 5 (discussing the schemes) to reflect this modification.
Change:
that share the same origin. An "exp" (Expiry) claim MUST be included with the time after which <del> the token expires.  This limits the time that a token over which a token is valid.  An "exp" claim MUST NOT be more than 24 hours from the time of the request. </del> <ins> the token expires.  This limits the time over which a token is valid.  An "exp" claim MUST NOT be more than 24 hours from the time of the request. </ins> This JWT is included in an Authorization header field, using an auth- scheme of "vapid".  A push service MAY reject a request with a 403

Discussion:
These are some suggested fixes for some nits that came up from the Shepherd write-up review.
Change:
version-invariant properties of QUIC described in QUIC-INVARIANTS to maximize its robustness to future versions of QUIC. <del> An arbitrary algorithmr MUST NOT make the routing behavior dependent </del> <ins> An arbitrary algorithm MUST NOT make the routing behavior dependent </ins> on any bits in the first octet of the QUIC packet header, except the first bit, which indicates a long header.  All other bits are QUIC <del> version-dependent and intermediaries should not base their design on </del> <ins> version-dependent and intermediaries SHOULD NOT base their design on </ins> version-specific templates. For example, one arbitrary algorithm might convert a non-compliant

Discussion:
Here are some suggestions from my first pass, but overall I think the static vs dynamic server ID allocation idea works nicely. 2 Q's: Is the definition of non-compliant different at LB and server in some cases? Might non-routable be a better term than non-compliant?
Yes, they can be different because the perception of the configuration is different. In general, during configuration updates the LB will have a configs that some servers don't. Therefore, a DCID with those CR bits will be compliant at the LB and non-compliant at the server. With static allocation, servers don't do anything with non-compliant DCIDs, so this is irrelevant. With dynamic allocation, it means that the LB will allocate an SID that the server doesn't know anything about, until: 1) the allocation times out 2) the LB has the occasion to forward another packet with that SID to the server when the server has the configuration. I don't feel strongly about this, but it works for me. If you want to file a PR with this change I'd approve it.
In PR I suggested non-routable, though I realize non-conformant may also be an option. The sentence which caused me to suggest non-routable is: URL I'm happy to write a PR if others find non-compliant potentially confusing as well.
I like it. Let's go with it.
Change:
QUIC Stream ID for a client-initiated bidirectional stream encoded as a variable-length integer.  A client MUST treat receipt of a GOAWAY frame containing a Stream ID of any other type as a connection error <del> of type HTTP_WRONG_STREAM. </del> <ins> of type HTTP_MALFORMED_FRAME. </ins> Clients do not need to send GOAWAY to initiate a graceful shutdown; they simply stop making new requests.  A server MUST treat receipt of

Discussion:
I'm pretty sure the intent of URL was correct but the wrong error was changed in the draft. This pr makes the change that I think was intended in URL
Just a note. If this is the right answer and the PR lands, then will need to replace the new instance of HTTPMALFORMEDFRAME with something, e.g. HTTPINVALIDGOAWAY or something
Yeah, that crossed my mind. :-) YAEC!
In , NAME correctly observed that I messed up , but he closed his PR and I'm not able to reopen it without more git wizardry than I'm interested in practicing today. Easier just to fix it in my own branch.
Change:
Verify that the resulting URI is well-formed. <del> If the client has supplied an address to use, verify that the address is included in the A or AAAA records to which the domain name resolves.  If the address is not included in the result, the validation fails. Dereference the URI using an HTTP GET request.  If an address was supplied by the client, use that address to establish the HTTP connection. </del> <ins> Dereference the URI using an HTTP GET request. </ins> Verify that the body of the response is well-formed key authorization.  The server SHOULD ignore whitespace characters at

Discussion:
This reverts commit a5cb357a64ce5e46815544c9faaf94b97b3eba56 I think we did not reach consensus on the list about this feature.
Oh, it's a shame that this was removed. I was hoping to use this feature to help when my servers were behind a load balancer. We should probably remove this reference as well:
Change:
the key config specifies a KEM, KDF, or AEAD algorithm the client doesn't recognize. <ins> Aggregators SHOULD use HTTP caching to permit client-side caching of this resource RFC5861.  Aggregators SHOULD favor long cache lifetimes to avoid frequent cache revalidation, e.g., on the order of days. Aggregators can control this cached lifetime with the Cache-Control header, as follows: </ins> Clients SHOULD follow the usual HTTP caching RFC7234 semantics for <del> key configurations.  Aggregators SHOULD favor long cache lifetimes to avoid frequent cache revalidation. </del> <ins> key configurations. </ins> Note: Long cache lifetimes may result in clients using stale HPKE keys; aggregators SHOULD continue to accept reports with old keys for <del> a reasonable period after key changes in order to avoid rejecting reports.  [[OPEN ISSUE: https://github.com/abetterinternet/prio- documents/issues/106]] </del> <ins> at least twice the cache lifetime in order to avoid rejecting reports. </ins> 4.2.2.

Discussion:
It seems silly to have clients revalidating the HPKE key for each request, so we probably want some kind of caching. I'm not sure HTTP Caching is quite what we want, but something... NAME NAME recommendations?
I'm going to need a little more context to provide good advice. If we don't need key consistency (it doesn't appear so) and you only need correctness, then the client should just be able to talk directly to the collector and get keys periodically. HTTP caching works fine for that purpose. This would also need a rejection message so that the collector (or the leader on their behalf - the leader is more likely to learn about bad key identifiers before clients) can reject an out-of-date key in case the cache needs to be invalidated.
We do not need key consistency. The rejection message seems like a good idea.
Change:
willing to receive, which, when intersected with the set of codecs the remote side supports, specifies what the remote side should send. However, not all parameters follow this rule; some parameters are <del> declarative, and the remote side MUST either accept them or reject </del> <ins> declarative, and the remote side must either accept them or reject </ins> them altogether.  An example of such a parameter is the TLS fingerprints RFC8122 as used in the context of DTLS RFC6347; these fingerprints are calculated based on the local certificate(s) offered

Discussion:
…or already fixed. NAME Change in normative text (previous ART AD requested it), please review.
LGTM, approved.
eom
LGTMOne minor comment.
Change:
Despite the following behavior being misguided, experience has shown that some customers use the IANA registry as a checklist against which to measure an implementation's completeness, and some <del> implementers blindly implement supported group.  Therefore, IANA [SHALL add/has added] the following warning to the registry: </del> <ins> implementers blindly implement supported group.  Therefore, IANA has added the following warning to the registry: </ins> IANA [SHALL update/has updated] the reference for this registry to <del> also refer to this document. </del> <ins> refer to this document instead of RFC8447. </ins> The value 0 (0x0000) has been marked as reserved.

Discussion:
Tweaks for Supported Groups. We still need to figure out what to do with curves smaller than 256.
Change:
"inclusion_proofs" to confirm that the key commitment has been submitted to a trusted registry.  Once the client receives the "ciphersuite" for the server, it should implement all Privacy Pass <del> API functions (as detailed in draft-davidson-pp-protocol) using this ciphersuite. </del> <ins> API functions (as detailed in draft-ietf-privacypass-protocol) using this ciphersuite. </ins> 5.

Discussion:
Initial work for fixing .
NAME
As discussed during IETF 110, the architecture document should provide guidance on how redemption contexts can be used and how they impact privacy. This is a bit of the calculus we don't yet have. cc NAME NAME
Yeah, this likely needs to be embedded both into the Architecture draft for the generic concept of a context, and then an actual instantiation of redemption contexts in the HTTP API doc.
Yep should we split out the HTTP work into a separate issue?
Thanks NAME This looks good, I have mostly just a few nits to resolve.
Change:
8.1.2.1. The Message Framer object can be added to one or more Preconnections <del> to run on top of transport protocols.  Multiple Framers may be added. If multiple Framers are added, the last one added runs first when framing outbound messages, and last when parsing inbound data. </del> <ins> to run on top of transport protocols.  Multiple Framers may be added to a preconnection; in this case, the Framers operate as a framing stack, i.e. the last one added runs first when framing outbound messages, and last when parsing inbound data. </ins> The following example adds a basic HTTP Message Framer to a Preconnection: <ins> Since Message Framers pass from Preconnection to Listener or Connection, addition of Framers must happen before any operation that may result in the creation of a Connection. </ins> 8.1.2.2. When sending Messages, applications can add Framer-specific key/value

Discussion:
How do framers behave in connection groups? I.e. do all connections share one framer object or does the framer object get duplicated when a connection gets cloned? If it does get duplicated, does it keep its current state? This might mostly be an implementation detail but I think it should be mentioned in section 6.4 of API.
Interim: same type of framer is plausible default (but new instances), but in general a framer should be per connection. State is not shared across connections. Bigger problem: framers are added to preconnections, not connections, so how is this done with cloning? (perhaps: add list of framers as parameter added to the clone call)
I've thought about it, and Idon't think we actually have a bigger problem here: On an initiated Connection/ConnectionGroup, the provenance of the Framers is Preconnection.AddFramer() -> Preconnection.Initiate(). On a Listener, the provenance of the Framers is Preconnection.AddFramer() -> Preconnection.Listen() -> Listener.Clone(). In a Rendezvous situation, there is (unless I'm missing something) always a Preconnection from which a Framer can ultimately be inherited.
In §8.1.2 ¶3, the doc says: but this doesn't seem to be conceptually compatible with the text at the top of §8.1.2.1, which says: I think the way most developers would think about this is as a pipeline: you feed data into the top-level framer with Send, which then percolates downward through the pipeline to the bottom-level framer, which then sends it to the transport.
I think this should be easy to address, by rephrasing: as: ... BUT "call each other" is surely a terrible way to put this, and there must be a way to say this cleanly and neatly, in line with how the code really goes. THIS, I suspect, is a very simple thing for NAME to do, and hence I assigned it to him.
Change:
receiver's buffer capacity for the connection, by limiting the total bytes of stream data sent in STREAM frames on all streams. <del> Senders MUST not send data in excess of either limit. </del> <ins> Senders MUST NOT send data in excess of either limit. </ins> A receiver sets initial limits for all streams by sending transport parameters during the handshake (transport-parameters).  A receiver

Discussion:
Noticed while reading text for a different issue; this appears to be the only instance of this construction in the documents.
Change:
There are certain factors that arise in operational reality that operators of ACME-based CAs will need to keep in mind when <del> configuring their services. </del> <ins> configuring their services.  For example: It is advisable to perform DNS queries via TCP to mitigate DNS forgery attacks over UDP </ins> [[ TODO: Other operational considerations ]]

Discussion:
I've noticed that boulder uses DNS over TCP. I suppose this has not been an arbitrary choice, but something that would be useful to document.
As an FYI, Boulder currently uses TCP for DNS to its local authoritative resolver, but the resolver uses UDP. We tried making the resolver do upstream resolution with TCP but got a large number of failures.
Change:
can also be specified during data transfer to affect specific Messages. <del> Connection: A Connection object represents one or more active transport protocol instances that can send and/or receive Messages between Local and Remote Endpoints.  It is an abstraction that represents the communication.  The Connection object holds state pertaining to the underlying transport protocol instances and any ongoing data transfers.  For example, an active Connection can represent a connection-oriented protocol such as TCP, or can represent a fully-specified 5-tuple for a connectionless protocol such as UDP, where the Connection remains an abstraction at the endpoints.  It can also represent a pool of transport protocol instances, e.g., a set of TCP and QUIC connections to equivalent endpoints, or a stream of a multi-streaming transport protocol instance.  Connections can be created from a Preconnection or by a Listener. </del> Listener: A Listener object accepts incoming transport protocol connections from Remote Endpoints and generates corresponding Connection objects.  It is created from a Preconnection object

Discussion:
Review comment: Section 4.1.2 : I would describe the object first and then the transport properties. In the current arrangement when properties are described it mentions Connection which is described just later. Also transport properties here are kind of repetition of what we have in Section 3.1. reordered descriptions, which also to me at least, seems to make the text on properties better relate to the action
These comments are good to be addressed to improve the document, however, they can be done as part of IETF last call as well
Fixes proposed in PRs , , , ,
LGTM