jiebi/CodeConvo huggingface dataset:
Code change:
Subscribe ID: Subscription Identifer as defined in message- subscribe-req. <del> Track Namespace: Identifies the namespace of the track as defined in (track-name). Track Name: Identifies the track name as defined in (track-name). </del> Expires: Time in milliseconds after which the subscription is no longer valid.  A value of 0 indicates that the subscription stays active until it is explicitly unsubscribed.

Related discussion:
text: This PR
Track namespace and track name properties were removed from SUBSCRIBEOK message in draft 02. But they are still part of the text under "6.5. SUBSCRIBEOK" which is confusing.
Code change:
Any number of HEADERS frames can may be sent on an existing stream at any time. <del> Additional type-specific flags for the HEADERS frame are: </del> <ins> The HEADERS frame defines the following flags: Bit 1 being set indicates that this frame is the last that the endpoint will send for the identified stream.  Setting this flag causes the stream to enter the StreamHalfClose. Bit 2 is reserved for future use. </ins> The END_HEADERS bit indicates that this frame contains the entire payload necessary to provide a complete set of headers.

Related discussion:
text: Also reservers flag 0x2 in DATA and HEADERS frames and renumbers flags accordingly.
Please feel free to exercise editorial privilege with respect to wording. Reserving 0x2 at NAME requests.
Code change:
An endpoint receiving a frame that changes the priority of a closed stream SHOULD alter the <del> weight of the priority group, or the dependencies of the streams that depend on it, if it has retained enough state to do so. Priority group information is part of the priority state of a stream. Priority groups that contain only closed streams can be assigned a weight of zero. </del> <ins> dependencies of the streams that depend on it, if it has retained enough state to do so. </ins> <del> The number of priority groups cannot exceed the number of non-closed streams.  This includes streams in the "reserved" state.  Priority state size for peer-initiated streams is limited by the value of .  Reserved streams do not count toward the concurrent stream limit of either peer, but only the endpoint that creates the reservation needs to maintain priority information.  Thus, the total amount of priority state for non-closed streams can be limited by an endpoint. 5.3.5. </del> <ins> 5.3.4. </ins> <del> Providing priority information is optional.  Streams are assigned to a priority group with an identifier equal to the stream identifier and a weight of 16. </del> <ins> Providing priority information is optional.  Streams are assigned a dependency on the connection with a weight of 16. </ins> <del> PushResources initially depend on their associated stream. </del> <ins> PushResources initially depend on their associated stream with a weight of 16. </ins> 5.4.

Related discussion:
text: NAME I would add an explicit hint to implementers that having more than 8 bits of internal precision is a good thing. NAME I think we should leave open the possibility to insert a new stream between the connexion and all its children, even if it's probably a large re-prioritization.
I think large re-prioritization is not a problem. If proxy gets such requests and it aggregates several frontend connections to single backend connection, inserting under stream 0x0 with exclusive flag set seems to be impossible in backend.
If it aggregates to a different backend connection it is not impossible to proxy. Consider streams A and B depend on stream 0x0 and are proxied to some backend connection as streams X and Y. If we get a new streams, C, that exclusively depends on 0x0, we can proxy it as stream Z by dropping the exclusive dependency and then re-prioritizing streams X and Y to depend on stream Z.
Yes, it works like that. But if we just don't allow 0x0 with exclusive dependency, we can do all priority stuff via proxy without doing any extra handling except for stream ID mappings.
Yep, true -- I don't have much of a preference -- if clients feel like it is not an important use case than I am perfectly happy to disallow it.
Is it possible to move this discussion to the mailing list? If you need comments from a client, I'm happy to take a look later. On Tue Apr 15 2014 at 9:39:56 AM, Jeff Pinner EMAIL wrote:
Code change:
about how a server should use size, type or any other input to decide how to prioritize. <del> The following examples demonstrate how a server that strictly abides the scheduling guidance based on urgency and request generation order could find that early requests prevent serving of later requests. </del> <ins> There can be scenarios where a server will need to schedule multiple incremental and non-incremental responses at the same urgency level. Strictly abiding the scheduling guidance based on urgency and request generation order might lead to sub-optimal results at the client, as early non-incremental responses might prevent serving of incremental responses issued later.  The following are examples of such challenges. </ins> At the same urgency level, a non-incremental request for a large resource followed by an incremental request for a small resource.

