jiebi/CodeConvo huggingface dataset:
Code change:
6.3.2. <ins> Every Track has a single 'Object Forwarding Preference' and publishers MUST NOT mix different forwarding preferences within a single track.  If a subscriber receives different forwarding preferences for a track, it SHOULD close the session with an error of 'Protocol Violation'. </ins> An "OBJECT_STREAM" message carries a single object on a stream. There is no explicit length of the payload; it is determined by the end of the stream.  An "OBJECT_STREAM" message MUST be the first and

Related discussion:
text: Couple of observations what use-cases would involve same client sending multiple subscription hints at the same time ? Hints are read access points on the same track and if a client ask for multiple such points, it will get objects on the same track regardless .. how relays puts them together in such a case for a given client cannot be normatively specified NAME can you give me a concrete use-case example of "resolve all relative Subscribe Hints that were passed in the Subscribe" from a single client so that it helps understand the issue better. I personally don't think the issue being discussed is directly related to this ...
The use case of an edge relay forwarding simultaneous requests from multiple connected clients. This is a common use-case for any edge or fan-out relay.
Individual Comment: This is definitely one use case. Another is a client making two simultaneous subscriptions: eg live edge and range request starting some time in the past.
One thing that will not scale is every subscription needing to go back to the original publisher. Consider the cases of a million users are joining a session that starts at the top of the hour and that is published from a mobile device. I think that in any real system there is also going to be no single idea of the live edge. The live edge is relative to which relay you subscribed to. If the relay you are on is over a geo sync satellite, it is going to be behind ones that are not. So here is what I think we should do. We should not allow relative subscription to things in the past. I think the uses cases I have heard for this can be deal with as subscribe to live edge forward and as once the client find out what object that is, do an absolute subscribe for any data in the past to fill in buffers etc. So to be clear, no relative group or object sequences that are negative but still allows absolute. This seems to meet the use cases and remove a ton of edge case design problems. To be clear, I think we should be able to subscribe to the current group, but give me object 0 forward in that group. If it is a group per GOP, this allows one to get everything needed to decode the current frame.
But not every subscription has to go back to publisher. It only has to go back to a node that is already subscribed and understands the live edge. Furthermore, concurrent requests would be coalesced at each node.
Code change:
6.3.2. <ins> Every Track has a single 'Object Forwarding Preference' and publishers MUST NOT mix different forwarding preferences within a single track.  If a subscriber receives different forwarding preferences for a track, it SHOULD close the session with an error of 'Protocol Violation'. </ins> An "OBJECT_STREAM" message carries a single object on a stream. There is no explicit length of the payload; it is determined by the end of the stream.  An "OBJECT_STREAM" message MUST be the first and

Related discussion:
text: Imagine in the worst case that 1 million requests are made within 100ms to a (really powerful) edge. That edge would only forward one request to the origin. All the rest would be held pending that response. This is exactly what happens when a few million people ask for a live HAS stream. Due to fan out and request coalescing, the CDN only sends a few requests back to the actual origin.
Yeah exactly. Only the first SUBSCRIBE will propagate upstream and the SUBSCRIBEOK is used to bootstrap the live edge. The relay can infer the live edge while the single upstream subscribe remains active. Because of the SUBSCRIBEOK, the relay knows that the received OBJECT only gets forwarded to the first downstream subscribe. Otherwise it would have to guess the live edge. The relay keeps track of while the upstream subscription remains active. The initial value is set by but all future updates are based on received messages. This way is can map from relative->absolute and reply with without issuing a new upstream subscription.
For the original use-case reported on this issue, if there are multiple subscribes at a relay with varying relative offsets, the relay has no choice but to send each combination of subscribe and a given -ve relative offsite upstream since that identifies each unique data point in the track. This has couple of issues it doesn't scale across relays and also when there are very high rate of subscriptions across relays and clients it makes the lookup and state management complicated latencies across relays and client locations ends up producing varying results for the same query since it depends on when the query was made and how long would it take to for conferencing cases when there are multiple publishers who can be active (have live edge), unjoined yet ( so no live edge) , the expectation for subscribes to get a OK back from original publishers will not scale in terms of latency of joins The more i think of it, subscribing back into paste using a relative offsets and expecting the answer to be vetted by the original publisher "unnecessarily complicates the protocol".
The group sequence numbers are consistent between subscriptions . If a relay receives relative subscribes of -5,-3 and -1, all it has to is send a single subscribe upstream of -5. The response would give it the live edge group as well as all the content for the various subscriptions.
Code change:
6.3.2. <ins> Every Track has a single 'Object Forwarding Preference' and publishers MUST NOT mix different forwarding preferences within a single track.  If a subscriber receives different forwarding preferences for a track, it SHOULD close the session with an error of 'Protocol Violation'. </ins> An "OBJECT_STREAM" message carries a single object on a stream. There is no explicit length of the payload; it is determined by the end of the stream.  An "OBJECT_STREAM" message MUST be the first and

