jiebi/CodeConvo huggingface dataset:
Code change:
Since the Signature and HMAC HTTP Authentication Schemes leverage TLS keying material exporters, their output cannot be transparently forwarded by HTTP intermediaries.  HTTP intermediaries that support <del> this specification will validate the authentication received from the client themselves, then inform the upstream HTTP server of the presence of valid authentication using some other mechanism. </del> <ins> this specification have two options: The intermediary can validate the authentication received from the client, then inform the upstream HTTP server of the presence of valid authentication. The intermediary can export the nonce (see compute-proof}), and forward it to the upstream HTTP server, then the upstream server performs the validation. The mechanism for the intermediary to communicate this information to the upstream HTTP server is out of scope for this document. </ins> 8.

Related discussion:
text: Ilari suggests on the :
to this. It's been implemented for exported authenticators and isn't too challenging.
Code change:
Statement a Transparent Statement is produced. Receipts are based on Signed Inclusion Proofs as described in COSE <del> Signed Merkle Tree Proofs (I-D.draft-ietf-cose-merkle-tree-proofs). </del> <ins> Signed Merkle Tree Proofs (I-D.draft-ietf-cose-merkle-tree-proofs) that also provides the COSE header parameter semantics for label 394. </ins> The Registration time is defined as the timestamp at which the Transparency Service has added this Signed Statement to its Append-

Related discussion:
text: Assuming URL is merged, that document will register everything that is needed for SCITT Receipts (a profile of COSE Receipts). There is clean up work to do in the architecture. Remove the editorial notes regarding 394. Review IANA considerations (AFAIK, 394 was never requested for registration in the document, despite the editor notes).
I've merged the PR, but we need to publish a new version to the data tracker. Ideally other authors (of COSE Receipts / COMETRE) will do an editorial pass, and then push a new version to the data tracker.
I'd personally prefer to separate the mediatype exclusion (which I agree with removing) to a different PR, but would approve both anyway. LGTM
Code change:
request at the path defined in jwt-vc-issuer-metadata. <del> The following is a non-normative example of a HTTP request for the </del> <ins> The following is a non-normative example of an HTTP request for the </ins> JWT VC Issuer Metadata configuration when is set to

Related discussion:
text: also add associated IANA registration request and fix up formatting etc in other IANA bits see it live URL
There are 2 parts of the draft discussing the path to issuer metadata: and I do believe the latter is the currently intended /.well-known mechanism, whereas the first section was probably not updated and would result in to resolve metadata. I guess this was an oversight in ?
Thanks for catching the inconsistency NAME and I believe you are correct that the latter is currently the intended mechanism for .well-known.
We might also want to use something other than "user" in the example path. It's not wrong exactly but maybe unnecessarily misleading or confusing.
endeavors to fix this (and a few other little things)
lgtm
Code change:
AbsoluteRange (0x4): Specifies a closed subscription starting at StartObject in StartGroup and ending at EndObject in EndGroup.  The <del> start and end of the range are inclusive. </del> <ins> start and end of the range are inclusive.  EndGroup and EndObject MUST specify the same or a later object than StartGroup and StartObject. </ins> A filter type other than the above MUST be treated as error.

