jiebi/CodeConvo huggingface dataset:
Code change:
The format of SUBSCRIBE REQUEST is as follows: <del> Full Track Name: Identifies the track as defined in (track-name). </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> Track Request Parameters: As defined in track-req-params.

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:
The format of SUBSCRIBE REQUEST is as follows: <del> Full Track Name: Identifies the track as defined in (track-name). </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> Track Request Parameters: As defined in track-req-params.

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:
The format of SUBSCRIBE REQUEST is as follows: <del> Full Track Name: Identifies the track as defined in (track-name). </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> Track Request Parameters: As defined in track-req-params.

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:
This specification defines the following term: <del> A URL that uses the "https" scheme and has no fragment components where ".well-known" RFC5785 resources containing information about the protected resource are published. </del> <ins> The Protected resource's resource identifier, which is a URL that uses the "https" scheme and has no query or fragment components. Protected resource metadata is published at a ".well-known" location RFC5785 derived from this resource identifier, as described in PRConfig. </ins> 2.

Related discussion:
text: As discussed during IETF 118.
The draft (and the examples in it) follow this language This means (taken from an example in the draft): This is inconsistent with RFC8414 (and its normative dependencies) which says This means (taken from an example in RFC8414): The RFC8414 way kind of hampers the ability to host these documents in multi-tenant system on certain deployments but i'm unsure if we can justify not doing it this way.
Thanks NAME this was the subject of my comments in . I do think that the way it's done in the draft currently makes sense for the context and is preferable. But it might raise some objections in IESG etc. review. I don't honestly know what the best course of action is. But wanted to bring it up earlier rather than later. Perhaps Roman's suggestion of asking the HTTP directorate for an early review in hope of avoiding surprise down the line?
The draft does say the following , which maybe provides sufficient justification. Maybe.
Code change:
charset ISO-8859-1, supporting other charsets only through use of RFC2047 encoding.  In practice, most HTTP field values use only a subset of the US-ASCII charset USASCII.  Newly defined fields SHOULD <del> limit their values to US-ASCII octets.  A recipient SHOULD treat other octets in field content (obs-text) as opaque data. </del> <ins> limit their values to visible US-ASCII octets (VCHAR), SP, and HTAB. A recipient SHOULD treat other octets in field content (obs-text) as opaque data. </ins> Field values containing control (

Related discussion:
text: In : This is probably overly broad considering that the ABNF says (I question the wisdom of including HTAB, but now is not the time to worry about that). Could this be changed to "printable or visible US-ASCII octets, plus SP and HTAB"? (Incidentally, why doesn't the rule use the ABNF rule?)
Code change:
Instead, applications are encouraged to ensure that URLs are discovered at runtime, allowing HTTP-based services to describe their own capabilities.  One way to do this is to use typed links RFC8288 <del> to convey the URIs that are in use, as well as the semantics of the </del> <ins> to convey the URLs that are in use, as well as the semantics of the </ins> resources that they identify.  See resource for details. 4.4.1.

Related discussion:
text: This change switches from "URL" to "URI" specifically for two contexts: URI schemes URI syntax (It might be good to also add an explanation somewhere in the Introduction; I can make a proposal if needed)
It is a PR, no?
Weird, it didn't show the UX for PRs before, but does now. shrug
See URL
Code change:
2.2. When presented with a request that contains one or more client hint <del> headers, servers can optimise the response based upon the information </del> <ins> headers, servers can optimize the response based upon the information </ins> in them.  When doing so, and if the resource is cacheable, the server MUST also generate a Vary response header field (Section 7.1.4 of RFC7231), and optionally Key (I-D.ietf-httpbis-key), to indicate

Related discussion:
text: and .
Looks good overall. changes the semantics of . Not only does it effectively put on subsequent responses from the same origin for the given lifetime, it also suggests that Client Hints should be added to requests to that origin, no matter where the requesting page has come from. Not a problem, but right now it's conveyed almost as an aside. This needs to be clearly specified so it isn't missed / misunderstood.
NAME updated, PTAL.
Thanks Mark!
This is better.
Code change:
displays a message to the attacker with instructions on how to access their account. <ins> 3.7. In all of the attack scenarios listed above, a user is tricked or exploited.  For other attacks, where the user is willingly colluding with the attacker, the security implications and potential mitigations are very different.  For example, a cooperating user can bypass software mitigations on his device, share access to hardware tokens with the attacker, and install additional devices to forward radio signals to trick proximity checks. This document therefore only considers scenarios where a user does not collude with an attacker. </ins> 4. Cross-device flows that are subject to the attacks described earlier,

Related discussion:
text: Accepted proposed text to clarify that this document does not cover cases where the user is colluding with an attacker.
Code change:
5.2. <ins> The REQUIRED "a" (public key) parameter is a byte sequence that contains the public key used by the server to validate the signature provided by the client.  This avoids key confusion issues (see SEEMS- LEGIT).  The encoding of the public key is described in context. 5.3. </ins> The REQUIRED "p" (proof) parameter is a byte sequence that specifies the proof that the user agent provides to attest to possessing the credential that matches its key ID. <del> 5.3. </del> <ins> 5.4. </ins> The REQUIRED "s" (signature) parameter is an integer that specifies the signature scheme used to compute the proof transmitted in the "p"

Related discussion:
text: Based on discussions with NAME NAME and others, there are potential key confusion attacks when the server is checking the signature using the wrong public key. I think the simplest solution is to add the public key to the TLS key exporter. That should solve the issue without increasing the amount of bytes sent on the wire
Including the public key in the exporter context makes it significantly harder to implement the server side of this. Including the hash of the public key in the signature appears to work also. I have a sketch model in Tamarin that doesn't find any attacks when the hash of the public key is in the signature, which gives me some confidence that it's doable, although NAME wasn't convinced. We should discuss this in the room at 117.
I agree with NAME The implementation complexity that comes from putting the public key in the exporter context is real, at least for some edge networks. I think we should pursue alternatives that don't weaken the security properties, even if they make the registration step a bit more explicit.
If this design makes implementation hard then we should totally change it. Can I ask you to elaborate on what causes this to be hard on the server side?
The basic problem in our particular case is that the component that terminates TLS and computes exported values is upstream of the component that has the public key. So when a request comes in with the header to the TLS terminator, the public key needs to get relayed back for computation. If, instead, the public key was signed, then the TLS terminator could simply forward the computed exporter without any sort of round trip. (I punched this in on my phone, but can draw pictures on a laptop if the above is not clear.) We don't necessarily need to cater to one implementation, but I would be surprised if this were not a common arrangement in practice.
Thanks, that makes sense. To explore the problem space: if we were to include the public key in both the context and a header parameter, would that work for your implementation? (That way the TLS terminator can call the exporter without a round trip.)
Yep, that would address the problem too.
SIGMA seems like it might be worth considering as an alternative. That is, sign the nonce, but then include a MAC that covers all of the relevant parameters.
Something like SIGMA should also work, but I'd like to minimize the number of primitives required to implement this.
Code change:
5.2. <ins> The REQUIRED "a" (public key) parameter is a byte sequence that contains the public key used by the server to validate the signature provided by the client.  This avoids key confusion issues (see SEEMS- LEGIT).  The encoding of the public key is described in context. 5.3. </ins> The REQUIRED "p" (proof) parameter is a byte sequence that specifies the proof that the user agent provides to attest to possessing the credential that matches its key ID. <del> 5.3. </del> <ins> 5.4. </ins> The REQUIRED "s" (signature) parameter is an integer that specifies the signature scheme used to compute the proof transmitted in the "p"

Related discussion:
text: Currently, modifying an HTTPS stack to support this draft only requires a signature implementation and a TLS key exporter API. Using a MAC would require a MAC primitive and opens the question "which MAC should we use?"
That's an easy question: you are using HKDF to get the values, so HMAC is a logical choice. The only reason I suggested that is that I'm increasingly nervous about these bespoke constructions. We understand what sign and mac provides.
I think we need to first identify what property it is we actually want, and then see what is the simplest way to get there. NAME what is the property we want?
NAME had a long chat about this today. We didn't come to any solid conclusions - the authentication property here is really subtle and the attacker model not yet clear. This is going to need some really careful work and detailed formal analysis to get right. In terms of this discussion, my personal take would be: I don't think a mac & sign approach is going to give you anything strictly better or different than an exporter + signature approach. In both cases its just a question of what you put in the exporter / mac. Having the public key conveyed in the header and bound explicitly in the exporter (rather than via the keyid) seems like a conservative and reasonable approach.
Thanks for thinking through this! I've written up to add the public key to both the context and the header
Code change:
For example, the base64url-encoded SHA-256 digest of the Disclosure <del> would be </del> <ins> for the </ins> <del> . The base64url-encoded SHA-256 digest of the Disclosure would be </del> <ins> claim from disclosures_for_object_properties above is </ins> .

Related discussion:
text: URL
Danke! Thanks Neil, That is indeed an error. Thanks for catching that. We'll get it fixed. I see how that other part is a bit confusing too and will look at improving how those pieces flow together. And also maybe fix some other stuff in that area while we're at it, like inadequate salt length in at least one of the disclosures in 5.2.3. On Wed, Sep 4, 2024 at 9:17 AM Neil Madden wrote: CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
Code change:
user authorization, including a push notification to a dedicated app on a mobile phone, or sending a text message with a link to an endpoint where the user can authenticate and authorize an action. <del> The Client Initiated Backchannel Authentication CIBA follows this pattern. </del> 2.3.

Related discussion:
text: Editorial clarifications based on feedback from Aaron Parecki (see )
A couple of editorial suggestions, but otherwise this looks fine to me!
Code change:
"order".  An integer indicating the delivery order (delivery- order).  This field is optional and the default value is 0. <del> "depends".  An list of dependencies by stream identifier (dependencies).  This field is optional and the default value is an empty array. </del> The payload of the OBJECT message consists of a fragmented MP4 container (fmp4).

Related discussion:
text: It's difficult to populate and has fringe benefit at best. Let's revisit this in the future if it's actually useful. removed after discussion in
To explain a bit more in-depth: The goal of the dependency list was to give relays the information required to know which frames are droppable. This doesn't actually accomplish that goal since a frame could be a reference for a future frame. It's a lot of state to keep track of and it's unlikely to be used by even the smartest relay. It's much simpler and probably a better user experience for a relay to obey the delivery order. The decoder doesn't actually need this list since the references are stored in the codec itself. A mismatch between the Warp dependency list and the codec reference list sounds pretty awful. Accurately populating the Warp dependency list requires parsing the codec bitstream, which is more difficult and expensive than it needs to be. The only immediate use-case for the dependency list is to mark init segments. We could have a separate field for that, or put the init segment in the CATALOG itself. There's a possible use-case for SVC but again, a relay can just follow delivery order and the decoder should be able to piece together dependencies from the underlying codec.
I went ahead and merged because I haven't heard a positive reaction to the dependency list. We can always make a PR to add it back and actually discuss the merits.
Code change:
endpoint will send for the identified stream.  Setting this flag causes the stream to enter one of StreamStates. <del> Bit 2 is reserved for future use. </del> <ins> Bit 2 being set indicates that this frame is the last for the current segment.  Intermediaries MUST NOT coalesce frames across a segment boundary and MUST preserve segment boundaries when forwarding frames. </ins> Bit 3 being set indicates that the Pad Low field is present.

Related discussion:
text: NAME did you just forget to create the pull request?
Didn't realize you couldn't merge from the referenced issue. What do you need from me to merge the commit?
Just some indication that you think that this is ready, that's all.
Do you think we need to add a requirement for must emit? or is the not coalesce sufficient?
Now that you mention it, MUST preserve is really what we are going for.
added "MUST preserve"
There is some usefulness from both an extensibility perspective and a load balancing perspective to indicate multiple messages over an individual stream. This issue is to un-reserve the 0x02 END_MESSAGE flag to ensure that intermediaries that are deployed proxy the flag so that they are agnostic to the layered protocol and can still successfully load balance messages appropriately.
Note that this places a requirement on proxies that they cannot coalesce data frames across "END_MESSAGE" boundaries.
Discussed in Zurich with no real conclusion. Support and opposition were weak.
Discussed in Zurich; accepted in principle. Jeff to do a pull request.
Renamed ENDMESSAGE to ENDSEGMENT to avoid any confusion with HTTP messages. Feel free to re-name. Couldn't find any text that stated intermediaries could combine frames but may want to add a requirement that intermediaries must re-emit the flag at the same byte position.
Code change:
several different representations. Some differences in representations are necessary to support <del> efficient verification of proofs and compatibility with deployed tree algorithms used in specific implementations. </del> <ins> efficient verification of different kinds of inclusion proofs and for compatibility with deployed tree algorithms used in specific implementations. </ins> 3.1. <del> A Merkle tree root is signed with COSE_Sign1, creating a Signed Merkle Tree Root: </del> <ins> A Merkle root is signed with COSE_Sign1: </ins> Protected header parameters:

Related discussion:
text: Changes from IETF 116 hackathon
I'm stopping on this PR, before it gets even larger.
NAME I have made several more changes, please review when you have a chance.
I am merging, we reviewed this content together at IETF.