Related discussion:
text: If the subscriptions were -345, -2, -1, the relay could decide to make two subscriptions upstream - one for -345, the other for -2, because it didn't want to force the smaller relative subscriptions to wait for the larger one. The point is, this is optimization logic for the relay. It does have a choice in what subscriptions it sends upstream based on the timing and diversity of the input subscriptions. Why is the latency of the join affected? Consider a subscriber talking to an edge where the subscriber is 100ms away from the origin. We consider two scenarios: in the first case the subscriber receives a SUBSCRIBEOK immediately after subscribing but then waits 100ms for the audio and video to arrive from the origin. In the second case the the subscriber waits 100ms to receive SUBSCRIBEOK but it is immediately followed by the audio and video. So in both cases the subscriber gets its audio and video after 100ms. The media latency is consistent under either scenario.
If the relay logc is to send only a single subscribe upstream, then you don't need anything to be said in Subscribe OK either. Since when the first object arrives it can compute the live edge by adding 5 to the object being reported and the compute the absolute values for others (in this case for -3 and -1). That would definitely make things simpler for sure.
For cases where a client wants to go back 345 groups in past, i will be very much inclined to do an absolute request after learning the latest known state of the group as an end application OR something catalog can describe more information to make the right absolute request on the first go
It can't do this because the order of items it receives as Streams is not guaranteed. The origin may send the groups in order -5,-4,-3,-3,-1, but they could be received at the relay (or any hop) as -3, -5,-4,-1,-2. That's why you need an explicit notification from the origin as to where the live edge is. Only that plus the group sequence numbers allow the correct sequencing, not the order of arrival.
In this case there was just a single subscribe request with -5 was sent upstream, based on your explanation above. This avoids all the confusion which would happen when there are multiple inflight -ve offsets.
This seems like it will have many race conditions.
Code change:
6.3.2. <ins> Every Track has a single 'Object Forwarding Preference' and publishers MUST NOT mix different forwarding preferences within a single track.  If a subscriber receives different forwarding preferences for a track, it SHOULD close the session with an error of 'Protocol Violation'. </ins> An "OBJECT_STREAM" message carries a single object on a stream. There is no explicit length of the payload; it is determined by the end of the stream.  An "OBJECT_STREAM" message MUST be the first and

Related discussion:
text: It seems like it would be better to transfer this in the STREAMHEADERTRACK and equivalent. Thoughts on that ? I also worry about how long a subscribe would wait to find out this information - that seems like it could be problematic for the client knowing when to give up on a subscribe. Hopefully we can discuss in Denver
Code change:
6.3.2. <ins> Every Track has a single 'Object Forwarding Preference' and publishers MUST NOT mix different forwarding preferences within a single track.  If a subscriber receives different forwarding preferences for a track, it SHOULD close the session with an error of 'Protocol Violation'. </ins> An "OBJECT_STREAM" message carries a single object on a stream. There is no explicit length of the payload; it is determined by the end of the stream.  An "OBJECT_STREAM" message MUST be the first and

