jiebi/CodeConvo huggingface dataset:
Change:
over QUIC with a mechanism to send unreliable data while leveraging the security and congestion-control properties of QUIC.  However, QUIC DATAGRAM frames do not provide a means to demultiplex <del> application contexts.  This document defines how to use QUIC DATAGRAM frames when the application protocol running over QUIC is HTTP/3 by adding an identifier at the start of the frame payload.  This allows HTTP messages to convey related information using unreliable DATAGRAM frames, ensuring those frames are properly associated with an HTTP message. </del> <ins> application contexts.  This document describes how to use QUIC DATAGRAM frames when the application protocol running over QUIC is HTTP/3.  It defines logical flows identified by a non-negative integer that are present at the start of the DATAGRAM frame payload. Flows are associated with HTTP messages using the Datagram-Flow-Id header field, allowing endpoints to match unreliable DATAGRAMS frames to the HTTP messages that they are related to. </ins> Discussion of this work is encouraged to happen on the MASQUE IETF mailing list (masque@ietf.org [1]) or on the GitHub repository which

Discussion:
This somewhat of an experiment. While trying to address I got distracted by the document's use of the "flow identifier" term. The document likes to compare "flow identifiers" with QUIC streams, which is fine. But QUIC makes the distinction between streams and stream IDs; the ID is a property of the stream but it isn't the only one, and sometimes it helps to talk about the stream in other contexts. This change tries to channel a similar editorial style. It replaces: "flow identifiers" with "flows" when talking about a logical entitiy "flow identifiers" with "flow IDs" when talking about the wire format, encoding, examples etc. This could be a change too far but I figured it would be a good discussion starter.
The draft doesn't do this. It relies on the QUIC varint encoding for non-negativity in DATAGRAM frames but could contain a negative value. Let's be clear in the spec.
Definitely agree, could you write a PR please?
I will.
fixed in URL
Thanks!
Change:
-1, so the largest legal value of Quarter Stream ID is 2 -1.  Receipt of a frame that includes a larger value MUST be <del> treated as a connection error of type FRAME_ENCODING_ERROR. </del> <ins> treated as a connection error of type H3_DATAGRAM_ERROR. </ins> The payload of the datagram, whose semantics are defined by individual applications.  Note that this field can be empty. Receipt of a QUIC DATAGRAM frame whose payload is too short to allow parsing the Quarter Stream ID field MUST be treated as an HTTP/3 <del> connection error of type H3_GENERAL_PROTOCOL_ERROR. </del> <ins> connection error of type H3_DATAGRAM_ERROR. </ins> Endpoints MUST NOT send HTTP/3 datagrams unless the corresponding stream's send side is open.  On a given endpoint, once the receive

Discussion:
Borrowing text from H3. Also I don't think there is a 'FRAMEENCODINGERROR' defined anywhere.
Thanks! Approved pending some minor tweaks
Change:
The "s=" and "t=" lines MUST stay the same. <del> Each "m=" and c=" line MUST be filled in with the port and address of the default candidate for the m= section, as described in RFC5245, Section 4.3.  Each "a=rtcp" attribute line MUST also be filled in with the port and address of the appropriate default candidate, either the default RTP or RTCP candidate, depending on whether RTCP multiplexing is currently active or not.  Note that if RTCP multiplexing is being offered, but not yet active, the default RTCP candidate MUST be used, as indicated in RFC5761, section 5.1.3.  In each case, if no candidates of the desired type have yet been gathered, dummy values MUST be used, as described above.  [TODO: update profile UDP/TCP per default candidate] </del> <ins> Each "m=" and c=" line MUST be filled in with the port, protocol, and address of the default candidate for the m= section, as described in RFC5245, Section 4.3.  Each "a=rtcp" attribute line MUST also be filled in with the port and address of the appropriate default candidate, either the default RTP or RTCP candidate, depending on whether RTCP multiplexing is currently active or not.  Note that if RTCP multiplexing is being offered, but not yet active, the default RTCP candidate MUST be used, as indicated in RFC5761, section 5.1.3.  In each case, if no candidates of the desired type have yet been gathered, dummy values MUST be used, as described above. </ins> Each "a=mid" line MUST stay the same.

