jiebi/CodeConvo huggingface dataset:
Code change:
EDHOC data and the OSCORE ciphertext, using the newly defined EDHOC option for signalling. <del> 4. The approach defined in this specification consists of sending EDHOC message_3 inside an OSCORE protected CoAP message. The resulting EDHOC + OSCORE request is in practice the OSCORE Request from fig-non-combined, sent to a protected resource and with the correct CoAP method and options, with the addition that it also transports EDHOC message_3. Since EDHOC message_3 may be too large to be included in a CoAP Option, e.g. if containing a large public key certificate chain, it has to be transported through the CoAP payload. The use of this approach is explicitly signalled by including an EDHOC Option (see signalling) in the EDHOC + OSCORE request. 4.1. </del> <ins> 5.2. </ins> The Client prepares an EDHOC + OSCORE request as follows.

Related discussion:
text: Clean-up after URL As the content-from-edhoc branch seems to be the most up-to-date one (in which the parts changed are introduced in the first place), this builds on , and only the latest commit is actually relevant.
Compared to the original bstridentifier mapping, this is a different int-to-bstr mapping, but one that's most likely efficient to implement. I have not made any statement on the efficiencies, but some guidance we could give is that from a coding density point of view, numeric Cx should only be used with -24..23; for all other values, doing it in a bstr is just as good and saves a byte in OSCORE. (In fact we may want to make that normative, so that only the single-byte case needs to be implemented where this needs explicit implementation).
Code change:
The "a=rtcp-mux" line MUST only be added if present in the most recent answer. <del> The "a=rtcp-mux-only" line MUST only be added if present in the most recent answer. </del> The "a=rtcp-rsize" line MUST only be added if present in the most recent answer.

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 ICE candidate event.  If the pool becomes depleted, either because a larger-than-expected number of ICE components is used, or because the pool has not had enough time to gather candidates, the <del> remaining candidates are gathered as usual. </del> <ins> remaining candidates are gathered as usual.  This only occurs for the first offer/answer exchange, after which the candidate pool is emptied and no longer used. </ins> One example of where this concept is useful is an application that expects an incoming call at some point in the future, and wants to

Related discussion:
text: The pool is only used in the first offer/answer exchange. After applying a local description, the pool size is frozen and changing the ICE servers will not result in new candidates being pooled. After an answer is applied, any leftover candidates are discarded. This only happens when applying an answer so that candidates aren't prematurely discarded for use cases that involve pranswer, or multiple offers.
I can live with this as is. Want to read again if we end up making changes to address EKR comments
Updated PR and its description based on our discussion.
Code change:
4.1.2. <del> Branch types must occur in a specific order relative to one another to avoid creating leaf nodes with invalid or incompatible settings. In the example above, it would be invalid to branch for derived endpoints (the DNS results for www.example.com) before branching between interface paths, since there are situations when the results will be different across networks due to private names or different supported IP versions.  Implementations must be careful to branch in an order that results in usable leaf nodes whenever there are multiple branch types that could be used from a single node. The order of operations for branching should be: Alternate Paths </del> <ins> Branch types ought to occur in a specific order relative to one another to avoid creating leaf nodes with invalid or incompatible settings.  In the example above, it would be invalid to branch for derived endpoints (the DNS results for www.example.com) before branching between interface paths, since there are situations when the results will be different across networks due to private names or different supported IP versions.  Implementations need to be careful to branch in a consistent order that results in usable leaf nodes whenever there are multiple branch types that could be used from a single node. This document recommends the following order of operations for branching: Network Paths </ins> Protocol Options

Related discussion:
text: SORRY I made a PR on your PR, when I meant to leave a review comment, see 1024. .... Silly to make a PR on a PR - I added a review comment instead...
In section 4.1.4 in the impl draft, we have: "The order of operations for branching, where lower numbers are acted upon first, should be: Alternate Paths Protocol Options Derived Endpoints" However, I would say there is not really a strict ordering required. The text actually indicates that selection of the protocol is rather independent while there is usually a dependency between the interface and derived endpoint. I think this is related to my other issue about the use of the term path, because a path consists of both the local and remote endpoint and therefore there is of course a dependency. So in summary I'm not sure how useful I find this whole section as currently written...
We should conclude if anything more is needed here besides cleaning up the terminology, where Alternate Paths is not a good term - see .
Any implementation should have a consistent order of operations. This is a recommended example. Reference the arch text that says it needs to work the same way each time.
Reference ICE/HE
Code change:
to use smaller packets, so that the limited reassembly capacity is not exceeded. <del> For TCP, MSS clamping (Section 3.2 of {?RFC4459}}) is often used to </del> <ins> For TCP, MSS clamping (Section 3.2 of RFC4459) is often used to </ins> change the sender's maximum TCP segment size, but QUIC requires a different approach.  Section 14 of QUIC-TRANSPORT advises senders to probe larger sizes using Datagram Packetization Layer PMTU Discovery