Related discussion:
text: The other option is we can use a delta encoding to make it impossible to specify an earlier object, but I think that would make it more complex.
Good point, I changed it to the same or later object
As mentioned in the sprawling , I think we should allow empty subscriptions, aka subscriptions that match no objects. It would be nice to have a way to check if a track exists without receiving any OBJECTs. The MoQ equivalent of a HTTP HEAD request. It could be useful to pre-warm the cache. An empty subscription could be the equivalent of "I'm interested, but don't have the bandwidth to receive objects yet". Again, similar to HTTP HEAD requests. For example, a client could issue a to accomplish two separate things: The track exists if it gets a SUBSCRIBE_OK. The encoder/CDN starts producing the track. The client could resubscribe at any point to immediately start receiving the track.
Can the same be accomplished with: or any other range request where start==end? Is it ok for the publisher sends SUBSCRIBEOK and SUBSCRIBEFIN, or does your use case require the publisher to hold the subscription open? Adding a new message is also an option.
I think there's a few potential use-cases: Check if the track exists. Check if the track is active. Check if the track is active, and get notified when the track is closed. Check if the track exists and group/object N exists. "exists" vs "active" is tricky. If you request absolute/0, then it's totally valid for the relay to return OK so long as the objects haven't expired yet, even if the publisher sent a FIN a long time ago. But what should the relay do if absolute/0 has expired? Should it return an error, even if the track is still actively producing objects? Requesting relative/0 is better, although what if that object has expired too? For example, a muted audio track. IMO ? SUBSCRIBE start/end=none ... UNSUBSCRIBE SUBSCRIBE start/end=none ... SUBSCRIBEFIN SUBSCRIBE start/end=absolute/N ... SUBSCRIBEFIN
And a more concrete use-case that NAME and NAME might like. Let's say I have 3 renditions: .
Code change:
AbsoluteRange (0x4): Specifies a closed subscription starting at StartObject in StartGroup and ending at EndObject in EndGroup.  The <del> start and end of the range are inclusive. </del> <ins> start and end of the range are inclusive.  EndGroup and EndObject MUST specify the same or a later object than StartGroup and StartObject. </ins> A filter type other than the above MUST be treated as error.

Related discussion:
text: The client starts watching a broadcast: This is a hint to the relay that the 720p track exists and it should start warming the cache. The relay is free to ignore the hint, but at the very least it will perform authentication. When the client decides that it has enough bandwidth for 720p, it will switch up at an aligned group: If the relay warmed the cache, then this switch is instantaneous. If the relay ignored the hint, then it takes at least an RTT to origin to fetch the 720p track. The time it takes to switch renditions matters more when switching down in response to congestion. The buffer will deplete while the CDN fetches the rendition from origin, which pre-warming subscriptions will avoid. And just to complete the example, you have to pre-warm the 480p SUBSCRIBE again. This could either be done with multiple subscriptions, or waiting until the SUBSCRIBE_FIN arrives and then subscribing again. I'm not quite sure which approach is better.
I'm a little concerned about this use case, for the reasons below: Is the assumption that the catalog, which declares the existence of the track, is not trustable? How? If the relay went forward to the origin with the same start=none request then the origin should not actually send anything and therefore the cache would not fill. The only way this works is if the relay goes forward with a different request with some !none start value. This non-deterministic behavior (ask one component for one thing and it asks for somehting else) can lead to scaling and debugging problems. I appreciate the benefits of cache warming, for fast start especially when the the edge relay is far from the origin. There are other ways to achieve this. One way can be by having a "warming client" make a conventional subscription request. This client may be an agent hosted on the edge relay for this purpose and its APi would be offered by the CDN and is outside the scope of moqt. As a third point, empty subscriptions are also a DDOS attack vector. As a client, if can make a hundred requests for streams that all then flow to a relay, but no content actually comes to me, it is a highly asymmetric (and therefore dangerous) DDOS tool.
I think it's useful for applications that don't use a catalog. ex.
Code change:
AbsoluteRange (0x4): Specifies a closed subscription starting at StartObject in StartGroup and ending at EndObject in EndGroup.  The <del> start and end of the range are inclusive. </del> <ins> start and end of the range are inclusive.  EndGroup and EndObject MUST specify the same or a later object than StartGroup and StartObject. </ins> A filter type other than the above MUST be treated as error.