Discussion:
Also fix a bunch of TODOs and a few places where text was obsolete. NAME NAME
I suspect we might need to say a bit more in this section this but this all looks good good so LGTM
Change:
in response to changes in the ICE configuration. When a new gathering phase starts, the ICE Agent will notify the <del> application that gathering is occurring through a callback.  Then, when each new ICE candidate becomes available, the ICE Agent will supply it to the application via an additional callback; these candidates will also automatically be added to the local session description.  Finally, when all candidates have been gathered, a callback will be dispatched to signal that the gathering process is complete. </del> <ins> application that gathering is occurring through an event.  Then, when each new ICE candidate becomes available, the ICE Agent will supply it to the application via an additional event; these candidates will also automatically be added to the local session description. Finally, when all candidates have been gathered, an event will be dispatched to signal that the gathering process is complete. </ins> Note that gathering phases only gather the candidates needed by new/recycled/restarting m= lines; other m= lines continue to use

Discussion:
Editorial suggestions, if helpful use, if not just close the PR.
fine with me to merge this
LGTM
Change:
either through timers or through least-recently-used eviction, depending on application requirements. <del> While QUIC has no clear network-visible end-of-connection signal and </del> <ins> While QUIC has no clear network-visible end-of-flow signal and </ins> therefore does require timer-based state removal, the QUIC handshake indicates confirmation by both ends of a valid bidirectional transmission.  As soon as the handshake completed, timers should be

Discussion:
URL, in the section 4.2, end-of-flow and end-of-connection both are used in a way that they both point to the same observation event. if these are same then lets stick to only one of them otherwise lets describe in a way that they point to different observation points.
let's use end-of-flow consistently.
Change:
Name: The name of the wire format <del> Recommended: Whether support for this wire format is recommended by the IETF MLS WG.  Valid values are "Y" and "N".  The "Recommended" column is assigned a value of "N" unless explicitly requested, and adding a value with a "Recommended" value of "Y" requires Standards Action RFC8126.  IESG Approval is REQUIRED for a Y->N transition. </del> <ins> Recommended: Same as in </ins> Reference: The document where this wire format is defined

