This just moves the reference to the canonical definition of what is valid up to the top of the section. That's the canonical text. This emphasizes the point that HTTP/2 is placing additional requirements on endpoints with respect to validation. This does not really in the sense that it leaves validation of DQUOTE and friends to the core semantics implementations. Note that any "MAY" requirement for rejecting a messaging can have the desired effect on those generating those messages: if an endpoint puts DQUOTE in a field name, that message will have little hope of being successfully handled.
My 2 cents: it seems that there's disagreement about whether the validity requirements from the core specs need to be repeated. Of course, DRY. Semantics currently says: The issue here is that H/2 actually extends that ABNF (without doing that as ABNF), which makes the link somewhat weak. Maybe formally (==ABNF) defining "h2-fieldname" as "lowercase-http-fieldname / h2-pseudofield" would be helpful.
So the proposal would be:
Julian, YES PLEASE for ABNF (yeah I know that is editorial, but it makes it so much more concise and exact). I think everybody agrees that a h2 impl MUST NOT generate invalid HTTP fields. The differences appear on the receiving side as the current document allows that h2 impls MAY accept some invalid HTTP fields. I've never understood the use-case for this? cheers
Well, AFAIU, we do not have a hard requirement on recipients in the base spec (and HTTP/1 either): So this seems consistent with what the base spec says.
I have no objection to adding ABNF to define H2’s fields. I would say that we should keep the prose, as the prose does a good job of expressing the why of our choices: for example, explaining the expectations around lowercase field names. However, I agree with NAME and my past self that we do not need add a “MUST validate” section.
Thanks Martin. I'm having a bit of difficulty parsing this sentence: "These checks are the minimum necessary to avoid accepting messages that might avoid security checks". Maybe "These checks are the minimum necessary to forward or process the message as an HTTP message" ? Also "A recipient can treat a message ..." why not "s/can/SHOULD" ? I think that should be enough to solve it.
My objection to ABNF is the same as before: we risk that being mistaken as defining what is valid. Something that meets that ABNF is not valid. The point of this section is to define what the absolute minimum is with respect to any form of message handling. Our attempt to require more complete validation roundly failed, so this is where we end up. Willy, I've tried again with the wording. But I want to avoid normative statements regarding the core semantics documents. Those already define what a receiver might do. Those requirements aren't strict enough, at least in the "acting as a tunnel" case, for HTTP/2. The point of this text is to point to HTTP and note that these checks won't guarantee you a valid message, but to allow those implementations that do apply those checks the option of using HTTP/2 signaling (reset streams) to indicate the error condition. I don't think that needs a SHOULD, but I'm OK with adding it.
NAME I think this is a flawed approach. By only defining a subset of invalid fields we create a set of fields that are not valid HTTP but may be valid H2 fields (by merit of being not defined as minimally invalid - just describing it is convoluted). I have yet to see any use-case for a field to be valid in H2 but invalid in HTTP? has identified that the example we have frequently used for such a field (double quote in name) will be a concern if passed onto CGI scripting language. So we have no known uses for such fields and security concerns about at least some of them. So why not just define valid H2 fields as a proper subset of valid HTTP fields plus pseudo fields? We can avoid defining what is valid by referencing other specifications (which do use ABNF). As suggests a field should be valid in H2 if and only if it is: I.e. the set of valid H2 fields is a proper subset of valid HTTP fields plus pseudo fields.
That is what RFC 7540 did. That failed. We can revert all of these changes (aside from editorial tweaks) and go back to what the previous version said, but would that be any more successful?
I take it that you consider RFC7540 failed because of URL which ultimately references URL These indicate that there are cases of CTL characters in field values observed in the wild. The response has been to relax the validation on fields so much that now security problems have been created. I think this is because the minimal validation approach is essentially trying to be secure with a black list (in this case a list of known bad characters). It is far more secure to use a white list approach (i.e what is the minimal character set required to carry the HTTP semantic ). I don't really understand why no attempt was made to enforce the previous specification - I really hope it was not because of who was violating. But if enforcing the spec is seen as impossible, then rather than just leave the validity of fields somewhat undefined, surely a better approach would have been to make some explicit exclusions to allow just the needed control characters in field values. Or perhaps field names must be valid HTTP field names (or psuedo and lowercase), but h2 is more relaxed on field values? Deserting the field and not actually precisely defining what is valid just seams like an inviation to create more special cases and more unforseen security problems.
The real reason for this situation is that we all know that what is extracted from H2 then HPACK will need further processing and that this processing may already be fooled by the contents extracted from there. In addition, H2 being a standard multiplexed protocol on top of TCP is abused by some not really interested in the HTTP aspect of it (e.g. URL) , putting intermediaries at risk of breakage and giving them even more motivation for dropping essential controls and becoming insecure. While I would prefer a wording directly referencing the HTTP spec, like Martin I'm convinced that some will simply not even read it. So I think the proposed addition here can be welcome provided that it does not use the terms "valid" or anything else that might make implementations think "OK that's sufficient", and that presenting the root cause and the risk remains useful to convince those who are hesitating (or at least give them good arguments for not disabling the tests). Let's try again: It's not far from what Martin wrote in the last update, it just tries to better present the context and mention that this has to be done before HTTP parsing. And I'd like to use for treat as malformed.
No attempt was made to enforce the previous specification because the IETF and httpwg have no enforcement mechanism. What could have been done to enforce it? W.r.t. this patch, I agree with NAME that it seems that the conversation has come full-circle to where we were with RFC 7540. In that circle I think the wording here is closest to what I’d want: a clear list of specific rules with a note that these rules are a lower bound on processing, not an upper bound.
I agree that misunderstanding the safety of the current spec is a real problem, but I don't think avoiding the word "valid" will help. Many developers will naturally think that a HTTP/2 specification would only support valid HTTP fields. You can't fix this in the text because that assumption has already been made in existing software and will be made again without reading the text. Even those that do read the text might get lost in the fine distinctions we are trying to make here between a field that is valid and one that may not be invalid. What is a safe field? If the safety checks are not sufficient for consuming HTTP semantics, what are H2 fields safe for? What layers can consume them without extra validation? Why are consumers protected against CR, LF and ':' attacks but they are not safe from DQUOTE ones? Fields passing these safety checks cannot not be passed to any existing layers that are written with the assumption that they will only receive valid HTTP fields and new user will wrongly assume that H2 safety checks are at least as good as those in HTTP/1. RFC7540 said that an imple MUST be invalid HTTP fields as malformed, but some impls ignored that. So how about we say that impls SHOULD treat invalid HTTP fields as malformed and then define the specific circumstances in which consenting peers can exchange invalid HTTP fields, perhaps indicating as much with a SETTING or new psuedo header that is needed to specifically allow h2 framing to be used for non-HTTP semantics? Yeah I know some will say "you can't force those users of invalid HTTP fields to do something special". So instead we make all users of valid HTTP fields need to do extra validation else risk being insecure? Anyway, sorry for re-re-re-re-litigating. My live-with criteria is that an implementation MAY treat invalid HTTP fields as malformed, so in that sense this PR is fine.... it just doesn't (and Martin says as much), so this is really just an editorial PR unrelated to .
Greg, I'm not suggesting that an H2 field is safe, but "safe to be parsed as HTTP". The main reason is that some basic HTTP components have been broken into pieces in H2 and need to be reassembled before being processed by HTTP. :scheme, :authority, :path are two such examples. In HTTP together they're called a URI. Cookie is another one. Some H2-specific issues may happen at the H2 layer that are impossible by definition in HTTP since HTTP/1. In my opinion this is the trouble that is being attempted to be addressed here. And yes it turns out that it diverges a bit from though it can address it if it mentions that consumed fields are subject to these checks. For sure, if we enforce strict validation of all H2 fields against HTTP ones it will address everything, except that we've already seen that implementors are not keen on switching between many specs at once and need some guidance. It's a delicate balance. Julian proposed to duplicate the ABNF there, I thought it was a good idea. And if we don't want to make it look normative we could write the minimum elements as a reminder.
But the spec currently as currently written and after this PR is not "safe to be parsed as HTTP". If that parsing is done by a scripting language then DQUOTE and other control characters that are current permitted by the spec may well not be safe. To take your example of a cookie header, how can you be sure that code which is currently safely the cookie header value (or set-cookie value) will be robust in the face of control characters within that value? Isn't the set of h2 fields that are "safe to be parsed as HTTP" a true subset of valid HTTP fields? What extra characters can we allow into fields that are not valid HTTP that we are sure will be parsed safely as valid HTTP by all existing layers currently running on top of H2 implementations? The intent of these changes have been to normalize the practise in the wild of h2 framing being used to carry control characters in fields for non-HTTP purposes. But if we nomarlize that, we are putting in jeopardy all existing code written to HTTP semantics that may not even be aware of the version of HTTP carrying the fields that they are interpretting. Surely there is some other way to allow h2 framing to be used to carry non-HTTP streams without putting all existing HTTP code at risk? If we don't want developers abusing the current protocol, then give them a proper solution for their use-case rather than corrupt the existing primary use-case.
They should represent the exact same level of risk as having the same code parse HTTP/1. But actually that might in fact be what we're all seeking without precisely realizing it, which is making sure an H2 message can be at least reconstructed as an H1 message that is safe to parse. The rules on CR/LF precisely have always been a concern to all of us for this. Same as above. This is always difficult to say if we'd try to extend what HTTP permits. However we're certain that some will almost always be dangerous along a chain or cause parsing issues even inside implementations. Not exactly. This is actually the current situation probably because some consider that the effort needed to comply with the rules in semantics is too high for little value the this level. This is something I can understand. For example in haproxy we have a semantics layer which performs a lot of controls, deduplicates content-length, checks Host against etc. But at the lowest level it is difficult to enforce such checks when you're just converting header lists to internal messages. However we already have the NUL/CR/LF checks that allows the upper layer parser to proceed (the initial implementation used to build an H1 message but that's no longer the case). Thus maybe we should replace all this with an approach centered around this tricky HTTP/1 translation, which also does not infer how implementations should work internally nor suggest to put anything non-HTTP inside HEADERS frames: Just to be clear, I really do not want to see HEADERS frame being abused to carry non-HTTP because I know pretty well what it's like to be an intermediary developer whose product is pointed the finger at for breaking stuff when inserted in a working but non-compliant chain. This is also why I would like to see the SHOULD reject as malformed.
I like this paragraph and I'm totally OK with a spec that has conditions like "implementations which reassemble elements as an HTTP/1-like message before ...." However, it is not just HTTP/1 as there are many HTTP semantic layers that are unaware of the protocol version, so it needs to be any impl that represents streams as HTTP messages must do specific validation whilst the h2 "abusers" are free use streams to the limites of HPACK capabilities, so long as they don't represent the results as HTTP messages - either on the wire or to layers above. Furthermore an impl that is representing HTTP messages cannot just do the minimal safety checks you listed. It MUST validate the fields against the general syntax of HTTP fields. For example, if I provide a h2 implementation of the Java class, then my impl MUST validate the fields against HTTP syntax. But if instead, I use my h2 impl to implement a gRPC API, then I'm under no such obligation as I'm not representing HTTP messages. More over, it is only the protocol impl that can do this validation. Another example is that my server is used on PAAS platforms where the application was deployed decades ago and the source code is probably lost and the dev team all retired. The app cannot be redeployed and it certainly cannot be reviewed for how it parses the Cookie header. It's not sufficient for me to switch them from HTTP/1 to H2 and in the process expose those applications to non-valid HTTP headers in HTTP messages I deliver to them. If the h2 impl is not going to validate the fields are valid HTTP then who is? So how about something like:
The thing is, stacks that support multiple versions will certainly not implement the full header syntax in each version because that is exactly what ought to be done at the semantics layer and why the HTTP spec was split like this as well. We really have messaging (H1,H2,H3) and semantics. The transport explains how to extract elements from a byte stream and how to encode them into a byte stream. The semantics details their syntax and consistency. NUL/CR/LF purely come from the H1 world but H1 was HTTP before H2 existed, so it could be argued that they are legacy limitations that probably affects most stacks. The cookie header splitting is purely H2, and once recombined it must parse correctly according to the semantics definition. But whether your cookie header field comes from H1/H2/H3, it will have to pass through the exact same validity checks. What is certain is that these HTTP syntax checks must be performed somewhere. But the messaging layer is not always exactly the best place for this. Typically an H1 implementation will not have code to check for embedded LF characters because it's a delimiter, while H2 needs to have explicit check against this. The rules on the resulting cookie header field format apply after Cookie header reassembly, not before. And this reassembly is specific to the messaging layer which defines how to serialize fields. Last, the generic rules are not sufficient to safely reassemble the pseudo-header fields. Maybe in the end we could combine our two parts, starting with yours to indicate what every HTTP implementation must do, and putting the focus on the extreme care that is required when translating to HTTP/1-like since we know that it's one of the most natural approaches (and even used in the examples in the spec). This could give roughly: With this I think it that the intent is clear, the guidance as well, it is exhaustive and doesn't leave any doubt on what needs to be done.
Oh, and of course: :-)
I think extreme care is need anytime a HTTP message is represented, not just when represented as a HTTP/1. If a H2 layer is delivering messages to a semantic layer that was developed against h1, then it will not be assuming HTTP valid charset in no matter if the message is passed as byte streams or lines or XML or JSON or Strings in classes. It seams wrong for one particular messaging layer (h2) to require changes in transport impartial HTTP semantic layers so the messaging layer can be "abused" for non HTTP purposes? As you say, the actual syntax validations needed to be done are dependent on the messaging layer. So they are best done in the messaging layer as it knows what it is and can sometimes do things efficiently like checking charsets during parsing. If the syntax is not validated by the messaging layer, then the semantic layer will have to do full validation, which will result in wasting CPU duplicating any checks that are done by the messaging layer (or are intrinsic to the transport).
I think I'm OK with this. There's just one minor thing: It's actually "LF and COLON", but to be exhaustive I'd write "CR, LF, and COLON" since we've always kept extreme care on CR due to older H1 implementations. I think we really want to say something about the pseudo headers. They do not exist in HTTP/1 and the recent portswigger report clearly shows that many of us were relying on the tests performed on the reassembled start line, but that was too late (in my case everything was already NUL/CR/LF clean but LWS were not imagined there). I think it would be appropriate to place the small enumeration I mentioned above somewhere (probably after the "minimal validation" part). But it's possible that it doesn't have its place in the headers section and that it would be better discussed in the security considerations. And maybe then the whole "minimal validation" part can be moved there with it, since after all, it's what all this is about, covering risks that are known for having already been abused. If you're interested I can propose a whole paragraph about all this, as being an implementer makes it easy enough for me to describe the traps. I'm just still having difficulties with all the toolchain and the XML docs which is why I don't send PRs.
(I'll add LF) As for pseudo-headers, welcome back scope creep. Would a simple prohibition on SP (and maybe HTAB) for pseudo-headers work? I'm fairly confident that the substitution is performed as needed, so there are no valid uses for the character. Given that that is the real problem, would that do? I don't feel like a full enumeration is going to be effective, but just one more simple bullet might not hurt.
I've initially thought about it when fixing my bugs ("if I had filtered LWS as well..."). But that's not enough for :scheme nor :path. If :path starts with any character that is valid in a domain name, or a colon, you can change the authority when concatenating values. E.g. or Would result in `URL" or "URL". Similarly if ":scheme" contains a colon, we're lost. In haproxy we've seriously hardened this part so that we don't have to deal with a variant of it any time soon. But I think that the absolute bare minimum is: no NUL/CR/LF/LWS in any of the currently known pseudo header fields no colon in :scheme nothing but "/" or "*" as the first char of :path I don't see how to fool a start line parser when reassembling something based on such minimum controls, but I do see how to fool them by relaxing any single one of the rules above.
Editors, it looks like this is ready to ship; anything stopping that?
Only that discussion was continuing. But it seems to have settled now.
Thanks Martin. What about adding the point I made above in URL for :scheme, :path and :method which need further protection (that's not addressed in core since purely H2) ? I could propose this text (yeah I know my formulations are not always great):
HTTP has always forbidden token delimiters in field names. It seems very odd that they are not forbidden in HTTP/2, aside from the specific restriction on colon. The token delimiters are DQUOTE and "(),/:;?NAME We really don't want those allowed in a field name because back-end gateways like CGI assume they have been blocked, and it would mean adding an impossible conversion step when forwarding h2 to h1. Also, it would be easier to read the Field Validity section if it first referenced what is valid for an HTTP field-name, then exclude uppercase because of lowercasing and permit the special-purpose colon for pseudo-fields, and finally list specific requirements on handling invalid characters because the length-delimited protocol elements might be used to carry invalid characters. Likewise, separating the error handling for field-name from that of field-value is useful because they are two different algorithms that are usually implemented separately.
This is really good other than a couple of niggles Expressing it this way makes it really clear the difference between recommended full HTTP validation and the minimal validation that must be imposed if full validation is not done.


This text wasn't actually changed in , but I noticed it while reviewing. This says that implementations which support TLS MUST use ALPN, but that's not really tied to what the implementation supports -- it's tied to what the current connection is doing. If you support TLS but are using cleartext TCP for the current connection (regardless of why), you're not required to use ALPN.


The original issue here was concerned with Transfer-Encoding, but this was not a normative statement, it was a note. With a forward reference, this is better. The section on connection-specific headers probably could have been more specific. Now that the -semantics draft has a specific list of things (plus whatever lists), we can lean on that more directly.
HTTP/2 prohibits Transfer-Encoding, but doesn't actually prohibit other values: HTTP/3 broadened this language to cover all transfer codings: Should H2bis follow suit?
Can you take this to the list Mike? It seems like the only sensible answer, but I'd like to double-check.
In my mind, I was relying on Section 8.2.2: However, that probably isn't linked well enough to the . Unfortunately, there isn't a term we can just lift out; perhaps something like this:
On review with full context, the text that Mike cites is fine. It's an informational note. Mark's note here about the linkage to -semantics is good though. I will float this on the list to see if I messed up (again).


I know that Cory beat me to it with , but I had written text. I only forgot to make the PR. Cory can decide which he likes better :)
In the aside about HTTP/2 deliberately not supporting Upgrade, it feels worth mentioning that we later partially reversed ourselves and brought back a moral equivalent of Upgrade with a less obvious name. Reference to RFC8441 appropriate here?
You put more things in your citation block, so it’s clearly better.


The code for the IANA policies in Section 11.1 looks like this: This document establishes a registry for HTTP/2 frame type codes. The "HTTP/2 Frame Type" registry manages an 8-bit space. The "HTTP/2 Frame Type" registry operates under either of the "IETF Review" or "IESG Approval" policies. That would be fine if that rendered as I would expect, as: Instead, it renders this way: That word ordering doesn't make sense. I'm not sure exactly what XML magic would be needed to produce the expected sentence order. Same thing occurs in Sections 11.2-4.
appears to fix only Section 11.1.


Followup for .
The code for the IANA policies in Section 11.1 looks like this: This document establishes a registry for HTTP/2 frame type codes. The "HTTP/2 Frame Type" registry manages an 8-bit space. The "HTTP/2 Frame Type" registry operates under either of the "IETF Review" or "IESG Approval" policies. That would be fine if that rendered as I would expect, as: Instead, it renders this way: That word ordering doesn't make sense. I'm not sure exactly what XML magic would be needed to produce the expected sentence order. Same thing occurs in Sections 11.2-4.
appears to fix only Section 11.1.


Fix some typos
"overridden" is the correct spelling; can you remove those changes? Thanks.
NAME it was "overriden", I changed it to "overridden". Am I missing something here?
No, I just need to slow down when I read diffs :) Thanks!
:smile:


Just state it. No need to justify it so (especially as this invites questions about the claimed benefits). This is less than Julian wanted from , but I think that it is important to include a requirement like this very clearly and it isn't really said anywhere else. At least not directly.
converted to lowercase when constructing an HTTP/2 message. I think this is somewhat misleading, it just provides the motivation why the lowercase format was introduced initially. I would just remove the sentence and potentially insert a note about lower-casing into the field name validity statements.
Agreed, I don't think the spec needs to defend itself on this choice.


The HTTP2-Settings header field and the h2c Upgrade token are both obsolete in the same way for the same reason, but it's rendered differently in their respective IANA sections. HTTP2-Settings is marked as Obsolete in the registry, with a reference back to the IANA Considerations of this document h2c gives no instructions to IANA, but includes explanatory text that the capability is removed and refers to Section 3.1. I would suggest that these should be aligned and combined, such that each one does two things: Instructs IANA to mark the entry as Obsolete Add a note that the element was used for Upgrade and reference Section 3.1 for more detail on Upgrade's removal


Only pseudo-header fields can be mandatory, so no point saying anything about fields more generally here.
sequence of HTTP/2 frames but is invalid due to the presence of extraneous frames, prohibited fields or pseudo-header fields, the absence of mandatory fields or pseudo-header fields, the inclusion of uppercase field names, or invalid field names and/or values (in certain circumstances; see Section 8.2). Are there any mandatory fields that are not pseudo-header fields?


As noted in , we don't need to redo these. A backward reference will do. This cuts quite a bit of XML out of the document, which I'm happy about.
NAME I disagree; IANA hold the registration data, not the document. My understanding is that templates need only appear in the originally registering documents; if there's doubt about that, we should check with the IESG and IANA.
That is true, but the registrations point to specs. The IANA Considerations need to take care of updating these references.
That's a good point; I will shelve that and change to adding a note that says "references to RFC 7540 for X, Y, and Z are updated to point to this document".
Absolutely. It just doesn't need to list them individually; a simple statements such as "update the references to RFCxxxx to this document in Registry Foo" will suffice.
If that's all which is necessary, yes. Hint: section numbers might change, and you don't want to handle that during AUTH48.
The current IANA Considerations for H2 bis has several requests to IANA that seem to be appropriate for the original document, but not a bis now that the registries are already filled out. Shouldn't these be reworded to say "this document updates..." or explain that the references for registries should point to this document, rather than the old RFC?
I don't think this is a good idea. At the end of the day, the IANA registry should point to the updated document.


Includes changes from , as that hits the same paragraph.
why is c4d3528 included?
Hmm, poor rebase on my part I think. I made , you made the changes there, then I made a branch for this and then rebased on top of . It should go away when merged.


A recent xml2rfc update changed the way that the element was rendered in text. Take advantage of that by adding quotes to strings that really do benefit from additional quoting, such as the "PRI ..." preface string. Most of the changes shown in a recent diff are down to losing quotes on header field names and other protocol elements. These do not need to be quoted for their meaning to be clear and unambiguous. The use of for these items improves the HTML rendering, but the loss of line noise in text renderings is a net win (at least in my opinion).
I agree with your reasoning, this seems like a good change.


I'm working on the wrong machine and my setup needs tuning. I'll just drop the errant commit.
[x] 1. ----- FP: Is the working group aware that RFC 793bis is in IESG evaluation (URL) ? Was the choice of having a normative reference to 793 conscious, in order to avoid any delay that might come from publication of draft-ietf-tcpm-rfc793bis? (Just checking this was considered) [x] 2. ----- for HTTP/2 over TLS. The general TLS usage guidance in [TLSBCP] SHOULD be followed, with some additional restrictions that are specific to HTTP/2. FP: Given this requirement, I would have expected to see [TLSBCP] normatively referenced, rather than informatively. [x] 3. ----- layer. The frame and stream layers are tailored to the needs of the HTTP protocol and server push. FP: I would think the server push is part of the HTTP protocol, which makes this formulation "HTTP protocol and server push" confusing. [x] 4. ----- Type: The 8-bit type of the frame. The frame type determines the Flags: An 8-bit field reserved for boolean flags specific to the FP: I would find a reference to the IANA registry useful. [x] 5. ----- implementation of flow control can be difficult. When using flow control, the receiver MUST read from the TCP receive buffer in a timely fashion. Failure to do so could lead to a deadlock when FP: "When using flow control" might be rephrased to indicate "when flow control limits are lower than the maximum" (or something of the sort), since if I understand correctly the capability is always used, it is just the window size that changes (effectively implementing control of flow). Also "timely fashion" - I know that it is probably hard, but it would be nice to have a more precise qualification, or at least a hint of what is timely. [x] 6. ----- stream that it successfully received from its peer. The GOAWAY frame includes an error code that indicates why the connection is FP: "error code" - here as well I would have liked a reference to the IANA registry. [x] 7. ----- Exclusive: A single-bit flag. This field is only present if the PRIORITY flag is set. Stream Dependency: A 31-bit stream identifier. This field is only present if the PRIORITY flag is set. Weight: An unsigned 8-bit integer. This field is only present if the PRIORITY flag is set. FP: I would have expected to see some definition of how the fields are used. If this is defined somewhere else, a reference would be good. [x] 8. ----- SETTINGS Frame { Length (24), Type (8) = 4, Unused Flags (7), ACK Flag (1), Reserved (1), Stream Identifier (31), Setting (48) ..., } Setting { Identifier (16), Value (32), } FP: Is there any reason why the Stream Identifier line is not: Stream Identifier (31) = 0, [x] 9. ----- a server does include a value it MUST be 0. A client MUST treat receipt of a SETTINGS frame with SETTINGSENABLEPUSH set to 1 as a connection error (Section 5.4.1) of type PROTOCOLERROR. FP: This is just my curiosity: what is the reason for this stronger requirement - I would think it shouldn't be a problem for the sender if it wants to advertise that it would permit/support server push. What am I missing? [x] 10. ----- A value of 0 for SETTINGSMAXCONCURRENTSTREAMS SHOULD NOT be treated as special by endpoints. A zero value does prevent the FP: When is it ok that the 0 value is treated as special? [x] 11. ----- set. Upon receiving a SETTINGS frame with the ACK flag set, the sender of the altered settings can rely on the value having been applied. FP: nit s/value/values. Also I believe this could be misunderstood - can it be made more precise on the fact that only the values that are present in the received frame with the ACK flag set (and not those that might have been ignored because not understood) have been applied. [x] 12. ----- A receiver MUST treat the receipt of a WINDOWUPDATE frame with an flow-control window increment of 0 as a stream error (Section 5.4.2) FP: nit s/an/a [x] 13. ----- FLOWCONTROLERROR (0x3): The endpoint detected that its peer violated the flow-control protocol. STREAMCLOSED (0x5): The endpoint received a frame after a stream was half-closed. FP: would be good to add a reference to the relevant sections. [x] 14. ----- set after receiving the HEADERS frame that opens a request or after receiving a final (non-informational) status code MUST treat the FP: Where is a "non-informational status code" defined? [x] 15. ----- FP: Are the following two sentences in Section 8.1.1. in contraddiction? request or response. Malformed requests or responses that are detected MUST be treated as a stream error (Section 5.4.2) of type PROTOCOLERROR. on the remainder of the request being correct. A server or intermediary MAY use RSTSTREAM -- with a code other than REFUSEDSTREAM -- to abort a stream if a malformed request or response is received. FP: In section 5.4.2. I read: An endpoint that detects a stream error sends a RSTSTREAM frame So the first sentence above implies RSTSTREAM MUST be sent, while the second sentence states RSTSTREAM MAY be sent. [x] 16. ----- their definitions in Sections Section 5.1 of [5.1] and Section 5.5 of [5.5] of [HTTP] respectively and treat messages that contain FP: References need fixing. [x] 17. ----- from the control data of the original request, unless the the FP: nit Remove one "the" [x] 18. ----- Note that request targets for CONNECT or asterisk-form OPTIONS requests never include authority information. FP: Please add a reference to 7.1 of [HTTP] as this is the first time "asterisk-form OPTION" appear in this document. [x] 19. ----- Advertising a SETTINGSMAXCONCURRENTSTREAMS value of zero disables server push by preventing the server from creating the necessary streams. This does not prohibit a server from sending PUSHPROMISE frames; clients need to reset any promised streams that are not wanted. FP: Do these two sentences contradict each other? In the first sentence I am reading that the server can't create the necessary stream to send the PUSHPROMISE frame, in the second sentence I read that it can? [x] 20. ----- on a DATA frame is treated as being equivalent to the TCP FIN bit. A FP: Can a reference be added to the section where the TCP FIN bit is defined? [x] 21. ----- Content-Type: image/jpeg ==> - ENDSTREAM Content-Length: 123 + END_HEADERS FP: I think it would be good to add a sentence about the meaning of - and + (which I understand to be flag set or not set) in section 2.2. [x] 22. ----- treated as delimiters in other HTTP versions. An intermediary that translates an HTTP/2 request or response MUST validate fields according to the rules in Section 8.2 roles before translating a message to another HTTP version. Translating a field that includes FP: is "roles" supposed to be there? [x] 23. ----- The CONNECT method can be used to create disproportionate load on an proxy, since stream creation is relatively inexpensive when compared FP: nit s/an/a [x] 24. ----- FP: I think it would be good to keep the 3rd paragraph in Section 11 instead of asking the RFC Editor to remove it, just to keep a trace of the registries that have been defined in 7540, since those registries will now reference this document, but this document does not contain all the definitions of the different fields. [x] 25. ---- Comments: Obsolete; see Section 11.1 FP: I would suggest to be explicit and add "of this document" (unless links can be maintained in IANA registries Comments fields).
All done, closing.
Assuming the BCP stuff gets merged via the other PR first.


Replaced 'body' with 'payload' in instances where it would be confusing. Added a flag in the HEADERS frame for header continuations. Added pointers in HEADERS+PRIORITY and PUSH_PROMISE which reference the flags in the HEADERS frame. This should
The continuation bit is inverted with respect to the FINAL flag. Is HEADER_END a better choice? Also, if an unbounded number of frames are permitted, then you need some way to place an upper bound on size. Especially since this requires* that all frames be assembled before processing. Currently, there isn't a default maximum, a setting or an error code.
It could be. I chose this polarity so that it was immediately compatible with what implementations do today for SPDY/2/3 (they don't know about such a bit). If I recall correctly, there currently isn't an explicit limit on header size in HTTP. Unless we're willing to impose such, it is up to the implementation to reject things which are too large by RESETTING the stream. That case probably does need more expounding, though.
Let's move this discussion to the list.
NAME suggested that his header compression () would include the ability to continue header blocks across frames. We should track this as a separate issue. Important consideration is the way that header blocks mutate session state (for header compression). Interleaving of continued header frames will cause issues if we don't address this. We should also consider whether this is a general facility or not.
I believe we should fix this by declaring that, if there is a continuation happening, no new headers frame is allowed to be sent until the continuation is finished. It just gets too difficult to deal with otherwise. , martinthomson EMAIL:
To clarify - you mean that no headers frame on a different stream can be sent?
yes. It isn't the only possible solution, but it is relatively simple and it seems like it should be a rare enough case... -=R , Mark Nottingham EMAIL:


Editorial change only. The idea is to read as soon as data arrives in the TCP buffer. In practice, this is not necessary, but leaving things in the TCP buffer indefinitely can deadlock. (Some implementations of over TCP-based protocols do this and in this case it is BAD.) For .
[x] 1. ----- FP: Is the working group aware that RFC 793bis is in IESG evaluation (URL) ? Was the choice of having a normative reference to 793 conscious, in order to avoid any delay that might come from publication of draft-ietf-tcpm-rfc793bis? (Just checking this was considered) [x] 2. ----- for HTTP/2 over TLS. The general TLS usage guidance in [TLSBCP] SHOULD be followed, with some additional restrictions that are specific to HTTP/2. FP: Given this requirement, I would have expected to see [TLSBCP] normatively referenced, rather than informatively. [x] 3. ----- layer. The frame and stream layers are tailored to the needs of the HTTP protocol and server push. FP: I would think the server push is part of the HTTP protocol, which makes this formulation "HTTP protocol and server push" confusing. [x] 4. ----- Type: The 8-bit type of the frame. The frame type determines the Flags: An 8-bit field reserved for boolean flags specific to the FP: I would find a reference to the IANA registry useful. [x] 5. ----- implementation of flow control can be difficult. When using flow control, the receiver MUST read from the TCP receive buffer in a timely fashion. Failure to do so could lead to a deadlock when FP: "When using flow control" might be rephrased to indicate "when flow control limits are lower than the maximum" (or something of the sort), since if I understand correctly the capability is always used, it is just the window size that changes (effectively implementing control of flow). Also "timely fashion" - I know that it is probably hard, but it would be nice to have a more precise qualification, or at least a hint of what is timely. [x] 6. ----- stream that it successfully received from its peer. The GOAWAY frame includes an error code that indicates why the connection is FP: "error code" - here as well I would have liked a reference to the IANA registry. [x] 7. ----- Exclusive: A single-bit flag. This field is only present if the PRIORITY flag is set. Stream Dependency: A 31-bit stream identifier. This field is only present if the PRIORITY flag is set. Weight: An unsigned 8-bit integer. This field is only present if the PRIORITY flag is set. FP: I would have expected to see some definition of how the fields are used. If this is defined somewhere else, a reference would be good. [x] 8. ----- SETTINGS Frame { Length (24), Type (8) = 4, Unused Flags (7), ACK Flag (1), Reserved (1), Stream Identifier (31), Setting (48) ..., } Setting { Identifier (16), Value (32), } FP: Is there any reason why the Stream Identifier line is not: Stream Identifier (31) = 0, [x] 9. ----- a server does include a value it MUST be 0. A client MUST treat receipt of a SETTINGS frame with SETTINGSENABLEPUSH set to 1 as a connection error (Section 5.4.1) of type PROTOCOLERROR. FP: This is just my curiosity: what is the reason for this stronger requirement - I would think it shouldn't be a problem for the sender if it wants to advertise that it would permit/support server push. What am I missing? [x] 10. ----- A value of 0 for SETTINGSMAXCONCURRENTSTREAMS SHOULD NOT be treated as special by endpoints. A zero value does prevent the FP: When is it ok that the 0 value is treated as special? [x] 11. ----- set. Upon receiving a SETTINGS frame with the ACK flag set, the sender of the altered settings can rely on the value having been applied. FP: nit s/value/values. Also I believe this could be misunderstood - can it be made more precise on the fact that only the values that are present in the received frame with the ACK flag set (and not those that might have been ignored because not understood) have been applied. [x] 12. ----- A receiver MUST treat the receipt of a WINDOWUPDATE frame with an flow-control window increment of 0 as a stream error (Section 5.4.2) FP: nit s/an/a [x] 13. ----- FLOWCONTROLERROR (0x3): The endpoint detected that its peer violated the flow-control protocol. STREAMCLOSED (0x5): The endpoint received a frame after a stream was half-closed. FP: would be good to add a reference to the relevant sections. [x] 14. ----- set after receiving the HEADERS frame that opens a request or after receiving a final (non-informational) status code MUST treat the FP: Where is a "non-informational status code" defined? [x] 15. ----- FP: Are the following two sentences in Section 8.1.1. in contraddiction? request or response. Malformed requests or responses that are detected MUST be treated as a stream error (Section 5.4.2) of type PROTOCOLERROR. on the remainder of the request being correct. A server or intermediary MAY use RSTSTREAM -- with a code other than REFUSEDSTREAM -- to abort a stream if a malformed request or response is received. FP: In section 5.4.2. I read: An endpoint that detects a stream error sends a RSTSTREAM frame So the first sentence above implies RSTSTREAM MUST be sent, while the second sentence states RSTSTREAM MAY be sent. [x] 16. ----- their definitions in Sections Section 5.1 of [5.1] and Section 5.5 of [5.5] of [HTTP] respectively and treat messages that contain FP: References need fixing. [x] 17. ----- from the control data of the original request, unless the the FP: nit Remove one "the" [x] 18. ----- Note that request targets for CONNECT or asterisk-form OPTIONS requests never include authority information. FP: Please add a reference to 7.1 of [HTTP] as this is the first time "asterisk-form OPTION" appear in this document. [x] 19. ----- Advertising a SETTINGSMAXCONCURRENTSTREAMS value of zero disables server push by preventing the server from creating the necessary streams. This does not prohibit a server from sending PUSHPROMISE frames; clients need to reset any promised streams that are not wanted. FP: Do these two sentences contradict each other? In the first sentence I am reading that the server can't create the necessary stream to send the PUSHPROMISE frame, in the second sentence I read that it can? [x] 20. ----- on a DATA frame is treated as being equivalent to the TCP FIN bit. A FP: Can a reference be added to the section where the TCP FIN bit is defined? [x] 21. ----- Content-Type: image/jpeg ==> - ENDSTREAM Content-Length: 123 + END_HEADERS FP: I think it would be good to add a sentence about the meaning of - and + (which I understand to be flag set or not set) in section 2.2. [x] 22. ----- treated as delimiters in other HTTP versions. An intermediary that translates an HTTP/2 request or response MUST validate fields according to the rules in Section 8.2 roles before translating a message to another HTTP version. Translating a field that includes FP: is "roles" supposed to be there? [x] 23. ----- The CONNECT method can be used to create disproportionate load on an proxy, since stream creation is relatively inexpensive when compared FP: nit s/an/a [x] 24. ----- FP: I think it would be good to keep the 3rd paragraph in Section 11 instead of asking the RFC Editor to remove it, just to keep a trace of the registries that have been defined in 7540, since those registries will now reference this document, but this document does not contain all the definitions of the different fields. [x] 25. ---- Comments: Obsolete; see Section 11.1 FP: I would suggest to be explicit and add "of this document" (unless links can be maintained in IANA registries Comments fields).
All done, closing.
Yeah, good rewording here.


For .
[x] 1. ----- FP: Is the working group aware that RFC 793bis is in IESG evaluation (URL) ? Was the choice of having a normative reference to 793 conscious, in order to avoid any delay that might come from publication of draft-ietf-tcpm-rfc793bis? (Just checking this was considered) [x] 2. ----- for HTTP/2 over TLS. The general TLS usage guidance in [TLSBCP] SHOULD be followed, with some additional restrictions that are specific to HTTP/2. FP: Given this requirement, I would have expected to see [TLSBCP] normatively referenced, rather than informatively. [x] 3. ----- layer. The frame and stream layers are tailored to the needs of the HTTP protocol and server push. FP: I would think the server push is part of the HTTP protocol, which makes this formulation "HTTP protocol and server push" confusing. [x] 4. ----- Type: The 8-bit type of the frame. The frame type determines the Flags: An 8-bit field reserved for boolean flags specific to the FP: I would find a reference to the IANA registry useful. [x] 5. ----- implementation of flow control can be difficult. When using flow control, the receiver MUST read from the TCP receive buffer in a timely fashion. Failure to do so could lead to a deadlock when FP: "When using flow control" might be rephrased to indicate "when flow control limits are lower than the maximum" (or something of the sort), since if I understand correctly the capability is always used, it is just the window size that changes (effectively implementing control of flow). Also "timely fashion" - I know that it is probably hard, but it would be nice to have a more precise qualification, or at least a hint of what is timely. [x] 6. ----- stream that it successfully received from its peer. The GOAWAY frame includes an error code that indicates why the connection is FP: "error code" - here as well I would have liked a reference to the IANA registry. [x] 7. ----- Exclusive: A single-bit flag. This field is only present if the PRIORITY flag is set. Stream Dependency: A 31-bit stream identifier. This field is only present if the PRIORITY flag is set. Weight: An unsigned 8-bit integer. This field is only present if the PRIORITY flag is set. FP: I would have expected to see some definition of how the fields are used. If this is defined somewhere else, a reference would be good. [x] 8. ----- SETTINGS Frame { Length (24), Type (8) = 4, Unused Flags (7), ACK Flag (1), Reserved (1), Stream Identifier (31), Setting (48) ..., } Setting { Identifier (16), Value (32), } FP: Is there any reason why the Stream Identifier line is not: Stream Identifier (31) = 0, [x] 9. ----- a server does include a value it MUST be 0. A client MUST treat receipt of a SETTINGS frame with SETTINGSENABLEPUSH set to 1 as a connection error (Section 5.4.1) of type PROTOCOLERROR. FP: This is just my curiosity: what is the reason for this stronger requirement - I would think it shouldn't be a problem for the sender if it wants to advertise that it would permit/support server push. What am I missing? [x] 10. ----- A value of 0 for SETTINGSMAXCONCURRENTSTREAMS SHOULD NOT be treated as special by endpoints. A zero value does prevent the FP: When is it ok that the 0 value is treated as special? [x] 11. ----- set. Upon receiving a SETTINGS frame with the ACK flag set, the sender of the altered settings can rely on the value having been applied. FP: nit s/value/values. Also I believe this could be misunderstood - can it be made more precise on the fact that only the values that are present in the received frame with the ACK flag set (and not those that might have been ignored because not understood) have been applied. [x] 12. ----- A receiver MUST treat the receipt of a WINDOWUPDATE frame with an flow-control window increment of 0 as a stream error (Section 5.4.2) FP: nit s/an/a [x] 13. ----- FLOWCONTROLERROR (0x3): The endpoint detected that its peer violated the flow-control protocol. STREAMCLOSED (0x5): The endpoint received a frame after a stream was half-closed. FP: would be good to add a reference to the relevant sections. [x] 14. ----- set after receiving the HEADERS frame that opens a request or after receiving a final (non-informational) status code MUST treat the FP: Where is a "non-informational status code" defined? [x] 15. ----- FP: Are the following two sentences in Section 8.1.1. in contraddiction? request or response. Malformed requests or responses that are detected MUST be treated as a stream error (Section 5.4.2) of type PROTOCOLERROR. on the remainder of the request being correct. A server or intermediary MAY use RSTSTREAM -- with a code other than REFUSEDSTREAM -- to abort a stream if a malformed request or response is received. FP: In section 5.4.2. I read: An endpoint that detects a stream error sends a RSTSTREAM frame So the first sentence above implies RSTSTREAM MUST be sent, while the second sentence states RSTSTREAM MAY be sent. [x] 16. ----- their definitions in Sections Section 5.1 of [5.1] and Section 5.5 of [5.5] of [HTTP] respectively and treat messages that contain FP: References need fixing. [x] 17. ----- from the control data of the original request, unless the the FP: nit Remove one "the" [x] 18. ----- Note that request targets for CONNECT or asterisk-form OPTIONS requests never include authority information. FP: Please add a reference to 7.1 of [HTTP] as this is the first time "asterisk-form OPTION" appear in this document. [x] 19. ----- Advertising a SETTINGSMAXCONCURRENTSTREAMS value of zero disables server push by preventing the server from creating the necessary streams. This does not prohibit a server from sending PUSHPROMISE frames; clients need to reset any promised streams that are not wanted. FP: Do these two sentences contradict each other? In the first sentence I am reading that the server can't create the necessary stream to send the PUSHPROMISE frame, in the second sentence I read that it can? [x] 20. ----- on a DATA frame is treated as being equivalent to the TCP FIN bit. A FP: Can a reference be added to the section where the TCP FIN bit is defined? [x] 21. ----- Content-Type: image/jpeg ==> - ENDSTREAM Content-Length: 123 + END_HEADERS FP: I think it would be good to add a sentence about the meaning of - and + (which I understand to be flag set or not set) in section 2.2. [x] 22. ----- treated as delimiters in other HTTP versions. An intermediary that translates an HTTP/2 request or response MUST validate fields according to the rules in Section 8.2 roles before translating a message to another HTTP version. Translating a field that includes FP: is "roles" supposed to be there? [x] 23. ----- The CONNECT method can be used to create disproportionate load on an proxy, since stream creation is relatively inexpensive when compared FP: nit s/an/a [x] 24. ----- FP: I think it would be good to keep the 3rd paragraph in Section 11 instead of asking the RFC Editor to remove it, just to keep a trace of the registries that have been defined in 7540, since those registries will now reference this document, but this document does not contain all the definitions of the different fields. [x] 25. ---- Comments: Obsolete; see Section 11.1 FP: I would suggest to be explicit and add "of this document" (unless links can be maintained in IANA registries Comments fields).
All done, closing.


Two paragraphs up we mandate the use of PROTOCOL_ERROR, so this is not necessary. For .


I improved the text along the lines Jörg suggested. However, I realized that the transition should really be in the diagram. That's basically impossible given the nature of the diagram, but it's worth including in the description at least. For .
This is a good clarification. One note about a whitespace change but the textual changes are :+1:


For .
[x] Section 5.1.1., 3rd para: When a stream transitions out of the "idle" state, all streams that might have been initiated by that peer with a lower-valued stream identifier are implicitly transitioned to "closed". Should one say "that might have been but were not initiated by that peers" to make clear that this applies only to un-used streams? [x] Section 5.3.1 Maybe update the section heading to read "Background on Priority in HTTP/2 as per RFC7540"? [x] Section 6.5: The document implies that SETTINGS frames are ACKed in the order they are sent. Should one make this explicit? [x] Last para of 6.5, top of page 37: "If the sender of a SETTINGS frame does not receive an acknowledgement within a reasonable amount of time, it MAY issue a connection error (Section 5.4.1) of type SETTINGSTIMEOUT." Should one provide some intuition on what "reasonable" could mean? An example? It seems, an HTTP/2 sender of a SETTINGS frame could know when this was passed to the TCP layer and may have some insights on application layer RTTs. [x] Section 6.9.1: Concerning flow control, should one say something about avoiding silly windows? [x] Section 8.1.1, p52 1st para: Probably just me, but I am mildly confused by the statement about messages having a non-zero content-length field but still no data in the data frames. The reference section 6.4 of the HTTP semantics draft didn't resolve that. [x] Section 8.2.1, p53: parse error? "When a request message violates one of these requirements, an implementation SHOULD generate a Section 15.5.1 of 400 (Bad Request) status code [HTTP], [...]" [x] Section 8.4.2, 4th para: "A client can use the SETTINGSMAXCONCURRENTSTREAMS setting to limit the number of responses that can be concurrently pushed by a server. Advertising a SETTINGSMAXCONCURRENTSTREAMS value of zero disables server push by preventing the server from creating the necessary streams. This does not prohibit a server from sending PUSHPROMISE frames; clients need to reset any promised streams that are not wanted. Confused: it disables server push, but the server can send PUSHPROMISE frames and then the client is supposed to reset a stream it wasn't willing to accept or capable of accepting? Which stream number would the server legitimately put into the PUSHPROMISE? [ ] There are a few cases where I am wondering if normative language should be used. Examples include [ ] -- 5.4.2, 2nd para, "sends an RST_STREAM frame" [x] -- 6.8, p43, 1st para, "the server can send another GOAWAY" [ ] -- 6.8, p43, 2nd para, "the sender can discard frames" [ ] -- 9.1, 3rd para, "clients can create" [ ] There may be further occurrences of "can" or similar.
FYI NAME I've updated this post to have a list of checkboxes for "addressed".
I've reviewed the changes here and I'm happy with 9/14. The others I don't think need to be addressed.


This isn't TCP RTT based. For .
[x] Section 5.1.1., 3rd para: When a stream transitions out of the "idle" state, all streams that might have been initiated by that peer with a lower-valued stream identifier are implicitly transitioned to "closed". Should one say "that might have been but were not initiated by that peers" to make clear that this applies only to un-used streams? [x] Section 5.3.1 Maybe update the section heading to read "Background on Priority in HTTP/2 as per RFC7540"? [x] Section 6.5: The document implies that SETTINGS frames are ACKed in the order they are sent. Should one make this explicit? [x] Last para of 6.5, top of page 37: "If the sender of a SETTINGS frame does not receive an acknowledgement within a reasonable amount of time, it MAY issue a connection error (Section 5.4.1) of type SETTINGSTIMEOUT." Should one provide some intuition on what "reasonable" could mean? An example? It seems, an HTTP/2 sender of a SETTINGS frame could know when this was passed to the TCP layer and may have some insights on application layer RTTs. [x] Section 6.9.1: Concerning flow control, should one say something about avoiding silly windows? [x] Section 8.1.1, p52 1st para: Probably just me, but I am mildly confused by the statement about messages having a non-zero content-length field but still no data in the data frames. The reference section 6.4 of the HTTP semantics draft didn't resolve that. [x] Section 8.2.1, p53: parse error? "When a request message violates one of these requirements, an implementation SHOULD generate a Section 15.5.1 of 400 (Bad Request) status code [HTTP], [...]" [x] Section 8.4.2, 4th para: "A client can use the SETTINGSMAXCONCURRENTSTREAMS setting to limit the number of responses that can be concurrently pushed by a server. Advertising a SETTINGSMAXCONCURRENTSTREAMS value of zero disables server push by preventing the server from creating the necessary streams. This does not prohibit a server from sending PUSHPROMISE frames; clients need to reset any promised streams that are not wanted. Confused: it disables server push, but the server can send PUSHPROMISE frames and then the client is supposed to reset a stream it wasn't willing to accept or capable of accepting? Which stream number would the server legitimately put into the PUSHPROMISE? [ ] There are a few cases where I am wondering if normative language should be used. Examples include [ ] -- 5.4.2, 2nd para, "sends an RST_STREAM frame" [x] -- 6.8, p43, 1st para, "the server can send another GOAWAY" [ ] -- 6.8, p43, 2nd para, "the sender can discard frames" [ ] -- 9.1, 3rd para, "clients can create" [ ] There may be further occurrences of "can" or similar.
FYI NAME I've updated this post to have a list of checkboxes for "addressed".
I've reviewed the changes here and I'm happy with 9/14. The others I don't think need to be addressed.


And an update to the section reference. For .
[x] Section 5.1.1., 3rd para: When a stream transitions out of the "idle" state, all streams that might have been initiated by that peer with a lower-valued stream identifier are implicitly transitioned to "closed". Should one say "that might have been but were not initiated by that peers" to make clear that this applies only to un-used streams? [x] Section 5.3.1 Maybe update the section heading to read "Background on Priority in HTTP/2 as per RFC7540"? [x] Section 6.5: The document implies that SETTINGS frames are ACKed in the order they are sent. Should one make this explicit? [x] Last para of 6.5, top of page 37: "If the sender of a SETTINGS frame does not receive an acknowledgement within a reasonable amount of time, it MAY issue a connection error (Section 5.4.1) of type SETTINGSTIMEOUT." Should one provide some intuition on what "reasonable" could mean? An example? It seems, an HTTP/2 sender of a SETTINGS frame could know when this was passed to the TCP layer and may have some insights on application layer RTTs. [x] Section 6.9.1: Concerning flow control, should one say something about avoiding silly windows? [x] Section 8.1.1, p52 1st para: Probably just me, but I am mildly confused by the statement about messages having a non-zero content-length field but still no data in the data frames. The reference section 6.4 of the HTTP semantics draft didn't resolve that. [x] Section 8.2.1, p53: parse error? "When a request message violates one of these requirements, an implementation SHOULD generate a Section 15.5.1 of 400 (Bad Request) status code [HTTP], [...]" [x] Section 8.4.2, 4th para: "A client can use the SETTINGSMAXCONCURRENTSTREAMS setting to limit the number of responses that can be concurrently pushed by a server. Advertising a SETTINGSMAXCONCURRENTSTREAMS value of zero disables server push by preventing the server from creating the necessary streams. This does not prohibit a server from sending PUSHPROMISE frames; clients need to reset any promised streams that are not wanted. Confused: it disables server push, but the server can send PUSHPROMISE frames and then the client is supposed to reset a stream it wasn't willing to accept or capable of accepting? Which stream number would the server legitimately put into the PUSHPROMISE? [ ] There are a few cases where I am wondering if normative language should be used. Examples include [ ] -- 5.4.2, 2nd para, "sends an RST_STREAM frame" [x] -- 6.8, p43, 1st para, "the server can send another GOAWAY" [ ] -- 6.8, p43, 2nd para, "the sender can discard frames" [ ] -- 9.1, 3rd para, "clients can create" [ ] There may be further occurrences of "can" or similar.
FYI NAME I've updated this post to have a list of checkboxes for "addressed".
I've reviewed the changes here and I'm happy with 9/14. The others I don't think need to be addressed.


This is confusing; hopefully this rewrite is a little less so. For .
[x] Section 5.1.1., 3rd para: When a stream transitions out of the "idle" state, all streams that might have been initiated by that peer with a lower-valued stream identifier are implicitly transitioned to "closed". Should one say "that might have been but were not initiated by that peers" to make clear that this applies only to un-used streams? [x] Section 5.3.1 Maybe update the section heading to read "Background on Priority in HTTP/2 as per RFC7540"? [x] Section 6.5: The document implies that SETTINGS frames are ACKed in the order they are sent. Should one make this explicit? [x] Last para of 6.5, top of page 37: "If the sender of a SETTINGS frame does not receive an acknowledgement within a reasonable amount of time, it MAY issue a connection error (Section 5.4.1) of type SETTINGSTIMEOUT." Should one provide some intuition on what "reasonable" could mean? An example? It seems, an HTTP/2 sender of a SETTINGS frame could know when this was passed to the TCP layer and may have some insights on application layer RTTs. [x] Section 6.9.1: Concerning flow control, should one say something about avoiding silly windows? [x] Section 8.1.1, p52 1st para: Probably just me, but I am mildly confused by the statement about messages having a non-zero content-length field but still no data in the data frames. The reference section 6.4 of the HTTP semantics draft didn't resolve that. [x] Section 8.2.1, p53: parse error? "When a request message violates one of these requirements, an implementation SHOULD generate a Section 15.5.1 of 400 (Bad Request) status code [HTTP], [...]" [x] Section 8.4.2, 4th para: "A client can use the SETTINGSMAXCONCURRENTSTREAMS setting to limit the number of responses that can be concurrently pushed by a server. Advertising a SETTINGSMAXCONCURRENTSTREAMS value of zero disables server push by preventing the server from creating the necessary streams. This does not prohibit a server from sending PUSHPROMISE frames; clients need to reset any promised streams that are not wanted. Confused: it disables server push, but the server can send PUSHPROMISE frames and then the client is supposed to reset a stream it wasn't willing to accept or capable of accepting? Which stream number would the server legitimately put into the PUSHPROMISE? [ ] There are a few cases where I am wondering if normative language should be used. Examples include [ ] -- 5.4.2, 2nd para, "sends an RST_STREAM frame" [x] -- 6.8, p43, 1st para, "the server can send another GOAWAY" [ ] -- 6.8, p43, 2nd para, "the sender can discard frames" [ ] -- 9.1, 3rd para, "clients can create" [ ] There may be further occurrences of "can" or similar.
FYI NAME I've updated this post to have a list of checkboxes for "addressed".
I've reviewed the changes here and I'm happy with 9/14. The others I don't think need to be addressed.


This is the one case in Jörg's review where I think we need text. In the other places, the text is secondary to other normative language and should not be restated in direct terms (or it would need to be far more precise than it is). For .
[x] Section 5.1.1., 3rd para: When a stream transitions out of the "idle" state, all streams that might have been initiated by that peer with a lower-valued stream identifier are implicitly transitioned to "closed". Should one say "that might have been but were not initiated by that peers" to make clear that this applies only to un-used streams? [x] Section 5.3.1 Maybe update the section heading to read "Background on Priority in HTTP/2 as per RFC7540"? [x] Section 6.5: The document implies that SETTINGS frames are ACKed in the order they are sent. Should one make this explicit? [x] Last para of 6.5, top of page 37: "If the sender of a SETTINGS frame does not receive an acknowledgement within a reasonable amount of time, it MAY issue a connection error (Section 5.4.1) of type SETTINGSTIMEOUT." Should one provide some intuition on what "reasonable" could mean? An example? It seems, an HTTP/2 sender of a SETTINGS frame could know when this was passed to the TCP layer and may have some insights on application layer RTTs. [x] Section 6.9.1: Concerning flow control, should one say something about avoiding silly windows? [x] Section 8.1.1, p52 1st para: Probably just me, but I am mildly confused by the statement about messages having a non-zero content-length field but still no data in the data frames. The reference section 6.4 of the HTTP semantics draft didn't resolve that. [x] Section 8.2.1, p53: parse error? "When a request message violates one of these requirements, an implementation SHOULD generate a Section 15.5.1 of 400 (Bad Request) status code [HTTP], [...]" [x] Section 8.4.2, 4th para: "A client can use the SETTINGSMAXCONCURRENTSTREAMS setting to limit the number of responses that can be concurrently pushed by a server. Advertising a SETTINGSMAXCONCURRENTSTREAMS value of zero disables server push by preventing the server from creating the necessary streams. This does not prohibit a server from sending PUSHPROMISE frames; clients need to reset any promised streams that are not wanted. Confused: it disables server push, but the server can send PUSHPROMISE frames and then the client is supposed to reset a stream it wasn't willing to accept or capable of accepting? Which stream number would the server legitimately put into the PUSHPROMISE? [ ] There are a few cases where I am wondering if normative language should be used. Examples include [ ] -- 5.4.2, 2nd para, "sends an RST_STREAM frame" [x] -- 6.8, p43, 1st para, "the server can send another GOAWAY" [ ] -- 6.8, p43, 2nd para, "the sender can discard frames" [ ] -- 9.1, 3rd para, "clients can create" [ ] There may be further occurrences of "can" or similar.
FYI NAME I've updated this post to have a list of checkboxes for "addressed".
I've reviewed the changes here and I'm happy with 9/14. The others I don't think need to be addressed.


This adds a few requirements ripped from my blog post, and cleans out use cases and such.
I have some thoughts about the content of this PR, but let's merge it, and see if my thoughts turn into text :-)


NAME I think this is ready for review and merging .
Duplicated "without without waiting" in Section 2.1. I wish I had spotted "where a user wishes to observe or control the graphical user interface of another computer through local user interfaces" in 3.1.2 - I'd suggest saying this as "where a user wishes to observe or control the graphical user interface of another computer through user interfaces that are local to the user". I think "This may include audio from both microphone(s) and/or cameras, or may include "screen sharing" or inclusion of other content such as slide, document, or video presentation" in 3.1.3 might need adjusting. Doesn't this need to say, "This may include audio from microphone(s) and/or cameras, and may include "screen sharing" or inclusion of other content such as slide, document, or video presentation"? (Also, we named everything except video as a media type, but if we're changing that paragraph anyway, we can add video as well) in 3.2, I had difficulty parsing "As this has a much larger total number of participants - as many as Live Media Streaming , but with the bi-directionality of conferencing, this should be considered a "hybrid"." I wasn't sure "much larger than what?" Is this intended to say something like "This use case can have an audience as large as Live Media Streaming as described in Section 3.3.3, but also relies on the interactivity and bi-directionality of conferencing as in Video Conferencing as described in Section 3.1.3. For this reason, this type of use case can be considered a "hybrid". (if we're forward-referencing section 3.3.3 in Section 3.2, this might be clearer if we swapped the order of Sections 3.2 and 3.3) In section 3.3.1, are there any non-hypothetical media types beyond "audio and/or video"? In Section 3.3.3, I asked you to distinguish between the live edge and the trailing edge (thank you for that), but I didn't realize that "either because the local player falls behind edge" was now unqualified. Is this "either because the local player falls behind the live edge**"? In 4.9.1, "this is infeasible in many use cases where provisioning of client TLS certificates is unsupported or infeasible." has two "infeasible"s. Perhaps one could be "impractical"? Your choice which, of course.
In submitting the -00 working group version, we tripped over an incompatibility between XML2RFC and google-i18n-address 3.0.0. The details are at URL and at URL I took the shortcut of removing the country: attributes for the authors in -00, but (per the comments on those issues, a version of XML2RFC that has been deployed, so we can add our country attributes back when we're fixing the nits identified in this issue. And NAME says it's "The Netherlands", but I'll let NAME and NAME wrestile that one out ... :zippermouthface:


Note - this is a rough draft, although I have done some edits while adding this material. I do have notes for to-dos, and I'm pretty sure I want to figure out how to do the diagrams in some way that will format with straight lines, for starters.
I'm happy to just merge this in now as is just to unblock other work and make progress, and make any adjustments later because there's nothing that stands out as controversial, NAME are you okay with this?
We have a plan on how to resolve our terminology migration for in this PR
Based on review comments from NAME on the mailing list .
Draft is in suhasHere/moq-drafts.
NAME - NAME and I are starting with the scenarios from URL
NAME - I think it would be good to close this issue when we have a reasonable plan for where the material from the scenarios draft goes, and then handle further changes via issues and PRs as usual. Does that make sense? NAME NAME and NAME - I wanted to let you know that NAME and I are (finally, finally!) merging text from the scenarios draft in the requirements draft, as NAME suggested. I think I have homes for almost all of the text from the requirements draft, but I do have some work to do, so that the material is in the right place, and that it flows with text from the previous version of the requirements draft. I am, of course, always interested in comments. And thank you each for the work you did on this material.
Awesome - let me know if something I can do to help
Thanks NAME .. look forward to the updates. +1 to NAME , please let me know if we can be of any help Here is my review. Firstly, I'd like to say that this document is badly needed. The requirements document doesn't get into the level of detail that this document does, and I think that this level of detail is important to make progress on the design. Terminology I think it would be useful to define some of the terminology, including terms like "track" and "media switch". Section 2.2 A few questions: Are the trackIDs "t1, t2, t3" separate MediaStreamTracks, or are they just multiple encodings of the same track? Are there scenarios in which it would be useful to be able to ingest multiple MediaStreamTracks (either audio or video)? I ask because the RUSH draft doesn't support ingestion of multiple tracks and I've been told that this is a problem by some customers. Section 2.4 A media switch, sourcing tracks that represent a subset of tracks from across all the emitters. Such subset may represent tracks representing top 5 speakers at higher qualities and lot of other tracks for rest of the emitters at lower qualities. [BA] The use of the term "media switch" suggests to me that it is forwarding tracks, rather than sourcing (e.g. transcoding) them. Can you clarify? subscribing to subset of the tracks [BA] I think there may be an implicit assumption here, which is that the receiver only indicates the track it wishes to subscribe to, rather than indicating the quality it wishes to receive. Above setup brings in following properties on the data model for the transport protocol [BA] The paragraphs that follow appear to describe different ways that the system could be implemented, rather than "properties on the data model". Do you mean to say that the design should be able to handle any of the approaches described? Media Switches to source new tracks but retain media payload from the original emitters. This implies publishing new Track IDs sourced from the SFU, with object payload unchanged from the original emitters. [BA] Is the term "source new tracks" implied by changing the Track IDs? If the payload is retained, this seems like forwarding to me, rather than "sourcing new tracks". Media Switches to propogate subset of tracks as-is from the emitters to the subscribers. This implies Track IDs to be unchanged between the emitters and the receivers. [BA] What does "as-is" mean here? Are you referring only the lack of a change in the "Track ID"? If the switch drops some frames in order to reduce quality (and bandwidth consumption) is it still "as-is"? Subscribers to explictily request multiple appropriate qualities and dynamically move between the qualtiies during the course of the session [BA] Is it a goal to be able to support such a "receiver driven" approach, as well as the other two approaches, which are sender driven? Section 3.1 For example, rather than waiting for 30 seconds before connecting, the user might quickly download the "key" frames of the past 30 seconds and replay them in order to "synchronize" the video decoder. [BA] I think this sentence points out that the term "access point" may need to be clarified, because in such a scenario, the term "access point" may have a different meaning in stored media than in media transmitted over the wire to speed up join latency. Section 3.2 It is possible to use groups as units of congestion control. When the sending strategy is understoud, the objects in the group can be assigned sequence numbers and drop priorities that capture the encoding dependencies, such that: an object can only have dependencies with other objects in the same group, an object can only have dependencies with other objects with lower sequence numbers, an object can only have dependencies with other objects with lower or equal drop priorities. [BA] This text seems to be mixing distinct concepts such as dependencies and layering. In layered coding, there is typically only a requirement not to depend on higher layers, but it's possible to depend on frames in lower layers. Mixing drop priority (a transport concept) with groups seems confusing to me. The main drawback is that if a packet with a given drop priority is actually dropped, all objects with higher sequence numbers and higher or equal drop priorities in the same group must be dropped. [BA] Leaving gaps in the sequence number space does seem problematic, but that's a choice, not a requirement. If the group duration is long, this means that the quality of experience may be lowered for a long time after a brief congestion. If the group duration is short, this can produce a jarring effect in which the quality of experience drops perdiodically at the tail of the group. [BA] What does "group duration" mean? Are you referring to time between I-frames? This paragraph seems to assume that group duration is a constant rather than something which can be set dynamically. Section 4 Some video codecs have a complex structure. [BA] Are you referring to codecs, or encodings? It would send for example: [BA] A picture might help here. I think you're referring to the scalabilty mode known as "L2T2h": URL Of course, we could encode these dependencies as properties of the object being sent, stating for example that "object 17 can only be decoded if objects 16, 11 and 7 are available." However, this approach leads to a lot of complexity in relays. We believe that a linear approach is preferable, using attributes of objects like delivery order or priorities. [BA] Why would this lead to complexity in relays in a receiver-driven scenario? The relay would only forward the layers that the receiver asked for, and wouldn't have to store state relating to the receivers. Also, the real issue here isn't dropping layers, which can occur at any point. The reason dependencies (and more) are needed (and why the "linear approach" doesn't work) comes when it is desired to add layers. It is of course possible just to start forwarding additional layers, but that doesn't improve quality unless the forwarded frames can actually be decoded. To figure this out, whoever is in charge (receiver or relay) needs to be able to determine the "upswitch points". This also implies feedback from the receivers to the encoder (e.g. LRR). Section 4.2 We propose to express dependencies using a combination of object number and object priority. [BA] How would this permit restoration of video quality after congestion clears up? I don't think you have enough information. Section 4.3 . Relay behavior In case of congestion, the relay will use the priorities to selectively drop the "least important" objects: [BA] Dropping is easy, it's adding layers back (and decoding them) that's hard.


We have an expectation that media itself is encrypted between a client and a server. We have identified a need for MOQ relays to have access to at least some, but perhaps not all, media metadata, in order to make forwarding decisions. So, for instance, timing metadata, but not names of media. If we intend to support media translators as well, the media translators will also need access to the media itself. It would be useful to be clear about what security relationships will be needed in various deployment architectures.
I think this is dependent on the conversation about MOQ entities and their functionalities, and what they need access to, in order to perform their functions, that we're having (especially starting at the January MOQ interim).


I suspect this may require a little bit more thought, but want to sense-check the direction. NAME any feedback you have would be welcome.
NAME NAME thank you both for your feedback, I've rewritten the block again based on your feedback and hope this is a lot more clearer.
MoQ Transport, in combination with a MoQ Streaming Format, needs to support mechanisms to allow ad insertion. This ad insertion: Should be compliant with current IAB and SCTE standards such as SCTE-35, which specifies signals that can be used to identify advertising breaks, advertising content, and programming content. VAST (Video Ad Serving Template) VPAID (Video Player Ad-serving Interface Definition) VMAP (Video Multiple Ad Playlist) Should be able to participate in both server-side and client side ad insertion schemes. The server-side solution may have a mode in which the ad is stitched seamlessly into the primary content and the ad boundaries are indistinguishable to the client. Should be dynamic in nature, allowing for just-in-time decisions to be made for choosing which content to insert. Should allow access to, and compatibility with, a subset of existing ad inventory.
Some of my initials thoughts: To stick to the separation model of "church and state", we should also have agility to support more than SCTE-35/IAB specs in the transport layer Is it required that all streaming formats must support event tracks? Or is the requirement here that just the transport through the catalog enables it? Is there a benefit to describing these requirements more generically - although enabling advertising for live broadcast is clearly the obvious use case having this functionality could be useful for other reasons, such as: In teleconferencing, a presenter switching one (or all) viewer's video to a different source such as the slide show or the presenters camera Falling viewers over to another source when the current one ends e.g Twitch's "raiding"
Given the PR above is merged, I'm closing this noting the above issue on ingest will carry on.


Hi, NAME I think this looks mostly fine (it looks like the abstract is a tiny bit garbled, but we can fix stuff like that in an editorial pass). Based on the changed title, I'm assuming that we aren't worrying about SRT and RUSH in this draft - that's probably a good call, because I don't think their requirements are going to look much like RTP over QUIC requirements. There will be some places that I will need to tighten up what I wrote, because they were still in scope when I was typing. I'll merge this, and see where I end up in an hour or two of typing.
I needed a bit more context for this: I'm probably confused by "The protocol". URL says it provides this authentication using TLS 1.3 handshake. Are you thinking of something in addition to the QUIC cryptographic handshake? (Assuming the definition of "Media Transport Protocol" in ), something provided by the Media Transport Protocol level? Or something else?
Something in addition to the QUIC cryptographic handshake (in which I am talking about TLS mutual authentication here, where client presents a valid certificate to server, and verifies the server certificate). Consider: Existing protocols in this space usually offer some "shared secret" of some variety as part of either/or an authentication handshake, and encryption of media: which are just secret values set in the field during connection handshake (see § 6.4) - but note they also support a cert-based approach which more closely matches TLS mutual auth where the Stream ID and user define the authorisation Before RIST Main profile there hasn't been a need for a lot of certificate-based authentication and so existing folk in field would use these types of shared secret patterns, and that having to keep PKI for devices may be problematic. Consider things like encoding hardware deployed in remote locations. Other options could be considered, like using a more SIP-like approach, but we would have to be careful not to bring the rest of the SIP kitchen sink with its round peg that might not fit in the square QUIC slot. I get this requirement presently is a bit flaky in part because the requirements are a bit unclear. Perhaps I put a little more description on the requirement, or remove it from the draft now, and leave it for a "ask later". Thoughts?
NAME I think (1) adding the explanation that this is beyond the authentication mechanism provided by QUIC, and (2) leaving it in the draft, with a note that more detail is needed, and will be added as discussion proceeds, is all that's needed for now.
Closing this as I think it has been addressed, please by all means speak up if we still should do work here.
I THINK what we are doing, is roughly Start with current "Media - Media Transport Protocol", where "Media Transport Protocol" might be RTP Encapsulate in QUIC, to give "Media - Media Transport Protocol - QUIC" If that's right, we should be using "Media Transport Protocol" to describe the first layer under "Media", and what we're doing might better be described as something like "Media Transport Protocol Encapsulation" ("in QUIC"). Whatever we choose, we should be consistent - the Abstract says which would make me believe that we're designing a replacement for existing media transport protocols, but then under "Non-requirements, we have I think that the second quote is correct, so we just need to be clearer in the first quote.
I agree with this, and it should be fixed. Would you like me to clean it up or do you want to roll it in with other changes?
Hi, NAME would it be OK if you did this cleanup? I think adding the picture of the two protocol stacks, in some form, will be super helpful for readers.
I think we can close this as our nomenclature for the document is kind of done now the -00 is out.
We have been talking about "Media Over QUIC" as a broad term that would include any media transport protocol running over QUIC, which (apparently) would include RTP over QUIC SRP over QUIC RUSH, which runs over QUIC If we are doing "Media over QUIC", all of these (and potentially others) would be in scope. If the scope of this document is "Media over RTP over QUIC", that would be fine, but we should say that. Thoughts?
I think we've fixed this one - I'll close it for now.


One more use case "Distribution withing a platform" is suggested. It does not seem to be covered by other use cases, but might be worth describing it as well. Some minor suggestions like UDP multicast instead of QUIC as the last mile transport, etc.
Thanks!


This is just a starting point, but brings the document closer to alignment with our spreadsheet. I've also added some additional details which should cover themes raised in the current BoF agenda.


NAME - Please let me know if this seems about right. One thing that's worth mentioning to you and to NAME - the latency characterizations that we wrote did not make use of the new "ultra-ultra-low latency" categories. I changed the one for gaming to ull100 ("ultra-low-latency under 100 ms") based on conversations at IETF 112, but other people would be better choices to review the characterizations of the use cases they're most interested in.
The opcons drafts uses 4 bands: ultra low-latency (less than 1 second) low-latency live (less than 10 seconds) non-low-latency live (10 seconds to a few minutes) on-demand (hours or more) I think these bands lose some granularity that is useful. For example, a functional video call or interactive game probably needs much less than 1s latency, while low latency live may span lower than 1s in some cases?
NAME - that's very true. The opcons draft was scoped for "streaming operators", and although we've talked (in MOPS) about doing a separate draft for low-latency streaming, we haven't done that yet (in MOPS). That may be for the best, if MOQ turns out to be "not ABR, less than 500 ms", or something like that. I'm also one of the opcons drafts, so I'm thinking we should add at least one, and probably two, lower-than-ultra-low(!!!) latency bands, and explain why we're doing that. I'm assigning this to me, so expect a PR soon.
The industry is terrible at naming things. "ultra-low", "low", "non-low", I mean really? It's all terrible marketing rather than an attempt to classify protocols. I like that the opcons tries to reuse and simplify the terminology but... latency is a complicated. Some protocols have artificial delays, but for the most part, protocols are defined by their ability to deal with congestion. A protocol like RTMP will be "ultra low-latency" within a datacenter or for a user with a perfect network connection, while it will be "low-latency" for somebody on a cellular connection, while it will be "non-low-latency" for somebody going through a tunnel... all of which depends on the implementation. At the end of the day, these lines in the sand don't add to the discussion. I would rather focus on the use-cases like "having a conversation with someone" rather than arguing over millisecond budgets.


The section "Moving Beyond RTP over QUIC" should cover the position of assessing the feasibility of the RTP family of protocols, and the size of work of any possible changes that may be required for them to be incorporated.
This We're going to need more work on RTP versus other transport protocols, but we definitely need to make this change!
I've already ranted enough about this section but I figured I'd file a ticket so it doesn't get forgotten. :)
I think what needs changing is that this is removed as a non-requirement, however I still think that we have to make it clear that a consideration "to RTP or not to RTP" must be described in the document.
I think we've now covered this, please chime up if there was anything missed.


This should address
Although it's true that RUSH predates DATAGRAM, streams were an intentional choice as RUSH implementations can leverage standard QUIC library reassembly of messages longer than one MTU.
Absolutely. It's disingenuous to say that RUSH is using QUIC streams because QUIC datagrams didn't exist yet. QUIC streams provide fragmentation, reliability, flow control, and cancellation (error codes). In fact, you could (but shouldn't) use QUIC streams to deliver individual RTP packets without much downside.
The above commits should fix this, please let me know if I got it wrong.


Although it's true that RUSH predates DATAGRAM, streams were an intentional choice as RUSH implementations can leverage standard QUIC library reassembly of messages longer than one MTU.
Absolutely. It's disingenuous to say that RUSH is using QUIC streams because QUIC datagrams didn't exist yet. QUIC streams provide fragmentation, reliability, flow control, and cancellation (error codes). In fact, you could (but shouldn't) use QUIC streams to deliver individual RTP packets without much downside.
The above commits should fix this, please let me know if I got it wrong.


(related to )
NAME could you please take a look and let me know if it's an accurate description?
I'm merging this, so we make sure that WARP is included. If we got anything wrong, please let us know - we'll make sure it gets fixed.
Luke Curley has written . It's QUIC based, using CMAF for encapsulation, stream based, has no ALPN amongst other features. That said, it should be included in the "prior art" section of the document.
Agreed!
Some things worth considering, but you guys decide what is worth mentioning. Warp is the only protocol that is not frame based. Instead it attempts to map the GoP structure to QUIC streams. High quality media is basically linear within a GoP in order to maximize compression, which fits very nicely with QUIC's streams. There's no point delivering frames out of order if they cannot be decoded out of order. Warp uses prioritization instead of deadlines to achieve dynamic latency. This removes the need for feedback outside of QUIC ACKs. It avoids a whole class of problems caused by dropped/delayed feedback. Warp uses CMAF segments for full compatibility with HLS/DASH, avoiding transmuxing on edge or at origin. Warp uses the full suite of QUIC functionality. This includes fragmentation, congestion control, flow control, streams (multiplexing + cancellation), etc. Some other protocols use QUIC datagrams and disable everything else, effectively using QUIC as a complex DTLS replacement. Warp supports a bidirectional API using QUIC streams however this was not in scope for the first version of the draft. I wanted to avoid bike shedding to focus instead on the above features. The actual version in production allows the player to manually choose the rendition and pause/play. Warp uses WebTransport at the moment, but we can decide if it's better suited for native QUIC (with ALPN) or even HTTP/3. Warp would even work over HTTP/2 (and Http2Transport) albeit with additional head-of-line blocking.


Media over QUIC is just the name of a mailing list and a general area of discussion. In some places, the draft refers to it ambiguously where a read may interpret it as the name of a protocol or working group. Maybe can call out that it is not those things and disambiguate references with "Media over QUIC mailing list" or "Media over QUIC problem space"?
I think the issue (or at least the resolution) is also tied to - the objectionable (or at least the obsolete) text in needs to change, and making the changed text also define all the ways we've used the label "MOQ" seems helpful. Expect a PR that attempts to resolve both.
Streams are equally capable of moving media, though the number of different ways to design a protocol have expanded with the addition of datagrams.
Absolutely. It might be worth mentioning that QUIC datagrams in their current state have caveats. They are congestion controlled, elicit acknowledgements, and these acknowledgements . QUIC datagrams certainly have their benefits, but protocols need to be designed to use them properly. Otherwise SRTP and DTLS might be better options.
This term may imply latency constraints that may not exist in all use cases. Further, I wonder if the framing as 'encapsulation of a media transport protocol as a payload' jives with what Victor mentioned during our call -- that part of what's interesting is using QUIC as a transport protocol.
NAME - two things (one each, for your two excellent points): this draft started out as a survey of what was being described as "Media Over QUIC" last summer (after the IETF 111 side meeting), then lurched downhill to being focused on RTP over QUIC, and then lurched BACK uphill, but not all the way uphill, to focusing on a subset of what's been proposed under the banner of "MOQ". Thanks for helping us spot places in the draft that haven't completed the trek! Agreed about reframing the framing, and if we suck any of the other use cases in - there was a lot of discussion around needing help with gaming for sub-100 ms latencies at the IETF 112 side meeting, so that might happen - the current framing might be even less helpful. Definitely worth fixing. Expect a PR soon.
I've been using the phrase "live media", defining it as "media that is actively being produced and consumed". It's not perfect but neither is drawing a numeric latency number in the sand.
NAME - just so that I understand (better) - are you saying that the media is being consumed at (roughly) the rate it's being produced? Any answer is fine, I just want to make sure I know what we're talking about here.
We have been talking about "Media Over QUIC" as a broad term that would include any media transport protocol running over QUIC, which (apparently) would include RTP over QUIC SRP over QUIC RUSH, which runs over QUIC If we are doing "Media over QUIC", all of these (and potentially others) would be in scope. If the scope of this document is "Media over RTP over QUIC", that would be fine, but we should say that. Thoughts?
I think we've fixed this one - I'll close it for now.


Based on feedback from NAME
That looks fabulous to me - merging now. There's not an issue for this, right?


It's likely that only NAME and I will care about this, but I think it matters :grin:


We should talk about whether the MOPS latency constraints make sense, or whether we should stop suffering and switch to something that's not about transport latency, but more about end-to-end workflow duration, which is what I think we're talking about in the "On Demand Media" section. But we can do that another day.
I think it's hard to really define latency for on demand for a whole host of reasons: The non-functional requirements for a system to process an on demand asset can vary dramatically. For example, it's common for news clips to have an SLA of clip duration to ingest, transcode, deliver, and be playable. Whereas for high resolution content, this stage of ingest and processing can take many multiples of duration and may be done hours/days in advance of its availability to playback. It's not really live, so the measurement of "latency" is a bit weird here. The latency between the origin storage serving the media to presentation on screen is, in general irrelevant from a playback perspective provided it doesn't stall out playback due to poor network conditions. Throughput and jitter have a greater affect.