Related discussion:
text: This PR cleans up some nits to make all the places we use the RFC9000 encoding syntax valid, updates our extensions to it, and add a non normative summary of parts of the syntax we use. I don't think this is making any changes to anything on the wire or normative changes to spec other than the statement SHOULD use smallest number of bytes for variable length integers which RFC9000 only requires for some fields.
I am not in love with the ABNF idea, but this is non-controversial.
Code change:
6.3.2. <ins> Every Track has a single 'Object Forwarding Preference' and publishers MUST NOT mix different forwarding preferences within a single track.  If a subscriber receives different forwarding preferences for a track, it SHOULD close the session with an error of 'Protocol Violation'. </ins> An "OBJECT_STREAM" message carries a single object on a stream. There is no explicit length of the payload; it is determined by the end of the stream.  An "OBJECT_STREAM" message MUST be the first and

Related discussion:
text: They won't be wasted until we have 64 message types valid on unidirectional streams. We currently only have 3 valid messages types. I think you mean that we could save the message type byte if OBJECT is the only message allowed on unidirectional streams, but that's not forward-compatible.
Draft-02 strongly implies the forwarding preference is a per-object decision. thus the following sequences would be legal: [sequences are written as (group, object)] Stream 2: (0, 1), (0, 2) (0, 3) (0, 5) -- type is StreamHeaderGroup Stream 6: (0, 4) -- type is ObjectStream or Stream 2: (0, 0), (1, 0), (2, 0), (3, 0) -- type is StreamHeaderTrack Stream 6: (1,1) -- type is Object Stream etc. If someone can imagine a use case for this, that's great. If not, it would be easier to implement with different assumptions, e.g. (1) Forwarding preference is a track-level property. Thus the preference could be provided in the SUBSCRIBE_OK and we wouldn't evens strictly need four different object codepoints (though you would want the distinct formats, and might want to retain the codepoints for that reason) (2) Forwarding preference is group-level -- some groups could be aggregated under StreamHeaderTrack, but others could be under StreamHeaderGroup. If there is a StreamHeaderGroup for a group, there MUST NOT be object-level streams for that group. Again, I have little sense of the use cases out there, but I think we should explicitly decide what we are doing and make it clear in the doc.
A related question is whether forwarding preference applies across subscribes. That is, for per-group streams, a current subscriber gets all of group 12 and then the stream closes. a later subscribe in the same session asks for group 12. Obviously, this will need a new stream. So maybe the answer is no, it does not apply across subscribes
I agree, this is very difficult for a decoder to support. The target use-case is non-reference frames. In your first example, object 4 is optional so it gets its own stream.
Code change:
6.3.2. <ins> Every Track has a single 'Object Forwarding Preference' and publishers MUST NOT mix different forwarding preferences within a single track.  If a subscriber receives different forwarding preferences for a track, it SHOULD close the session with an error of 'Protocol Violation'. </ins> An "OBJECT_STREAM" message carries a single object on a stream. There is no explicit length of the payload; it is determined by the end of the stream.  An "OBJECT_STREAM" message MUST be the first and

