jiebi/CodeConvo huggingface dataset:
Code change:
the requirements above only apply to the generic syntax for field values as defined in HTTP. <del> 8.1.2.1. HTTP/2 uses special pseudo-header fields beginning with ':' character (ASCII 0x3a) to convey message control data (see HTTP). Pseudo-header fields are not HTTP header fields.  Endpoints MUST NOT generate pseudo-header fields other than those defined in this document.  Note that an extension could negotiate the use of additional pseudo-header fields; see extensibility. Pseudo-header fields are only valid in the context in which they are defined.  Pseudo-header fields defined for requests MUST NOT appear in responses; pseudo-header fields defined for responses MUST NOT appear in requests.  Pseudo-header fields MUST NOT appear in a trailer section.  Endpoints MUST treat a request or response that contains undefined or invalid pseudo-header fields as malformed. All pseudo-header fields MUST appear in a field block before all regular field lines.  Any request or response that contains a pseudo- header field that appears in a field block after a regular field line MUST be treated as malformed. 8.1.2.2. </del> <ins> 8.2.2. </ins> HTTP/2 does not use the <del> header field to indicate connection-specific header fields; in this protocol, connection-specific metadata is conveyed by other means. An endpoint MUST NOT generate an HTTP/2 message containing </del> <ins> header field (HTTP) to indicate connection-specific header fields; in this protocol, connection-specific metadata is conveyed by other means.  An endpoint MUST NOT generate an HTTP/2 message containing </ins> connection-specific header fields; any message containing connection- specific header fields MUST be treated as malformed.

Related discussion:
text: This is a rearrangement of the HTTP-related sections, in preparation for actually addressing 867.
This doesn't actually address the issue -- I came to a point where I realised this would add a bunch of new requirements and prose that would need heavy scrutiny, and if we want to finish soon, that may not be advisable (although maybe we can figure it out during WGLC). In the meantime, I think this rearrangement is much clearer than the original ordering -- see what you think.
The section talks about how to generate the various pseudo-header fields from a message, but not not how to create a message from the abstract constructs in HTTP semantics, such as the target URI. This includes security considerations around trusting the contents of . I'm happy to do a PR for this. Also, this is a weird paragraph: "HTTP/2 shares the same default port numbers" implies that it could choose to do otherwise; while that might have been an open question pre-core, I think this needs to be re-worded. Likewise, "requests for target resource URIs" is odd; is this meant to be "requests with target URIs"?
Yeah, most of this is just OLD. For instance, the "discovery" aspect really only relates to the need to use ALPN, but we have a better nomenclature now. If you are happy to do a PR, I'm more than happy to review rather than write.
Code change:
PRI <del> No </del> <ins> Yes </ins> <del> No </del> <ins> Yes </ins> ConnectionHeader of this document

Related discussion:
text: There seems to be some disagreement about this, but I think that Roy is right. It's not critical how it is registered, since it shouldn't appear in a valid request anywhere, but it meets the criteria.
I really don't think it matters, so I'm fine with it either way. Theoretically, there may be some compat value in having it listed as safe/idempotent since an intermediary may be more likely to let such methods pass. But the time slice in which this registry has existed and HTTP/2 hasn't will be miniscule -- I expect any HTTP/2-unaware intermediary won't look at the registry values either.
To the extent that it matters (i.e., very little, as you point out), I think that the intermediary example weakens the case for safe+idempotent. I really don't want HTTP/2 to pass an intermediary without triggering some deliberate recognition; that has been the source of some very serious bugs in the past.
Code change:
This document defines state variables and constants for the BBR algorithm. <del> The variables starting with C, P, or rs not defined below are defined in delivery-rate-samples, "Delivery Rate Samples". </del> <ins> Variables for connection state (C), per-packet state (P), or per-ACK rate sample (rs) that are not defined below are defined in delivery- rate-samples, "Delivery Rate Samples". </ins> 2.1.

Related discussion:
text: Minor clarifications to the prose Removes explicit references to Youtube
I am going to redo this on top of the markdown version. cc NAME NAME
Thanks, this 4-commit version with purely editorial changes looks great to merge now. Thanks!
Text LG, but we should decide if we want to impose the line limits I've seen in other Github IETF projects.
Code change:
encryption. The "aesgcm" content coding uses a fixed record size.  The resulting <del> encoding is either a single record, or a series of fixed-size records.  The final record, or a lone record, MUST be shorter than the fixed record size. </del> <ins> encoding is any number of fixed-size records - which could be zero records - followed by a single partial record.  The partial record MUST be shorter than the fixed record size. </ins> The record size determines the length of each portion of plaintext that is enciphered, with the exception of the final record, which is

Related discussion:
text: This moves the values that were in the Encryption header field to the start of the payload. This provides a meagre efficiency gain as well as removing the need to have two correlated header fields. This should go most of the way to address WGLC comments.
Looks good to me in general. That said; this removes the parsing weirdness for "Encryption" (good), but not for "Crypto-Key", right?
NAME happy to correct any parsing weirdness, but need to know precisely what it is first.
Code change:
Parameters: The parameters are defined in version-specific-params. <del> 6.11. </del> <ins> 6.10. </ins> The receiver sends an ANNOUNCE_OK control message to acknowledge the successful authorization and acceptance of an ANNOUNCE message.