Discussion:
Also copies the "Recommended" field by reference, instead of reciting it in each registry. Note that this has a conflict with that will not catch -- "MLSContentTBS" will have to be changed to whatever new name is agreed in that PR.
The of absolutely needs to be unique for every signature happening in the protocol, for security and avoid signature ambiguity. That includes signatures happening in extensions. Should this be referenced in a IANA considerations to ensure there is no conflict in the future? Or at least say something about this somewhere? We have to think how to design things well here to be future-proof: the structure must be used for every signature done with the leaf signature keys, which includes what might happen in extensions but also in future versions of MLS. If future versions of MLS could avoid doing , that would be great!
This seems to come down to whether we expect the signature keys used for MLS authentication to be used outside of MLS (otherwise there's no risk of confusion) and if so, whether this spec has any influence on that usage. If you're using your MLS key to sign Bitcoin transactions, we can't do much to help that. Note that there is not an issue for future version of MLS here. The label is constructed as , so a future version could just increment the part of that. Given all that, I might prefer a recommendation that signature keys not be reused across contexts, rather than trying to accommodate reuse. If we do something here, we should do something analogous to the registry, which are similarly intended for domain separation between different use cases. We should probably consider making an exporter label registry anyway.
I agree, we shouldn't do anything about someone using the MLS signature key in another protocol. About future MLS versions: I agree, but note that there is a length tag before that. It means that we impose to all signature of future MLS versions to start with (including the quic integer) Is it something acceptable or not, I don't now. I just think we should have in mind that the decisions we make now on will have an impact on the design of future MLS versions. About extensions: in the extensions document, there is a signature computed with If two extensions were to use the same label then this could lead to security problems, this is why I think the labels should be in some registry to ensure they are all unique.

One other thing we could do is to separate all extensions signatures from the core MLS signatures, for exemple using the label "MLS 1.0 extension [label from extension]"? Like that a bogus extension can't introduce a security flaw in core MLS that way?
Change:
Endpoint and group lookups result in links to registration resources and group resources, respectively.  Endpoint registration resources <del> are annotated with their endpoint names (ep), domains (d, if present), context (con) and lifetime (lt, if present).  Additional </del> <ins> are annotated with their endpoint names (ep), domains (d, if present) and context (con); the lifetime (lt) is not reported.  Additional </ins> endpoint attributes are added as link attributes to their endpoint link unless their specification says otherwise.  Group resources are annotated with their group names (gp), domain (d, if present) and

Discussion:
We've had conflicting concepts (show remaining vs show registered), and they problematic w/rt caching and useless to some kinds of consumers, respectively. Given that there is no clear case for existing consumers that could fully work from those attributes in lookup, they're removed; when a use case does come up, it can still register a lookup parameter. Closes: URL
should lt value in lookup give time from specification moment to end or from lookup moment to end
added text in this sense in section 7
That's hard to keep consistent with caching. What use cases do we have for exposing a lifetime in the endpoint lookup at all?
returning the lt value as specified at registration time does not really help and can be omitted at lookup. Returning the remaining registration time till end of registration "could" be useful to a commissioning device that is unaware of the earlier registration time because it was not involved.
Given that caching of down-counting values is problematic, and the 'Returning the remaining [...] time [...] "could" be useful' does not sound too convinced, I'd suggest just not returning it by default and leaving it up to extensions to say what exactly they need. NAME is that something you'd be happy with?
Change:
Generate a provisional GroupContext object by applying the proposals referenced in the initial Commit object in the order <del> provided, as described in proposals.  Add proposals are applied left to right: Each Add proposal is applied at the leftmost unoccupied leaf, or appended to the right edge of the tree if all leaves are occupied. </del> <ins> provided, as described in proposals.  First the list of update proposals, then the list of remove proposals, and last the list of add proposals.  Add proposals are applied left to right: Each Add proposal is applied at the leftmost unoccupied leaf, or appended to the right edge of the tree if all leaves are occupied. </ins> Create a DirectPath using the new tree (which includes any new members).  The GroupContext for this operation uses the

Discussion:
by updating the description for creating a commit to explicitly mention that first all update proposals are applied, then remove proposals, and last add proposals.
The writes: However, from this it is not immediately clear to me in which order the collections of proposals , , and are to be applied. I assume it should be in that order because it makes practical sense and because they're written in that order in the Commit struct. If my guess is correct, perhaps it would be useful to make this explicit? E.g.:
NAME - I agree with your interpretation here. Could you make a PR with some proposed wording?
Apologies for closing/opening the issue. I will open a PR to update the wording.
Change:
The SDP for |answer-B1| looks like: <del> The SDP for |offer-B2| looks like: </del> <ins> The SDP for |candidate-B4| looks like: </ins> <del> The SDP for |answer-B2| looks like: </del> <ins> The SDP for |candidate-B5| looks like: The SDP for |candidate-B6| looks like: The SDP for |offer-B2| looks like: (note the increment of the version number in the o= line, and the c= and a=rtcp lines, which indicate the local candidate that was selected) The SDP for |answer-B2| looks like: (note the use of setup:passive to maintain the existing DTLS roles, and the use of a=recvonly to indicate that the video streams are one-way) </ins> 8.

Discussion:
NAME NAME PTAL
This LGTM. Have you run it through a parser? If not, I'm going to give that a shot.
Addressed all comments, save the parser. PTAL.
LGTM. Fluffy?
LGTM - I did not really have time to review it but again, looks close enough I'd like to see it merged into the draft and that will make it easier to fix any nits.
Change:
The source code and issues list for this draft can be found at https://github.com/ietf-wg-httpapi/ratelimit-headers [2]. <ins> References to "ThisRFC" in the IANA Considerations section would be replaced with the RFC number when assigned. </ins> 1. The widespreading of HTTP as a distributed computation protocol

Discussion:
Merge three "add to table" into one request to "add these to the table" Create a new registry for quota fields.
looks good!
NAME NAME I made some edits: ad an addressable subsection for iana-ratelimit-parameters add , to iana table reference specification sections in IANA registries removed normative parts from IANA mention IANA table in {{quota-policy}} Could you please PTAL?
ooops I missed your comment :) Ok, let's merge.
Since parameters are always allowed in Limit we could define a "registry" and add them subsequently as soon as implementers needs them. They can be used to specify: max throughputs request distribution other policies All data in parameters is informative.
I assume there must be previous art in keeping a registry like this that we can mimic, but I can't think of a good example off the top of my head that wouldn't be using a separate registry or document to manage that. What's your thinking about where to keep this registry?
NAME registries are usually maintained by IANA: we can check with NAME if that's possible...
We can pretty easily define a registry. You include a section in the RFC. See URL You define a table that is the registry, and meanings of the columns, and perhaps populate it with the initial entries. The WG decides some rules, like "X-" is left for experimentation. There must be something written (it can be an internet draft or something else on the net), whether a set of "experts" need to review for comliance and clarity, and so on.
If you'd like, I can make a PR that provides the initial text for this next week.
Yes, that would be great NAME
Can you give me an initial set of fields (even if it's just one or two), and an example, and a pointer to which section in the current draft? thanks.
Hi NAME Thanks for your support! To make best use of your time, I'd wait for to be merged (waiting for mnot's review) so you can PR directly vs . WRT the parameter registry: currently the initial set is just : See: URL Do you have a proposal for the registration policy?
Thanks, I'll wait. I think it should be expert review.