Related discussion:
text: As described on the issue, there are many permutations of this and we'll encounter heat death if we try to explain everything. This change pulls a Captain Kirk.
Thank you!
Paraphrasing NAME S 10 is still somewhat ambiguous on what to do if you have both non-incremental and incremental resources at the same urgency level. There is no single correct answer here, and the "starvation" text partially addresses this, but I'm not sure that's enough. Maybe explicitly pointing out the situation and saying no guidance is given? Editors suggestion here is NOT to add any more normative guidance but to provide a better linkage between the the paragraphs that touch on these matters.
I still personally feel it would be good to call out this specific situation, since it's an edge case you probably -will- encounter and for which you need to (in my opinion) make a conscious decision. The starvation text already calls out other examples, so I feel this edge case could also use some text.
Code change:
Abstract <del> This document clarifies the use of TLS 1.3 post-handshake authentication and key update with HTTP/2. </del> <ins> This document updates HTTP/2 to prohibit TLS 1.3 post-handshake authentication, as an analog to existing TLS 1.2 renegotiation restriction. </ins> Note to Readers

Related discussion:
text: This addresses feedback from the list: URL URL NAME NAME does this look good to you?
Very nice, thanks. You almost managed to do this with a net reduction in total lines. The only additions here are my fault. Respect.
Code change:
advertisement breaks).  The use of "live rewind" where a window of media between the live edge and trailing edge can be made available for clients to playback, either because the local player falls behind <del> edge or because the viewer wishes to play back from a point in the past. </del> <ins> the leading edge or because the viewer wishes to play back from a point in the past. 3.3. For the video conferencing/telephony use case, there can be additional scenarios where the audience greatly outnumbers the concurrent active participants, but any member of the audience could participate.  This use case can have an audience as large as Live Media Streaming as described in lmstream, but also relies on the interactivity and bi-directionality of conferencing as in Video Conferencing as described in vidconf.  For this reason, this type of use case can be considered a "hybrid".  There can be additional functionality as well that overlap between the two, such as "live rewind", or recording abilities. Another consideration is the limits of "human bandwidth" - as the number of sources are included into a given session increase, the amount of media that can usefully understood by a single person diminishes.  To put it more simply - too many people talking at once is much more difficult to understand than one person speaking at a time, and this varies on the audience and circumstance.  Subsequently this will define some limitations in the number of potential concurrent or semi-concurrent, bidirectional communications that occur. </ins> 4.

