jiebi/CodeConvo huggingface dataset:
Code change:
preferences for a track, it SHOULD close the session with an error of 'Protocol Violation'. <del> An "OBJECT_STREAM" message carries a single object on a stream. There is no explicit length of the payload; it is determined by the end of the stream.  An "OBJECT_STREAM" message MUST be the first and only message on a unidirectional stream. </del> <ins> An "OBJECT_STREAM" message carries a single object on a stream.  An "OBJECT_STREAM" message MUST be the first and only message on a unidirectional stream. </ins> An Object received in an "OBJECT_STREAM" message has an "Object Forwarding Preference" = "Object".

Related discussion:
text: This had consensus in the past, but a PR wasn't written. Particularly now that we have Object Status, which is optional for all other mappings, it makes sense to add the length and make things consistent.
In our current encoding, you can stream objects without knowing their length in advance if your forwarding preference is Object or Datagram, but not if it's Track or Stream (since those require explicit lengths in the front). I feel like those two aspects should not be tied: we should either support or not support streaming for all preferences.
Individual Comment: In order to stream multiple objects with unknown lengths in a multi-object stream, you'd need additional framing. Alternately, we could create single-object variants of the TRACK and GROUP stream header.
I agree it's weird to have a mix of unframed and framed messages. While I prefer unframed streams... I think we should state that MoQ objects are always framed, represent a single point in time, and have a known length. It's an optimization to withhold the length in the datagram and dedicated stream case but maybe we should include it.
In meeting we decided add a length to everything. We can add extension later to have no length if we need ( Thanks to Mike E for suggestion )
LGTM
Code change:
1.2. <ins> This document uses the following terminology from RFC8941 to specify syntax and parsing: List and Byte Sequence. </ins> Phrases like TLS client certificate authentication or mutually- authenticated TLS are used throughout this document to refer to the process whereby, in addition to the normal TLS server authentication

Related discussion:
text: try to align better with the style guide on structured fields usage for
See URL, which would affect sections 2.2 and 2.3
Will update the structured fields parts to align with the style guide.
LGTM
Code change:
A publisher sends a SUBSCRIBE ERROR control message in response to a failed SUBSCRIBE REQUEST. <del> Full Track Name: Identifies the track in the request message for which this response is provided. </del> <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> Error Code: Identifies an integer error code for subscription failure.

Related discussion:
text: by explicitly specifying the namespace. Also consistently changes to the (b) notation to indicate a variable length sequence of bytes.
This PR got lost when merging 289.
Assume a setup with two publishers, a single relay and one subscriber. P1 ANNOUNCE's track namespace fooba P2 ANNOUNCE's track namespace foo S1 sends a SUBSCRIBE REQUEST for Full Track Name How does the relay know whether is Track Namespace: and Track Name: , or Track Namespace: and Track Name , and hence which publisher to route the subscribe to? I see a few possibilities: 1) The relay should not allow this scenario (via namespace construction and/or authorization). If so the draft should include text explaining that this is disallowed (normatively?) or "bad things(tm)" happen. 2) Change SUBSCRIBE REQUEST to be able to disambiguate the Track Namespace from the Track Name. This could be done by sending name and namespace in separate message fields, or having stricter rules for the structure of Full Track Name such that a relay can extract the constituent parts. 3) Explicitly state that Full Track Names are matched to namespaces via "longest prefix match".
Option 3 looks interesting. P1 can use a longer track namespace to steer the sub request from P2. Like a traffic engeering for content.
I like option 2. I don't agree with treating track namespace as merely a string prefix. Even if you go with option 3, there's still a race condition where a late ANNOUNCE will cause a SUBSCRIBE to an unintended track. I want to give the track namespace more properties so it's treated more like a broadcast identifier. A few folks are headed down this path without realizing it, such as proposing that there's a single catalog per track namespace. I don't see how that would even work if ANNOUNCE is used purely for routing like a BGP announcement.
NAME : are you saying you believe that the relay resolves the described ambiguity by using 'longest prefix' matched (eg: option 3)? Another option I hadn't considered based on this comment is that the relay would send OBJECTs from BOTH publishers since they both match the Full Track Name. This will break in the current design, since each publisher has their own Object Sequence and Group Sequence and when merged the consumer will be left with garbage.
Code change:
A publisher sends a SUBSCRIBE ERROR control message in response to a failed SUBSCRIBE REQUEST. <del> Full Track Name: Identifies the track in the request message for which this response is provided. </del> <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> Error Code: Identifies an integer error code for subscription failure.