Related discussion:
text: However the receiver doesn't know that, instead it just sees a gap between 3 and 5. Does the receiver try to decode and catch any errors? How long does it wait before trying? If I want minimal latency, do I have to partially decode (on a per codec basis) to get the frame dependency graph? I really don't like this option. I instead want an explicit way to know that this object is a non-reference frame. Ideas: Make a separate track for non-reference frames and SVC layers. Receive a formula that every 3x+1 object is optional? Receive a live object catalog containing metadata about each object. My vote is a separate track and each track has a uniform forwarding preference.
I like the idea of uniform forwrarding preference for a track. That's what I had in mind when we landed that PR. I can't think of any use cases this restriction prevents.
I think the consensus in Denver was to have one preference per track
just to be clear , the preference is set as track level property and can have 4 values - track, object, group and datagram.
Yes, although for various reasons the PR I'm doing is going to make it subscription-level property. I think is hard to write it otherwise, and I can just about see a use case for it.
When a few of us discussed it last week, the feeling was that if it came back in the SUBSCRIBEOK, and Objects started arriving before the SUBSCRIBEOK, the receiver wouldn't know how to process the incoming Objects. In the past, we've decided we don't like that, so the feeling was to land a PR to add the restriction now, and then we can talk more about wire format changes. NAME Is Object decoding not an issue for some reason I'm forgetting? Or were you thinking that buffering Objects was fine?
I am arguing that buffering objects is fine. The usual case, I think, is that SUBSCRIBE_OK arrives first. It's irritating we're using a byte in the object encoding (and creating new error conditions to check for) just to avoid buffering. But I can live with keeping it for now.
This is an improvement, though I would still like to get rid of all the wasted bits
Code change:
Abstract This document describes how "http" URIs can be accessed using <del> Transport Layer Security (TLS) to mitigate pervasive monitoring attacks. </del> <ins> Transport Layer Security (TLS) in HTTP/2 to mitigate pervasive monitoring attacks. </ins> Note to Readers

Related discussion:
text: NAME thoughts?
Seems fine, with the edits Mark suggested. I'll merge and make those changes unless Paul gets to it first.
Looks pretty good to me, some tweaks here.
Code change:
frame. <del> The HTTP/1.1 request that is sent prior to upgrade is assigned stream identifier 1 and is assigned pri-default.  Stream 1 is implicitly half closed from the client toward the server, since the request is completed as an HTTP/1.1 request.  After commencing the HTTP/2 connection, stream 1 is used for the response. </del> <ins> The HTTP/1.1 request that is sent prior to upgrade is assigned a stream identifier of 1 (see StreamIdentifiers) with pri-default. Stream 1 is implicitly "half closed" from the client toward the server (see StreamStates), since the request is completed as an HTTP/1.1 request.  After commencing the HTTP/2 connection, stream 1 is used for the response. </ins> 3.2.1.