Related discussion:
text: Some section refs weren't linked to the sections; some objects were defined multiple ways; one reference wasn't actually cited in the text.
Thanks a lot!
Code change:
be acknowledged, an endpoint MAY wait until an ack-eliciting packet has been received to include an ACK frame with outgoing frames. <ins> A receiver MUST NOT send an ack-eliciting frame in all packets that would otherwise be non-ack-eliciting, to avoid an infinite feedback loop of acknowledgements. </ins> 13.2.2. A receiver determines how frequently to send acknowledgements in

Related discussion:
text: It's no longer normative and it's in a single section. I only moved text so far, and not as far as NAME suggested. I can go farther here or in a follow-up PR.
NAME I would like to merge this. WDYT?
Can we merge this soon. I'm worried about it developing conflicts.
Yep, NAME lost the chance to fix the PR. We are - of course - still open for editorial improvements in the form of new pull requests though.
calls them "exemplary" but 13.2.4 has MUST in it.
For reference, this refers to and in the editor's copy. I'm in favour of striking the exemplary note and saying that while the recovery draft is advisory, this document depends on implementations following something like what is recommended.
The specific MUSTs aren't really about the ACK algorithm per se, but about state endpoints will have to maintain for other reasons that are typically folded into your loss recovery code. If an implementation is unable to do duplicate detection for a packet number range, it MUST fail toward rejecting all packets, not toward accepting potential duplicates. An implementation must track the greatest packet number ever received, for use in recovering future packet numbers. In fact, the first requirement is discussed in 12.3 and could probably be dropped here. The second isn't actually called out (MUST) in 17.1, but could easily be moved there.
I think I'm inclined towards reorganizing the text and putting all the 'exemplary' parts into one section(ie: "Limiting ACK Ranges") and moving the normative text either into "Managing ACK Ranges" or elsewhere in the draft.
I thought I could clean this up fairly quickly, but I think a fair number of paragraphs need to move, including some of NAME suggestions. I'm happy to try to improve this in a few days if no one else has beaten me to it.
Anyone want to help NAME out and take this on?
Sorry about dropping this one. I'm fine with it, and happy to make editorials one later.Thanks Ian. When you lay it out like this, it seems so obvious. I checked that we don't have citations for {{ack-tracking}}, so this works nicely. If you care about the "MAY", then we can fix that in another PR.
Code change:
3.2. <del> The properties specified during pre-establishment has a close </del> <ins> The properties specified during pre-establishment have a close </ins> connection to system policy.  The implementation is responsible for combining and reconciling several different sources of preferences when establishing Connections.  These include, but are not limited to: Application preferences, i.e., preferences specified during the <del> pre-establishment such as Local Endpoint, Remote Endpoint, Path Selection Properties, and Protocol Selection Properties. </del> <ins> pre-establishment via Selection Properties. </ins> Dynamic system policy, i.e., policy compiled from internally and externally acquired information about available network