Related discussion:
text: It also violates the logic described that says a Full Track Name can be used as a cache key.
Yeah that seems quite problematic NAME Let's say a relay have two connected publishers who send IN ORDER: A subscriber connects and issues: What happens next? The relay forwards the SUBSCRIBE to publisher 1. The relay returns SUBSCRIBE ERROR notfound The relay forwards the SUBSCRIBE to publisher 2. The relay forwards the SUBSCRIBE to publisher 1&2. These are in the order of Alan's options. I added option 4 based on Suhas' comment. Would occur if the relay rejects publisher2's ANNOUNCE because of thr shared prefix. Would occur because the track namespace is an ID, not a prefix, and must fully match an ANNOUNCE. Would occur because publisher2 has the longer path prefix. Would occur because both publishers could_ produce the requested track. And to throw a wrench in things, a third publisher joins.
There's also the case where the relay replies to the subscribe requests on behalf of the publisher(s), so it doesn't have to make the routing decision at subscription time. But it does need to decide where to forward OBJECTs when they arrive.
Implementing this now so I have some more thoughts. We should explicitly support UNANNOUNCE and UNSUBSCRIBE, which implicitly occur when the connection is dropped. On ANNOUNCE, the relay MUST ensure that the namespace not a subset/superset of an existing ANNOUNCE. On SUBSCRIBE, the relay looks up the track based on the prefix and appends itself to a list of subscribers. If not found, it looks up the namespace and creates a track entry if valid. On UNSUBSCRIBE, the relay looks up the track based on the full name and removes itself from a list of subscribers. On UNANNOUNCE, the relay deletes any namespaces and tracks matching the prefix. A radix tree is used for both so the relay can iterate through any values that match the given prefix. This is a global radix tree, similar to how QUIC connections are identified when variable length connection IDs are supported. On ANNOUNCE, the relay inserts the upstream into the upstreams hash map and errors on a duplicate. On SUBSCRIBE, the relay looks up the namespace and then the track, creating an entry if not found.
Code change:
A publisher sends a SUBSCRIBE ERROR control message in response to a failed SUBSCRIBE REQUEST. <del> Full Track Name: Identifies the track in the request message for which this response is provided. </del> <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> Error Code: Identifies an integer error code for subscription failure.

Related discussion:
text: On UNSUBSCRIBE, the relay looks up the namespace and then the track, deleting an entry if found. On UNANNOUNCE, the relay deletes from the namespace and track hash map. This is a strictly better than option 1. It provides the same functionality but faster, and without the restriction on namespace prefixes. Runs into issues with ANNOUNCE. example: and are subscribed to different publishers, despite using THE SAME NAME. This invalidates the claim that the track name is the cache key. We can't migrate to the new longer prefix from unless there's a guarantee they are producing the same content. A similar issue occurs when UNANNOUNCE is fired, when happens implicitly when the connection is dropped: Each subscription needs to keep reference to the track when the SUBSCRIBE was received, instead of doing a lookup based on full track name when each OBJECT is received. This will cause havok when resubscriptions occur, for example with ABR, as switching away from and back to a track MAY result in different content. It's not viable. The subscription would intermingle objects from separate publishers that happen share a prefix, all while using the same . I really don't want to support subscribing based on wildcards or prefixes anyway. This is also the slowest option, as there needs to be a global RadixTree that maps tracks to subscriptions on receipt of each object. All other options listed above would keep an array of subscribers per track, resolved using a (shardable) HashMap.
I think this seems like the right approach. Having 2 producers with conflicting namespaces is a bad idea, unless the authz policy and application is somehow OK with the consequences. I have added to clarify the thinking further
I'm of the view of two things 1) apps should not do this if it is a problem for that app usage of relay 2) relay should use the latest "announce" to override any earlier announces that are more specific ( or the same )
Discussed at IETF 117: Support in the room for changing "Full Track Name" from a single string to a tuple of Namespace and Track Name, and matching on Namespace exactly.
IIRC, my recollection was not the same, also I don't think we concluded that the namespace match exactly. The discussion went over what the authz model defines and how that impacts the flow.
Code change:
A publisher sends a SUBSCRIBE ERROR control message in response to a failed SUBSCRIBE REQUEST. <del> Full Track Name: Identifies the track in the request message for which this response is provided. </del> <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> Error Code: Identifies an integer error code for subscription failure.

