jiebi/CodeConvo huggingface dataset:
Code change:
Transparency Services MUST ensure that for any Signed Statement they register, enough information is made available to Auditors (either in the Append-only Log and retrievable through audit APIs, or included <del> in the Receipt) to authenticate and retrieve the Transparent Statements describing the registration policy and trust anchors that apply to this registration. </del> <ins> in the Receipt) to reproduce the Registration checks that were defined by the Registration Policies at the time of Registration. </ins> 4.1.2.

Related discussion:
text: Please review and we'll merge Wednesday morning US Pacific time if there are no objections. I'll incorporate agreed suggestions as well.
Merging with no other feedback.
good enough By and large the document is at a point where it can be called on for final reading. There are some nits or issues that we would like to see done to tighten it up. The introduction discusses distributed, but there is no real discussion of how or what that means and it leads readers to set an expectation that is incorrect. This word should be deleted. Removal of the Feeds definition. This was in the original version, and we have bounced all over the place during the last year to formulate a solution to a problem with Federation. We have decided collectively to park that and thus the use of feeds is gone. In a future overarching product or charter it could come back. There is a bit of a misunderstanding generated by stating that receipts don't expire, which later on is a line that requests for a refreshed receipt can be supported. The logical receipt is intended to never expire and based on the protected content in the ledger's log a new receipt can be generated at any time. This gives us an avenue to bridge a world from today to post quantum cryptography based counter signatures that is important. We need to clear up these two points. What goes into the append only log can vary from implementation to implementation. It may be that one implementation records the hash of the signed statement, plus evidence of how we proved that it was valid at the time of acceptance (things like records of OCSP response, or CRL lookups). Another implementation may simply store the signed statement. This from a generic point of view means that given access to the signed statements you can prove that it is on the append only log always. In section 4.1.1.2 it alludes that an auditor can mine the log to authenticate and retrieve the transparent statement. Based on the last statement this has two problems. The first it assumes that the signed statement is kept and that it can generate a new receipt (see 3) and produce a transparent statement. If it could this would be equivalent to the original in intent but not binary equal. The original receipt (or last created receipt from a refresh) is not required (or intended) to be kept in the ledger.
Code change:
Transparency Services MUST ensure that for any Signed Statement they register, enough information is made available to Auditors (either in the Append-only Log and retrievable through audit APIs, or included <del> in the Receipt) to authenticate and retrieve the Transparent Statements describing the registration policy and trust anchors that apply to this registration. </del> <ins> in the Receipt) to reproduce the Registration checks that were defined by the Registration Policies at the time of Registration. </ins> 4.1.2.

Related discussion:
text: Generically then this is impossible and may be where we would leverage consistency proofs in a later version.By and large the generic aspect of the document is there but we missed one sentence: "Signed Statements and Artifacts associated with a software package." We would suggest removing the "software package".
Code change:
concerns related to HTTP semantics are about securing server-side applications (code behind the HTTP interface), securing user agent processing of content received via HTTP, or secure use of the <del> Internet in general, rather than security of the protocol.  Various organizations maintain topical information and links to current research on Web application security (e.g., OWASP). </del> <ins> Internet in general, rather than security of the protocol.  The security considerations for URIs, which are fundamental to HTTP operation, are discussed in URI.  Various organizations maintain topical information and links to current research on Web application security (e.g., OWASP). </ins> 17.1.

Related discussion:
text: Inspired by follow-up discussions on , make a concrete proposal for how the RFC 3986 security considerations might be mentioned in our own security considerations. I understand the editors' stance on adding substantial new text at this point, and will defer to them on whether this constitutes "substantial".
Code change:
respond with a StreamErrorHandler or ConnectionErrorHandler of type FLOW_CONTROL_ERROR if it is unable accept a frame. <del> The following additional flags are defined for the WINDOW_UPDATE frame: </del> <ins> The WINDOW_UPDATE frame defines the following flags: </ins> <del> Bit 2 being set indicates that flow control for the identified </del> <ins> Bit 1 being set indicates that flow control for the identified </ins> stream or connection has been ended; subsequent frames do not need to be flow controlled.