Related discussion:
text: What's bad about having more information available that can guide the selection process?
NAME the problem is that the Connection properties are not expressed in a way suitable for selection. If they should also be used for Selection they would have to be reworked to be of type Preference. Otherwise I do not know what they mean for selection. What does it mean if I pick say a particular connection group transmission scheduler? Is it required or preferred? Most connection properties also do not look very useful to me for selection so in case there are some we need I think it would be simpler to just define a matching selection property.
NAME we're only discussing whether it's allowed to use them as additional input or not. I agree, some (like the scheduler choice) don't seem useful, but some do... generally we may not have good guidance on how they should be used by an implementation, but giving the system freedom to use as many inputs as possible is probably a good thing. Regarding the type, require/prefer//ignore/avoid/prohibit obviously works fine for a "wishlist" of boolean character: having something, or not having it. The selection properties are generally like that - except "Interface Instance or Type" and "Provisioning Domain Instance or Type" which are, well... wishlist-collections. Consider the capacity profile. Surely configuring this early can be useful input - e.g. if someone picks low latency / interactive, you may even want to put this traffic on a specific network interface! But if you'd want to make a copy of the capacity profile as a "proper" selection property, how would you do it? Apply require/prefer/ignore/avoid/prohibit for each of its values? Then I could say "prefer" low latency/non-interactive but "avoid" low latency/non-interactive, which would surely be odd. Apply the qualifier to the whole thing? Then it's about, e.g. "avoiding" to use a capacity profile at all. That's odd as well. I think it's in the nature of the current selection properties that they merely say "I want to be able to do this, and this is how important it is to me", which is different from configuring something. That's also why, as written, they simply wouldn't work for later connection configuration.
Code change:
3.2. <del> The properties specified during pre-establishment has a close </del> <ins> The properties specified during pre-establishment have a close </ins> connection to system policy.  The implementation is responsible for combining and reconciling several different sources of preferences when establishing Connections.  These include, but are not limited to: Application preferences, i.e., preferences specified during the <del> pre-establishment such as Local Endpoint, Remote Endpoint, Path Selection Properties, and Protocol Selection Properties. </del> <ins> pre-establishment via Selection Properties. </ins> Dynamic system policy, i.e., policy compiled from internally and externally acquired information about available network

Related discussion:
text: Connection properties really are about configuring something, but I still say that being able to use them as early input is good. I agree that the implementation isn't super clear as they don't come with a require/prefer/... etc. qualifier, but then we just offer some freedom to implementers.
NAME I just pushed a commit that updates the selection and connection properties text, removing "connection" almost everywhere, but adding a disclaimer in the beginning that says that connection properties should be configured as early as possible because they can influence decisions made by the implementation, and "In the remainder of this document, we only refer to Selection Properties because they are the more typical case." Frankly I'm not sure this is better... but it does remove most of the "selection and connection" double mentions that you pointed out.
Fixed up branch building and resolved merge conflicts. I'll merge this in later today before the posting deadline.
Cool thanks! Sorry if I messed something up
As discussed in
Thank you for updating this – looks good! just needs s/send-params/msg-properties/ and merging
Code change:
Section 4.4 of IANA-POLICY) where two registrations MUST NOT have the same Key.  This registry is initially empty. <del> 10.  References </del> <ins> 9.  References </ins> <del> 10.1.  URIs </del> <ins> 9.1.  URIs </ins> [1] mailto:masque@ietf.org

Related discussion:
text: This PR aims to take the design discussions we had at the last interim, and propose a potential solution. This PR should in theory contain enough information to allow folks to implement this new design. That will allow us to perform interop testing and confirm whether the design is sound.
I'm confused by this pull request (probably because I was out of the loop for a while). My understanding, at least when I first read the proposal a month ago was that we would separate multiplexing streams and multiplexing contexts into different layers, so that methods that need context would get it (CONNECT-UDP), and features that don't (WebTransport/extended CONNECT) could use stream-associated datagrams directly.
NAME you're referring to which this PR isn't trying to address. That'll happen in a subsequent PR.
In , capsules, contexts and context IDs are explicitly defined as end-to-end and there are requirements for intermediaries to not modify them, and to not even parse them. The motivation for this was to ensure that we retain the ability to deploy extensions end-to-end without having to modify intermediaries. NAME mentioned that these requirements might be too strict, as he would like to have his intermediary be able to parse the context ID, for logging purposes.
Part of the comment from the PR is also about consistency of interface for generic HTTP libraries that can be used to build either endpoints or intermediaries. If the context ID is always present, it's overly prescriptive to say that an intermediary can't parse it, and such a requirement couldn't be enforced anyways. If context IDs are negotiated on/off, whether this is possible depends on the negotiation mechanism.
I think its fine for a component that has bytes passing through it to look at those bytes. The import thing to do is set expectations on what that means for the protocol behaviour we are defining. We don't expect intermediaries to do anything with a context ID; they should not enforce the protocol semantic rules (odd, even, reuse etc). H2 and H3 somewhat solve this problem by decoupling frame parsing from frame payload interpretation. E.g. if the form of a request or response is invalid, an intermediary shouldn't pass it on. DATAGRAM is different because it isn't defined as an actual HTTP/3 frame with frame headers and frame payload.
Code change:
Section 4.4 of IANA-POLICY) where two registrations MUST NOT have the same Key.  This registry is initially empty. <del> 10.  References </del> <ins> 9.  References </ins> <del> 10.1.  URIs </del> <ins> 9.1.  URIs </ins> [1] mailto:masque@ietf.org

Related discussion:
text: Something that might work is to formalise that quarter stream ID is part of the envelope that intermediaries have to be able to handle the syntax of, but context ID is part of content and separate.
Unless you encrypt capsules end-to-end, I don't think any text in the spec can in practice prevent intermediaries from inspecting and modifying capsules. You can send something like GREASE capsules, though.
In , we introduce the CLOSEDATAGRAMCONTEXT capsule which allows endpoints to close a context. That message currently only contains the context ID to close. NAME suggests that we may want to add more information there. Should we differentiate between "context close" and "context registration rejected"? Should we add an error code? In particular, do folks have use cases for these features?
My first concern is with infinite loops. If the context was "garbage collected" by the recipient, the sender can simply re-create it if they still want it. However, if it was closed due to incompatibility (i.e. rejected) or hitting a resource limit (e.g. max # of contexts), reopening it in response will produce a tight infinite loop. This could be maybe be avoided by some kind of heuristic, but an explicit indication of what's going on seems better.
This issue assumes that decide to go with the two-layer design described in . Given that design, some applications might not need the multiplexing provided by context IDs. We have multiple options here: Make context ID mandatory Applications that don't need it waste a byte per datagram Negotiate the presence of context IDs using an HTTP header Context IDs would still be mandatory to implement on servers because the client might send that header Have the method determine whether context IDs are present or not This would prevent extensibility on those methods Create a REGISTERNOCONTEXT message This assumes we use the Message design from We add a register message that means that this stream does not use context IDs This allows avoiding the byte overhead without sacrificing extensibility
Making the context ID mandatory is simple, although slightly wasteful. For the variations where it is optional, I prefer the one that uses a header. It could work with a variant of where we do Header + Message, and the Header determines whether or not you have contexts, and whether or not they can be dynamic.
What are the benefits of message over header to make it optional?
Code change:
Section 4.4 of IANA-POLICY) where two registrations MUST NOT have the same Key.  This registry is initially empty. <del> 10.  References </del> <ins> 9.  References </ins> <del> 10.1.  URIs </del> <ins> 9.1.  URIs </ins> [1] mailto:masque@ietf.org

Related discussion:
text: To me it seems like header is sufficient, because the context IDs are end-to-end, and should not affect intermediaries, making the header a natural place to put it. I think having the context ID be the default behavior and the header is to opt-out is the right decision if we were to allow removing it.
This is a bit of a bike-shed, but why would it default to having context-IDs instead of not having them?
I think the second option "Negotiate the presence of context IDs using an HTTP header" is the best personally. In terms of: "Context IDs would still be mandatory to implement on servers because the client might send that header", I assume server in this context is the final application server, not a proxy? Even so, I'd argue it's applications which decide if they need this functionality, so if a server only implemented one application and it didn't use Context-IDs, then I don't see why it would need to implement it.
Ian, in your comment, are you talking about an intermediary when you say "proxy"? If so, then an intermediary need not implement anything based on the payload of than H3 DATAGRAM, it only has to pass the data along. That may be worth a clarification.
Having context ID optional has a nice future-proof property - other uses of datagrams in HTTP/3 can decide if they want the second layer or not. I wouldn't even state it as application needing multiplexing or not. Other applications might find it very useful to include a second ((third, fourth, fifth) layer of frame header. I think its fine for us to state as much in this in the spec, while also defining an explicit second layer for multiplexing.
Yes, by proxy I meant intermediary. And I agree about what intermediaries need to do, I just wanted to ensure I understood what server meant when David used it above. Yup, whenever all this gets written up, we can make it clear that intermediaries can ignore much of this.
The method defines the semantics of datagrams for a particular request, thus I think the third option makes most sense.