Related discussion:
text: Alan's chat protocol could check if a chat room or participant exists by performing an empty subscribe. The relay doesn't have to forward ranges verbatim. Just like if a CDN receives a HEAD request, the relay MAY issue a GET request to the origin instead. I think this is actually pretty common? In the MoQ case, the relay could request instead of from the origin. It's completely up to the relay; it would only do this if there's sufficient bandwidth/cache available. It's a little bit of business logic though; maybe the customer can choose to enable it. Just keep in mind that we don't want the relay to have access to the catalog. So you're asking applications to provide this functionality, requiring a custom service worker, a custom player, and hooks to notify the service worker on player start/stop. And the service worker itself doesn't actually want to receive these objects, so yeah there would need to be a non-standard API to actually warm a track. Plus it gets more complicated when you through in alternative renditions. Maybe the client has no intention of downloading AV1 tracks, or maybe it has no intention of downloading Japanese subtitles. This sort of selection criteria should be signaled to the service worker; pre-warming all tracks is a waste. I think this is the type of thing we build into the protocol instead of asking every application make a unique implementation. Warming would be completely optional for both the publisher and subscriber. I don't quite understand. The CDN would deduplicate subscriptions so only one would ever reach the origin for a given track. If the relay already has an active subscription for the 480p track, then it wouldn't need to issue another subscribe upstream to serve empty subscriptions. But if you're talking about using random track names, a client can already SUBSCRIBE to random track names (just like random HTTP paths) to DoS the origin. Or maybe you're talking about a client potentially pre-warming a bunch of valid tracks. Like somebody wrote a bot to scrape all Twitch broadcasts with zero viewers and issued an empty subscribe to them all. The CDN is completely in charge of determining if it pre-warms empty subscribes, which it should not do if it's near capacity or detects abuse. But I don't think this is unique to empty subscribes.
Code change:
AbsoluteRange (0x4): Specifies a closed subscription starting at StartObject in StartGroup and ending at EndObject in EndGroup.  The <del> start and end of the range are inclusive. </del> <ins> start and end of the range are inclusive.  EndGroup and EndObject MUST specify the same or a later object than StartGroup and StartObject. </ins> A filter type other than the above MUST be treated as error.

Related discussion:
text: A client could perform a normal subscribe and then either immediately unsubscribe, close the connection, or set MAXSTREAMSUNI=0 avoid receiving any objects. These empty subscribes follow the normal authentication logic, so the mitigation is going to be the same for both.
Individual Comment: Let's retitle this issue to be more specific about what the ask is. Empty subscriptions are possible with draft-01. Their semantics are a bit undefined - eg: a relay or publisher has multiple options - SUBSCRIBEERROR, SUBSCRIBEOK + SUBSCRIBEFIN, SUBSCRIBEOK and no FIN, in case the subscriber wants to do something else? Do we need to mandate a particular behavior for better interoperability? Then there's a separate issue about supporting these use cases: If these are required, then there's other ways to spell that without changing Subscribe - and none of these cases have anything to do with subscribing except maybe 3? A QUERY_TRACK (eg: HEAD) message that doesn't alter the subscribe state seems like a more apt vehicle. How to pre-warm a cache seems out of scope. I think we should open a separate issue about this case, and what the relay requirements are (if any) around backpressure. The same thing can happen if a client runs out of streams and doesn't grant new credit in a timely way. Are there obligations to keep the subscription open and/or cache at the relay for some period of time, or can a relay aggressively drop objects or reset subscriptions? A naive relay is going to get itself in big trouble very quickly.
Now that we have TRACKSTATUSREQUEST, can we close this one? The one use case we haven't completely addressed explicitly is cache pre-warming, which is tracked by
LGTMAfter or equals to? (in case one requests a single object)
Code change:
9.7. <del> The status has been updated to "obsoleted" for both "SHA" and "MD5", and their descriptions states that those algorithms are NOT RECOMMENDED. </del> <ins> The status of "MD5" has been updated to "deprecated", and its description states that this algoritm MUST NOT be used. The status of "SHA" has been updated to "obsoleted", and its description states that this algorithm is NOT RECOMMENDED. </ins> The status for all other algorithms have been updated to "standard".

Related discussion:
text: States that MUST NOT be used. Sets the MD5 status to deprecated.
Looks good, thanks!
Code change:
microservices, monolithic services and infrastructure services such as managed databases. <del> A virtually or physically separated network, which contains two or more workloads.  The workloads within a Trust Domain may be invoked only through published interfaces. </del> <ins> A collection of systems, applications, or workloads that share a common security policy.  In practice this may include a virtually or physically separated network, which contains two or more workloads.  The workloads within a Trust Domain may be invoked only through published interfaces. </ins> A published interface to a Trust Domain that results in the invocation of a workload within the Trust Domain.