Related discussion:
text: Also reservers flag 0x2 in DATA and HEADERS frames and renumbers flags accordingly.
Please feel free to exercise editorial privilege with respect to wording. Reserving 0x2 at NAME requests.
Code change:
TBD <del> @VC_JWT </del> <ins> 11.1. This section requests registration of the "application/sd-jwt" media type RFC2046 in the "Media Types" registry IANA.MediaTypes in the manner described in RFC6838, which can be used to indicate that the content is an SD-JWT. 11.2. This section requests registration of the "+sd-jwt" structured syntax suffix in the "Structured Syntax Suffix" registry IANA.StructuredSuffix in the manner described in [RFC6838], which can be used to indicate that the media type is encoded as an SD-JWT. </ins>

Related discussion:
text: To fix Issue , I found that removing Example 2b is the best way to go. I tried to fixate the nonces used in the examples despite decoys being generated in one of the examples, but that got quite messy and introduces a lot of unsafe code paths into the python code. An alternative would be to manage the example manually, but that is a source for errors, so let's not do that.
The decoy concept is intuitive enough that a separate example isn't needed, I think. And per the separate example that has a completely different set of digests might cause confusion. So removing 2b seems like a good course of action. The change is larger than I'd have expected. Are all the other file changes due to regenerating examples? I think so but it caught my attention. And it seems like and this will be difficult to resolve. But maybe you've already considered that.
Why remove an entire example, if we can add a text clarifying that "Example 2b uses the same data as 2a, but because even for the same claim values, different nonces are used, not just the decoys but all digests are different from those in 2a"?
That was my initial approach, but with that change there's really not that much value to the example: It just shows a bunch of digests, where the number of digests is higher than it was previously. The fact that the digests are different can be confusing for readers at worst and the example is not very helpful at best.
So instead of showing the decoy digests in the examples you propose to list them seperately and not show a complete example with decoy digests?
We agreed on our call to generate a snippet of markdown code to explicitly list the decoy digests to improve the explanation.
I updated the python script and the spec to show the decoy digests: URL
Other than the little nit about the the text that says the decoys in the example are about the address, this looks pretty good.
Do you want to mention something in the doc history?
Good point, done!
NAME Can you please review this?
states that it was created using data from , but adding decoy values. I'd expect its param to be a superset of example 2a's, but it's not the case. Am I missing something?
Code change:
TBD <del> @VC_JWT </del> <ins> 11.1. This section requests registration of the "application/sd-jwt" media type RFC2046 in the "Media Types" registry IANA.MediaTypes in the manner described in RFC6838, which can be used to indicate that the content is an SD-JWT. 11.2. This section requests registration of the "+sd-jwt" structured syntax suffix in the "Structured Syntax Suffix" registry IANA.StructuredSuffix in the manner described in [RFC6838], which can be used to indicate that the media type is encoded as an SD-JWT. </ins>

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:
If input_key contains characters not in lcalpha, DIGIT, "_", "-", ".", or "*" fail serialisation. <del> If the first character of input_key is not lcalpha, fail </del> <ins> If the first character of input_key is not lcalpha or "*", fail </ins> serialisation. Let output be an empty string.

