jiebi/CodeConvo huggingface dataset:
Code change:
6.4. <del> Groups of Connections can be created using the Clone Action: </del> <ins> Entangled Connections can be created using the Clone Action: </ins> Calling Clone on a Connection yields a group of two Connections: the parent Connection on which Clone was called, and the resulting cloned

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:
6.4. <del> Groups of Connections can be created using the Clone Action: </del> <ins> Entangled Connections can be created using the Clone Action: </ins> Calling Clone on a Connection yields a group of two Connections: the parent Connection on which Clone was called, and the resulting cloned

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:
6.4. <del> Groups of Connections can be created using the Clone Action: </del> <ins> Entangled Connections can be created using the Clone Action: </ins> Calling Clone on a Connection yields a group of two Connections: the parent Connection on which Clone was called, and the resulting cloned

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.
Code change:
6.4. <del> Groups of Connections can be created using the Clone Action: </del> <ins> Entangled Connections can be created using the Clone Action: </ins> Calling Clone on a Connection yields a group of two Connections: the parent Connection on which Clone was called, and the resulting cloned

Related discussion:
text: I always saw connection groups as an abstraction for multi-streaming connections (or their emulation) – therefore I see no use for grouping connections from multiple listeners. My opinion is auto-grouping for multi-streaming is fine, otherwise it is not. really falls out of 1 I want your semantics, but call it
NAME Me too. I can imagine other things ( this paper of ours comes to mind: URL ), but generally I agree and don't think we should complicate the API for this. But I'm getting confused: you wrote "you might want all streams of a multi-streaming connection grouped, but not all multi-streaming connections received through the same listener". That sounded to me like you want to support multiple streams, but from several listeners?! ACK Agreed!
NAME let me elaborate on this… You might want all streams of a multi-streaming connection grouped, e.g., all streams within a QUIC connection You might not want all multi-streaming connections (e.g., QUIC connections) received through the same Listener object grouped You definitely do not want all all streams of all QUIC connection received through one listener grouped (except if you have hierarchical groups that allows you to sort that out the cases above)
I agree with all this. Anyway I think it's a moot point: whether they're grouped or not is not up to the listener to decide? So grouping needs to be something that can be queried.
Ok – fair enough – but I still think the Listener is the right place to configure whether connections that come out of it should be grouped by default or not.
Not unless we have a concrete idea on what to do with this information inside the transport system. => I think no text update is needed as a result of this issue and lean towards closing it...
I don't think we really need a text update for the grouping, but for the original question. To address the handling of incoming streams in multi-streaming connections, I would like to have the solution NAME outlined reflected in the API.
One question on this, for NAME the description of your Listener object being able to accept multiple events, is that how it works in general or was that specif for a multi-streaming scenario? As specified I am not sure that our Listen action does not allow multiple ConnectionReceived events? The text says
NAME The listener object for all cases (both multi streaming and receiving brand-new transport connections) allows multiple events.
Code change:
6.4. <del> Groups of Connections can be created using the Clone Action: </del> <ins> Entangled Connections can be created using the Clone Action: </ins> Calling Clone on a Connection yields a group of two Connections: the parent Connection on which Clone was called, and the resulting cloned

Related discussion:
text: I think the existing text is a bit ambiguous, but it seems that "listening continues" implies that the event can certainly fire again.
Revisit after is done
Regarding this text: This seems to imply that the Preconnection object, which may be full of many carefully tuned settings that could be useful for another Connection, is no longer usable. While I understand that the specific Preconnection cannot change for a Connection, this is inconvenient to the application. I see two good options to solve this: Make a deep copy of the Preconnection upon Initiate(), and say that a Preconnection may be used or changed but changes can no longer influence the Connection (this is what Network.framework currently does) Allow a URL() method to let the applications do the deep copy themselves when and if they want to re-use.
+1 to reusing the preconnection. Do you even need a deep copy. The connection is a new object that should be independent of the preconnection anyway, no? Another thought: Are there actually ways to get different connections out of the preconenction. E.g. you do racing and end up with two open connections and (suddenly) want to use both...?
I'd like to see this as well. To me it makes most sense to allow calling Initiate() on the same Preconnection multiple times to get multiple Connections, but not allow to change this Preconnection anymore after the first Initiate. This way it would be similar to Listen() and Rendezvous(), where we have a Preconnection that yields multiple Connections, and that cannot be changed anymore after Listen() or Rendezvous(). So here we already have a binding between the Preconnection and the Connections that come out of it. If the application wants to change the Preconnection before re-using it, I'd be in favor of letting it explicitly clone the Preconnection - not sure if we actually want to call it clone() though, because we already have Connection.Clone(), which creates a Connection Group, a completely different thing.
Why do you think it should not be allowed that a preconnection can be changed after the first initiate? If you don't change it you should get the same kind of connection, if you change it you might get something different. Your choice!
I wanted the API contract to be similar for different forms of Connection establishment. But I may be overthinking this.
Code change:
6.4. <del> Groups of Connections can be created using the Clone Action: </del> <ins> Entangled Connections can be created using the Clone Action: </ins> Calling Clone on a Connection yields a group of two Connections: the parent Connection on which Clone was called, and the resulting cloned

