jiebi/CodeConvo huggingface dataset:
Code change:
being carried in the other direction, this would not qualify as "Interactive". <ins> 2.2. The MOQ working group has used a wide variety of terms, with some, but not enough, effort to reconcile terms in use in various drafts. As these drafts are being adopted by the MOQ working group, it seems right to make every effort to align terminology for ease of reading and implementation. This draft does not yet, but will, align with the terminology defined in I-D.draft-ietf-moq-transport, as a starting point.  We note that -00 of that draft observes that the working group hasn't converged on terminology and definitions, and if MOQ terminology changes, the terminology in this draft will change accordingly. </ins> 3. Our goal in this section is to understand the range of use cases that

Related discussion:
text: Are there scenarios in which it would be useful to be able to ingest multiple MediaStreamTracks (either audio or video)? I ask because the RUSH draft doesn't support ingestion of multiple tracks and I've been told that this is a problem by some customers. Section 2.4 A media switch, sourcing tracks that represent a subset of tracks from across all the emitters. Such subset may represent tracks representing top 5 speakers at higher qualities and lot of other tracks for rest of the emitters at lower qualities. [BA] The use of the term "media switch" suggests to me that it is forwarding tracks, rather than sourcing (e.g. transcoding) them. Can you clarify? subscribing to subset of the tracks [BA] I think there may be an implicit assumption here, which is that the receiver only indicates the track it wishes to subscribe to, rather than indicating the quality it wishes to receive. Above setup brings in following properties on the data model for the transport protocol [BA] The paragraphs that follow appear to describe different ways that the system could be implemented, rather than "properties on the data model". Do you mean to say that the design should be able to handle any of the approaches described? Media Switches to source new tracks but retain media payload from the original emitters. This implies publishing new Track IDs sourced from the SFU, with object payload unchanged from the original emitters. [BA] Is the term "source new tracks" implied by changing the Track IDs? If the payload is retained, this seems like forwarding to me, rather than "sourcing new tracks". Media Switches to propogate subset of tracks as-is from the emitters to the subscribers. This implies Track IDs to be unchanged between the emitters and the receivers. [BA] What does "as-is" mean here? Are you referring only the lack of a change in the "Track ID"? If the switch drops some frames in order to reduce quality (and bandwidth consumption) is it still "as-is"? Subscribers to explictily request multiple appropriate qualities and dynamically move between the qualtiies during the course of the session [BA] Is it a goal to be able to support such a "receiver driven" approach, as well as the other two approaches, which are sender driven?
Code change:
being carried in the other direction, this would not qualify as "Interactive". <ins> 2.2. The MOQ working group has used a wide variety of terms, with some, but not enough, effort to reconcile terms in use in various drafts. As these drafts are being adopted by the MOQ working group, it seems right to make every effort to align terminology for ease of reading and implementation. This draft does not yet, but will, align with the terminology defined in I-D.draft-ietf-moq-transport, as a starting point.  We note that -00 of that draft observes that the working group hasn't converged on terminology and definitions, and if MOQ terminology changes, the terminology in this draft will change accordingly. </ins> 3. Our goal in this section is to understand the range of use cases that

Related discussion:
text: Section 3.1 For example, rather than waiting for 30 seconds before connecting, the user might quickly download the "key" frames of the past 30 seconds and replay them in order to "synchronize" the video decoder. [BA] I think this sentence points out that the term "access point" may need to be clarified, because in such a scenario, the term "access point" may have a different meaning in stored media than in media transmitted over the wire to speed up join latency. Section 3.2 It is possible to use groups as units of congestion control. When the sending strategy is understoud, the objects in the group can be assigned sequence numbers and drop priorities that capture the encoding dependencies, such that: an object can only have dependencies with other objects in the same group, an object can only have dependencies with other objects with lower sequence numbers, an object can only have dependencies with other objects with lower or equal drop priorities. [BA] This text seems to be mixing distinct concepts such as dependencies and layering. In layered coding, there is typically only a requirement not to depend on higher layers, but it's possible to depend on frames in lower layers. Mixing drop priority (a transport concept) with groups seems confusing to me. The main drawback is that if a packet with a given drop priority is actually dropped, all objects with higher sequence numbers and higher or equal drop priorities in the same group must be dropped. [BA] Leaving gaps in the sequence number space does seem problematic, but that's a choice, not a requirement. If the group duration is long, this means that the quality of experience may be lowered for a long time after a brief congestion. If the group duration is short, this can produce a jarring effect in which the quality of experience drops perdiodically at the tail of the group. [BA] What does "group duration" mean? Are you referring to time between I-frames? This paragraph seems to assume that group duration is a constant rather than something which can be set dynamically. Section 4 Some video codecs have a complex structure. [BA] Are you referring to codecs, or encodings? It would send for example: [BA] A picture might help here.
Code change:
being carried in the other direction, this would not qualify as "Interactive". <ins> 2.2. The MOQ working group has used a wide variety of terms, with some, but not enough, effort to reconcile terms in use in various drafts. As these drafts are being adopted by the MOQ working group, it seems right to make every effort to align terminology for ease of reading and implementation. This draft does not yet, but will, align with the terminology defined in I-D.draft-ietf-moq-transport, as a starting point.  We note that -00 of that draft observes that the working group hasn't converged on terminology and definitions, and if MOQ terminology changes, the terminology in this draft will change accordingly. </ins> 3. Our goal in this section is to understand the range of use cases that