Related discussion:
text: See issue Question for reviewers. Do we need the final sentence on how a workload is invoked? If the sentence was not there would it change how we think about a trust domain? Do we need the second sentence as an example? Should we add more examples (e.g. trust domains can be defined as all the applications or workloads that recognise a specific issuer).
The definition of a Trust Domain feels very specific to network segmentation. Is there a industry level Trust Domain definition we can use instead? For example, should we use a definition that defines the trust domain in terms of the shared policies that apply? Something like: "A trust domain refers to a collection of systems, applications, or workloads that share a common security policy".
I'm good with this
Code change:
3.3.3. <del> In this specification, use of the Capsule Protocol RFC9297 is OPTIONAL.  Clients MAY request use of the Capsule Protocol by including a "Capsule-Protocol: ?1" header field in the request. Server support for the Capsule Protocol is also OPTIONAL.  If the request includes "Capsule-Protocol: ?1", and the server does not support the Capsule Protocol, the server MUST respond with a 4xx (Client Error) status and a "Capsule-Protocol: ?0" response header field, and MUST discard any data received on this request stream. Upon receiving such a response, the client MUST retry the request without the Capsule Protocol and MAY disable use of the Capsule Protocol with this URI Template for the remainder of the session. </del> <ins> In this specification, support for the Capsule Protocol RFC9297 is OPTIONAL for clients.  Clients MAY request use of the Capsule Protocol by including a "Capsule-Protocol: ?1" header field in the request. Server support for the Capsule Protocol is REQUIRED.  Servers MUST confirm use of the Capsule Protocol by echoing the "Capsule-Protocol: ?1" header in their response. </ins> When using the Capsule Protocol, TCP payload data is sent in the payload of a new Capsule Type named DATA (data-capsule).  The ordered

Related discussion:
text: We could potentially figure out recommendations for all these questions, but fundamentally it might be best to instead make capsules mandatory for connect-tcp, like they are for connect-udp and connect-ip. That would simplify implementations and improve consistency.
Individually, I think it would be interesting to try out this direction — probably based on implementation experience for how easy it is to add. On one hand, this makes connect-tcp less of a trivial drop-in. On the other, it opens up more possible use cases.
I heard a good deal of support for this direction in the HTTPBIS meeting.
Thanks!
Code change:
3.2. Dictionaries are ordered maps of name-value pairs, where the names <del> are short, textual strings and the values are items (item) or arrays of items, both of which can be parameterised (param).  There can be zero or more members, and their names are required to be unique within the scope of the dictionary they occur within. </del> <ins> are short, textual strings and the values can be items (item) or arrays of items, both of which can be parameterised (param).  There can be zero or more members, and their names are required to be unique within the scope of the dictionary they occur within. </ins> Implementations MUST provide access to dictionaries both by index and by name.  Specifications MAY use either means of accessing the

