jiebi/CodeConvo huggingface dataset:
Code change:
3.3.2. <del> For each URL "[helper]" in "PAUploadStartResp.helper_urls", the client sends a GET request to "[helper]/key_config".  The helper responds with status 200 and an "HpkeConfig" message.  Next, the client collects the set of helpers it will upload shares to.  It ignores a helper if: </del> <ins> Let "[helper]" denote the helper URL encoded by "PAUploadStartResp.param.helper_url".  When a client sends a GET request to "[helper]/key_config", the helper responds with status 200 and an "HpkeConfig" message.  The client aborts if any of the following happen: </ins> the client and helper failed to establish a secure, helper- authenticated channel;

Related discussion:
text: Partially addresses . (We also need to decide if/how to allow a particular PA protocol to use multiple helpers for privacy.) Right now, multiple helpers are used for redundancy in case one of the helpers dropped out. This removes this mechanism from the core protocol.
Squashed and rebased.
That's a good idea,
Hmm... Do we need to decide. Per our discussion on Wednesday, if the clients learn this out of band then we won't need this field at all because clients will get it separately and helpers don't need to know what the other helpers are, right?
My takeaway is that the parameters must contain all input needed to run the protocol, including the helpers. And all of this is configured out of band. You could punt everything except for the cryptographic goop out of the parameters structure, forcing clients to know the leader and helper and get their public keys out of band as well, which would be fine. It's just different. I think both work just fine, but I lean towards having params specify everything. It just seems simpler to me. That said... making public key discovery part of the client upload protocol here is more complex, I think. So, .
Squashed.
LGTM. Multiple helpers "for privacy" seems like it's inherently a per-protocol thing (Prio supports it, Hits does not). If and when we decide to address that, should we move this to the protocol-specific slot in PAParam?
Code change:
RFC EDITOR PLEASE DELETE THIS SECTION. <ins> draft-07 Initial version of the Tree based Application Key Schedule (*) Initial definition of the Init message for group creation (*) Fix issue with the transcript used for newcomers (*) Clarifications on message framing and HPKE contexts (*) </ins> draft-06 Reorder blanking and update in the Remove operation (*)

Related discussion:
text: Update change log for draft-07 No conflicting PRs so I did break many lines that were too long. Fix a few minor editorial issues after merging the tree-based application key schedule.
Code change:
The format provides a generalized way to attach any additional information to the timestamp. <ins> We refer to this format as the Internet Extended Date/Time Format (IXDTF). </ins> This document does not address extensions to the format where the semantic result is no longer a fixed timestamp that is referenced to a (past or future) UTC time.  For instance, it does not address:

Related discussion:
text: We need a name that people will use until they can say RFC9999 timestamps (and maybe even when they can).
"Extended Timestamps" or "Extended Internet Timestamps" ?
RFC 3339 says "Internet Date/Time Format". That is what sedate says at the moment as well, but that can't stay the same. So I'm considering moving to: Internet Date/Time Format Extended The alternative .... Extended Internet Date/Time Format sounds like a date/time format for the Extended Internet (EI is actually in use as "Extensible Internet", which this shouldn't be confused with). I'd rather call it Fritz, but I haven't found a way to retronym this...
Thanks
Code change:
header field names proliferates. <del> Client applications interfacing with different servers may thus need to process different headers, or the very same application interface </del> <ins> User Agents interfacing with different servers may thus need to process different headers, or the very same application interface </ins> that sits behind different reverse proxies may reply with different throttling headers.

Related discussion:
text: Improves terminology
In other parts of the document we still use client as we are not sure whether to refer explicitly to a User Agent or not. Ideas welcome...
See RFC 7230 terminology definitions (, not changing in the new specs, FWIW).
Code change:
By virtue of the definition of the data stream, the Capsule Protocol is not in use on responses unless the response includes a 2xx <del> (Successful) status code.  The Capsule Protocol MUST NOT be used with messages that contain Content-Length or Transfer-Encoding header fields. </del> <ins> (Successful) status code. The Capsule Protocol MUST NOT be used with messages that contain Content-Length, Content-Type, or Transfer-Encoding header fields. Additionally, HTTP status codes 204 (No Content), 205 (Reset Content), and 206 (Partial Content) MUST NOT be sent on responses that use the Capsule Protocol. </ins> 4.2. <del> Definitions of new HTTP Methods or of new HTTP Upgrade Tokens that use the Capsule Protocol MAY use the Capsule-Protocol header field to simplify intermediary processing. </del> <ins> Definitions of new HTTP Upgrade Tokens that use the Capsule Protocol MAY use the Capsule-Protocol header field to simplify intermediary processing. </ins> "Capsule-Protocol" is an Item Structured Header RFC8941.  Its value MUST be a Boolean.  Its ABNF is:

Related discussion:
text: The only scenario that might benefit an attacker is where the elision of datagrams (or things that look like them) might be used to evade security protections that scan the stream of data. For an attack to be effective, those same protections would have to be ignorant of datagram forwarding behaviour at the same intermediary. This binding to CONNECT is a useful shortcut that means we don't need to engage with all that stuff, which wouldn't be that easy to write down. (This aversion to engagement is, I believe, a large part of why people want to slap "Sec-" on all new headers.)
MT's framing of this is helpful. Adding some security consideration about what might go wrong for an intermediary seems potentially useful. Spending text on why a browser is special in this regard seems less compelling to nme.
I was about to write a PR for this, but I think we should first If we decide that capsules are only allowed for HTTP upgrade tokens (and not new methods) then we've restricted ourselves to CONNECT and Upgrade which are both inaccessible from JavaScript.
LGTM thanks
Code change:
All HTTP/3 requests MUST include exactly one value for the ":method", ":scheme", and ":path" pseudo-header fields, unless it is a CONNECT <del> request (connect).  An HTTP request that omits mandatory pseudo- header fields or contains invalid values for those fields is malformed (malformed). </del> <ins> request (connect). If the ":scheme" pseudo-header field identifies a scheme which has a mandatory authority component (including "http" and "https"), the request MUST contain either an ":authority" pseudo-header field or a "Host" header field.  If these fields are present, they MUST NOT be empty.  If both fields are present, they MUST contain the same value. If the scheme does not have a mandatory authority component and none is provided in the request target, the request MUST NOT contain the ":authority" pseudo-header and "Host" header fields. An HTTP request that omits mandatory pseudo-header fields or contains invalid values for those fields is malformed (malformed). </ins> HTTP/3 does not define a way to carry the version identifier that is included in the HTTP/1.1 request line.

Related discussion:
text: So should we say that the target authority MUST be present in either "Host" or ":authority", or do we leave it alone?
Well, assuming we still allow requests for URIs that do not have an authority component (e.g, a URN or similar), I think it is better to just leave it alone. OTOH, folks are still going to ask what needs to be sent when the request target doesn't have an authority component, so that ought to be defined somewhere here more sensibly than it was for 1.1.
Discussed in ZRH. Proposed resolution is that if a URI scheme has a mandatory component, it better have one of those two things, preferably a :authority. Alert httpbis.
Doesn't this beg the question "what if the request is for a URI that does not have a mandatory authority component?" All of the other cases are described. I would add something like: Thanks!
Code change:
(method equals 2 or 3), then mac_length_3 is the EDHOC MAC length of the selected cipher suite.  If the Initiator authenticates with a signature key (method equals 0 or 1), then <del> mac_length_3 is equal to the output size of the EDHOC hash algorithm of the selected cipher suite. </del> <ins> mac_length_3 is equal to hash_length. </ins> ID_CRED_I - identifier to facilitate the retrieval of CRED_I, see

Related discussion:
text: I strongly think that all 10 EDHOC-KDF should be in the same table The text about maclengthx need to use the defined term hash_length
I made one commit for review.
Code change:
constants-of-interest) for a new path, but the delay SHOULD NOT be considered an RTT sample. <del> Prior to handshake completion, when few to none RTT samples have been generated, it is possible that the probe timer expiration is due to an incorrect RTT estimate at the client.  To allow the client to improve its RTT estimate, the new packet that it sends MUST be ack- eliciting. </del> Initial packets and Handshake packets could be never acknowledged, but they are removed from bytes in flight when the Initial and Handshake keys are discarded, as described below in discarding-

Related discussion:
text: PTO packets always have to be ACK-eliciting, not just during the handshake, per existing text: "When a PTO timer expires, a sender MUST send at least one ack-eliciting packet in the packet number space as a probe,..." Also removed an "unless" clause, because if there's nothing to send, you don't arm the PTO timer.
Code change:
obtained via some other mechanism such as being configured in the Verifier by an administrator. <del> For example, for some claims the Verifier might check the values of claims in the Evidence against constraints specified in the Appraisal Policy for Evidence.  Such constraints might involve a comparison for equality against reference values, or a check for being in a range bounded by reference values, or membership in a set of reference values, or a check against values in other claims, or any other test. Such reference values might be specified as part of the Appraisal Policy for Evidence itself, or might be obtained from a separate source, such as an Endorsement, and then used by the Appraisal Policy for Evidence.  The actual data format and semantics of a known-good value are specific to claims and implementations.  There is no general purpose format for them or general means for comparison defined in this architecture document.  Similarly, for some claims the Verifier might check the values of claims in the Evidence for membership in a set, or against a range of values, or against known- bad values such as an expiration time.  These reference values may be conveyed to the Verifier as part of an Endorsement or as part of Appraisal Policy or both as these are the two input paths to the Verifier. </del> The Relying Party uses Attestation Results by applying its own Appraisal Policy to make application-specific decisions such as authorization decisions.  The Attestation Result Appraisal Policy