Related discussion:
text: First, I like the idea of reusing Preconnections. I am not sure whether we should define now whether they should be changeable after the first initiation. There might be kinds of Preconnections where this is a good idea, there might be others where it is not. I anticipate one can realize connection pools as a sub-class of Preconnection. In this case, in such cases, it should not be possible to change a Preconnection.
So the difference is if you think you morph a preconnection into a connection, or if the preconnection create the connection. i think the first think does not make sense because their are two completely different things; they have not actions or events in common.
NAME The morphing one has its beauty for modeling TCP fastopen / 0-RTT data.
Whether it makes sense to re-use a perhaps depends on how fully specified it is? Reusing a completely specified , that will just re-open an identical 5-tuple as an existing might not make sense. Reusing a partially specified , e.g., with the source port left as a wildcard to new connections can open without conflicts, seems reasonable.
NAME right, using the exact same set of fully-specified properties isn't going to work. But having a partially specified one and copying it, or modifying one that was used (by switching out the Remote, etc) would be useful.
This might work better the other way -- on , the Preconnection corresponding to the initiated/initiating connection gets deep-copied into the new connection, leaving the existing Preconnection in the state that it was. That deep copy, inside the connection, cannot be reused, but the existing one could be. (This probably only works for connections on which you . turns the preconnection into a listener from which multiple , each of which will have their own deep copy of the listener, will spawn. might be even weirder, but there's a potentially bigger win to allowing reuse, but I don't quite have my head around how it would work)
So i think there is actually not that much too deep copy because a preconception is not a super class of a connection. At the moment when you call initiate or rendezvous the preconception should create a connection and store all information regarding this connection in the connection object which is later returned.
Code change:
6.4. <del> Groups of Connections can be created using the Clone Action: </del> <ins> Entangled Connections can be created using the Clone Action: </ins> Calling Clone on a Connection yields a group of two Connections: the parent Connection on which Clone was called, and the resulting cloned