Related discussion:
text: In 4.9.1, "this is infeasible in many use cases where provisioning of client TLS certificates is unsupported or infeasible." has two "infeasible"s. Perhaps one could be "impractical"? Your choice which, of course.
In submitting the -00 working group version, we tripped over an incompatibility between XML2RFC and google-i18n-address 3.0.0. The details are at URL and at URL I took the shortcut of removing the country: attributes for the authors in -00, but (per the comments on those issues, a version of XML2RFC that has been deployed, so we can add our country attributes back when we're fixing the nits identified in this issue. And NAME says it's "The Netherlands", but I'll let NAME and NAME wrestile that one out ... :zippermouthface:
Code change:
Announce Error codes <ins> Announce Cancel Reason codes </ins> Message types TODO: register the URI scheme and the ALPN

Related discussion:
text: It's meant to be sent by the subscriber, indicating that the announce is no longer accepted. The fields should mirror ANNOUNCE_ERROR so the subscriber can indicate stuff like authentication expired, another announce was received, etc.
LG, but I noticed: "If a publisher receives new subscriptions for that namespace after receiving an ANNOUNCECANCEL, it SHOULD close the session as a 'Protocol Violation'." I believe that's racy, because the SUBSCRIBE and ANNOUNCECANCEL can be inflight at the same time? Also, shouldn't it be "after sending an ANNOUNCE_CANCEL", or am I misunderstanding the text?lgtm
Code change:
Announce Error codes <ins> Announce Cancel Reason codes </ins> Message types TODO: register the URI scheme and the ALPN

Related discussion:
text: Many thanks on review and any help of fixing all the small stuff (point me too it, or PR on the PR, anything) much appreciated.
NAME - thanks for review. I think I fixed all the stuff you raised. Can you take another look NAME - handing the baton to you on this one. Thanks you
At interim, to support make before break use-cases, we need to clarify relay behavior when a new announce arrives for existing published.
This came up during discussion of . The current draft is ambiguous whether multiple distinct publishers (not reconnect) can announce the same namespace to a relay. If that is allowed, should SUBSCRIBE messages be sent to all publishers that have announced that namespace? What happens if multiple SUBSCRIBE_OKs come back? Do we need normative text describing how a relay handles all these situations, or is it implementation specific? Some possible error conditions: Two publishers publisher the same track/group/object with different content One publisher skips an object (perhaps due to a delivery timeout) but another publisher sends it ?
I initially added a recommended session migration algorithm in . However it's too prescriptive and non-normative and I removed it. However I do think we should talk about what it takes to gracefully migrate a MoqTransport session, if it's non-obvious and should be in the draft (maybe an appendix), and if we need more mechanisms in the protocol. This recommended algorithm requires servers to not error on a duplicate ANNOUNCE. It also results in an RTT where duplicate OBJECTs will arrive on both sessions, which is not necessarily ideal. Here's the original text before I removed it:
I think it'd be useful to have a PR to look at if you're willing to write one up?
Code change:
An origin server that receives an If-Modified-Since header field SHOULD evaluate the condition as per evaluation prior to performing <del> the method.  The origin server SHOULD NOT perform the requested method if the selected representation's last modification date is earlier than or equal to the date provided in the field value; instead, the origin server SHOULD generate a </del> <ins> the method. To evaluate a received If-Modified-Since header field: An origin server SHOULD NOT perform the requested method if a received If-Modified-Since condition evaluates to false; instead, the origin server SHOULD generate a </ins> response, including only those metadata that are useful for identifying or updating a previously cached response.

Related discussion:
text: They're still requirements, and without the changes, we don't explicitly say how to evaluate the conditionals; elsewhere (e.g., we refer to them as evaluating to either true or false, hence these changes.
I see. Maybe a less intrusive change would be to say: "... The origin server SHOULD NOT perform the requested method if the condition evaluates to false: the selected representation's last modification date is earlier than or equal to the date provided in the field value; instead, the origin server SHOULD generate a 304 (Not Modified) response, including only those metadata that are useful for identifying or updating a previously cached response."
re-specifies precondition processing from . E.g., [...] Do we want to try to fold these into Semantics so that it isn't duplicated? That would require some small adjustments to Semantics AFAICT (e.g., to make it clear what the selected representation is in each case, etc.).
Why not just end each first sentence with ", as defined in Section X.x of Semantics." and remove the rest?
Er, never mind ... having looked at the full section, I think this should stay as is because it is refining the requirements in terms of the cache's stored responses.
I think we can close this. It isn't duplicated: Semantics already refers to this section to define cache handling.
Re-reading the current text, I think I'm finding it most disturbing that semantics 13.1.3 If-Modified-Since doesn't say how to evaluate the condition, whereas caching 4.3.2 does (but just for caches). I think it needs to be removed from caching and made generic. This is necessary because semantics 13.2 refers to evaluation in their algorithms. INM and if-match define how to evaluate, but IMS and IUS don't.
It defines it near the end of the section because of the etag discussion. Anyway, we can improve that.
I proposed a fix for that, but now that is proposed as well, some of the text in caching is clearly duplicative. Will adjust and push another commit or two; please review.
There is a larger problem here -- the section on evaluation was split into two sections (evaluation and precedence) but the conditionals only reference the first. This can be fixed by moving precedence back within evaluation with subsections for the other content in evaluation.
Code change:
An origin server that receives an If-Modified-Since header field SHOULD evaluate the condition as per evaluation prior to performing <del> the method.  The origin server SHOULD NOT perform the requested method if the selected representation's last modification date is earlier than or equal to the date provided in the field value; instead, the origin server SHOULD generate a </del> <ins> the method. To evaluate a received If-Modified-Since header field: An origin server SHOULD NOT perform the requested method if a received If-Modified-Since condition evaluates to false; instead, the origin server SHOULD generate a </ins> response, including only those metadata that are useful for identifying or updating a previously cached response.

Related discussion:
text: Okay, I have updated the PR to make evaluation one section (with two subsections), fixed a few typos, made the requirements self-descriptive, and updated If-Range to be consistent as well.
(but see comments)
Code change:
member, as described in trailer.fields. Additionally, specific HTTP versions can use it to indicate the <del> transfer codings the client is willing to accept in the response. </del> <ins> transfer codings the client is willing to accept in the response.  As of publication, only HTTP/1.1 uses transfer codings (see transfer.codings). </ins> The TE field value consists of a list of tokens, each allowing for optional parameters (except for the special case "trailers").

Related discussion:
text: "Additionally, specific HTTP versions can use it to indicate the transfer codings the client is willing to accept in the response." If we phrase it this way, we'd have to say somewhere in Semantics what transfer codings actually are. Or we decide that they are specific to HTTP/1.*, rephrase this, and link to Messaging.
Code change:
member, as described in trailer.fields. Additionally, specific HTTP versions can use it to indicate the <del> transfer codings the client is willing to accept in the response. </del> <ins> transfer codings the client is willing to accept in the response.  As of publication, only HTTP/1.1 uses transfer codings (see transfer.codings). </ins> The TE field value consists of a list of tokens, each allowing for optional parameters (except for the special case "trailers").

Related discussion:
text: Good point.
For .
URL be good to have tests...
goes back to URL
sent mail: URL
See URL
Proposal: leave weight in ABNF for consistency with other Accept-* fields change second requirement (on recipients) not to rely on "q" being last
Code change:
<del> Media Over QUIC - Use Cases and Considerations for Media Transport </del> <ins> Media Over QUIC - Use Cases and Requirements for Media Transport </ins> Protocol Design draft-gruessing-moq-requirements-latest

Related discussion:
text: Move "considerations" to a separate draft, and do various related cleanup work (for example, removing unneeded references that supported text that has been deleted.
(but document focus is on all media categories, not just live media) (moving the considerations section to its own draft) (moving this diagram to the considerations draft)
Our diagram shows "media transport protocol" as one layer, which can be true, but the text points out that anything running over HTTP/3, or even WebTransport over HTTP/3, will have multiple media transport protocols. It would be helpful for readers if we showed this.
Sports fans of this draft may remember that this section was called Requirements, and true sports fans may remember that the contents had changed very little from when James and I thought this draft would be focused on Interactive use cases - and now it's focused on live media use cases. Rather than go into the BOF with a "Requirements" section that was a natural attraction for protocol designers, and almost completely mistargeted, I provided text for some of the considerations that I could type off the top of my head, before the I-D deadline. The existing list of considerations is not a complete list, and some of the considerations that are described in this section are "To Do", where the first thing To Do is to decide whether that consideration is a consideration for Live Media. To mention one significant example, the discussion about WebTransport doesn't mention one of the biggest advantages - the use of existing CDN infrastructure for live media streaming. But there are other examples - and I may think about this issue, and let other people also provide thoughts here, before I try to resolve the issue with PRs. (tagging the group, so you can be thinking about this as well) NAME NAME NAME NAME NAME
NAME and NAME - It is occurring to me that all the use cases we're recommending in this draft, and all the use cases that are named in , are pointing towards LIVE media. This document is even explaining why we think that's what matters first.
Code change:
<del> Media Over QUIC - Use Cases and Considerations for Media Transport </del> <ins> Media Over QUIC - Use Cases and Requirements for Media Transport </ins> Protocol Design draft-gruessing-moq-requirements-latest

Related discussion:
text: If we renamed the document as "Live Media Over QUIC", it would be more accurate, and the BOF proponents could point to this draft and ask people with other use cases if their use cases overlap with the live media use cases, perhaps allowing the BOF to recommend doing the live media use cases in this draft, and inviting people to provide comments on this draft explaining their use cases, so the IESG would know what to do with them. Your thoughts?
I don't object to the name change but I don't feel strongly.
That name works for me too.
We should revisit after the BOF, when we know what the scope of the document will be. :sunglasses:
So, this is slightly more complicated than I had hoped. The use cases in the draft span "Media Over QUIC". The considerations (and, if we get that far, requirements) in the draft only cover "LIVE Media Over QUIC". So, let's leave this one open, until we find out the right thing to do, and then we can Do The Right Thing. :innocent:
I would propose we rename (again) to "Media over QUIC Use Cases and Requirements", for a few reasons: Scope of use cases that the WG will work on isn't yet settled, and it's likely that we may need to cover some (but not all) interactive use cases as well as hybrid interactive/live. I still think we should set the protocol requirements in the document - this frees up the charter to describe scope and milestone, and our draft (if WG adopted) to set the use cases and what we will require of the deliverables. If WG adopted, the details of what is in and out can be made via WG consensus. This follows a similar title format to and other documents like it. NAME thoughts?
Code change:
If char is a DIGIT, append it to input_number. <del> Else, if type is "integer" and char is ".", append char to input_number and set type to "decimal". </del> <ins> Else, if type is "integer" and char is ".": If input_number contains more than 12 characters, fail parsing. Otherwise, append char to input_number and set type to "decimal". </ins> Otherwise, prepend char to input_string, and exit the loop.

Related discussion:
text: Explicitly disallow thirteen digits before the dot.
NAME I think this is the right way to validate the number of digits in a decimal.