jiebi/CodeConvo huggingface dataset:
Code change:
Reason Phrase: Provides the reason for announcement error and "Reason Phrase Length" field carries its length. <del> 6.10. </del> <ins> 6.12. </ins> The publisher sends the "UNANNOUNCE" control message to indicate its intent to stop serving new subscriptions for tracks within the

Related discussion:
text: Once again data is flowing from A to R to B. I think it would be bad if the new ANNOUNCE, or an error on the QUIC connection from A to R caused a termination or error of the subscribe between B and R. I'm think it is better for B to unsubscribe if it is not receiving the media it wold expect.
Having explicit messages reflecting the actions would be my inclination as well. I thought it might be beneficial to explain the role of the above proposed messages with few flow diagrams Here is the happy path flow (it ignores Subscribe_OK and response flows to keep the flow focussed)
Summary thoughts: Want to support disconnection without propagation to all subscribers (ie: If there were two publishers) Need a way to cleanly unsubscribe from a track (UNSUBSCRIBE) - Like STOPSENDING? Need a way to indicate that a relay is no longer the place to subscribe to for a track (ie: UNANNOUNCE) But UNANNOUNCE does not indicate an unsubscription. Need a way to indicate the track is FIN'd and ending, could use the catalog or put in the protocol (or both) Likely want a way to drain a relay, such as an HTTP GOAWAY style functionality. (Could be SUBSCRIBETERMINATE) Timeouts do need to be handled, even if they're not the ideal/clean case. Want to know whether the relay wants to stop publishing or the origin did, so a client can decide whether to re-sub. NOTE: Objects can be dropped, hard to know if they'll ever arrive. Cullen will summarize a proposal. Note that the relay doesn't really need to know about tracks or what its subscribing to. An open issue is how to do FIN, whether it as part of Objects, only the catalog, a separate message, etc.
Rough notes on proposal in the call: The catalog updates and says what the last message in a track is. Catalogs are a way that endpoints can say there will never be more on a track. The annouce has an equivalent un-Annouce message. It changes routing of future subscribes but does not change state of existing subscribes. The entity that send an subscribe and send an un-subscribe The entity that receives a subscribe can send a go-away which will let the entity that sent the subscribe go do something new ( like subscribe to something else ).
Code change:
Reason Phrase: Provides the reason for announcement error and "Reason Phrase Length" field carries its length. <del> 6.10. </del> <ins> 6.12. </ins> The publisher sends the "UNANNOUNCE" control message to indicate its intent to stop serving new subscriptions for tracks within the

Related discussion:
text: We might need to figure out what data goes in the go away to given info that the clients enough info to do the right thing. Timeout can happen, and connections disappearing, and we need to sort out what impact that has but that is not the primary way to cause flow of media to change. Update: Key issue here is when the relays see the go away, do they drop the related forwarding state for the subscription, or do they just forward the update to the subscribers and wait for the subscribers to remove the subscription.
NAME NAME thanks for capturing the notes. I will work on set of small PRs to capture some of the items from the summary.
The point I was trying to clarify on the last call was that catalog already has a mechanism for a publisher to communicate to all subscribers that the track it has advertised as being available is no longer available. A clean FIN if you like. We can, as has been pointed out, create a control message which says the same thing. But then we have a weird asymmetry in which a publisher notifies clients of track availability through a catalog update but then uses control messages to do the reverse. For good design with clean encapsulation, we should seek symmetry in operation. We should either use control messages to advertise the availability/unavailability of tracks , or use catalogs, but not a hybrid of both. In my understanding of moq-transport, control messages have utility that is scoped to the current hop. They negotiate the format in which data will be exchanged on that hop and issue commands to subscribe/unsubscribe/announce etc. Those commands have no applicability to any other hops on the distribution chain. A catalog however is a contract between a publishers and all subscribers. Unlike control messages, it holds data that is not interpreted hop-by-hop and is intended for targets that can be many hops away. I think relays should be as simple as possible. In my conception, they should not understand whether tracks are being published or not. Their job is to move objects. Their view of the world is around objects and they do not need to understand what tracks are. While of course we can build all sorts of track intelligence in to relays, I think if we can build a base protocol which is agnostic to tracks, then it will be scalable and robust, and cleverness with tracks can evolve in the streaming formats without affecting deployed networks of relays.
Code change:
the content coding is reflected in a separate Encryption header field value in the order in which they were applied. <ins> Content codings that use the Encryption header field MUST always include a value for the header field when the content coding has been applied.  If no parameters are needed, then a dummy value is necessary to avoid confusion about which set of parameters applies to which content coding.  This requirement applies to uses of the "aesgcm" content coding. </ins> Encryption header field values with multiple instances of the same <del> parameter name are invalid. </del> <ins> parameter name in a single encryption-params production are invalid. </ins> Servers processing PUT requests MUST persist the value of the Encryption header field, unless they remove the content coding by

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:
who can access the Append-only Log.  While this can be used to limit who can read the Log, it may also limit the usefulness of the system. <del> Some jurisdictions have a Right to be Forgotten.  However, once a Signed Statement is inserted into the Append-only Log maintained by a Transparency Service, it cannot be removed from the Log. </del> <ins> Once a cryptographic digest of the Signed Statement is registered on the Append-only Log, the registration cannot be removed from the Append-only Log. </ins> 6.