That means that there should be a document describing the parameter, and that the experts can be directed to verify that the documentation is clear and unambiguous, and that there is no significant overlap with the parameters already defined. The other choices are "specification required" and "first-come first-served."
NAME we just merged structured fields in RateLimit Headers!
Thanks for the ping, I saw :) I'll propose a PR soon.
URL I think it needs to be tweaked, since it's just defined as a "quota" registry in that PR. Should it be a ratelimit fields registry?
Change:
out-of-order delivery, but should be deleted promptly. If a new participant joins mid-call, they will need to receive from <del> each sender (a) the current sender key for that sender, (b) the signing key for the sender, if used, and (c) the current KID value for the sender.  Evicting a participant requires each sender to send a fresh sender key to all receivers. </del> <ins> each sender (a) the current sender key for that sender and (b) the current KID value for the sender.  Evicting a participant requires each sender to send a fresh sender key to all receivers. </ins> 5.2.

Discussion:
The signature mechanism was removed from SFrame some time ago. This PR removes a few remaining references to it.
Seems good but needs rebasing
NAME NAME I think we are ok to merge this PR?
Change:
in active use, then that pair MUST be used, even if ICE has not yet completed.  Note that this differs from the guidance in RFC5245, Section 9.1.2.2, which only refers to offers created when <del> ICE has completed.  Each "a=rtcp" attribute line MUST also be filled in with the port and address of the appropriate default candidate, either the default RTP or RTCP candidate, depending on whether RTCP multiplexing is currently active or not.  Note that if RTCP multiplexing is being offered, but not yet active, the default RTCP candidate MUST be used, as indicated in RFC5761, section 5.1.3.  In each case, if no candidates of the desired type have yet been gathered, dummy values MUST be used, as described above. </del> <ins> ICE has completed.  In each case, if no RTP candidates have yet been gathered, dummy values MUST be used, as described above. </ins> Each "a=mid" line MUST stay the same.