Related discussion:
text: Previously the text was specific to policy for Evidence, but the same applies to policy for appraising Attestation Results, so generalizing the text. This also removes a redundant sentence where older text and newly merged text from this morning said the same thing. And the diffs look larger than they really are, since some text was just moved around to be in a different order. Signed-off-by: Dave Thaler
Code change:
the "extensions" field of a LeafNode object with the "application_id" extension. <del> However, applications SHOULD NOT rely on the data in an </del> <ins> However, applications MUST NOT rely on the data in an </ins> "application_id" extension as if it were authenticated by the Authentication Service, and SHOULD gracefully handle cases where the identifier presented is not unique.

Related discussion:
text: URL This definition of a handshake message is being defined in terms of a Proposal or Commit object, neither of which are defined in this session. Furthermore, PublicMessage or PrivateMessage aren’t defined either as this point in the text. To improve clarity, consider defining these key terms. The use of "respectively" in the text is suggesting that PrivateMessages don’t have integrity protection which is not accurate. (see the Cryptographic Dependencies section of the HPKE specification for more information). Is this Section 4 of RFC9180?  If so, why not say that? What would be the circumstance where the application_id extension would be treated with equal standing as something from the AS?  Why can’t this be a "MUST"? Unsaid is what to do if the proposal list is not valid.  Please clarify. Is this normative behavior required, or could it be left up to application?  The mixing of updates/removes on the same node and the SHOULD guidance already means that this "recovery from an invalid node" may not be consistent across clients/DS-es. Same observation on recovering from ReInit with any other proposals. Is there any additional retry mechanism?  Let’s say the sender of the proposal doesn’t see it reflect in the epoch after it sent proposal.  And then not in the next epoch.  Does it try resending indefinitely? This setup seems a little simplistic. If the application data is encrypted to begin with, how does the adversary know the question being posed by Alice?
Code change:
ready to use as soon as it is passed to the application via the event. <del> A ListenError occurs either when the Preconnection cannot be fulfilled for listening, when the Local Endpoint (or Remote Endpoint, if specified) cannot be resolved, or when the application is prohibited from listening by policy. </del> <ins> A ListenError occurs either when the Properties of the Preconnection cannot be fulfilled for listening, when the Local Endpoint (or Remote Endpoint, if specified) cannot be resolved, or when the application is prohibited from listening by policy. </ins> <del> A Stopped event occurs after the Preconnection has stopped listening. </del> <ins> A Stopped event occurs after the Listener has stopped listening. </ins> 6.3.