Related discussion:
text: You have to explain what this means and include reference. Since you are likely not going to do this, I suggest to delete this sentence.
I think we should take NAME 's change, and that the current text is problematic.
LGTM
Code change:
"nonce": A random unique value generated for this signature. <ins> "alg": The HTTP message signature algorithm from the HTTP Message Signature Algorithm Registry, as an "sf-string" value. "keyid": The identifier for the key material as an "sf-string" value. </ins> Additional parameters can be defined in the iana-param-contents. The signature parameters are serialized using the rules in RFC8941 as

Related discussion:
text: This adds several new specialty identifiers for requests and responses to cover the method, authority, scheme, origin, path, query, and status code values of the HTTP message. It also edits the identifier's associated value to remove the verb and the string construction rules and instead align with HTTP Semantics.
NAME I haven't added references in yet but I tried to move the language in the direction you are suggesting. NAME I added the target-uri field we discussed, please review the text.
Responded to comments and updated normalization rules, please re-review.
Folding in this PR to the main document, discussion can continue on specifics of identifiers and their values as needed.
Code change:
An Accept-Encoding header field with a field value that is empty implies that the user agent does not want any content coding in <del> response.  If an Accept-Encoding header field is present in a request and none of the available representations for the response have a content coding that is listed as acceptable, the origin server SHOULD send a response without any content coding. </del> <ins> response.  If a non-empty Accept-Encoding header field is present in a request and none of the available representations for the response have a content coding that is listed as acceptable, the origin server SHOULD send a response without any content coding unless the identity coding is indicated as unacceptable. </ins> When the Accept-Encoding header field is present in a response, it indicates what content codings the resource was willing to accept in

Related discussion:
text: I would suggest a less normative fix, like and just send that now to the RFC editor as a clarification.
Great, thanks!
NAME - are you going to create a PR for this?
LGTM
Code change:
signature be verified but also the workload identity of the workload requesting the replacement Txn-Token. <del> 9.5. </del> <ins> 9.6. </ins> The authorization model within a trust domain boundary is most often quite different from the authorization model (e.g.  OAuth scopes)

Related discussion:
text: The notes copy-pasted from the WG notes do say "when", but based on our recollection of the events during that session, the real ask was to clarify that one could use unsigned JSON objects. That is indicated in the action item (i.e. the last line in that issue description)
the following came up in the IETF 120 session about TraTs: "Add an outline on when self-signed may be useful Yaron thought self-signed wil be a footgun Suggest a simple JSON object as replacement." The description of in section 7.1 is too rigid as it only allows an inbound token or a self-signed token. It should make it clear that an implementation may choose to have any different format for the subjecttoken.
Just a few very minor comments
Code change:
signature be verified but also the workload identity of the workload requesting the replacement Txn-Token. <del> 9.5. </del> <ins> 9.6. </ins> The authorization model within a trust domain boundary is most often quite different from the authorization model (e.g.  OAuth scopes)

Related discussion:
text: The following issue came up during the IETF 120 session on TraTs: There was a comment about some of the processing rules that was the equivalent of NULL with extra processing steps (N_A)
George and Atul recommend that we should drop the sentences after "REQUIRED A unique transaction identifier as defined in Section 2.2 of ]." Since this is a normative section, it need not have any usage guidance in there. If required we can add non-normative usage guidance such as "The txn value MAY be used to identify the call chain"
Code change:
extensions. The authentication proofs described in this document are not bound to <del> individual HTTP requests; if the same user sends an authentication proof on multiple requests they will all be identical.  This allows </del> <ins> individual HTTP requests; if the key is used for authentication proofs on multiple requests they will all be identical.  This allows </ins> for better compression when sending over the wire, but implies that client implementations that multiplex different security contexts over a single HTTP connection need to ensure that those contexts

Related discussion:
text: The user ID parameter "u" effectively identifies the keying material that servers might use to verify the authenticator sent in the header. As noted on the list, this is more or less a key ID, and I think leaning into that framing could be helpful. For example, beyond avoiding the confusion raised on the list, it might also be more ergonomic for different types of authenticators. One could imagine using a for unprompted authentication where the server only learns that someone with a valid private key produced the authenticator but not necessarily which one.
Code change:
This effectively prevents the use of renegotiation in response to a request for a specific protected resource.  A future specification might provide a way to support this use case.  Alternatively, a <del> server might use a ConnectionErrorHandler of type </del> <ins> server might use an ErrorHandler of type </ins> to request the client use a protocol which supports renegotiation.

