jiebi/CodeConvo huggingface dataset:
If we renamed the document as "Live Media Over QUIC", it would be more accurate, and the BOF proponents could point to this draft and ask people with other use cases if their use cases overlap with the live media use cases, perhaps allowing the BOF to recommend doing the live media use cases in this draft, and inviting people to provide comments on this draft explaining their use cases, so the IESG would know what to do with them. Your thoughts?
I don't object to the name change but I don't feel strongly.
That name works for me too.
We should revisit after the BOF, when we know what the scope of the document will be. :sunglasses:
So, this is slightly more complicated than I had hoped. The use cases in the draft span "Media Over QUIC". The considerations (and, if we get that far, requirements) in the draft only cover "LIVE Media Over QUIC". So, let's leave this one open, until we find out the right thing to do, and then we can Do The Right Thing. :innocent:
I would propose we rename (again) to "Media over QUIC Use Cases and Requirements", for a few reasons: Scope of use cases that the WG will work on isn't yet settled, and it's likely that we may need to cover some (but not all) interactive use cases as well as hybrid interactive/live. I still think we should set the protocol requirements in the document - this frees up the charter to describe scope and milestone, and our draft (if WG adopted) to set the use cases and what we will require of the deliverables. If WG adopted, the details of what is in and out can be made via WG consensus. This follows a similar title format to and other documents like it. NAME thoughts?
~~
Thanks! This Lgtm but I'll let Steven take a look too
This looks to me as well, thanks!
UAs should not decode any URL-encoded (or otherwise encoded) characters while storing a cookie, e.g. a cookie such as should not be interpreted as a cookie. I landed some WPTs for this in URL Chrome, Edge, Firefox, and Safari do the right thing. I think this could just be a clarifying note in the parsing algorithm section.
I'll take this one
Let's make sure we are consistent for names and attributes.
URL As promised at the meeting last week I have reviewed both: URL URL This is my review of the Birkholtz draft profile. REVIEW NOTES Overall very good, just a few comments: BIRKHOLTZ [Section 2]: “This document defines inclusion proofs for CCF ledgers. Verifiers MUST reject all other proof types” It’s unclear to me how useful this normative language is. Does it pollute the implementer’s wider implementation of cose-merkle-tree-proofs? In which case I think it’s wrong: verifiers might well verify many different transparent statements from a plurality of logs with a plurality of proof types. Of course for any given transparent statement they need to implement the proof verification correctly but I don’t see the value of this rejection statement. Privacy Considerations could do with some content (or removal if we consider that leaves and log activity are not relevant leakage of privacy info) Security Considerations could do with some content: CCF ledgers have certain trade-offs and assumptions about the environment they run in: should these be noted? Possibly a small nit, but “Historical transaction ledgers produced by Trusted Execution Environments” feels wrong to me. The ledger isn’t produced ‘by’ the TEE. It’s produced by a lump of code running in a TEE protected environment of some flavour. Or at least you have to hope it is. See comment on security considerations. [Section 7] reference to cose-merkle-tree-proofs is broken. Please fix. [Appendix A. Attic]: Casual language “Not ready to throw these texts into the trash bin yet.” … but there’s nothing else in there! Please remove. Jon
This is related to issue On the flight back from Switzerland, I spent time looking at the cache directives and how they differ from the descriptions in RFC2616. I worked out these problems and drafted a pull request, but I haven't checked whether we changed these deliberately for RFC7234, or if the distinctions just got lost in the rewrite. In any case, I think this is an improvement, but definitely needs reviews.
This ended up being an editorial change between drafts because the only normative changes were already noted for and , and this is just rewording what we had for .
From : Both state that a (depending on context private, shared or both types of) "cache MAY store the response and reuse it for later requests, even if the response would normally be non-cacheable". To my understanding, this does not intend to override the requirements from the "Storing Responses in Caches" section (URL) altogether. Instead, I would assume that it only refers to the condition "has a status code that is defined as heuristically cacheable" in that section (or, as it was stated in RFC7234, "has a status code that is defined as cacheable by default")? Would it make sense to amend the list of conditions in that section, appending to the "the response either..." second-level list: "contains a private response directive if the cache is not shared"?
OP here
lists some directives that allow responses with Authentication to be stored, but some of those directives' definitions do not mention this.
I think this should also be added for ; see .
I think this issue needs to be reopened and the specification text reverted to something more like what was in RFC2616. That spec specifically requires public be present to allow responses to a request with Authorization to be stored by a shared cache, regardless of must-revalidate or proxy-revalidate. This is not implied by those other directives.
How big can a group be? I know we (probably) won't be able to set a fixed limit, but I feel like we need to answer this in order to know what kind of design assumptions to make. Is a single group expected to be small enough to fit in the cache? Will the protocol work if a media track is just a single group that is being appended to for hours if not days? I was thinking about stream mapping and the resource-use-at-relays problem earlier today, and realized we might not currently have a conclusive answer for those.
As it stands today, the group ID is merely an annotation used by SUBSCRIBE hints. It's a sync point only by convention; in actuality the relay has no idea if objects within a group depend on each other. The relay is expected to cache/serve/evict objects independently so the group size is irrelevant. For example, a valid use-case is a single audio group with an object per frame. Each OBJECT would have an expires field of 30s, effectively dropping the head of the group as time progresses. The total number of objects per group is unbounded but the cache size is bounded. I strongly disagree with this. I want groups to actually be sync points, in which a relay knows that it should not evict OBJECT N without also evicting OBJECT N+1. Then the maximum size of the group actually matters.
IMO the size of a group (in bytes, or object count, or wallclock duration) should not be defined by the moq-transport spec. Limits such as these are driven by the physical characteristics of the caches and therefore should be provided by the relay (cache) provider. A streaming format (such as WARP) may choose to define a minimum object size to be supported for interop reasons between relays, but this should probably stay outside of moq-transport.
+1 to will's point. Group Size vary depending on the application - video, audio, chat, something new If any application needs to be aware of this, we can do the following Have catalog specify the group size per track Have a MOQT message updated where the Publisher can specify it per track in Subscribe OK. This might help as hint to caches if need be.
Individual Comment: There may be something interesting for moqt here in expressing more information that's useful to a cache.
Maybe an explicit expiry time would be more useful than a TTL, or a TTL at the group rather than the object level? Caches will evict stuff and can go fetch it if someone asks for it later. Maybe what needs to be specified is what happens when a cache receives Objects 0-10, evicts 0-3, then gets a SUBSCRIBE for Absolute/0-10?
Yeah, the cache needs some dependency information if it has any hope of evicting objects before the maximum TTL. That should be the purpose of group in my opinion.
I think we should allow it to be pretty much any size and as we use a VarInt for the object id so it does not matter. I guese I am not seeing a problem here from what we have today with pretty much no limit on number of of objects or number of groups. So I guess I am saying whatever max of VarInt is which I assume will be at least 2^60.
NAME are you fine with NAME point? If so, please close the issue.
I think we should add a note that groups can be in practice arbitrarily big.
From NAME
NAME and NAME - I agree with Magnus in his email (cut and pasted in the description), where he said "what about RMTP and SRT?", but I'm thinking that since we already have a "Why QUIC?" section, we should probably have a "Why NOT other protocols" section, rather than trying to talk about that in (what was) Section 6.1. That could also conveniently map into saying why we're not looking at "Interactive Media" in this document (and, transitively, in the BOF), and why we're not looking at "On Demand" (Media) in this document (and in the BOF). Please let me know if this is a BAD idea soon (I'm typing PRs).
NAME for media ingest, Magnus has a good point about covering not just HLS and DASH, but also making (even brief) reference to non-segmented protocols like RTMP and SRT (but really, this can be expanded to RIST, ZiXi, etc etc etc). This can just be a sentence or two; I'm happy to write it.
NAME - I had a complicated day yesterday, which became less complicated last night, so I'm not coherent enough to type text. I'll see what I can do in the next couple of hours, and if I can include these NAME suggestions.
The current definition of latency targets in the draft is based on specific numeric ranges. Those do make sense (since they ultimately come from use case requirements), but I believe we should focus more on what consequences those have for the protocol design. Reflecting on our experience with QUIC used for live video vs QUIC used for video conferencing, my proposed definition of the latency target for live video would be "latency an order of magnitude higher than one RTT". Two major examples of why this is important: When the target latency is on the order of one RTT, it makes sense to use FEC and codec-level packet loss concealment. When the target latency is in the range of many, many RTTs, selectively retransmitting only lost packets is almost always better than FEC. When the target latency is on the order of one RTT, it is impossible to use congestion control schemes like BBR, since BBR has probing mechanisms that rely on temporarily inducing delay and amortizing the consequences of that over multiple RTTs.
I think the first point illustrates nicely why protocols like RTP have low-level control over packetization, while the existing MoQ proposals defer it entirely to the QUIC stack.
NAME - that's super helpful. It helps us explain a few things - why we need to know this, in order to explain why we're shooting for One Protocol, and why we think the first three use cases in the draft are different (they're all RTPish), and why we're not looking at RTP in the BOF - right now, the draft just says AVTCORE is looking at RTP over QUIC, which really isn't much of a justification, engineering-wise.
Victor's points are well made, though I think picking the boundary of the number of round trips necessary to rely on standard QUIC loss detection is a challenge. 5 RTTs provides almost 5 opportunities to repair a loss, which in my experience is almost always enough. Similarly, I'd expect it's enough for BBR to complete various probing cycles. It's also important to understand what RTT we have in mind here. I think the RTT used to understand what domain you're in is approximately smoothed RTT (not min RTT), because the number of rounds for loss recovery or BBR gain cycling or Cubic packet conservation matter the most.
I agree that the numeric ranges are not useful when designing a protocol but they're useful enough as product requirements. However focusing on the RTT completely misses the point. Network latency involves fixed delays (min RTT) but most of it is caused by queuing (primarily congestion control). This includes any queues within the application, the network layer, intermediate routers, and even the receiver. You can think of latency as the "frame RTT" which is decoupled from the packet RTT. Of course the packet RTT is important, but it just doesn't factor in how much data has been queued. For example, it's just useless to talk about RTMP and HLS/DASH latency in terms of network RTTs. In my opinion, the problem with those protocols is that they impose unnecessary dependencies, making it slow to drop the bitrate to reduce queue sizes. Sending media over a single stream means that every frame depends on every previous frame regardless of the GoP structure (no frame dropping), and it also means that new GoPs are dependent on the previous GoPs (no skipping ahead).
WebRTC avoids these unnecessary dependencies which is how it's able to rapidly respond to congestion to keep latency low. I've been working on a "latency theory" document if any of these ideas are resonating with people. I feel like it's too early though, and we should be focusing on the use-cases and requirements instead.
NAME - please let me know when you think it's not too early to focus on "latency theory". I'd love to know more (in particular, I'd love to know if I'd be able to contribute effectively to that important topic). Just filing this away for now, as you suggest.
From Vittorio: The “insufficientscope” description here is problematic. The privileges the AT carries/points to are not necessarily (or exclusively) represented by the included scopes (eg the RO might have granted document:read to the client, but RO might have no privileges for the particular document being requested in this particular call). It might be useful to specify that “invalidscope” should be used for authorization errors that can be actually expressed in terms of delegated authorization, leaving to RS implementers the freedom to handle other authorization issues (eg user privileges, RBAC, etc) with a different error code. Or at least, we should be clear that authorization logic not expressed via scopes is out of scope (pun not intended) for this specification. Note, this isn’t an abstract problem: there are SDKs out there that use “invalid_scope” for every permission issues. Very confusing.
to me, insufficientscope => the client does not have scope required for the request invalidscope => when I see invalid_scope, I think that the RS does not understand what scope the client has
I'll get clarity for what Vittorio is asking for.
Here is my restatement from thread with Vittorio: "insufficientscopes" - is the correct error to return if the application has not been granted the scopes required for the request Vittorio: "to me the highest order but is ensuring that the reader doesn’t abuse insufficientscopes and realizes other error codes are possible." I've submitted a pull request with suggested language changes
This addresses the reference issues, comments and nits from the AD review (see )
NAME would you mind taking a quick look before I publish a new draft?
(tried using ietf-comments but ran into issues so just tracking manually in one combined issue)... cc NAME Thank you for the work on this document. Almost all my comments are about references. I think a new version is necessary before starting IETF Last Call, to avoid process issues along the way. Francesca The boilerplate is duplicate, please remove the second occurrence. Can you please update the reference to 8941 to draft-ietf-httpbis-sfbis ? That doc is with the RFC Editor so should not be holding this document up. Also, I believe the reference to draft-ietf-httpbis-sfbis should be normative, not informative, since terminology from that doc is used. Alternatively, if you want to keep the ref informative, you can import the part of the terminology that is necessary for this doc. I think that's a uglier solution, so I highly prefer sfbis to be made normative, but won't block on it. [URLPattern] "URL Pattern Standard", March 2024, URL needs to be indicated as Living standard (see RFC 9110 or 9421 for eample of whatwg specs references). Please fix this so that the Fetch spec is properly referenced (normatively is needed, I believe). RFC 8792 should be (informatively) referenced. I agree with Mark's write up, 5861 should really be informative. There is several occurrences of {Origin}, please fix. Please add a reference. It would be good to have an informative reference to 6265 (or even 6265bis). This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [ tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: URL [ICT]: URL
We would register: CWT Status Mechanisms registry in CWT JWT Status Mechanisms registry in JWT Status Types registry in OAuth parameters Any ideas how we could simplify this?
looks good to me in general. I would extend this to more than two weeks, if I look back how the current year went by. I think this is a good start for now, so we should merge this first and then evaluate afterwards if we can merge both status registries.
JWT/CWT registries use three week periods, the OAuth Parameter one uses two weeks. Should we just align with these registries for each one?
Section 4 of RFC 8126 -> supply registration procedures for the registries Define where these registries should be placed
Editors Call: we propose to put into OAuth Parameters: URL
Attempt to cover client-cert and caching interactions per mnot's guidance in issue
Thanks Mark, accepted all your suggested changes
Origin servers might select a response based upon the value of the request header. This might impact caches in these situations: When an intermediary that's generating also has a cache When an intermediary between the generator of and the origin has a cache (e.g., as part of a CDN hierarchy or a server-side reverse proxy) When the client on the other side of the TLS connection has a cache (e.g., the browser or other user agent) and the UA's use of client certs varies (e.g., different certs are used, or no cert is used) Some guidance about this is probably necessary. In cases (1) and (2), it's just a matter of adding to all responses for an access-controlled resource. (3) is more subtle, because the browser/UA doesn't see the client cert in the request, since it's generated downstream. From its perspective, will always select a non-existent header field, and so it'll match whatever the certificate used actually is. The most straightforward thing to do for (3) is to advise that an intermediary generating MUST/SHOULD transform on responses (when it occurs) to . There need to be some detail work around how this should happen, to make sure that parsing corner cases are caught.
Thanks NAME and apologies that I somehow missed seeing this issue when you initially submitted it. I think I can put together a bit of text with guidance along the lines of your suggestions. Is it okay or preferred to use vs. ? , which isn't a standard I know but it does show up near the top of search results. And on trying to educate myself more I found that says 'A proxy MUST NOT generate a Vary field with a "" value.' I think RFC 7231 means proxy only in the forward proxy notion of proxy so it's okay for a reverse proxy / gateway. And draft-ietf-httpbis-semantics-19 has a more explicit definition of proxy as such. But it did give me pause.
Ignore MDN, it's often wrong (will file a PR there when I get a chance). is the most semantically correct, but making it uncacheable works too.
Thanks Mark. I took a pass at this with PR
Looks pretty good, a couple of nits
NAME - is Oct 1999 correct? (taken from Last-Modified)
Last edit is 1999 but was just a markup fix, original document is dated 1996-10-03. HTH,
This seems out of place, although I understand that versioning is very message-based. I'd suggest putting it in 15. Extending HTTP?
It's not about extending HTTP. The version number literally exists as a field of the message, or at least inherited by the context of the connection, and must be retained by recipients because of version-specific requirements. That's why we need to define both cases as part of the message abstraction.
Fair enough. Can we open the section with a sentence or two that says that it's a field of the message, to give that context? The current text is pretty abstract.
Takes a dependency on URL
I think that it would be better to explicitly reference CERTIFICATE_REQUEST in the cases where a CERTIFICATE is generated directly in response to one. Using the "get context" API from exported authenticators is ugly. This is more important now that exported authenticators folds the request into the response. We probably want to use a flag for whether this is spontaneous so that we can avoid reserving a Request-ID for spontaneous CERTIFICATE messages.
I'm a little dubious about this. Having the same value transported in two different fields and then checking that they're equal seems potentially more error-prone than just transporting it in one place, even if that one place is by calling into a library to interpret for you.
For posterity, discussion in Montreal: Nice not to have to dig out the Request-ID. However, if you duplicate it, then you have to compare and check that they're equal, so you're still calling into TLS. There is an existing duplication in the CERTIFICATE_REQUEST, where the Request-ID is carried outside the EA.
Here is the status: I do not believe there is a security problem. Roy says that Antoine thinks there is a problem. Antoine is, however, not at the meeting.
Antoine can object in the next iteration or during WGLC
The replacement loses the security issue and adds a new one. The modification of removing the certificate chain, which will save space in the ledger, opens up a problem of building the chain dynamically may result in the wrong trust anchor.LGTM
A bit more in security considerations for Choice of a Hash Algorithm (1st & 2nd preimage resistant and not majorly truncated) for issue
While looking at this I noticed URL only allows hash algs from the registry. URL removed the JOSE HMAC stuff but also removed allowing the hash alg to be "a value defined in another specification and/or profile of this specification" which I thought we wanted to have - for Christian's type use cases and extensibility in general. This isn't the right place for a discussion but wanted to note it somewhere before our call.
I think we intentionally removed “a value defined in another specification and/or profile of this specification” Because using that would require a separate profile and not just defining an identifier.
from this PR URL
Proposed text to add MP-TCP RFCs.
From NAME review: Section 5.8: What is the verdict on RFC 6356? Is it not worth bringing this up in relation to concurrent usage? RFC 8041 do bring up additional experience with also other algorithms for MP-TCP that have been tried. I would at least claim “At the time of writing, there are no IETF standards for concurrent multipath congestion control in the general Internet.” that this sentence is factual wrong as RFC 6356 is an IETF experimental specification. I do think this section brings up important aspects to consider. However, it also point to some interesting challenges in reasoning and responsibility between functionalities when managing different paths. Looking at the text I think we have scheduler application data, path availability checks as well as congestion control all impacting what is happening. What is truly congestion control here?