Related discussion:
text: I wonder how much the transport draft can mandate how a given relay application should implement the business rules. The transport draft must just indicate relay behavior and the course of actions to take for what happens when " if match succeeds vs match fails ", which is what is in the draft today already
Uh, my understanding of what we talking about what not at all removing Full Track Name - it was about we did not need to define a separator for concatenating things in a tuple. I don't agree there was support for chaning Full Track Name to Namesapce and Track Name tuple and only doing full matches. That is not going to work for many of the use cases and not what we are discussing.
I thought what came out of this discussion is 1) we do not know how duplicate ANNOUNCE work even when the names are identical ( do we keep first, last , error etc ) 2) once we figure that out, we can start to deal with the more complicated issue of partial match or overlapping Perhaps I have this recollection wrong but if so point me at right place in recording for that.
My motivation for ANNOUNCE was for the contribution case. A client like OBS will connect to the server, ANNOUNCE a new catalog track, and then the server will issue a corresponding SUBSCRIBE to get the data flowing. This is modeled after the QUICR PUBLISHINTENT message, except that data doesn't flow until the other side issues a SUBSCRIBE. However, announcing a namespace prefix subverts this behavior: The relay doesn't know if an ANNOUNCE is a prefix for routing, or a single broadcast being published. The relay effectively needs a business agreement with each client to determine. I think we should split this ANNOUNCE functionality into separate messages if just for the sake of discussion:
In the case of , a tuple makes perfect sense as it mirrors the arguments to SUBSCRIBE. This message would be primarily used for contribution to "push" a new broadcast. It also makes sense as a reconnect signal where the last message wins. In the case of , matching the longest prefix might make sense instead. I know very little about BGP but maybe there's some inspiration there. This message would primarily be used for inter-relay routing.
I assumed that full track name was a tuple already, and "full track name as a concatenation" was a notational convenience.
Code change:
A publisher sends a SUBSCRIBE ERROR control message in response to a failed SUBSCRIBE REQUEST. <del> Full Track Name: Identifies the track in the request message for which this response is provided. </del> <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> Error Code: Identifies an integer error code for subscription failure.

Related discussion:
text: Now that I read the draft more carefully, it does send full track name in messages, rather than a tuple of track name and track NS. As far as I'm concerned, this is a mistake -- I don't think this actually works, and I have no idea how one is supposed to implement that. I believe "error" is actually equivalent to "keep first" here. I think it's a safety vs practicality trade-off. On one hand, if two different programs announce the same track, it will not work, since they will publish conflicting objects under the same name; if we disallow re-announcing, we will prevent that. On the other hand, re-announcing makes reconnects more practical.
NAME Sorry if I misread the room and/or the author's meeting. Let's continue discussing. That is being discussed in / , let's keep this issue focused on the SUBSCRIBE REQUEST ambiguity?
Individual comment: Just to illustrate the problem further here, I wrote a short sketch of a generic relay (python syntax): So the concrete proposal I have is to change to have two fields, tracknamespace and trackname. Then the first bit would change to: This is not to say the every relay has to do matches in this way. By squishing the namespace and name together it's not possible to implement a relay that does exact matching. If we put the tuple in , a relay that wants non-exact matching rules based on full track name can always construct it by concatenating namespace and track_name together. NAME Can you say more about the use cases that would break with a change like this, or suggest an alternate way to implement an exact matching relay?
In a recent editor's call there was some discussion, which split into three separate issues - capturing it here: 1) SUBSCRIBE REQUEST should have a way to denote which part of the Full Track Name is the namespace. Either a Track Namespace Length field or just transmitting Track Namespace and Track Name in two fields. There was consensus to add this. 2) Does relay matching behavior (eg: exact match vs longest prefix vs ??) need to be negotiated in band? () 3) Is there a way to subscribe to more than one track at a time (eg: wildcard subscribe, ). I'd like to keep this issue focused on 1.
Code change:
1.4. This specification uses the terms "Holder", "Issuer", "Verifier", <del> defined by I-D.ietf-oauth-selective-disclosure-jwt. </del> <ins> "Key Binding JWT" defined by I-D.ietf-oauth-selective-disclosure-jwt. </ins> 2.

Related discussion:
text: I removed the subsection numbers where appropriate to be less dependent on changes in the SD-JWT spec. I also removed references to the issuance/presentation format, as this was unified in SD-JWT. This also meant that the section on the data formats for issuance and presentation in our spec can now be just one section, as there are no big differences any longer.
There are a number of references to specific section numbers in SD-JWT that are now out of sync and point to the wrong sections or non-existent sections. And some lingering use of terms like "Combined Format for XXXXX" that are no longer used in SD-JWT.
And there may well be other changes coming to the section layout URL so it might be prudent to avoid specific section number references (for the time being anyway).
lgtm
Code change:
and failed transactions.  It is therefore strongly RECOMMENDED to use an identifier, unique within the trust domain, for the "txn" value. <ins> 9.8. A workload may be configured to access more than one instance of a Transaction Token Service to ensure redundency or reduce latency for transaction token requests.  The workload configuration should be protected against unauthorized addition or removal of Transaction Token Service instances.  An attacker may perform a denial of service attack or degrade the performance of a system by removing an instance of a Transaction Token Service from the workload configuration. 9.9. A workload may accidently send a transaction token request to a service that is not a Transaction Token Service, or an attacker may attempt to impersonate a Transaction Token Service in order to gain access to transaction token requests which includes senstive information like access tokens.  To minimise the risk of leaking sensitive information like access tokens that are included in the transacation token request, the workload must ensure that it authenticates the Transaction Token Service and only contact instances of the Transaction Token Service that is authorized to issue transaction tokens. </ins> 10. 10.1.