Related discussion:
text: Two changes here, one editorial and one probably-editorial: The endpoint might send a connection or a stream error of HTTP11_REQUIRED, depending on the scope of the requirement. Note that this was non-normative language, so removing the implication that it would always be a connection error simply makes clearer what was already permitted. The server might know as soon as the connection is established that it will want the cert, but want it protected by the handshake. Either endpoint, not just the client, may choose to renegotiate before sending their preface.
Code change:
status.  This is because differentiating between the two may not be possible in an eventually consistent system. <del> 2.1.3. </del> <ins> 3.1.3. </ins> <del> 2.1.3.1. </del> <ins> 3.1.3.1. </ins> Query parameters:

Related discussion:
text: A few thoughts after IETF 117. Goals: Address identity up front (by not addressing it directly). Frame feeds in the context of the API Relate media types to feeds This PR is mostly placeholders for future work, but hopefully highlights some areas for follow up based on our in person discussions.
NAME I can't merge this, but we should unless there are changes requested.
fixed collaborator list
LGTM
Code change:
Additionally, User Agents SHOULD NOT send CACHE_DIGEST when in "privacy mode." <del> 5.  References </del> <ins> 6.  References </ins> <del> 5.1.  URIs </del> <ins> 6.1.  URIs </ins> [1] https://lists.w3.org/Archives/Public/ietf-http-wg/

Related discussion:
text: The PR introduces a new SETTINGS parameter that can be used by a server to notify if (and how) it makes use of the CACHEDIGEST frames. You might find the discussion about how to use the parameter interesting. The text of the PR, under the assumption that the underlying transport will be TLS 1.3, suggests the client: to wait for SETTINGS parameter when doing a full handshake retain the value of the parameter in the TLS session cache and reuse the cached settings parameter value when doing 0-RTT resumption
Looks good to me, delta the one comment I made.
Code change:
A client that places the importance of protection against passive attacks over performance might choose to withhold requests until an encrypted connection is available.  However, if such a connection <del> cannot be successfully established, the client MAY resume its use of </del> <ins> cannot be successfully established, the client can resume its use of </ins> the cleartext connection. A client can also explicitly probe for an alternative service

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:
StartGroup: The start Group ID.  Only present for "AbsoluteStart" and "AbsoluteRange" filter types. <del> StartObject: The start Object ID, plus 1.  A value of 0 means the entire group is requested.  Only present for "AbsoluteStart" and "AbsoluteRange" filter types. </del> <ins> StartObject: The start Object ID.  Only present for "AbsoluteStart" and "AbsoluteRange" filter types. </ins> EndGroup: The end Group ID.  Only present for the "AbsoluteRange" filter type.

Related discussion:
text: I'm not totally sure what to do with the special value of 0 for StartObject and EndObject. If StartObject == 0, that's requesting the whole group. But if it's 1, that maps to a first object of zero, which is also consistent with requesting the whole group. For EndObject, the special value makes sense, because the subscriber might not know how many objects there are. There's also the error case where StartObject == 0 and EndObject != 0, or the reverse. IMO it would make more sense for EndObject to have the special value at zero, but not StartObject.
You're correct, this was an editorial error on my part. I did not intend to make StartObject have a special value.
Code change:
infrastructure network, and is therefore out of scope for this document. <del> 5.5.2. </del> <ins> 5.2.6.2. </ins> Hosts on the stub network may need to discover hosts on the AIL, or on the stub network.  In the IoT network example we've been using,

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:
Macintosh file type code(s): N/A Windows Clipboard Name: N/A <ins> IANA is asked to register the following entry in the "HTTP Problem Types" registry: IANA is asked to register the following entry in the "HTTP Problem Types" registry: </ins>

Related discussion:
text: defines a framework for problem types, which can be used as a standardized response format when errors occurs. With resumable uploads, we have a few cases where such problem types could be useful, but usage remains entirely optional. The text in this PR has been inspired by similar sections from .
Thank you very much for quick feedback, Lucas!
Code change:
header field set to "1" (i.e., it adds it if not present in the request).  An intermediary MUST use the "Early-Data" header field if it might have forwarded the request prior to handshake completion <del> (see be-consistent for details). </del> <ins> (be-consistent describes considerations for clusters of servers). </ins> An intermediary MUST NOT remove this header field if it is present in a request.  "Early-Data" MUST NOT appear in a "Connection" header

Related discussion:
text: Just editorial suggestions here, but all good ones.
Nice wording, I really like this new version. Thanks!
Code change:
The specifics (such as the format) of returned access token is not part of this specification. <del> 2.4.4. </del> <ins> 2.5.4. </ins> The authorization server responds with an access token as described in section 5.1 of RFC6749. <del> 2.4.5. </del> <ins> 2.5.5. </ins> The example belows shows how the client in trust domain A presents an authorization grant to the authorization server in trust domain B

Related discussion:
text: Added use cases. We may want to refine these, or move them into a non-normative section later.
Code change:
SUBSCRIBE_NAMESPACE is not required for a publisher to send ANNOUNCE and UNANNOUNCE messages to a subscriber.  It is useful in applications or relays where subscribers are only interested in or <del> authorized to access a subset of available annoucements. </del> <ins> authorized to access a subset of available announcements. </ins> 6.12.

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?