Related discussion:
text: Fixes for those things that were obviously busted. Which (I hope) addresses the comments, with one exception (Richard's discuss contained suggested edits that should clear that one up).
Code change:
server MUST reply with one of the versions offered by the client.  If the server does not support any of the versions offered by the client, or the client receives a server version that it did not <del> offer, the corresponding peer MUST close the connection. </del> <ins> offer, the corresponding peer MUST close the session. </ins> [[RFC editor: please remove the remainder of this section before publication.]]

Related discussion:
text: I also wonder if Connection URL should be renamed to Session URL?
Part of PR has text "MUST close the connection if there are duplicates" It seems like we should be closing the session, and we should specify an error code.
I think this is editorial, but unsure because of "specify an error code"
I would prefer: instead of:
Code change:
5.1. An origin can reduce the risk of attacks on opportunistically secured <del> connections by committing to provide an secured, authenticated </del> <ins> connections by committing to provide a secured, authenticated </ins> alternative service.  This is done by including the optional "commit" member in the http-opportunistic well-known resource (see well- known).  This feature is optional due to the requirement for server

Related discussion:
text: I think that I caught everything in the first round of discussion. There aren't any substantial changes here, but it's a PR so that others can confirm.
Code change:
Digest Algorithm: unixcksum <del> Description: The algorithm computed by the UNIX "cksum" command, as defined by the Single UNIX Specification, Version 2 </del> <ins> Description: The algorithm used by the UNIX "cksum" command </ins> UNIX.  The output of this algorithm is an ASCII digit string representing the 32-bit CRC, which is the first word of the output of the UNIX "cksum" command.

Related discussion:
text: There's not really any reason to describe anything other than the algorithm used and the format of encoding.
From NAME WGLC review This seems like cruft. The important things for the table are clear pointers to the algorithm definition and the encoding of values created by the algorithm.
If it's not broken, don't fix it :P I think we spent too much time wrt old algorithms. I'm in favor of anyone that wants to provide a PR that has consensus.
It is broken -- let's fix it. :)
LGTM
Code change:
unsupported-algorithm.  It is not a protocol error if preferences are ignored.  Applications that use Integrity fields and Integrity preferences can define expectations or constraints that operate in <del> addition to this specification.  How to deal with ignored preferences is a scenario that should be considered. </del> <ins> addition to this specification.  Ignored preferences are an application-specific concern. </ins> "Want-Content-Digest" and "Want-Repr-Digest" are of type "Dictionary" where each:

Related discussion:
text: Apologies in advance.
No apology needed. I stuttered over this same sentence yesterday when fixing an unrelated nit. I almost changed it then but didn't want to mix concerns. Given that somebody else has raised a comment and provided an alternative I agree with, leads me to believe its worth fixing. Thanks.
Much cleaner, +1
Code change:
The "next-hop-aliases" parameter does not include any DNSSEC information or imply that DNSSEC was used.  The information included in the parameter can only be trusted to be valid insofar as the <del> client trusts its proxy to provide accurate information.  This </del> <ins> client trusts the proxy to provide accurate information.  This </ins> information is intended to be used as a hint, and SHOULD NOT be used for making security decisions about the identity of a resource accessed through the proxy. <ins> Inspecting CNAME chains can be used to detect cloaking of trackers or malicious hosts.  However, the CNAME records could be omitted by a recursive or authoritative resolver that is trying to hide this form of cloaking.  In particular, recursive or authoritative resolvers can omit these records for both clients directly performing DNS name resolution and proxies performing DNS name resolution on behalf of client.  A malicious proxy could also choose to not report these CNAME chains in order to hide the cloaking.  In general, clients can trust information included (or not included) in the "next-hop- aliases" parameter to the degree that the proxy and any resolvers used by the proxy are trusted. </ins> 5. This document registers the "next-hop-aliases" parameter in the "HTTP

Related discussion:
text: NAME please take a look!
Without going through a proxy, clients implement CNAME cloaking mitigations on the basis of DNS information they see during resolution, which is totally reasonable. If resolution is subverted (or whatever) and the CNAME information is modified, these client checks might not work. When going through a proxy, the proxy is the one doing DNS resolution, so it seems like any sort of funny business that one might do to DNS answers for the proxy might affect the client's ability to implement cloaking mitigations correctly. The security considerations might benefit from a bit of expansion to cover this additional aspect of the threat model.
Code change:
This document establishes a registry for HTTP/2 settings.  The "HTTP/2 Settings" registry manages a 16-bit space.  The "HTTP/2 <del> Settings" registry operates under the RFC8126. </del> <ins> Settings" registry operates under the "Expert Review" policy (RFC8126). </ins> New registrations are advised to provide the following information:

Related discussion:
text: Followup for .
The code for the IANA policies in Section 11.1 looks like this: This document establishes a registry for HTTP/2 frame type codes. The "HTTP/2 Frame Type" registry manages an 8-bit space. The "HTTP/2 Frame Type" registry operates under either of the "IETF Review" or "IESG Approval" policies. That would be fine if that rendered as I would expect, as: Instead, it renders this way: That word ordering doesn't make sense. I'm not sure exactly what XML magic would be needed to produce the expected sentence order. Same thing occurs in Sections 11.2-4.
appears to fix only Section 11.1.
Code change:
use the connection established through the proxy, but need to gracefully handle situations in which this parameter is not present. <ins> The proxy MAY send the empty string ("") as the value of "next-hop- aliases" to indicate that no CNAME records were encountered when resolving the next hop's name. </ins> 3. The "next-hop-aliases" parameter does not include any DNSSEC

Related discussion:
text: Since next-hop-aliases is a String parameter, the syntax allows an empty string . In cases where there is no chain, is it advisable to send the empty string to indicate this, rather than omitting the parameter? If so, it might help to add a sentence somewhere that highlights this usage type.
That's a good question! I don't think there needs to be a normative requirement here, but I think it's reasonable to have signify that there were no aliases.
This mention is clear. LGTM