Related discussion:
text: I think you're referring to the scalabilty mode known as "L2T2h": URL Of course, we could encode these dependencies as properties of the object being sent, stating for example that "object 17 can only be decoded if objects 16, 11 and 7 are available." However, this approach leads to a lot of complexity in relays. We believe that a linear approach is preferable, using attributes of objects like delivery order or priorities. [BA] Why would this lead to complexity in relays in a receiver-driven scenario? The relay would only forward the layers that the receiver asked for, and wouldn't have to store state relating to the receivers. Also, the real issue here isn't dropping layers, which can occur at any point. The reason dependencies (and more) are needed (and why the "linear approach" doesn't work) comes when it is desired to add layers. It is of course possible just to start forwarding additional layers, but that doesn't improve quality unless the forwarded frames can actually be decoded. To figure this out, whoever is in charge (receiver or relay) needs to be able to determine the "upswitch points". This also implies feedback from the receivers to the encoder (e.g. LRR). Section 4.2 We propose to express dependencies using a combination of object number and object priority. [BA] How would this permit restoration of video quality after congestion clears up? I don't think you have enough information. Section 4.3 . Relay behavior In case of congestion, the relay will use the priorities to selectively drop the "least important" objects: [BA] Dropping is easy, it's adding layers back (and decoding them) that's hard.
Code change:
Append-only Log becomes immutable, and the Receipt provides universally-verifiable evidence of this property. <del> 5.2.3.2. </del> <ins> 5.2.4.2. </ins> There is no fork in the Append-only Log.  Everyone with access to its contents sees the same sequence of entries, and can check its

Related discussion:
text: Extending the architecture with Transparent Statements recording the Transparency Service configuration, notably its registration policy. The syntax of the configuration (notably its supported registration policies) are still TBC.
Code change:
the user agent MAY reuse the same credentials for all other requests within that protection space for a period of time determined by the authentication scheme, parameters, and/or user preferences (such as a <del> configurable inactivity timeout).  Unless specifically allowed by the authentication scheme, a single protection space cannot extend outside the scope of its server. </del> <ins> configurable inactivity timeout). The extent of a protection space, and therefore the requests to which credentials might be automatically applied, is not necessarily known to clients without additional information.  An authentication scheme might define parameters that describe the extent of a protection space.  Unless specifically allowed by the authentication scheme, a single protection space cannot extend outside the scope of its server. </ins> For historical reasons, a sender MUST only generate the quoted-string syntax.  Recipients might have to support both token and quoted-

Related discussion:
text: I think that this requires only that the text acknowledge this uncertainty and note that clients could decide to provide authentication information on every request made to the origin, without knowledge of the extent of the protection space. It might also note that particular authentication schemes might define mechanisms that allow clients to decide where to use credentials. RFC 7616 defines , which allows for scoping; RFC 7617 has a section on .
re the first point: we are defining the framework here; whether a scheme uses realm, and how exactly it is used, is out of scope here. What we do is reserve the parameter name "realm", and say what it is for. Could an auth scheme use it in credentials? I believe the answer is "yes".
I think both aspects are up to the authentication scheme in question. Martin, do you feel strongly about this, or can we close?
As you say, it's kinda up for grabs. The main spec isn't very satisfactory though in that it doesn't specify, but doesn't really admit to why that is. Maybe if I can be given a chance to think of some text for this and you can see if you like it.
Code change:
both the two-octet Request-ID as well as at least 96 bits of additional entropy. <ins> Upon receipt of a "CERTIFICATE_REQUEST" frame, the recipient MUST verify that the first two octets of the authenticator's "certificate_request_context" matches the Request-ID presented in the frame. </ins> The TLS library on the authenticating peer will provide mechanisms to select an appropriate certificate to respond to the transported request.  TLS libraries on servers MUST be able to recognize the