Discussion:
LGTM
What needs to happen to finish this one ?
NAME NAME I think this reflects our discussion in the bug.
LGTM
NAME back at you
Ugh, git push failing due to airplane wifi. Will update when it succeeds
done
Where are we on this. Is this waiting for justin ?
yes, we are waiting for justin
Change:
equivalent parameters.  The two Connections are otherwise independent. <del> TCP does not on its own preserve Message boundaries.  Calling "Send" on a TCP connection lays out the bytes on the TCP send stream without any other delineation.  Any Message marked as Final will cause TCP to send a FIN once the Message has been completely written. </del> <ins> SEND.TCP.  TCP does not on its own preserve Message boundaries. Calling "Send" on a TCP connection lays out the bytes on the TCP send stream without any other delineation.  Any Message marked as Final will cause TCP to send a FIN once the Message has been completely written, by calling CLOSE.TCP immediately upon successful termination of SEND.TCP. </ins> <del> TCP delivers a stream of bytes without any Message delineation. All data delivered in the "Received" or "ReceivedPartial" event will be part of a single stream-wide Message that is marked Final (unless a MessageFramer is used).  EndOfMessage will be delivered when the TCP Connection has received a FIN from the peer. </del> <ins> With RECEIVE.TCP, TCP delivers a stream of bytes without any Message delineation.  All data delivered in the "Received" or "ReceivedPartial" event will be part of a single stream-wide Message that is marked Final (unless a MessageFramer is used). EndOfMessage will be delivered when the TCP Connection has received a FIN (CLOSE-EVENT.TCP or ABORT-EVENT.TCP) from the peer. </ins> Calling "Close" on a TCP Connection indicates that the Connection <del> should be gracefully closed by sending a FIN to the peer and waiting for a FIN-ACK before delivering the "Closed" event. </del> <ins> should be gracefully closed (CLOSE.TCP) by sending a FIN to the peer and waiting for a FIN-ACK before delivering the "Closed" event. </ins> Calling "Abort" on a TCP Connection indicates that the Connection <del> should be immediately closed by sending a RST to the peer. </del> <ins> should be immediately closed by sending a RST to the peer (ABORT.TCP). </ins> 9.2.

Discussion:
(SCTP mapping) This uses a new approach for such text for TCP, UDP and SCTP. Also: updates appendix D of interface.
We've updated Implementation mapping details for most protocols with , but we didn't tackle SCTP yet.
I'm fine with this being assigned to me. However, it's more than just writing the SCTP text. Here's the relevant part of what I wrote in PR : I don't suggest to delete much of the text that's there but definitely amend it with the RFC reference at least for what's covered in RFC 8303. There's a very direct line from this type of text in RFC 8303 to the original specs, so I do believe that should be helpful. That's (obviously) post-Montreal though!
NAME please send a PR along these lines.
Change:
3.2. The dynamic table consists of a list of field lines maintained in <del> first-in, first-out order.  Each HTTP/3 endpoint holds a dynamic table that is initially empty.  Entries are added by encoder instructions received on the encoder stream; see encoder- instructions. </del> <ins> first-in, first-out order.  A QPACK encoder and decoder share a dynamic table that is initially empty.  The encoder adds entries to the dynamic table and sends them to the decoder via instructions on the encoder stream; see encoder-instructions. </ins> The dynamic table can contain duplicate entries (i.e., entries with the same name and same value).  Therefore, duplicate entries MUST NOT

Discussion:
I opted to reframe the language from HTTP/3 endpoint to decoder, since encoder and decoder instances are what this spec primarily talks about. We already say that HTTP/3 endpoints contain both an encoder and a decoder. I also added a comment that encoders track the contents of the table at the decoder. I specifically did not say that they keep a full copy of the table, however; they might not.
NAME said:
NAME said: