jiebi/CodeConvo huggingface dataset:
Code change:
2.2.1. <del> To be considered as a match, the dictionary must not yet be expired as a dictionary.  When iterating through dictionaries looking for a match, the expiration time of the dictionary is calculated by taking the last time the dictionary was fetched and adding the "ttl" seconds from the "Use-As-Dictionary" response.  If the current time is beyond the expiration time of the dictionary, it MUST be ignored. </del> <ins> To be considered as a match, the dictionary resource MUST be either fresh HTTP-CACHING or allowed to be served stale (see eg RFC5861). </ins> 2.2.2.

Related discussion:
text: I'm not 100% sure it's just a workaround and origin-compressing against previous releases at build time may be preferable for some cases. The most extreme case that comes to mind is something like a huge WASM app (like Photoshop) where the files are upwards of 50MB (well, huge relative to the usual web page resources). Presumably the CDN could still do the work to do the compression (maybe as an offline job for future requests) so it doesn't require the origin to do it necessarily but it's a lot more reasonable in the extreme cases. That said, I think we can still get buy without a separate TTL and adding one later if it ends up being useful can be done as an enhancement without breaking the existing case.
I like red patches. Thanks.
Code change:
the abstract stating the mechanism is only being proposed for controlled environments.  The abstract specifies environments where the Quick-Start request could give false positives (and therefore <del> would be unsafe to deploy).  The abstract also specifies environments where packets containing the Quick-Start request could be dropped in the network; in such an environment, Quick-Start would not be unsafe to deploy, but deployment would still not be recommended because it could cause unnecessary delays for the connections attempting to use Quick-Start. </del> <ins> would be unsafe for incremental deployment where some routers forward, but do not process the option).  The abstract also specifies environments where packets containing the Quick-Start request could be dropped in the network; in such an environment, Quick-Start would not be unsafe to deploy, but deployment would not be recommended because it could lead to unnecessary delays for the connections attempting to use Quick-Start.  The Quick-Start method is discussed as an example in RFC9049. </ins> For authors of alternate congestion control schemes who are not ready to bring their congestion control mechanisms to the IETF for

Related discussion:
text: Update the QS text and various editorial suggestions. if merged.
I'll propose a PR with some editorial updates to the first part of the ID.
Code change:
header. The Use-As-Dictionary response header is a Structured Field <del> STRUCTURED-FIELDS with values for "match", "match-dest", "id", and "type". </del> <ins> STRUCTURED-FIELDS Dictionary with values for "match", "match-dest", "id", and "type". </ins> 2.1.1. <del> The "match" value of the Use-As-Dictionary header is a sf-string value that provides the URLPattern to use for request matching </del> <ins> The "match" value of the Use-As-Dictionary header is a String value that provides the URLPattern to use for request matching </ins> (https://urlpattern.spec.whatwg.org/). The URLPattern used for matching does not support using Regular

Related discussion:
text: Switched from using the ABNF field types to the human names (i.e. sf-dictionary to Dictionary) for all of the Structured Field header values. Switched dictionary "type" to a Token (from String).
NAME could you PTAL at the change in referencing the header field types? Specifically, I wasn't sure if I should capitalize the types or not (I did since that's how the structured fields RFC referred to them).
Yep, this looks good. It's common to add something to you Notational Conventions section (or whatever) that says roughly "This specification uses the following terms from [ref to SF]: String, Byte Sequence, Token, ..."
Code change:
community MUST consider the following criteria.  These criteria will be evaluated in various domains (see general-use and special-cases). <ins> Some of the sections below will list criteria that SHOULD be met.  It could happen that these criteria are not in fact met by the proposal. In such cases, the community MUST document whether not meeting the criteria is acceptable, for example because there are practical limitations on carrying out an evaluation of the criteria. The requirement that the community consider a criterion does not imply that the result needs to be described in a resulting RFC. There is no formal requirement to document the results, although normal IETF policies for archiving proceedings will provide a record. This document, except where otherwise noted, does not provide normative guidance on the acceptable thresholds for any of these criteria.  Instead, the community will use these evaluations as an input when considering whether to progress the proposed algorithm. </ins> 5.1. The criteria in this section evaluate the congestion control

Related discussion:
text: A few clarifying nits, as resolving the tension between a global "MUST evaluate" and some local "SHOULD evaluate"s.
Merge!
Code change:
HTTP/2 relies on the HTTP definition of authority for determining whether a server is authoritative in providing a given response (see <del> HTTP).  This relies on local name resolution for the "http" URI scheme and the authenticated server identity for the "https" scheme. </del> <ins> HTTP).  This relies on local name resolution for the " " URI scheme and the authenticated server identity for the " " scheme. </ins> 10.2.

Related discussion:
text: Also, use .
and 9.1.1: We quoted "https" where preceded by "resources". Please let us know if this is incorrect. Original: CONNECT is primarily used with HTTP proxies to establish a TLS session with an origin server for the purposes of interacting with https resources. ... For https resources, connection reuse additionally depends on having a certificate that is valid for the host in the URI. Currently (best viewed in the .html or .pdf output): CONNECT is primarily used with HTTP proxies to establish a TLS session with an origin server for the purposes of interacting with "https" resources. ... For "https" resources, connection reuse additionally depends on having a certificate that is valid for the host in the URI.
Folded into .
: We made quoting consistent around lowercase instances of "http" and "https" when describing URIs or schemed URIs, per quoted instances in , 3.2, and 10.1. Please let us know any objections. Original: http and https schemed URIs http or https schemed URIs http or https URIs Currently: "http" and "https" schemed URIs "http" or "https" schemed URIs "http" or "https" URIs
Code change:
HTTP/2 clients MUST indicate the target domain name when negotiating TLS. <del> Deployments of HTTP/2 that negotiate TLS 1.3 or higher need only support and use the SNI extension; deployments of TLS 1.2 are subject to the requirements in the following sections.  Implementations are </del> <ins> Requirements for deployments of HTTP/2 that negotiate TLS13 are included in tls13features.  Deployments of TLS 1.2 are subject to the requirements in tls12features and tls12ciphers.  Implementations are </ins> encouraged to provide defaults that comply, but it is recognized that deployments are ultimately responsible for compliance.

Related discussion:
text: A lot has happened to TLS since we did RFC 7540. This tries to capture that succinctly. It rolls in changes from RFC 8740.It mentions early data and RFC 8470.It updates references, citing TLS 1.3 rather than 1.2 for a generic TLS reference.
A few small changes are included in , which could be integrated easily.
I won't create the pull request just yet, but here are some proposed changes: URL NAME do you think that you could review these? I've paraphrased some of RFC 8740 and I want to make sure I haven't missed anything.
(The GitHub link did something silly, but I'm assuming 837d46a5ff9e23a62cb719f69be7f1d10bf8da80 is the right commit and just looked at that.) s/the handshake// Though I wonder if this sentence can just be omitted. I needed to address it in RFC8740 because RFC7540 didn't have a TLS version dispatch. But now the TLS 1.2 features section is explicitly mentioned as being 1.2-only, so that exception already doesn't apply. Otherwise LGTM. (I think the default values in server settings is implicit from the fact that we haven't received anything from the server yet, but whatever.)
Thanks. I've updated my branch to remove the renegotiation piece. I've updated that link (which I should have checked).
Code change:
prefix) MUST also be set.  Link-layer technologies that require the 'L' flag bit to be cleared are out of scope of this document. <del> The 'Stub Router' flag bit (I-D.hui-stub-router-ra-flag) MUST be set in the RA flags field.  The values of the 'M' and 'O' flag bits MUST be copied from the respective 'M' and 'O' flag bit values seen in the most recent (unicast or multicast) RA received from a non-SNAC- router.  For the selection of the most recent RA, the following RAs MUST be excluded: </del> <ins> The 'SNAC Router' flag bit (I-D.ietf-6man-snac-router-ra-flag) MUST be set in the RA flags field.  The values of the 'M' and 'O' flag bits MUST be copied from the respective 'M' and 'O' flag bit values seen in the most recent (unicast or multicast) RA received from a non-SNAC-router.  For the selection of the most recent RA, the following RAs MUST be excluded: </ins> If there is no recent RA from a non-SNAC-router, both 'M' and 'O' flag bits MUST be cleared, unless the SNAC router rebooted recently.

Related discussion:
text: Update draft version "stub router flag" -> SNAC router flag fix a few cases where Esko (I think!) missed changing stub router to SNAC router but should have (there are some cases where "stub router" is correct and I hope I did not change any of those.
In the update to the 'SNAC router' name () the flag name was not yet taken along in the update. This issue is to decide on that change also, and if needed make the change. (The 6man document would also need to change the flag name then, first.)
Code change:
sense for their operational use cases. At least one identifier for an identity document MUST be included in <del> the protected header of the COSE envelope, either "x5t" or "kid". </del> <ins> the protected header of the COSE envelope, as one of "x5t", "x5chain" or "kid". </ins> Support for "x5t" is mandatory to implement. <del> Support for "kid" is optional. </del> <ins> Support for "kid" and "x5chain" is optional. </ins> <del> When "x5t" is present, "iss" MUST be a string with a value between 1 and 8192 characters in length that fits the regular expression of a distinguished name. </del> <ins> When "x5t" or "x5chain" is present, "iss" MUST be a string with a value between 1 and 8192 characters in length that fits the regular expression of a distinguished name. </ins> The mechanisms for how Transparency Services obtain identity documents is out-of-scope of this document. <del> The "kid" header parameter MUST be present when the "x5t" header parameter is not present.  Key discovery protocols are out-of-scope of this document. </del> <ins> The "kid" header parameter MUST be present when neither "x5t" nor "x5chain" are present.  Key discovery protocols are out-of-scope of this document. </ins> The protected header of a Signed Statement and a Receipt MUST include the "CWT Claims" header parameter as specified in CWT_CLAIMS_COSE.

Related discussion:
text: Given a transparent statement (and possibly auxiliary transparent statement from the TS log recording root and intermediate certificates) verifiers must be able to retrieve and review the full certificate chain. This clearly separates PKI issues (delegated to certificate issuance) and the evidence required to keep them transparent and auditable. The text included a a way to implement this requirement based on transparent configuration statements, which I found useful but may be too detailed/prescriptive for the architecture.
I don't think its in the spirit of COSE to include the full cert chain in a protected header. A thumbprint to a certificate that is in a chain is more concise.
This issue will be closed if no PR is raised by Friday.
Closed with
These changes seem appropriateI suggested a couple of improvements, but overall I support this PR. LGTM
Code change:
Subscribe ID: Subscription identifier as defined in message- subscribe-req. <ins> ContentExists: 1 if an object has been published for this subscription, 0 if not.  If 0, then the Final Group and Final Object fields will not be present. </ins> Final Group: The largest Group ID sent by the publisher in an OBJECT message in this track.

Related discussion:
text: by adding an explicit bool indicating whether any Objects were published for a subscription, similar to the explicit bool added to SUBSCRIBE_OK in .
and define: However, what happens if no objects were ever produced/sent?
Individual Comment: Oops. Two possible ways to handle this: 1) Flag indicating presence of these fields (Use Location now that is defined elsewhere?) 2) Change the semantics of the fields to be exclusive (eg: it is the first object NOT sent), so 0/0 means none.
I'm inclined towards 0/0, because optional fields are more complex to parse and I would expect the existing logic to work correctly with 0/0.
Let's say the last object delivered by the relay is . Does the relay send RESET or ? Is the subscriber able to infer the presence of future objects? What if either of those objects actually exist in the cache?
Individual Comment: If we use exclusive encoding then I'd say that the receiver shouldn't infer the existence of non-existence of the named object, and either 5/30 or 6/0 works, but 5/30 is preferable?
If you define there will be no objects greater than or equal to these, then 0/0 makes total sense. So 0/0 for null case and say the last group ID of the last object publish was 10 then the value in SUB_FIN would be 11.
In we went with an explicit flag, so I'm inclined to do the same here for consistency.
Code change:
Subscribe ID: Subscription identifier as defined in message- subscribe-req. <ins> ContentExists: 1 if an object has been published for this subscription, 0 if not.  If 0, then the Final Group and Final Object fields will not be present. </ins> Final Group: The largest Group ID sent by the publisher in an OBJECT message in this track.

Related discussion:
text: To allow subscribers to indicate that no new subscriptions will be routed to the publisher for a given namespace. Happy to bikeshed on the name and whether we really need another frame for this.
The problem is not possible for the subscriber to reject an ANNOUNCE afterwards. This would be very useful, for example to inform a publisher that no more subscriptions will be routed to them for whatever reason. Examples: The auth parameter in ANNOUNCE has expired. Another publisher has sent an overriding ANNOUNCE (reconnect?) The broadcast has been closed remotely, ex. some moderation tool. Without this message, the only recourse for the subscriber is to close the connection. This won't work if multiple ANNOUNCE messages are pooled over the same connection, nor is it clean.
I propose two options: can be sent after . We add and to mirror . I personally hate 3 separate messages for a subscriber to close an announce, or a publisher to close a subscription. See
very trivial bikeshed comment ... I would prefer to call it something other RESET ( and also other places we use RESET ). I get the TCP analogy but I think that is the wrong way to think about this. I would prefer something like REVOKE.
how about ANNOUNCE_CANCEL to cancel an open announce ?
Conclusion is that we do need to add a new frame to end an ANNOUNCE. Additionally, there was a principle stated that we should not rely on closing the session as the typical or optimal way to close state and close either an ANNOUNCE or SUBSCRIBE.
On the call today, people tend to prefer ANNOUNCECLOSE over ANNOUNCECANCEL as a name. They also prefer merging SUBSCRIBERESET and SUBSCRIBEFIN into a single message, possibly SUBSCRIBE_CLOSE.
On an editorial note, it'd be nice to have subsections for publisher/subscriber to make it clearer to the reader.
If we're going to combine and , then we should just combine and now. My desire is to have four messages: publisher create: ANNOUNCE publisher close: UNANNOUNCE subscriber accept: ANNOUNCEOK subscriber close: ANNOUNCESTOP The same goes for subscriptions: subscriber create: SUBSCRIBE subscriber close: UNSUBSCRIBE publisher accept: SUBSCRIBEOK publisher close: SUBSCRIBESTOP
Code change:
Subscribe ID: Subscription identifier as defined in message- subscribe-req. <ins> ContentExists: 1 if an object has been published for this subscription, 0 if not.  If 0, then the Final Group and Final Object fields will not be present. </ins> Final Group: The largest Group ID sent by the publisher in an OBJECT message in this track.

Related discussion:
text: PR updated, PTAL
This came out of discussion on When a relay receives an SUBSCRIBE it may need to issue its own SUBSCRIBE to a publisher that has previously ANNOUNCE'd a namespace matching that track. The current draft doesn't specify how this match is done. A relay could implement an exact match on Track Namespace (requires a tweak to SUBSCRIBE), or could do a longest prefix match on track name vs all ANNOUNCE'd namespaces, or possibly something else. Is it ok to leave this up to implementations or should the draft specify this behavior more exactly? If more than one matching type is allowed, does it need to be negotiated, and by whom (publisher, subscriber, or both)?
An issue that came up in interop that is somewhat related - NAME relay was implemented to take the namespace from the connect URL, because in his use-case, ANNOUNCE can be made redundant with the connect URL (eg it contains a namespace and enough auth). However, this caused an interop problem because my chat application assumes a certain functionality from relays, and that includes supporting ANNOUNCE messages to determine routing to publishers. Do we need to be more prescriptive about relay behavior?
ANNOUNCE is what my implementation expects as well. A producer can announce track namespaces at any point (after being connected). Overloading connect URL with track info is limiting
This is going to be a slightly long comment but this is how I think this should work. The catalog has two fields for the track namespace , and track name. We also specify in the catalog a way to form a URL from these two fields. See Teds proposal and that is catalog specific. The things we put in these track namespaces and track name fields are already canonicalized in a way defined by the catalog and URL. When the application using the moq transport puts these two fields into message, they are treated as just a bunch of bits and any comparison of them is done with bitwise compare. A relay that needs to check if a namespace matches another does not need to worry about string prep or escape encoding of the bits, the will all have been done when the catalog was formed. This allows the relays to work faster by just doing bitwise compare yet at the same time allows us to use URI at the application level. The transport draft just needs to deal with a bag of bits.
Code change:
Subscribe ID: Subscription identifier as defined in message- subscribe-req. <ins> ContentExists: 1 if an object has been published for this subscription, 0 if not.  If 0, then the Final Group and Final Object fields will not be present. </ins> Final Group: The largest Group ID sent by the publisher in an OBJECT message in this track.

Related discussion:
text: The catalog draft pushes the work to the URL definition, and the URL definition does the heavy lifting but that is where this type of stuff should be
NAME Just to clarify that when you say "bitwise compare" you also mean exact matching the entire namespace field from announce to the one in subscribe?
I would like to decouple the media layer from the transport layer. A tool like ffmpeg should be able to generate a MoQ catalog without knowing the namespace it will be served from, much like a tool like zip should be able to generate a file without knowing the path it will be stored. HLS/DASH provides this functionality with absolute or relative paths. If the playlist contains relative paths, then it can be served from any HTTP host/path provided the segments are served from the same host/path. If you want to decouple the two (ex. application serves playlist, CDN serves segments), then you use absolute URLs. To accomplish the same thing, the namespace should be optional in a MoQ catalog. This would mean media tracks are served from the same namespace as the catalog: whatever that might be.
To expand further, I think that MoQ broadcasts should be namespace agnostic: a broadcast ingested with namespace XXX is NOT required to be delivered as XXX. I understand where Cullen is coming from: an application like WebEx can use the same namespace for contribution/distribution because it controls the full pipeline. The application has all of the information required for all future routing/identification so it can set it on the first hop and expect any relays to blindly proxy. However, for a more generic or distributed system, this is not true. A client like OBS knows nothing about how the broadcast will eventually be distributed, fanned out, or the requirements of potentially multiple CDNs that might be used, nor will those requirements be the same between vendors (present or future). So I don't think we should require that input namespace == output namespace. In the HTTP world, this would be like requiring that all HTTP paths match the origin. It's quite restrictive and just means a CDN needs find another way to perform routing via a custom header/parameter. I propose we emulate the HTTP model where there's non in-band notification that a path/namespace was modified. An origin might serve and a CDN might decide to serve it as .