Related discussion:
text: Takes a dependency on URL
I think that it would be better to explicitly reference CERTIFICATE_REQUEST in the cases where a CERTIFICATE is generated directly in response to one. Using the "get context" API from exported authenticators is ugly. This is more important now that exported authenticators folds the request into the response. We probably want to use a flag for whether this is spontaneous so that we can avoid reserving a Request-ID for spontaneous CERTIFICATE messages.
I'm a little dubious about this. Having the same value transported in two different fields and then checking that they're equal seems potentially more error-prone than just transporting it in one place, even if that one place is by calling into a library to interpret for you.
For posterity, discussion in Montreal: Nice not to have to dig out the Request-ID. However, if you duplicate it, then you have to compare and check that they're equal, so you're still calling into TLS. There is an existing duplication in the CERTIFICATE_REQUEST, where the Request-ID is carried outside the EA.
Code change:
expiring as a dictionary in 7 days independent of the cache lifetime of the resource. <del> 2.1.7.2. </del> <ins> 2.1.6.2. </ins> A response that contained a response header:

Related discussion:
text: This changes the URLPattern match to use a single match pattern to be consistent with other uses of URLPattern.
NAME NAME this is an attempt at a change to have it use a single string for pattern construction. I don't feel great about the same-origin check part of the validation but I don't see why it wouldn't work. It still allows for people to waste bytes by not using path-relative patterns so I may have to re-open the issue around that but should provide the consistency you were asking for. This would be instead of PR .
a couple nitpicks while passing by
Code change:
header field as a set-cookie-string (defined below). NOTE: The algorithm below is more permissive than the grammar in <del> sane-set-cookie.  For example, the algorithm strips leading and trailing whitespace from the cookie name and value (but maintains internal whitespace), whereas the grammar in sane-set-cookie forbids whitespace in these positions.  In addition, the algorithm below accommodates some characters that are not cookie-octets according to the grammar in sane-set-cookie.  User agents use this algorithm so as </del> <ins> sane-set-cookie.  For example, the algorithm allows cookie-name to be comprised of cookie-octets instead of being a token as specified in sane-set-cookie and the algorithm accommodates some characters that are not cookie-octets according to the grammar in sane-set-cookie. In addition, the algorithm below also strips leading and trailing whitespace from the cookie name and value (but maintains internal whitespace), whereas the grammar in sane-set-cookie forbids whitespace in these positions.  User agents use this algorithm so as </ins> to interoperate with servers that do not follow the recommendations in sane-profile.

Related discussion:
text: This is a partial revert of 5469d51 from PR
Talked with NAME a moment ago. I think there are some additional changes that will be necessary, but I don't object to the idea of this revert. Seems like a mistake in the original PR.
Happy to amend the PR if you can give me an idea of what additional changes are required.
I wrote up a change that should cover all the points we want to make. Namely, we still want UAs to accept that larger character set while encouraging server to use the more limited character set.
This looks reasonable to me, thanks to you both.
Code change:
HTTP fields (HTTP) are conveyed by HTTP/2 in the HEADERS, CONTINUATION, and PUSH_PROMISE frames, compressed with COMPRESSION. <del> To improve efficiency and interoperability, field names MUST be converted to lowercase when constructing an HTTP/2 message. </del> <ins> Field names MUST be converted to lowercase when constructing an HTTP/2 message. </ins> 8.2.1.