Related discussion:
text: Into SUBSCRIBEDONE. I didn't remove the SUBSCRIBEERROR message in favor of SUBSCRIBE_CLOSED as NAME suggested in this PR. Addresses some comments in , but possibly not all
So my notes from this discussion. CLOSE is confusing with QUIC layer. People seemed to prefer UNSUBSCRIBE over SUBSCRIBE_CLOSE. I love the move aware from RST and FIN as naming.
Propose names from my understanding of discussion call Announce (send by publisher) , AnnouceOK, AnnouceError UnAnnounce (send by publisher) UnAnnounceOK, UnAnnounceError AnnouceEnd ( sent by thing that received Annouce) , AnnouceEndOK, AnnouceEndOK Subscribe (send by subscriber) , SubscribeOK, SubscribeError UnSubscribe (send by subscriber) , SubscribeOK, SubscribeError SubscribeEnd (send by thing that received subscriber), SubscribeOK, SubscribeError Mostly trying to get rid of FIN / RST and have different names for the messages that flow in opposite directions.
I don't like the name of the different messages used to terminate. I'd rather have one message that transitions to the terminal state, with an optional error code and final group/object. IMO the subscription flow: And the ANNOUNCE flow mirrors: The brackets mean a message is optional. The sender is responsible for creating and the receiver is responsible for closing, possibly at the bequest of the sender (like QUIC's STOP_SENDING).
has been merged, adding yet another term (CANCEL), but I figured we'd clean that up with this issue.
Since we are bikeshedding, I prefer ANNOUNCE_RESCIND instead of CANCEL, since an announce is more of a declarative statement than an active request from the sender.
Heh and UNANNOUNCE and UNSUBSCRIBE stick out because they don't share the same prefix.
I like the names being proposed as they help make make is easier to understand. I do want to separate out one issue. The STOP / CLOSE type thing happens way after the initial SUBSCRIBE thus it can end up in a situation where auth has expired or something else has gone wrong this I like the current design that allows an OK or ERROR to be returned for those. I think it is also key for sender of the things stoping the subscribe to know that the other side has acted on that so we need the OK.
Code change:
Parameters: The parameters are defined in version-specific-params. <del> 6.11. </del> <ins> 6.10. </ins> The receiver sends an ANNOUNCE_OK control message to acknowledge the successful authorization and acceptance of an ANNOUNCE message.

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:
Parameters: The parameters are defined in version-specific-params. <del> 6.11. </del> <ins> 6.10. </ins> The receiver sends an ANNOUNCE_OK control message to acknowledge the successful authorization and acceptance of an ANNOUNCE message.

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:
Parameters: The parameters are defined in version-specific-params. <del> 6.11. </del> <ins> 6.10. </ins> The receiver sends an ANNOUNCE_OK control message to acknowledge the successful authorization and acceptance of an ANNOUNCE message.

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:
Implementations MUST support all of the settings defined by this specification and MAY support additional settings defined by <del> extensions.  Unsupported or unrecognized settings MUST be ignored. New settings MUST NOT be defined or implemented in a way that requires endpoints to understand them in order to communicate successfully. </del> <ins> extensions to this protocol.  Unsupported or unrecognized settings MUST be ignored.  New settings MUST NOT be defined or implemented in a way that requires endpoints to understand them in order to communicate successfully. </ins> Each setting in a SETTINGS frame replaces the existing value for that setting.  Settings are processed in the order in which they appear,

Related discussion:
text: This is a really minor thing, but as I was reading the spec, I was wondering for a bit what "extensions" meant (user defined? something else?). I think the intent is to reference extensions defined by future RFCs that revise HTTP/2 protocol.
Code change:
HTTP/1.1 defaults to the use of , allowing multiple requests and responses to be carried over a <del> single connection.  The " " connection option is used to signal that a connection will not persist after the current request/response.  HTTP implementations SHOULD support persistent connections. </del> <ins> single connection.  HTTP implementations SHOULD support persistent connections. </ins> A recipient determines whether a connection is persistent or not based on the most recently received message's protocol version and

Related discussion:
text: The close connection item used to be defined in Connection as whereas now its effect is described in Messaging without definition. I think it should be defined somewhere.
gets pretty close to that text: ... with text below that elaborates. What do you want to see here?
looks good except as noted by NAME the bare close strings look weird.LGTM, except for 'the close' being a bit weird (but I don't feel that strongly about it; suggestions for replacement inline).
Code change:
material, or use some pre-configured algorithm agreed upon by the signer and verifier. <del> A means of determining that a given key and algorithm presented in the request are appropriate for the request being made.  For </del> <ins> A means of determining that a given key and algorithm used for a signature are appropriate for the context of the message.  For </ins> example, a server expecting only ECDSA signatures should know to reject any RSA signatures, or a server expecting asymmetric cryptography should know to reject any symmetric cryptography.

Related discussion:
text: A signature over another signature does not provide the transitive protection that it seems it should. The examples and advice have been updated to accomodate this.
NAME NAME can you please verify the signatures on the updated examples in this PR?
Code change:
3.1. <del> The protocol defined in this document has two identifiers. Negotiating "h2" or "h2c" implies the use of the transport, security, framing, and message semantics described in this document. </del> <ins> The protocol defined in this document has two identifiers.  Creating a connection based on either implies the use of the transport, security, framing, and message semantics described in this document. </ins> 3.2.

Related discussion:
text: By removing the word negotiating and avoiding the actual identifiers, we can get the important point across
Maybe a hangover from trying to tear up the photos of the "http" URI and upgrade dance. But this seems to read oddly. On one hand: on the other: I don't have a solid suggestion to improve things.
How about we just remove "h2c" from the latter statement.
OK, that isn't going to fly. I just tried it. Pulling that string is unwise. We agreed to keep "prior knowledge" in the document, and the "h2c" ALPN token is part of that. The "h2c" upgrade token has been removed already. (Too subtle? Probably.)
Code change:
expired or revoked keys for signature verification using reasonable and appropriate means for the given key-distribution method. <ins> 8.9. When Holder Binding is not enforced, any entity in possession of a Combined Format for Presentation can forward the contents to third parties.  When doing so, that entity may remove Disclosures such that the receiver learns only a subset of the claims contained in the original Combined Format for Presentation. For example, a device manufacturer might produce an SD-JWT containing information about upstream and downstream supply chain contributors. Each supply chain party can verify only the claims that were selectively disclosed to them by an upstream party, and they can choose to further reduce the disclosed claims when presenting to a downstream party. In some scenarios this behavior could be desirable, but if it is not, Issuers need to support and Verifiers need to enforce Holder Binding. </ins> 9. The privacy principles of ISO.29100 should be adhered to.

Related discussion:
text: Example 2b includes different nonces than Example 2a. We try to use deterministic random numbers to generate the examples, but in this case, due to the order in which the decoys and regular salts are created, this approach does not produce the same nonces for the same "real" disclosures.
PR was merged
Code change:
should be supported, but further extended metadata of the contents of the media or its ontology should not be supported. <ins> 4.4.1. 4.4.2. 4.4.3. 4.4.4. 4.4.5. </ins> 4.5. Packaging of media describes how encapsulation of media to carry the

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:
6.4.2. <del> The format of SUBSCRIBE REQUEST is as follows: </del> <ins> The format of SUBSCRIBE is as follows: </ins> Track Namespace: Identifies the namespace of the track as defined in (track-name). Track Name: Identifies the track name as defined in (track-name). <ins> Subscribe ID: Session unique identifier for the subscription. "Subscribe ID" is monotonically increasing variable length integer and it MUST uniquely identify a subscription within a session. "Subscribe ID" is used by subscribers and the publishers to identify a given subscription.  Subscribers specify the "Subscribe ID" and it is included in the corresponding SUBSCRIBE_OK or SUBSCRIBE_ERROR. </ins> StartGroup: The Location of the requested group.  StartGroup's Mode MUST NOT be None.

Related discussion:
text: This PR is expected to be base PR to support multi-subscribe like flows that will follow up. It adds support for SubscribeID and also renames the trackId to to avoid the confusion and make the scope clear.
NAME NAME NAME wondering if the latest commits address the feedback. thanks
The normative bits look fine. PR needs some cleanup. Recommend splitting ID -> Alias to another PR, so this subscribe ID doesn't get caught up with bikeshedding the field name.LGTM but I would like Subscribe ID to be the first field in every message for consistency.Still looks fine after the split Having reviewed some code that does subscription matching with the current draft, I strongly endorse splitting those.
Code change:
Response: <del> Additional fields may be present.  Fields that are not understood MUST be ignored. </del> <ins> Responses to this message are vendor-specific.  Fields that are not understood MUST be ignored. </ins> 2.1.2.

Related discussion:
text: Updated error returns to be CBOR, and a couple of other things. Still more to do
Since we are talking about , does this mean we must refactor this API endpoint's response with minimally viable CBOR and a CDDL spec in place of JSON?
Yes. Discussed at the hackathon and will make a proposal as part of URL
Added to PR - LMK if you like it
I will have to experiment with it more, but so far I like it. You can link this issue to close it once you merge . Thanks.
Merged.
It's sufficient/better to just ResolveSignedStatement (meaning you get back what was put in) and then the client can pull the Statement out if they want it. Reduces complexity for no loss of functionality
So no separate endpoint, you mean?
Reviewed and merged in
Showing keys without saying what they're for is unhelpful Cedric suggests it might be even better to remove the specifics and just include a standard key discovery locator (which also helps avoid format/types arguments in this doc)
I have attempted to resolve this by removing it in the translation to CBOR in PR - will this suffice?
Reviewed and addressed in
LGTM