Related discussion:
text: Agreed on the security considerations for ensuring that the access token is not sent to an incorrect endpoint (I can imagine an adversary getting into a build server, modifying the TTS location for a workload, and then have the TTS send tokens to it. I can also imagine this happening by accident, especially if there are multiple TTS's in a deployment.
Regarding the second point: Yes, should there be a way for the workload to determine it can trust the TTS before sending it an external token? This isn't something that is common in OAuth specs. It is assumed that the client knows whether to send the request or not.
Regarding 1: I think we wanted to talk about it at the last IETF and ran out of time. I seem to remember a few conversations around "discovery" but nothing concrete was decided.
I found the issue it's
Code change:
the developers of alternative algorithms and by the IETF in the context of each proposal. <del> The high-order criterion for advancing any proposal is a serious scientific study of the pros and cons that occur when the proposal is considered for publication by the IETF or before it is deployed at large scale. </del> <ins> The high-order criterion for advancing any proposal within the IETF is a serious scientific study of the pros and cons that occur when the proposal is considered for publication by the IETF or before it is deployed at large scale. </ins> <del> After initial studies, we encourage authors to write a specification of their proposal for publication in the RFC series.  This allows others to concretely understand and investigate the wealth of </del> <ins> After initial studies, authors are encouraged to write a specification of their proposal for publication in the RFC series. This allows others to understand and investigate the wealth of </ins> proposals in this space. This document is meant to reduce the barriers to entry for new

Related discussion:
text: Thanks for the edits. I am a big fan of losing fewer words, so I reverted changes that went in the wrong direction.
Code change:
such as audio, but other media types in this use case have much more stringent latency targets. <del> 4.2. </del> <ins> 3.2. </ins> For the video conferencing/telephony use case, there can be additional scenarios where the audience greatly outnumbers the concurrent active participants, but any member of the audience could participate.  As this has a much larger total number of participants - as many as Live Media Streaming lmstream, but with the bi- <del> directionality of confercing, this should be considered a "hybrid". </del> <ins> directionality of conferencing, this should be considered a "hybrid". </ins> <del> 4.3. </del> <ins> 3.3. </ins> The use cases in this section, unlike the use cases described in interact, still have "humans in the loop", but these humans expect

Related discussion:
text: NAME - I think this version is ready for submission as -03, when the submission window reopens during IETF 115. Please let me know what you think.
It would help people contribute to this document if there are blank sections in outline form, and we will be less likely to miss critical stuff.
The IETF 115 proposal to the working group is to use the approved charter as the high level outline for the Requirements section.
Code change:
as shown here. This specification uses the Augmented Backus-Naur Form (ABNF) <del> notation of RFC5234 with a list extension, defined in Section 7 of RFC7230, that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). </del> <ins> notation of RFC5234 but relies on Structured Headers from I-D.ietf- httpbis-header-structure for parsing. </ins> <del> Additionally, it uses the "field-name", "OWS" and "token" rules from RFC7230, and "type", "subtype", "content-coding" and "language-range" from RFC7231. </del> <ins> Additionally, it uses the "field-name" rule from RFC7230, and "type", "subtype", "content-coding" and "language-range" from RFC7231. </ins> 2.

Related discussion:
text: I think this also but I might have missed something. Misc changes that aren't actually necessary to use Structured Headers: "variant-item" became "variant-axis". I defined what clients ("caches"?) MUST do when a server violates one of its MUSTs. I removed the (incorrect) definition of available-value in favor of allowing arbitrary . It wasn't clear what excluding characters like was gaining us, and the restriction would have required extra words when parsing the headers. I removed {{gen-variant-key}} entirely and had Compute Possible Keys return a list of lists that could be directly compared against the Structured Header parse of . It would be difficult to keep the old behavior of returning a list of strings without re-adding some restriction on an available-value, for example by requiring that they don't contain spaces. I simplified Compute Possible Keys a bit.
URL shows a Variant-Key of But that's now This also has implications for the URL algorithm, which currently ignores semicolons.
looks like a parameterised list is currently a list of strings, but if is adopted, its syntax will need to be changed, as it doesn't fit into parameterised list particularly well (although I guess it could).
Currently waiting on resolution of .
NAME is closed now. Any hints?
Hi NAME - getting to it. Are you planning on implementing or using?