Related discussion:
text: Just state it. No need to justify it so (especially as this invites questions about the claimed benefits). This is less than Julian wanted from , but I think that it is important to include a requirement like this very clearly and it isn't really said anywhere else. At least not directly.
converted to lowercase when constructing an HTTP/2 message. I think this is somewhat misleading, it just provides the motivation why the lowercase format was introduced initially. I would just remove the sentence and potentially insert a note about lower-casing into the field name validity statements.
Agreed, I don't think the spec needs to defend itself on this choice.
Code change:
header field (field.if-none-match) indicates that the client wants to validate one or more of its own stored responses in comparison to the <del> stored response selected by the cache (as per </del> <ins> stored response chosen by the cache (as per </ins> constructing.responses.from.caches). If an

Related discussion:
text: Me confused. Which PR is relevant now? Both?
The other one is an evolution of this one.
We use the phrases 'selected representation' and 'selected response' in Semantics and Caching (respectively) to refer to two completely different concepts. Can we do better?
No
I think the two concepts match pretty well (and are used correctly in the four sentences). However, I also think that "chosen response" would be okay given it is only used in four places. I really don't think it needs a separate definition, since it means what the two words mean. So, maybe.
It was actually used in a few more places as the response selected. I think I found all of them.
See .
Code change:
accepted? Re-negotiation in an existing protocol should be supported to allow <del> changes in what is being sent of received. </del> <ins> changes in what is being sent or received. 4.3.1. 4.3.2. 4.3.3. 4.3.4. 4.3.5. 4.3.6. 4.3.7. </ins> 4.4.

Related discussion:
text: NAME could you take a look at this? I know everyone's thinking has changed on details, but we can capture those changes as the working group converges.
The subsections should be Publishing Media Naming or Identification Packaging Media Media Consumption Relays/Caches End to End Security This is only a starting point, of course, but , and it's easier to keep track of them if the document subsections match, at least for now.
NAME - ISTM that the contain a lot of material that might better be put in another section. I'll work through that before we talk (next week, right?), but please keep this note in mind, so we can fix what I get wrong. Also - ISTM that we really do need a "specific protocol considerations" requirement section, to capture things like streams/datagrams, WebTransport/H3/QUIC, one MOQ protocol, etc. I'll add that in the PR for this issue as well.
NAME most of the sections had some beginning text (and I can't remember who wrote it - was it you?). I'm copying the bullets from NAME slides into each section as a starting point. I'm not sure whether deleting the beginning text is the right thing to do, because it might or might not match the resulting subsections' contents, and of course the new subsections don't have beginning text because they didn't exist before, but let's talk about that, next week.
Code change:
A name-value pair.  Both the name and value are treated as opaque sequences of octets. <del> The dynamic table (see dynamic.table) is a header table used to associate stored header fields to index values.  This table is dynamic and specific to an encoding or decoding context. </del> <ins> The dynamic table (see dynamic.table) is a table that associates stored header fields with index values.  This table is dynamic and specific to an encoding or decoding context. </ins> <del> The static table (see static.table) is a header table used to associate static header fields to index values.  This table is </del> <ins> The static table (see static.table) is a table that statically associates header fields with index values.  This table is </ins> ordered, read-only, always accessible, and may be shared amongst all encoding or decoding contexts.

Related discussion:
text: had a few actionable comments that seemed relatively easy to handle. In the absence of feedback from NAME and NAME I responded. Of note: the introductory text in URL about the choice to make the format inflexible.
Code change:
properties of that path can vary, with similar impacts on congestion control <del> 5.7. </del> <ins> 5.8. </ins> Multipath transport protocols permit more than one path to be differentiated and used by a single connection at the sender.  A

Related discussion:
text: Created a separate issue to discuss ECN.
The guideline section discusses "Investigating a Range of Environments", with a focus especially on "Random Early Detection (RED) ] and Drop-Tail." The IETF and the IRTF have produced several different proposals for Active Queue management, with somewhat different characteristics. Interestingly, there is a tension there between developing Queue Management that "plays well" with existing congestion control algorithms, and developing congestion control algorithms that "take advantage" of AQM. Not sure what to say there, but at a minimum we should develop expectations about "signals" produced by AQM (e.g., the ECN markings of L4S) and reaction by congestion control algorithms. To go further, the could be a discussion of "honest signals", such as delays, that are very hard to "fake" in routing nodes, other signals such as ECN marks that could be produced by the network at very little cost, and packet losses that fall kind of in between. But we are not writing for the IRTF, so this could be kept brief.
On the topic of AQM, IETF published Characterization Guidelines (RFC7928) and Recommendations (RFC7567) that could be exploited for further discussions in this work.
Martin and Gorry: add a reference to 7567 to AQM behavior and evaluation criteria, which is not in scope for this document talk about evaluating CC interaction with AQM
Something like "CCs should be evaluated against AQMs that are prevalent in the internet" -- is there a reference that provides a taxonomy?
Editors: FQ-CoDel, PIE, L4S (RFC9332) have RFCs Are the others that should be evaluated, and do they have available specs?
Discussed at IETF 118: Many operators are not particularly aware of AQM or these concepts in general Include FIFO in the list Also do at least an AQM "you should evaluate the scenario with FIFO queues and should also consider the impact of various common AQMs and run detailed simulations against them", while maybe name-checking a few particularly relevant ones. Yes, should have criteria for this, and also should not ask people to run NxN interop matrix. Out of scope to mandate AQM
I suggest: Probably ought to include a suitably configured RED also.
Code change:
properties of that path can vary, with similar impacts on congestion control <del> 5.7. </del> <ins> 5.8. </ins> Multipath transport protocols permit more than one path to be differentiated and used by a single connection at the sender.  A

Related discussion:
text: ... and not suggest ALL of these need to be checked, more encourage consider AQM and FIFO scenarios.
I fixed a typo, but otherwise this looks good.
Code change:
properties of that path can vary, with similar impacts on congestion control <del> 5.7. </del> <ins> 5.8. </ins> Multipath transport protocols permit more than one path to be differentiated and used by a single connection at the sender.  A

Related discussion:
text: Editors: just focus on what needs to be evaluated (the last sentence) and toss the rest. We are not going to satisfy anyone with a discussion of the bigger picture.
In the Internet, most connections never exit Slow-Start. RFC 5033 kind of explicitly focuses on the long duration connections, because at the time of writing the accepted rule was that the 10% long duration connections were were causing 90% of traffic. I don't know whether that's still true.
With the usage of QUIC, more short-lived connections are aggregated into a long connection.
Looks OKThanks for updating this.