jiebi/CodeConvo huggingface dataset:
Code change:
MUST send the quic_transport_parameters extension; endpoints that receive ClientHello or EncryptedExtensions messages without the quic_transport_parameters extension MUST close the connection with an <del> error of type 0x16d (equivalent to a fatal TLS missing_extension </del> <ins> error of type 0x016d (equivalent to a fatal TLS missing_extension </ins> alert, see tls-errors). Transport parameters become available prior to the completion of the

Related discussion:
text: One possible resolution to ; all literals are zero-padded to full bytes.
IANA made the following observation while creating the H3 registries: While the IANA copy of the registry uses two digits throughout, the QUIC draft is similarly inconsistent about whether literal hex values have any leading zeros. Is it worth updating our hex literals to use full bytes (, , etc.) or synchonizing on some other format? We probably shouldn't synchronize on trimming, since IANA has already skewed the other way.
NAME did fix this or do we need to inform IANA also?
We should probably shoot IANA an e-mail to update the registries with leading zeroes where they hadn't already assumed them.
I'll let you do that. The only registries that are affected are in HTTP/3 and QPACK.
Fixed both in the registry and the documents.
Yeah, this is easy to understand. The tables must have been annoying.
Code change:
in the "PreSharedKeyID" object.  Specifically, "psk_secret" is computed as follows: <del> Here "0" represents the all-zero vector of length KDF.Nh.  The </del> <ins> Here "0" represents the all-zero vector of length "KDF.Nh".  The </ins> "index" field in "PSKLabel" corresponds to the index of the PSK in the "psk" array, while the "count" field contains the total number of PSKs.  In other words, the PSKs are chained together with KDF.Extract

Related discussion:
text: Right now, the vector is described in a couple of ways. This PR standardizes on "of length ".
Code change:
attribute MUST NOT be specified. If the RTP/RTCP multiplexing policy is "require", each m= section <del> MUST contain an "a=rtcp-mux" attribute. </del> <ins> MUST contain an "a=rtcp-mux" attribute.  If an "m=" section contains an "a=rtcp-mux-only" attribute then that section MUST also contain an "a=rtcp-mux" attribute. </ins> If this session description is of type "pranswer" or "answer", the following additional checks are applied:

Related discussion:
text: I applied the following principles, which unfortunately are somewhat inconsistent with the current mux-exclusive draft. You use a=rtcp-mux to negotiate mux a=rtcp-mux-only is used by the offerer to say "I really mean it" To that end, offers contain a=rtcp-mux-only if the policy is require. Answers don't contain it because you don't need it to negotiate mux.
Those principles are consistent with bundle-only, although I wrote the mux-only examples as if mux-only should always be included whenever a=rtcp-mux is present.
NAME back at you
NAME ping
LG
Code change:
The TLS handshake establishes one or more input secrets which are combined to create the actual working keying material, as detailed <del> below.  The key derivation process makes use of the following functions, based on HKDF RFC5869: </del> <ins> below.  The key derivation process makes use of the HKDF-Extract and HKDF-Expand functions as defined for HKDF RFC5869, as well as the functions defined below: </ins> Given a set of n InputSecrets, the final "master secret" is computed by iteratively invoking HKDF-Extract with InputSecret_1, <del> InputSecret_2, etc.  The initial secret is simply a string of 0s as long as the size of the Hash that is the basis for the HKDF. </del> <ins> InputSecret_2, etc.  The initial secret is simply a string of zeroes as long as the size of the Hash that is the basis for the HKDF. </ins> Concretely, for the present version of TLS 1.3, secrets are added in the following order:

Related discussion:
text: Some small tweaks and fixes for issue : Move HKDF-Extract citing to a sentence and bring HKDF-Extract with it. Change the Messages arg to HashValue, as the actual hashing is stated in the definition of Derive-Secret which is passing this function a hash, not messages. (fixes issue ) More concise defining of HkdfLabel. Use the word "zeroes" instead of "0s". Edited to add: Also, appended a commit to fix an extra trailing paren.
The other possibility is that a hash of the concatenation of hashes was to be the new HashValue. Simplest change is just to make the arg for what's currently used in the definition and passed in.
NAME Rebased. Is this ok to merge now?
It never actually says that hash_value is H(messages).
This should be clear now.
Code change:
how to process them from format also apply to HTTP/3 datagrams sent and received using the DATAGRAM capsule. <ins> The DATAGRAM Capsule is transparent to intermediaries, meaning that intermediaries MAY parse it and send DATAGRAM Capsules that they did not receive.  This allows an intermediary to reencode HTTP/3 Datagrams as it forwards them: in other words, an intermediary MAY send a DATAGRAM Capsule to forward an HTTP/3 Datagram which was received in a QUIC DATAGRAM frame, and vice versa. Note that while DATAGRAM capsules are sent on a stream, intermediaries can reencode HTTP/3 datagrams into QUIC DATAGRAM frames over the next hop, and those could be dropped.  Because of this, applications have to always consider HTTP/3 datagrams to be unreliable, even if they were initially sent in a capsule. </ins> 5. In order to facilitate extensibility of contexts, the

Related discussion:
text: NAME points out that in order to correctly forward DATAGRAMs between transports where the QUIC DATAGRAM frame isn't always available, intermediaries need the ability to parse some capsules.
CAPSULE was easier to understand when it was fully opaque. When should I choose to define a semi-opaque CAPSULE vs defining a new frame? Aren't both constructs effectively hop-by-hop?
NAME you're the one who asked for this :-) The benefit of a semi-opaque capsule is that it allows defining new capsules without having to update every single intermediary in the chain, because intermediaries forward all unknown capsules.
Code change:
respectively. In order to achieve the privacy and security goals of the protocol a <del> also needs to observe the guidance in client-responsibilities. </del> <ins> also needs to observe the guidance in sec-client. </ins> The interacts with the as an HTTP client by constructing a request using the same restrictions as the request, except that the target

Related discussion:
text: Why is it that media type registration is a journey of discovery each and every time? It's like the coastline paradox: the closer you get, the more detail resolves. Also, each requirement makes sense in isolation, but if you need an entire RFC to explain it, maybe something has gone wrong.
no strong feelings on this one.
Code change:
A TLSCiphertext record was received that had a length more than <del> 2^14+256 bytes, or a record decrypted to a TLSPlaintext record </del> <ins> 2^14 + 256 bytes, or a record decrypted to a TLSPlaintext record </ins> with more than 2^14 bytes.  This alert is always fatal and should never be observed in communication between proper implementations (except when messages were corrupted in the network).

Related discussion:
text: NAME Quick PR for fix noted for PR plus a couple other small nits. Still on draft 08. Fix a typo. ("permittion" is not a word) Consistently use spaces around the "+" in "2^14 + 256". (some did; some didn't)
Code change:
process the Commit (i.e., not including any members being added or removed by the Commit). <ins> The sender of a Commit SHOULD NOT include any Update proposals that the sender themselves generated.  If sender generated one or more Update proposals during an epoch, then it SHOULD instead update its leaf and direct path by sending "path" field in the Commit. </ins> If there are multiple proposals that apply to the same leaf, the committer chooses one and includes only that one in the Commit, considering the rest invalid.  The committer MUST prefer any Remove

Related discussion:
text: Any Update proposal for the sender is redundant if the Commit includes a .
This is true, but they're also harmless, since the information in the will overwrite all of their effects. Note that: A requirement to this effect would only be binding on a committer. The receiver of a Commit MUST process all of the referenced proposals, as prescribed in the Commit. A is required if a Commit covers Updates or Removes; if a Commit covers a self-Update, then it must have a . So there's no reasn to condition on "if a is included". This seems fine for some advisory text, but not an absolute prohibition.
The way I read Section 11.2 is that the receiver should verify that the committer has followed the rules, e.g. that the commit contains all valid proposals, etc., even if that is not explicit in the list of things the receiver of a commit should do. So any requirement on the committer would also affect the receiver. So if we mandate that a committer can't include self-updates if the path is populated, then it would be implicit that the receiver checks that the committer actually followed the rules when processing a commit. I'm not sure I understand your second point. My reasoning would be that if a committer wants to do an update, they would just include a path rather than an update proposal, which is redundant anyway.
Sorry NAME I missed that there was still conversation going on here before merging . On the latter point: All I'm saying is that there is no case where there is both (a) a self-update and (b) no . So you're always in the bad scenario :) In our Wire chat, you made a good point that repeated proposals for the same leaf are invalid, and self-Updates are effectively repeats of the . Reopening, will file a fresh PR to adjust the text.
Code change:
protocols and paths without requiring major changes to the application. <del> design explains the design principles behind the Transport </del> <ins> requirements explains the fundamental requirements for a Transport </ins> Services API.  These principles are intended to make sure that transport protocols can continue to be enhanced and evolve without <del> requiring too many changes by application developers. </del> <ins> requiring significant changes by application developers. </ins> concepts presents the Transport Services architecture diagram and defines the concepts that are used by both the API and

Related discussion:
text: I think it would also be useful to somehow better explain that in figure 3 the API function is ONE part of the system.
See linked PR first please to see if this resolves this?
A PR was merged that addressed important text issues with separation of requirements and overview, and should more clearly set out that the requirements are for the system. The question of whether the overall TAPS systems requirements belong in this ID; the API; or a separate RFC needs some discussion based on the review, before this can be closed.
Many good text improvements in the PR NAME but I noticed two smaller updates in the PR that I think were incorrect. Fixed in
The review comment showed were many places where the wording of architecture can be improved. There are some high level principles that I think should remain in the architecture document. The decision in today's interim is to review the architecture to get this more into a shape that is valuable as a reference, and then check the updated draft.
I now suggest the issues are addressed and we close this issue without moving text between documents
I agree with that; closing.
Overall review: I think we need to keep the normative language for the key features that differentiate the API. I'd really like to use REQUIRED, RECOMMENDED, rather MUST and SHOULD - because these are not protocol operation requirements, but are implementation requirements to conform. This includes requirements based on Minset - where the WG dervied this API: This is after all why the WG worked on Minset as the basis of the API. I suggest we group all the requirements on architecture as short one or two sentence blocks (preferably as a bullet or definition list) collected into a single subsection, so they are easy to find and read and we say that these are the key architectural requirements. We insert this new requirements text either their own section, or in section 1.3 (although I am open to other places where we can call-out the architectural requirements). The following are key requirements, that define the TAPS architecture: It is RECOMMENDED that functionality that is common across multiple transport protocols is made accessible through a unified set of TAPS interface calls. As a baseline, a Transport Services system interface is REQUIRED to allow access to the minimal set of features offered by transport protocols {{?I-D.ietf-taps-minset}}.
Code change:
protocols and paths without requiring major changes to the application. <del> design explains the design principles behind the Transport </del> <ins> requirements explains the fundamental requirements for a Transport </ins> Services API.  These principles are intended to make sure that transport protocols can continue to be enhanced and evolve without <del> requiring too many changes by application developers. </del> <ins> requiring significant changes by application developers. </ins> concepts presents the Transport Services architecture diagram and defines the concepts that are used by both the API and

Related discussion:
text: This is intended to provide predictable outcomes to the application using the transport service. I would then suggest to use lower case within other parts of the document - except were pointed to from here, (we could refer to the requirements subsection, if we thought necessary).
for discussion at the interim, but IMO we could start the interim with a PR based on these suggestions and work from there.
I suspect that we need more protocol-specific properties to be able to talk to various kinds of native protocol peers (other than TCP and UDP: these should already work fine with what we have, I believe). A concrete example: we're hiding stream numbers. In NEAT, we needed to make them configurable though, because we wanted a NEAT client to be able to talk to a native SCTP server, where an application may expect certain type of data to arrive via a certain stream number. I suspect that we may need something similar for a QUIC peer. Should we address this? (I'd say yes) How .. is it a protocol-specific (per-Message) property? (I'd say yes... and perhaps a per-Connection property too, with text explaining that the per-Message one automatically becomes the Connection default unless otherwise specified) What other such things are we missing... what other expectations may e.g. a native QUIC or SCTP application have that we just cannot fulfil with our current system?
Code change:
Server.  On the other hand, if the HNA signs the Homenet Zone itself, the zone would be collected by the Synchronization Server and directly transferred to the Public Authoritative Server(s).  These <del> policies are discussed and detailed in sec-dnssec-deplyment and sec- views. </del> <ins> policies are discussed and detailed in sec-dnssec-deplyment. </ins> 4.2.

Related discussion:
text: …ument, dealing with issue
handling different views (7.0) .... some would like to have different views, This document deals with the view that the Internet gets from the CPE(s) only.
Code change:
Unlike CONNECT-UDP requests, which require specifying a target host, CONNECT-IP requests can allow endpoints to send arbitrary IP packets to any host.  The client can choose to restrict a given request to a <del> specific host or IP protocol by adding parameters to its request. When the server knows that a request is scoped to a target host or </del> <ins> specific prefix or IP protocol by adding parameters to its request. When the server knows that a request is scoped to a target prefix or </ins> protocol, it can leverage this information to optimize its resource allocation; for example, the server can assign the same public IP <del> address to two CONNECT-IP requests that are scoped to different hosts and/or different protocols. </del> <ins> address to two CONNECT-IP requests that are scoped to different prefixes and/or different protocols. </ins> CONNECT-IP uses URI template variables (client-config) to determine the scope of the request for packet proxying.  All variables defined

Related discussion:
text: Instead of just an address / hostname, could we ask to open a tunnel to a prefix?
Tommy, can you please clarify the reasoning why this functionality is useful. Specifying the target as a subnet would to my understanding compared to a general IP tunneling address just restrict that the client will never try to send IP packets to any IP addresses outside of this subnet. And thus potentially enable serving multiple masque clients using restricted targets to share the source IP address. Is that the intention? Or is the intention here to have the masque server potentially redirect to another instance based on the target in the request?
This came up in a discussion—if we let you ask to connect to a specific hostname or address instead of all addresses (as we do today), we wondered if there was any need to connect to a subnet of addresses. This would be for connecting to an IPv6 /64, which is unique enough for a device, and doesn't require needing to assign an IP address exclusively to the client that is issuing the request.
I'm supportive of adding this if we can come up with an encoding that's not a pain to implement. For example slash with prefix length seems fine to me - the slash would be percent-encoded just like the IPv6 address colons are.
In relation to my just raised issue on source address validation if we add this functionality, I would think that the proxy would need to do destination or source address validation depending on direction of traffic to enforce the signalled aspect.
Code change:
If the server sends a Retry packet, it MUST use the original version. The client ignores Retry packets using other versions.  The client <del> MUST NOT use a different version in the subsequent Initial that contains the Retry token.  The server MAY encode the QUIC version in its Retry token to validate that the client did not switch versions, and drop the packet if it switched. </del> <ins> MUST NOT use a different version in the subsequent Initial packet that contains the Retry token.  The server MAY encode the QUIC version in its Retry token to validate that the client did not switch versions, and drop the packet if it switched. </ins> QUIC version 2 uses the same transport parameters to authenticate the Retry as QUIC version 1.  After switching to a negotiated version

Related discussion:
text: here (URL) it is better that we call it QUIC version 1 not just QUIC. As later it is referred as QUIC version 1.here (URL) I would add reference to VN draft instead of calling it "that document"here (URL) i would add "packet" after "Initial" just to be clear, as we have now a initial version in VN draft.
Thanks, fixed here URL
Code change:
4.3.1. <del> An endpoint can use the critical Default-Uri-Host Option to indicate the default value for the Uri-Host Options in the messages that it sends to the other endpoint.  Its value MUST be a valid value for the Uri-Host Option (Section 5.10.1 of RFC7252). For TLS, the base value for the Default-Uri-Host Option in the direction from the Connection Initiator to the Connection Acceptor is given by the SNI value. For WebSockets, the base value for the Default-Uri-Host Option in the direction from the Connection Initiator to the Connection Acceptor is given by the HTTP Host header field. The active value of the Default-Uri-Host Option is replaced each time the option is sent with a modified value.  Its starting value is its base value (if available). 4.3.2. </del> The sender can use the elective Max-Message-Size Option to indicate the maximum message size in bytes that it can receive.

Related discussion:
text: The next pass will add text related to the default URI-Host for TLS SNI cases.
Code change:
This document Both <ins> 7.5. The following entry is added to the "HTTP/3 Error Code" registry established by HTTP3: H3_WEBTRANSPORT_BUFFERED_STREAM_REJECTED 0x3994bd84 WebTransport data stream rejected due to lack of associated session. This document. </ins>

Related discussion:
text: .
cc NAME NAME
Looks great!
For a simple application that wants to send "hello world" over a WebTransport stream, it would take a minimum of 2.5 round trips for the data to arrive on the server. This is still an improvement over WebSockets but I'm wondering if we could do better. If the client is able to create streams prior to receiving the CONNECT response, then it would remove a round trip. The server would need to buffer any data received on streams associated with an unknown WebTransport session. If the server responds with a non-200 status code, then these streams are discarded. I believe 0-RTT is disabled for WebTransport because CONNECT is not idempotent and would be subject to replay attacks. An idempotent CONNECT would remove a round trip when 0-RTT is used... although I'm not sure this is a good idea.
I think this is a reasonable optimization
The client requirement is odd in comparison to MASQUE / CONNECT-UDP which says "client can risk sending datagrams before getting a 200 response, a different response means that datagrams will be discarded". What is the motivation for the requirement in WebTransport? If you need some kind of ordering guarantees, then stream IDs provide that.
Discussed at IETF 110. There were no objections to buffering (with some limits), so I think we should go ahead and add it.
After the client initiates the WebTransport session by sending a CONNECT request, the server sends a 200 response and is free to create streams. This means that a server-initiated stream may arrive prior to the CONNECT response. Is the client able to infer that the session was successfully established, or does the client need to buffer this stream until it receives a proper response?
Since there are no ordering guarantees across streams on the receiver side, I'd say you have to buffer until the 200 is processed.
I agree with Lucas here. We also had a similar problem in QuicTransport (server has to buffer streams before checking the origin), and we handled it by buffering.
Discussed at IETF 110. There were no objections to buffering (with some limits), so I think we should go ahead and add it.
Code change:
for the "encrypted_client_hello" extension.  Clients MUST ignore any "ECHConfig" structure with a version they do not support. <del> The length, in bytes, of the next field. </del> <ins> The length, in bytes, of the next field.  This length field allows implementations to skip over the elements in such a list where they cannot parse the specific version of ECHConfig. </ins> An opaque byte string whose contents depend on the version.  For this specification, the contents are an "ECHConfigContents"

Related discussion:
text: The goal here is really to provide more clarify about cardinality, if there's a better way or place to do that, that'd be fine.
I don't believe this is necessary. This idiom is well understood in TLS and this just appears to be excess verbiage.
Hiya, (As with all these PRs, I'm ok if they're not accepted...) For me, that is better than the original, but I do think we ought state the expected cardinality that implementers need to handle somewhere. I reckon it's better to not assume implementers are very familiar with SVCB as for libraries at least, the DNS stuff happens elsewhere. They will have to figure that out eventually, but better to say it somewhere explicitly I think, or we may face some important code base that doesn't handle >1 public key when it ought. Cheers, S.