jiebi/CodeConvo huggingface dataset:
Code change:
within the subscription range is forwarded to each active subscriber, dependent on the congestion response.  A subscription remains active until it expires, until the publisher of the track terminates the <del> track with a SUBSCRIBE_FIN (see message-subscribe-fin) or a SUBSCRIBE_RESET (see message-subscribe-reset). </del> <ins> track with a SUBSCRIBE_DONE (see message-subscribe-done). </ins> Objects MUST NOT be sent for unsuccessful subscriptions, and if a subscriber receives a SUBSCRIBE_ERROR after receiving objects, it

Related discussion:
text: I'm leaning towards CLOSED instead of CLOSE because CLOSE implies its a requested action, so to me SUBSCRIBE_CLOSE sounds like something the subscriber would send, not the publisher. For a similar reason, I like CANCEL slightly better than STOP, but both work. UNANNOUNCE and UNSUBSCRIBE are good words, but I think it's better to follow a pattern in this case and I like NAME sequence of messages.
NAME CANCEL and CLOSED are slightly better, sure. NAME there MUST still be an OK before objects can be sent. That way the receiver can tell upon receipt of the CLOSED if the subscription was ever active.
So to add an OK, we need to add another state. The question for me is what is the use case where we need to deliver that information in the end of the subscribe.
This discusion is probably easier looking at state machine diagrams
Sections 6.8 and 6.9 strongly imply that SUBSCRIBEFIN/RST are sent at the true end of the track. So are they not sent at the conclusion of a SUBSCRIBE that does not cover the end of the track? For example, if the last object of a track is (10, 12), and there's one subscribe for (4,0) to (5, 100) Is there a SUBSCRIBEFIN? If not, how does the subscriber know that in fact (5, 60) is the last object in that subscription? If so, does Final Group and Final Object refer to the last object in the subscription?
Individual Comment: Putting my HTTP hat on for a second, when you ask for something with unknown length, you infer from a graceful termination that the last thing you got was the true end of that resource. If you send a range request, the graceful termination at the end does not convey that the last thing was the true end. Once the object expires, you can issue another request to the same name and potentially get a totally different thing. Does this model work for moq, or do we need something different?
There are three different things you might want to communicate to a receiver at the end of the subscribe: 1) You got all of the objects in the range; 2) You got almost all of the objects, but some were dropped for latency/bandwidth reasons 3) The track was truncated for some reason and possibly, 4?
Code change:
within the subscription range is forwarded to each active subscriber, dependent on the congestion response.  A subscription remains active until it expires, until the publisher of the track terminates the <del> track with a SUBSCRIBE_FIN (see message-subscribe-fin) or a SUBSCRIBE_RESET (see message-subscribe-reset). </del> <ins> track with a SUBSCRIBE_DONE (see message-subscribe-done). </ins> Objects MUST NOT be sent for unsuccessful subscriptions, and if a subscriber receives a SUBSCRIBE_ERROR after receiving objects, it

Related discussion:
text: 4) You got everything I have but i'm not sure if that's everything
is somewhat relevant to this issue.
As mentioned in , there are 3 different ways for a publisher to close a subscriber, each with minor differences. : I never sent you an object. : There are no more objects to send after group/object X/Y. : There are more objects after group/object X/Y... but I won't send them. A few things: I think it should be renamed since it's not the only ERROR message. Maybe ? The only difference is that one has an error code. Otherwise they both include a final group/object and it's up to the application/library to decide if they wait for the final object(s). I'd like to only implement this once but right now I have to copy/paste any code to handle these almost identical messages. What if we merged them and use error code 0 to signal a FIN. The reason phrase should be removed as part of . There really needs to be a state machine like with this many ways to terminate a subscription. I think these are all protocol violations: then then then My interpretation of the draft is that a followed by a is invalid, which is not obvious and unlike QUIC. I don't think so. The library/relay behavior doesn't change based on . The only thing that miiiight differentiate between the two is the application, which can use errors codes for this purpose. At the very least I would merge these two messages. But I would also like to explore a single way for the publisher to close a subscription. The application can signal the nuanced differences between errors (ex. error code 404 vs 410). The library/relay doesn't care, it just forwards the error code.
Individual Comment: The inspiration for FIN vs RST in moq came from HTTP caching. If a resource has no content-length, and the caching proxy has received N bytes, does it have the entire resource, or does it need to refetch the tail? If that response was terminated with a FIN (H2 or H3), then it has the whole resource. If it was terminated by a RST, it can't assume that it does. So the value I see in these two messages is for a moq relay is similar.
Code change:
within the subscription range is forwarded to each active subscriber, dependent on the congestion response.  A subscription remains active until it expires, until the publisher of the track terminates the <del> track with a SUBSCRIBE_FIN (see message-subscribe-fin) or a SUBSCRIBE_RESET (see message-subscribe-reset). </del> <ins> track with a SUBSCRIBE_DONE (see message-subscribe-done). </ins> Objects MUST NOT be sent for unsuccessful subscriptions, and if a subscriber receives a SUBSCRIBE_ERROR after receiving objects, it

Related discussion:
text: A client connected to the relay and subscribed to a track, which fowarded the subscribe to a publisher. The track was published to the relay and ended with a FIN. Another client subscribes to this track from the beginning (Absolute/0,0) and no end. Does the relay need to resubscribe upstream? Now suppose that the connection from the publisher to the relay closed abruptly, or the track was terminated with SUBSCRIBE_RST. This is a signal to the relay that it's worth another subscribe to find out where the end of the track is. I can live if we consolidate the framing to a single message, and define a special error code to mean FIN, but I do think the transport needs to see the difference.
I like it. I would also like to merge ERROR with CLOSED, but we'll chat about that.
Code change:
header of the COSE_Sign1 Envelope, to one of the root certificates most recently registered as a trust anchor of the Transparency Service.  An "x5chain" with a leaf certificate that corresponds to <del> the "x5t" value MAY be included in the unprotected header in support of certain supply chain scenarios. </del> <ins> the "x5t" value MAY be included in the unprotected header. </ins> The Transparency Service MUST apply the Registration Policy that was most recently added to the Append-only Log at the time of

Related discussion:
text: Remove ambiguous details reported in (.
x5t value MAY be included in the unprotected header in support of certain supply chain scenarios.
LGTMLGTM
Code change:
header field includes information about the selected representation's complete length. <del> A sender that generates a 206 response with an </del> <ins> A sender that generates a 206 response to a request with an </ins> header field SHOULD NOT generate other representation header fields beyond those required, because the client already has a prior

Related discussion:
text: For
[x] (7.6.3) Via "If a port is not provided, a recipient MAY interpret that as meaning it was received on the default TCP port, if any, for the received-protocol." So if received-protocol is "3", it's a UDP port. If received-protocol is "1" or "1.1", is the default port 80 or 443? IIUC the scheme isn't included to determine this. Editors: URL [x] (7.7) Message Transformations "A proxy that transforms the content of a 200 (OK) response can inform downstream recipients that a transformation has been applied by changing the response status code to 203 (Non-Authoritative Information)" Why not an normative word, instead of "can"? Editors: URL [x] (12.5.3) Is it correct that "identity" and having no field value for Accept-Encoding are synonymous? Editors: URL [x] "Servers that fail a request due to an unsupported content coding ought to respond with a 415 (Unsupported Media Type) status" Why not s/ought to/SHOULD ? Editors: URL [x] (14.3) Why can only origin servers send "Accept-Ranges: bytes"? Why not intermediaries? Editors: URL [x] (15.3.7) "A sender that generates a 206 response with an If-Range header field"... (13.1.5) leads me to believe that only clients can send If-Range. So how can there be a response with If-Range? Editors: URL [x] (15.3.7.2) The last instance of THISSTRINGSEPARATES has a trailing '--'. If this is intentional, it ought to be explained. Editors: URL [x] (16.3.1) says field names SHOULD begin with a letter, but (16.3.2.1) says they SHOULD begin with "an alphanumeric character". More broadly, the "Field name:" description in (16.3.1) should probably refer to (16.3.2.1) unless I'm misunderstanding the scope of these sections.
Code change:
header field includes information about the selected representation's complete length. <del> A sender that generates a 206 response with an </del> <ins> A sender that generates a 206 response to a request with an </ins> header field SHOULD NOT generate other representation header fields beyond those required, because the client already has a prior

Related discussion:
text: Editors: URL [x] (17.13) s/TCP behavior/TCP or QUIC behavior Editors: URL [x] (B) It would be good to mention here that accept-ext has been removed in (12.5.1), and accept-charset is deprecated in (12.5.2), if that is new to this spec. Editors: see URL and URL
Because it isn't required, nor is it widely implemented (if at all). We try not to make requirements that we know won't be honoured.
Because the header is information about the capabilities of the origin server, not other members of the request chain. Intermediaries can change (e.g., with proxy configuration). Note that a gateway (e.g., a CDN) is effectively acting as an origin server, so it can do this. The language in this section needs to be tweaked, however; there are a few instances of 'server' that should be 'origin server'.
field"... (13.1.5) leads me to believe that only clients can send If-Range. So how can there be a response with If-Range? It looks like the phrase 'to a request' was dropped somewhere between and now.
this is intentional, it ought to be explained. This is how multipart works; see . I don't think there's value in re-specifying it here.
As per the spec: ...
Because we avoid making existing servers that predate this spec non-compliant (unless there's a very good reason, such as security)
Code change:
SETTINGS_ENABLE_CONNECT_PROTOCOL value is 0x08 (decimal 8), as in HTTP/2. <ins> If a server which advertises support for Extended CONNECT but receives an Extended CONNECT request with a ":protocol" value that is unknown or is not supported, the server SHOULD respond to the request with a 501 (Not Implemented) status code (HTTP).  A server MAY provide more information via a Problem Details resoponse RFC7807. </ins> 4. This document introduces no new security considerations beyond those

Related discussion:
text: I think this is an issue. and we need graceful way to fall back to fallback. I do not believe that HTTP11REQUIRED and 421 response code are the right solution. I think it would be good to make this part of WebSockets over HTTP3 spec. edit: remove double negation -> I think that HTTP11REQUIRED and 421 response code are not the answer.
I agree the options we have today are not the right fit. This document could provide that and update RFC 8441.
The server could just close the stream with H3VERSIONFALLBACK. Is that not sufficient?
Perhaps for WebSockets, but there's a more general question here. When a client uses Extended CONNECT with an unknown protocol, what is the correct failure mode? There's no guarantee that HTTP/1.1 would support an arbitrary requested protocol, even if it might be more likely to work with WebSockets.
I'm not sure we need a general solution, because it isn't clear that we have a general problem. The answer here will depend on why the client is using this protocol in the first place. For example with MASQUE, the client will know which proxy to connect to thanks to out-of-band configuration, so the proxy operator is responsible for ensuring its HTTP servers are in sync with its config servers. For WebSocket on the other hand, the issue is that WebSockets were originally designed for h1 and there exist servers that are gradually deploying h2 or h3 for GET but don't yet support WebSocket there. For those, H3VERSIONFALLBACK should be sufficient.
That's nice in theory. We should still say what happens when the proxy operator makes a mistake.
Why is this specific to extended CONNECT then? A server operator could make a mistake and end up with some GET resources not working on h3 too, right?
The example I would use here is a server that supports masque on H3 and H2 CONNECT. If for some reason a proxy operator gets desyncd with the config that it may or may not be responsible for, then things could go wrong. In a scenario where version fallback to HTTP/1.1 is not desirable, articulating such an error is underspecified. Similarly for H2 and H3 websocket, telling client the resource is not available or the stream was reset with the fallback error code is misinformation.
Code change:
SETTINGS_ENABLE_CONNECT_PROTOCOL value is 0x08 (decimal 8), as in HTTP/2. <ins> If a server which advertises support for Extended CONNECT but receives an Extended CONNECT request with a ":protocol" value that is unknown or is not supported, the server SHOULD respond to the request with a 501 (Not Implemented) status code (HTTP).  A server MAY provide more information via a Problem Details resoponse RFC7807. </ins> 4. This document introduces no new security considerations beyond those

Related discussion:
text: a header describing why?
Yes, that should work. This should be in the spec.
Sent out URL to address this using the 501 response code recommendation.
Code change:
header field and the <del> header field is not present in a selected stored response, a cache SHOULD use the stored response's </del> <ins> header field is not present in a stored response, a cache SHOULD use the stored response's </ins> field value (or, if no Date field is present, the time that the stored response was received) to evaluate the conditional.

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:
an indefinite-length encoding enables efficient generation of messages where lengths are not known when encoding starts. <ins> This format is designed to convey the semantics of valid HTTP messages as simply and efficiently as possible.  It is not designed to capture all of the details of the encoding of messages from specific HTTP versions (MESSAGING, H2, H3).  As such, this format is unlikely to be suitable for applications that depend on an exact recording of the encoding of messages. </ins> 2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

Related discussion:
text: The format is capable of capturing messages, but the design only really supports the expression of the semantics of valid messages. That makes it unsuitable for applications that need to know exactly what was put on the wire in a given protocol.
This document is going to be viewed by some as establishing the 'shape' of an HTTP message -- which is a good and perhaps necessary thing. However, some will be sad, because it doesn't suit some applications such as forensic preservation of messages, bot detection, debugging, faithful representation of HTTP/1, etc., due to transformations and loss of certain information (especially around headers). So it'd be good to set expectations early on (perhaps in the Introduction).
Good point. It's for semantics, not forensics and all that.
Code change:
creates some risks for clients (see pinrisks). Authentication for HTTP over TLS is described in Section 3.1 of <del> RFC2818, noting the additional requirements in I-D.ietf-httpbis-alt- svc.  The header field MUST be ignored if strong authentication fails; otherwise, an attacker could create a persistent denial of service by falsifying a commitment. </del> <ins> RFC2818, noting the additional requirements in Section 2.1 of I- D.ietf-httpbis-alt-svc.  The header field MUST be ignored if strong authentication fails; otherwise, an attacker could create a persistent denial of service by falsifying a commitment. </ins> The commitment to use authenticated TLS persists for a period determined by the value of the "ma" parameter.  See Section 4.2.3 of

Related discussion:
text: for encryption. I had these in my local repo. They weren't pushed, but I wanted to make sure that they are OK before merging them.
Code change:
mechanisms provided by the infrastructure.  Therefore, stub routers MUST provide DNS-SD service as described in this section. <del> 5.5.1. </del> <ins> 5.2.6.1. </ins> The adjacent infrastructure can be assumed to already enable some service discovery mechanism between hosts on the infrastructure

Related discussion:
text: … AIL change situations
Section 5.2.3 defines the mandatory DHCPv6-PD client role for the stub router. However, there are no details here what should trigger the stub router to renew/rebind the prefix lease. A reference to RFC 8415 should be added (as it contains some requirements on this topic). See section 18.2.12. Refreshing Configuration Information of RFC 8415. Do we define the SHOULD requirements of 18.2.12 about detecting a new network (new AIL) as mandatory for the stub router, or not? (If not: has consequences for wider IPv6 connectivity in such new-AIL cases) And what about the SHOULD requirement that involves "if the client detects a significant change regarding the prefixes available on the link (when new prefixes are added or existing prefixes are deprecated), as this may indicate a configuration change. " -> can we specify this better? What are the significant changes in our case? And how to do this detection? (e.g. monitor RAs?)
For this issue, we could reference the improved text in URL instead of RFC 8415. This text should be sufficient detail that stub router implementers know what to do. (Or at least, the DHC WG thinks it is enough for DHCPv6 client implementers to know what to do :-) ) PR with this pointer text is still needed.
Code change:
1.3 in 0-RTT mode), a client can reuse the settings value found in previous connections to that origin RFC6454 to make assumptions. <del> 4. </del> <ins> 5. </ins> This document registers the following entry in the Permanent Message Headers Registry, as per RFC3864:

Related discussion:
text: Resolves URL
cc NAME NAME
Hey Yoav, Thanks; will take a look. Two immediate things: You're getting a error in the markdown; . I see you've added yourself as an author. That's generally the decision of the chair - NAME in this case.
Hopefully fixed. Is there a way to test it locally? Apologies for the noobness. Removed myself.
See URL for build info.
NAME Thank you for working on the proposal. Am I correct in assuming that changes other than the switch to Cuckoo filters and the introduction are unintentional? For example, I see flag of the frame being removed. Do you have a working code that implements Cuckoo filters? I am curious to see it working. The concept of makes sense to me. Maybe we might want to adjust the codepoints and the naming in relation to .
Oh, I now understand the intent of removing the flag. The motive of the proposal is to build a digest without referring to every response object stored in cache. The fact means that it is not be easy for the client to determine the freshness of the entries that is going to be included in the digest. I am sympathetic to the idea, but I am afraid if the approach works well with the current mechanism of HTTP/2 caching. My understanding is that browsers that exist today only consume a pushed response when it fails to find a freshly cached response in its cache. Otherwise, the pushed response never lands in the browser cache. Unless we change the behavior of the browsers to respect the pushed response even if a freshly cached object already exists in its cache, there's a chance that servers would continually push responses that gets ignored by the client (due to the existence of a freshly cached response in the browser cache with the same URL). NAME Assuming that I correctly understand the motive of removing the distinction between a fresh digest and a stale digest, I would appreciate it if you could clarify your ideas on the problem.
Thanks for reviewing, NAME :) My intent was to include all stored resources in the digest, regardless of them being stale or fresh. Entries are added to the digest when a resource is added to the cache and removed from the digest when a resource is removed.