Related discussion:
text: This adds an explicit Listener object to the API ( to clarify behaviour of multi-streaming protocols ( clarify behaviour and enable re-use of Preconnections (
We talk about listen objects in architecture and implementation, but not in the API. Changes needed: Let return a Listener Move the the Listener Allow Preconnection to be used multiple times.
This issue popped up while discussing and seem to be a wired QUIC multi-streaming issue, possible affecting SCTP too): When a multi-streaming protocol like QUIC allows both ends to open new streams (e.g. by cloning the QUIC connection representing the stream), the both side needs a way to get a ConnectionReceived event for a new stream. That might result in the following weird pattern: I think this needs to be documented somehow and we may need to add a Selection Property do turn off this behaviour.
Calling is an active open. Once the connection is open, the peer can open new streams, but those would surely be events on the not on the .
NAME I am not sure with this one: assuming you have a bunch of ? The first one? What happens if I close the first one?
That's a good point, and I'm not sure I know the answer, but I don't think the should fire the events. A is a potential connection, yet to be instantiated, but these connections come from an already active connection. I've never been entirely comfortable with cloning a connection as the multi-streaming abstraction. This is perhaps the first scenario where it struggles though.
I do not understand the pattern in the example. You do not get a ConnectionReceived after an active open, you need a Listen?
NAME Your assumption is true for TCP, but not for multi-streaming transports like QUIC. With QUIC, you can indeed get additional TAPS connections (QUIC streams) based on an existing, initiated connections. The question is how to handle this. NAME A possible way out would be making itself is returned by an event then.
NAME the TAPS interface is the same weather you have TCP or QUIC underneath. For TAPS an active open generates a READY event not a ConnectionReceived? I do not think your example is a valid TAPS sequence.
NAME the Ready event is not shown in the example (it would be within the first ). The problem I raised is how to model the addition of streams to a multi-streaming connection.
Code change:
ready to use as soon as it is passed to the application via the event. <del> A ListenError occurs either when the Preconnection cannot be fulfilled for listening, when the Local Endpoint (or Remote Endpoint, if specified) cannot be resolved, or when the application is prohibited from listening by policy. </del> <ins> A ListenError occurs either when the Properties of the Preconnection cannot be fulfilled for listening, when the Local Endpoint (or Remote Endpoint, if specified) cannot be resolved, or when the application is prohibited from listening by policy. </ins> <del> A Stopped event occurs after the Preconnection has stopped listening. </del> <ins> A Stopped event occurs after the Listener has stopped listening. </ins> 6.3.

Related discussion:
text: In case of QUIC, additional streams can be initiated by the server/listening side of the QUIC connection. If we model QUIC streams as TAPS connections, this results in events at the client (and server) side for each new QUIC stream.
NAME agree we could add , although it's a significant shift in the model. If we did that, we might also want to revisit as the way of creating a new stream on a connection, in favour of a method on . NAME did you implement this with QUIC? How does your implementation work?
I also see a problem with the communication pattern here. To me, modelling a stream as a TAPS connection means that for every new connection that a peer creates (be it a stream of an existing connection or not), I'll have to listen. So: if I expect 5 incoming connections, which may e.g. be 1 connection with 1 stream and 4 later-added streams below the API, I'll have to listen 5 times. What this also means is that the grouping notion should be a readable property - I believe that we currently only describe it as something that's actively created via clone(). Regarding code, no idea how NAME has done this, but I believe that the NEAT implementation is like I describe here. For more details on this specific aspect, see: URL
NAME We create a Listener from a Connection to handle inbound streams associated with the same parent transport connection. NAME Currently, our Listener object doesn't require calling Listen() for each new connection—you can get the event invoked many times, so it doesn't require knowing how many streams may be opened by the peer. In order to get back pressure, we're talking about having a window for how many new inbound connections will be allowed at a time.
Ok, that also sounds perfectly reasonable. Actually it seems that this (receiving multiple ConnectionReceived events on one Preconnection) is already supported by our current text, sorry for missing this! So... what is the problem we're discussing here - what do we need to change in the text? I think we need only the following: do we have a use case for one Listener getting multiple Connections without having these Connections grouped? (I guess not? Grouping is not a promise of multi-streaming.)
Code change:
ready to use as soon as it is passed to the application via the event. <del> A ListenError occurs either when the Preconnection cannot be fulfilled for listening, when the Local Endpoint (or Remote Endpoint, if specified) cannot be resolved, or when the application is prohibited from listening by policy. </del> <ins> A ListenError occurs either when the Properties of the Preconnection cannot be fulfilled for listening, when the Local Endpoint (or Remote Endpoint, if specified) cannot be resolved, or when the application is prohibited from listening by policy. </ins> <del> A Stopped event occurs after the Preconnection has stopped listening. </del> <ins> A Stopped event occurs after the Listener has stopped listening. </ins> 6.3.

Related discussion:
text: If so, we need the ability to query whether connections are grouped (currently grouping is only created actively via "clone"). Otherwise, we can just statically say that all Connections that are created from the same Preconnections are grouped. some kind of ConnectionReceived event for the Rendezvous case, with text saying that all Connections created off the same PreConnection are grouped. (right?) a way to provide back pressure. Here, we already have PreConnection.Stop(). In the interest of keeping things simple, do we think that intelligently switching between a listening and a non-listening mode would be enough? If so, maybe we should have a call similar to Stop which stops listening, but does not dispose of the PreConnection, such that Listen could be called again. Maybe have an "End" call which stops and disposes, and let Stop only stop listening (because "Stop", to me, indicates only stopping but nothing else).
NAME This solution sounds very reasonable – I guess we should do it the same way for TAPS and add that as Text to the API NAME Some comments: It depends – if writing a server, you might want all streams of a multi-streaming connection grouped, but not all multi-streaming connections received through the same listener. So the behaviour wether to group should be a property of the Listener. I would not group connections received through the same Rendezvous (analogous to server-style listener). We might want to add a property to the listener
NAME I agree, but: just because groups may encompass more than the Connections from one Listener doesn't mean that it would be bad to always group the Connections from one Listener (i.e., group them among themselves, but maybe group them with others too). Besides, I think that wouldn't be the listener deciding anyway. Just to understand this, are you saying "no, see my argument for case 1" ? Then we're just discussing case 1, my answer is above. Otherwise I'd say: why not? yes ... but what do you mean with ? We have , just the semantics are not what I suggested. Regarding , I think that's a good idea - my own proposal was me overdoing "keep it simple, let's not add features". Nobody needs to use this unless they want to.
NAME I guess the answer really depends on what a connection group is for you.