Related discussion:
text: For . Note that this makes missing values ; if we like that approach, I think we should do it for missing parameter values too (currently they use , which isn't part of our type system). I used because it aligns with the semantics of current uses nicely.
OK with me.
NAME This is a keen observation. Assuming that we are fine with requiring that knowledge on what the top type is, maybe we should also consider adding support for rule. It has been my understanding that the only reason we do not support rule in SH is because can only be applied for certain top types (but we are now requiring that knowledge).
We've discussed requiring knowledge of top-level types extensively, and I think we have agreement that it's OK. I"m not sure what you want regarding support for ; can you give an example (or open a new issue)?
I'm running my SH implementation against the HTTP Archive dumps (400,000,000+ HTTP requests) to see how the from BSH parse in something like the real world. A number of headers are failing because they have valueless dictionary members; e.g., , , . It should be pretty easy to accommodate these, as we already have optional values on parameters.
PTAL at the PR, especially the note about using True for missing parameter values.
Ping NAME NAME
Seems like a reasonable change. I'm happy to remove the 'null' from parameters too.
(already OK'ed in the PR)
Code change:
Let URL be the URL of the dictionary request. <del> Let PATTERN be a URLPattern constructed by setting input=MATCH, and baseURL=URL (https://urlpattern.spec.whatwg.org/). </del> <ins> Let PATTERN be a URL Pattern URLPattern constructed by setting input=MATCH, and baseURL=URL. </ins> <del> If PATTERN has regexp groups then return FALSE (https://urlpattern.spec.whatwg.org/#urlpattern-has-regexp- groups). </del> <ins> If PATTERN has regexp groups then return FALSE. </ins> Return True.

Related discussion:
text: Changed it to a proper normative reference. For
Merging this. Can always clean it up more if it is still a concern.
For example: Usually, we add something like URLPattern to the references, then that.
Sorry, didn't mean to close the issue. Feel free to close this out if the current language looks OK (also happy to update it if it needs some more tweaking).
Going to close this out now. Thanks for taking the time on this.
Code change:
The request SHALL include an "Upgrade" header field with the value "connect-tcp". <del> The request's target SHALL correspond to the URI derived from expansion of the proxy's URI Template. </del> <ins> The request SHOULD include a "Capsule-Protocol: ?1" header. </ins> If the request is well-formed and permissible, the proxy MUST attempt to establish the TCP connection before sending any response status

Related discussion:
text: This leaves only the Capsule Protocol mode
I do think we should add FINAL_DATA, but I'm fine with merging this first and then discussing that in
As of draft-ietf-httpbis-connect-tcp-05, connect-tcp now optionally supports the capsule protocol. However, this optionality adds non-trivial complexity to implementations. As currently written, if a client wishes to use capsules, the server can reject the use of capsules, and now the client needs to cache that this server doesn't support them. However it's undefined for how long the client should cache this information, and within what scope. We could potentially figure out recommendations for all these questions, but fundamentally it might be best to instead make capsules mandatory for connect-tcp, like they are for connect-udp and connect-ip. That would simplify implementations and improve consistency.
Individually, I think it would be interesting to try out this direction — probably based on implementation experience for how easy it is to add. On one hand, this makes connect-tcp less of a trivial drop-in. On the other, it opens up more possible use cases.
I heard a good deal of support for this direction in the HTTPBIS meeting.
Thanks!
Code change:
as that of the next later Object, with the assumption that the Object's data was reordered. <del> If neither the subscriber or publisher specify DELIVERY TIMEOUT, Objects are delivered as indicated by their Group Order and Priority. </del> <ins> If neither the subscriber or publisher specify DELIVERY TIMEOUT, all Objects in the track matching the subscription filter are delivered as indicated by their Group Order and Priority.  If a subscriber exceeds the publisher's resource limits by failing to consume objects at a sufficient rate, the publisher MAY terminate the subscription with error 'Too Far Behind'. If an object in a subgroup exceeds the delivery timeout, the publisher MUST reset the underlying transport stream (see closing- subgroup-streams). </ins> When sent by a subscriber, this parameter is intended to be specific to a subscription, so it SHOULD NOT be forwarded upstream by a relay

Related discussion:
text: At some point, the relay would have to drop the data; we should specify how that happens (lowest priority stream gets dropped first?).
Individual Comment: +1 We need to specify what happens in this case. I think there's two parts: 1) selecting what gets dropped (this is a priority question) 2) the mechanism for dropping (stream resets, etc).
+1 Expanding Alan's list, I think we should determine: (1a?) valid boundaries for dropping data (group? object? byte? bit?) (2a?) under what circumstances the subscriber needs to be informed of the dropped data (do we need different verbs with different semantics in this case, e.g. fetch/subscribe? is dropping data always permitted and something all subscribers must be able to tolerate?) (2b?) the means of informing subscribers of dropped data (implied or explicit)
The AI is to add an error code for SUBSCRIBE_DONE to indicate a subscription was cancelled because the subscription was too far behind.