Related discussion:
text: The only thing that needs "copying" is the properties but you need to create a new object anyway because preconnection properties have preferences and connection properties not but have to be marked as mutable or unmutable. These two things are also not the same. So the only that that's left to copy maybe are the endpoints. Not sure if the preconnection and connection both have a copy of the endpoints or if an endpoint only exists once and both have a reference (which means if the endpoint gets somehow updated that's relevant for both) or maybe even the connection does not need a reference to the endpoint anymore...?
NAME right – but I don't know a way of specifying "a is consumed if fully specified, else may be reusedin any current programming language. Maybe tracking lifetimes so closely doesn't matter though, and we can just write this in the draft.
I have no problem with an Interface where some Preconnections can be reused and others can not. That makes a pretty nice case for -- preconnection reuses itself for multiple incoming connections. For ` I see this API-wise as some kind of listen called at both sides.
Side meeting says we can reuse the initiate call. Implementation should specify that a deep copy is made on Initiate() or Listen()
Will be trivial to fix after is done
Sorry to reopen an old issue, but when reading the current API draft, I noticed that it still says that reusing the Preconnection is possible for Listeners, but not possible for Initiate() and Rendezvous(). For example, see Section 6.1: "The Initiate() Action consumes the Preconnection […]" From what I read in this issue, I think Preconnections should be allowed to be reused for Initiate() and Rendezvous() as well (possibly with a note on deep-copy).
This looks just right to me, thanks a lot for doing this! In particular having read again, I believe that NAME should definitely have the last word on this one. So I'll go with whatever NAME says.
Code change:
4.1.4. Session description objects (RTCSessionDescription) may be of type <del> "offer", "pranswer", and "answer".  These types provide information as to how the description parameter should be parsed, and how the media state should be changed. </del> <ins> "offer", "pranswer", or "answer".  These types provide information as to how the description parameter should be parsed, and how the media state should be changed. </ins> "offer" indicates that a description should be parsed as an offer; said description may include many possible media configurations.  A

Related discussion:
text: I was reading this draft and noticed a couple of minor wording issues that made the text not as clear as it could be. I don't believe the changes are controversial, or change the intention of the draft.
These changes look good - I agree the rewrite of the offer/answer paragraph is a nice improvement.
Looks fine to me
Code change:
"authority" as defined in Section 3.2 of RFC3986. The Alternative-Address Option is a repeatable option as defined in <del> Section 5.4.5 of RFC7252. </del> <ins> Section 5.4.5 of RFC7252.  When multiple occurrences of the option are included, the peer can choose any of the alternative transport addresses. </ins> The elective Hold-Off Option indicates that the server is requesting that the peer not reconnect to it for the number of seconds given in

Related discussion:
text: URL - WGLC review by Esko Dijk Page 20: Alternative-Address Option - the semantics of including multiple of these options is not defined. Can the receiver pick any of the addresses? Or does it need to try the first address first? And then keep trying all alternatives until one succeeds, or not?
URL Unless Carsten or Hannes (authors of draft-bormann-core-coap-sig-02) have a preference, I would suggest that the addresses are unordered (pick any).
Code change:
contains the unmodified payload of a UDP packet (referred to as "data octets" in UDP). <del> Clients MAY optimistically start sending UDP packets in HTTP Datagrams before receiving the response to its UDP proxying request. However, implementors should note that such proxied packets may not be processed by the UDP proxy if it responds to the request with a failure, or if the proxied packets are received by the UDP proxy before the request. </del> By virtue of the definition of the UDP header UDP, it is not possible to encode UDP payloads longer than 65527 bytes.  Therefore, endpoints MUST NOT send HTTP Datagrams with a Payload field longer than 65527

Related discussion:
text: PR in response to Al's OPSDIR review -- Reviewer: Al Morton Review result: Has Nits Hi David, this is the OPS-DIR review. I tried to stay in my lane. I found this paragraph confusing (which doesn't mean it is incorrect, just that someone with limited background read the section 2 requirements list, all MUSTs, and then the paragraph below, which seems to have a conflicting MUST with the SHOULD and MAY that follows). Help readers like me understand the options you are allowing here: If the client detects that any of the requirements above are not met by a URI Template, the client MUST reject its configuration and fail the request without sending it to the UDP proxy. While clients SHOULD validate the requirements above, some clients MAY use a general-purpose URI Template implementation that lacks this specific validation. I see that Christer's GEN_ART review picked-up on this too (I looked after I was done...). In Section 5, there seems to be a possible operations issue for proxy operators: Clients MAY optimistically start sending UDP packets in HTTP Datagrams before receiving the response to its UDP proxying request. However, implementors should note that such proxied packets may not be processed by the UDP proxy if it responds to the request with a failure, or if the proxied packets are received by the UDP proxy before the request. This seems like a good place to limit the amount of optimistic traffic, given that the request is not yet accepted. (also, would the optimistic traffic use Context ID zero?) In Performance Considerations UDP proxies SHOULD strive to avoid increasing burstiness of UDP traffic: they SHOULD NOT queue packets in order to increase batching. This requirement is written qualitatively, so users might "know a violation if they see it", but not hold the proxy system/operator to any specific performance without providing more details here. Inter-packet delay variation measurements on proxy ingress and egress would characterize increased burstiness well. Another solution is s/SHOULD/should/ (I doubt some increased burstiness will be avoidable, or enforceable.) Thanks in advance for considering these comments, Al
Code change:
A signature algorithm <del> The HPKE parameters are used to instantiate HPKE I-D.irtf-cfrg-hpke for the purpose of public-key encryption.  The "DeriveKeyPair" function associated to the KEM for the ciphersuite maps octet strings to HPKE key pairs. </del> <ins> MLS uses draft-07 of HPKE I-D.irtf-cfrg-hpke for public-key encryption.  The "DeriveKeyPair" function associated to the KEM for the ciphersuite maps octet strings to HPKE key pairs. </ins> Ciphersuites are represented with the CipherSuite type.  HPKE public keys are opaque values in a format defined by the underlying protocol

Related discussion:
text: cc NAME
NAME is the build expected to fail?
No, but the problem seem unrelated to your change, so we are all good.
Looks like it was a transient failure. Re-running resulted in success.
NAME points out that the HPKE version is not pinned. This is probably needed for interop. Version -07 should come sometime this week, so that seems like a perfectly fine version to use. I can send a PR when that version is cut.
Fixed by
Code change:
RDAO: Clarify that it is an option for RAs and not other ND messages. <ins> Examples: Use example URIs rather than unclear reg names (unless it's RFC6690 examples, which were kept for continuity) </ins> changes from -24 to -25 Large rework of section 7 (Security policies)

Related discussion:
text: ... and a few other cases of example errors and use of unregistered names.