Related discussion:
text: This change to the key syntax allows dictionaries and parameters to use "" as a starting character for names, allowing keys like value mygoditsfullofstars*
LGTM. Do you want to add the change note, or shall I do that after merging?
BTW - would take a PR with an example key that looks like the last one above :)
In URL, NAME asks for as a dictionary member name. I think this just means adding it to valid start characters in key.
Code change:
according to the "application/x-www-form-urlencoded parsing" section of HTMLURL, resulting in a list of ("nameString", "valueString") tuples.  The REQUIRED "name" parameter of each component identifier <del> contains the "nameString" of a single query parameter as a String value.  Several different named query parameters MAY be included in the covered components.  Single named parameters MAY occur in any order in the covered components. The component value of a single named parameter is calculated by the following process: Parse the "valueString" of the named query parameter defined by the "application/x-www-form-urlencoded parsing" section of HTMLURL, which is the value after percent-encoded octets are decoded Encode the "valueString" using the "percent-encode after encoding" process defined by the "application/x-www-form-urlencoded serializing" section of HTMLURL, which results in an ASCII string This ASCII string is the component value Note that this value does not include any leading "?" characters, equals sign "=", or separating "&" characters.  Named query parameters with an empty "valueString" have an empty string as the component value. </del> <ins> contains the encoded "nameString" of a single query parameter as a String value.  The component value of a single named parameter is the encoded "valueString" of that single query parameter.  Several different named query parameters MAY be included in the covered components.  Single named parameters MAY occur in any order in the covered components, regardless of the order they occur in the query string. The value of the "name" parameter and the component value of a single named parameter are calculated by the following process: Parse the "nameString" or "valueString" of the named query parameter defined by the "application/x-www-form-urlencoded parsing" section of HTMLURL, which is the value after percent- encoded octets are decoded. Encode the "nameString" or "valueString" using the "percent-encode after encoding" process defined by the "application/x-www-form- urlencoded serializing" section of HTMLURL, which results in an ASCII string. Output the ASCII string, Note that the component value does not include any leading "?" characters, equals sign "=", or separating "&" characters.  Named query parameters with an empty "valueString" have an empty string as the component value.  Note that due to inconsistencies in implementations, some query parameter parsing libraries drop such empty values. </ins> If a query parameter is named as a covered component but it does not occur in the query parameters, this MUST cause an error in the

Related discussion:
text: Encodes query parameter names to match values, to avoid non-ascii or otherwise problematic values.
In 2.2.8: What if the query parameter contains non-ASCII characters? I think this needs to say that the name parameter needs to contain the raw (percent-encoded) name.
Good catch, I believe you're correct.
Code change:
6.9. <del> A publisher issues a "SUBSCRIBE_RST" message to all subscribers </del> <ins> A publisher issues a "SUBSCRIBE_RESET" message to all subscribers </ins> indicating there was an error publishing to the given track and subscription is terminated. <del> The format of "SUBSCRIBE_RST" is as follows: </del> <ins> The format of "SUBSCRIBE_RESET" is as follows: </ins> Subscribe ID: Subscription Identifier as defined in message- subscribe-req.

Related discussion:
text: QUIC uses RESET, we should too.
Teeechnically, QUIC uses STOP for receiver-initiated closes. But RESET is better than RST.
Code change:
6.9. <del> A publisher issues a "SUBSCRIBE_RST" message to all subscribers </del> <ins> A publisher issues a "SUBSCRIBE_RESET" message to all subscribers </ins> indicating there was an error publishing to the given track and subscription is terminated. <del> The format of "SUBSCRIBE_RST" is as follows: </del> <ins> The format of "SUBSCRIBE_RESET" is as follows: </ins> Subscribe ID: Subscription Identifier as defined in message- subscribe-req.

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:
6.9. <del> A publisher issues a "SUBSCRIBE_RST" message to all subscribers </del> <ins> A publisher issues a "SUBSCRIBE_RESET" message to all subscribers </ins> indicating there was an error publishing to the given track and subscription is terminated. <del> The format of "SUBSCRIBE_RST" is as follows: </del> <ins> The format of "SUBSCRIBE_RESET" is as follows: </ins> Subscribe ID: Subscription Identifier as defined in message- subscribe-req.

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:
6.9. <del> A publisher issues a "SUBSCRIBE_RST" message to all subscribers </del> <ins> A publisher issues a "SUBSCRIBE_RESET" message to all subscribers </ins> indicating there was an error publishing to the given track and subscription is terminated. <del> The format of "SUBSCRIBE_RST" is as follows: </del> <ins> The format of "SUBSCRIBE_RESET" is as follows: </ins> Subscribe ID: Subscription Identifier as defined in message- subscribe-req.

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 .