jiebi/CodeConvo huggingface dataset:
One small normative change: I relaxed a SHOULD to a MAY when discussing relays writing data out of order. No one is implementing this right now.
Here are some editorial notes on the document Line 72. “MOQT is a generic protocol is designed to work” Line 91-93. “The development of MOQT is driven by goals in a number of areas - specifically latency, the robustness of QUIC, workflow efficiency and relay support.” This sentence is intriguing. What does the robustness of QUIC mean? Latency, workflow efficiency, relay support are not “areas” or maybe area should be defined. (side note on the missing Oxford comma in this sentence) The Section 1.1.1. Latency as a whole is very confusing. HTTP-based streaming is not designed for low latency mostly due to the essential request-response paradigm. Queuing on the path has a insignificant impact on the end-to-end latency for HAS. The “speed at which a protocol can detect queuing” is not related to the relatively high latency issues of HAS. Overall, I see a mix of unrelated subjects here, which makes the paragraph overall meaningless. I would recommend starting the paragraph with a topic sentence (which may be the last one of the current paragraph). Line 120. “Applying QUIC to HAS …” (and the following sentences) is not necessary. The reasons for which QUIC does not bring advantages to HAS are still debatable on many points. This QUIC-on-HAS remark could raise unnecessary questions although the beginning of Section 1.1.2 is clear and sufficient to convey the message. Line 125. “Universal” has a too broad sense. Do you mean “Unicity of protocol in the whole pipeline” (or something like this)? Line 127. “Internet delivered media today has protocols optimized for ingest…” I don’t understand this sentence. Line 127. Some examples of protocols could be good to support these claims. Note that WHIP is an attempt to unify the protocol. Line 146. “to treat relays as first-class citizens of the protocol” is an excellent marketing message but it does not mean anything in a technical norm. Furthermore, see my two reserves above. I’d claim that the current draft is not making relay first-class, on the contrary.
Line 179. “a join point” joint? Line 231. “The application is solely responsible for the content of the object payload.” What is the application? It is a bit confusing. It has not been defined. Line 269 .“within a single MOQT scope, subscribing to the same full track name would result in the subscriber receiving the data for the same track.” I am not sure to understand this sentence. Is a single MOQT scope a scope with only one server or do you mean “within a MOQT scope”? the two “same” adjectives are confusing too. Line 273. It would be better to stick to “servers” or to “connection URIs” to refer to the elements of the scope. Line 339. “The portion MUST NOT contain a non-empty portion.” Is it a double negation to say that the ‘authority’ MUST contain an empty ‘host’ portion? Line 357. This sentence may require a MUST. Line 359. “for exchanging …” and following sentences are not related to session initialization. They are rather remarks that would be a fit with the draft Section 4. +1 to the TODO remarks on line 381. This should be in Section 4. Line 654. “it allows the peers…” The term “peer” is used 7 times. It is supposed to be an “endpoint” (as defined Line 173), unless peer and endpoint have different meaning (in which case peer must be defined) Line 693. “A relay that reads from a stream and writes to stream in order will introduce head-of-line blocking.” I don’t understand this claim.
Thanks for the feedback. I'm going to mark this as Editorial, but there are a number of points here. If you believe any of them are not editorial (ie: "Line 357. This sentence may require a MUST."), please split into a separate issue.
Will assign to Mo.
NAME Please go through these and fix any that still apply.
I think the intent of the draft was clear but this makes it explicit not to open a uni stream before setup exchange is done.
It's unclear what messages are allowed to be sent or received during the SETUP handshake. Here's my intuition: Until receiving the SETUP, the client: MUST NOT send messages MUST buffer any received messages. Until receiving the SETUP, the server: MUST NOT send messages. MUST NOT receive messages. The client needs to buffer messages because the server is unaware of when the client receives the SETUP. There's no equivalent to HANDSHAKE_DONE, and adding something like that would add an RTT anyway.
A potential optimization exists if the message encoding if the same for all supported versions (invariants). For example, if the client only advertises support for versions 1,2,3 and those versions share the same SUBSCRIBE encoding and meaning. This seems unlikely, given a separate version was created in the first place, and seems very brittle. If this was the case, then the client could process any invariant messages immediately and buffer the others. However, the client still couldn't send messages unless the server buffered any received messages.
The most flexible optimization would be the one where you could encode the SUBSCRIBE_REQUEST for every version you offer as a field in SETUP parameters. TLS does not do exactly that, but there are some things in ClinetHello that are only applicable for certain versions.
I have written what I think is a slightly more robust Security Consideration for HPACK. This covers: the attack in the general sense, how the attack might apply in HPACK and HTTP, particular areas of concern, how HPACK inherently mitigates these attacks, what environments might need additional mitigation, and some suggested mitigation strategies. Mitigation strategies that I have described are: actor-based isolation (a generalized application of the origin isolation principle) destroy values on failed guesses (thanks here to Adam Barth for the idea), either probabilistically, or based on a count, with a recommendation that shorter values be made harder to guess specific protection for "special" header fields There are a few formatting changes in the first commit, sorry.
Addresses Ea of Bob comments that the "no guidance is provided" sounds like it is in conflict with the rest of the section that includes some normative recommendations. The intent of this text was to highlight there is no (or at least very little) about how servers are supposed to combine priority parameters with the million other things that they have to worry about. This change shuffles the sentences around to try and make the original intent clearer.
This is much better than the original. Thank you for the PR.
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:
We left open pending some explicit text about the double GOAWAY graceful shutdown. Here is some proposed text that we can iterate on. One difference from what we discussed is the first GOAWAY has last-stream-id of 2^31 - 1. The calculation based on MAXCONCURRENTSTREAMS isn't really needed and just opens up implementations to bugs.
I first brought this up in URL but I wanted to open an issue to track this as I believe this is a design flaw with HTTP/2 as it is today. Consider an HTTP/1.1 connection to a proxy that speaks HTTP/2 to the server. If the server needs to shut down, it will send a GOAWAY acknowledging the last request it processed. However, there is a race condition where a request could be in flight or queued. When the server eventually sees the delayed requests, it will not process it and the proxy will eventually return an error (most likey 5xx) to the client. Requiring proxies to buffer the request in order to replay for this case is not feasible. One solution is to have the server send an ALTSVC frame, but this is not ideal as it implies each server must keep track of a list of alternatives. It may not make sense for the origin server itself to maintain this (potentially quickly changing) list. Another solution is to allow acknowledging unreceived streams in the GOAWAY. For instance, the server could acknowledge last-stream-id plus SETTINGSMAXCONCURRENTSTREAMS. This might work in practice, but seems hacky. Another (and in my view best) solution would be to introduce a two phase shutdown mechanism. Some strawman language: "If a server needs to shut down for maintenance, the server SHOULD immediately send a DRAINING frame on all its client HTTP/2 connections to indicate that it will soon shut down. This allows the client to stop issuing new requests and avoids unnecessary retries. After a reasonable amount of time, the server SHOULD send a GOAWAY with status NOERROR on all its connections and then close the connection. Clients MAY may open new connections to the server after receiving a DRAINING frame."
I have added some text in URL that covers some of this. I'm going to leave this one open, because I don't think that this is completely done yet. We need to discuss whether we want to be more explicit about this particular use case.
Discussed in NYC; double GOAWAY sounds good.
This is almost a straight revert of the various GOAWAY -> GTFO changes. It seems like this is the popular move as per the discussion on the httpbis mailing list. Arguments for the revert: GOAWAY is self-descriptive and serves it purpose well. Editorial changes that don't clearly improve the spec should be discouraged so we can reach a stable spec sooner (granted this change doesn't affect the wire at all, but documentation churn counts too). GTFO is crass and doesn't belong in internet standards. GTFO, if it really stands for "General Termination of Future Operations," has a surprising definition and may produce confusion. We should strive for absolute clarity above all else in editorial changes.
Boo! You guys are no fun.
goaway is just as bad as gtfo for the same reasons as the argument against gtfo... just called it disconnectclient or endcommunication if you're going to be a grumplestiltskin.
QUENCH may be a better, more descriptive word that has been used before in RFC's (for TCP Source Quench messages)
I think we should call it BIKESHED. , Sean McElroy EMAIL:
Here we go.. useless HN circle jerk.
:cat2:
How about STFU?
Boo!
:-1:
This commit should be reverted. It's time we stop behaving like oversensitive automatons and display the beautiful human quality that is a sense of humor every once in a while.
^ this
^ that
how about something like PLZSTOP? it's slightly humorous, but it actually reflects what is wanted (if I understood the spec correctly)
GOAWAY is clearer for non-native English speakers, easier to pronounce, and more professionally appropriate than the common connotational definition of GTFO. There are times and places for pushing the boundaries of professional speech, but the HTTP2 spec isn't one of them.
At least the pendulum didn't swing the other way NICETALKINGTOYOU
This revert is for the express purpose of stopping endless bikeshedding. We shouldn't encourage trivial changes to frame names. If the name is good enough, it should stay. I'm all for fun and games, but clarity and concision (as well as spec stability) come first.
For those that prefer GTFO, please explain how it is clearer than GOAWAY (please consider an international audience too).
so mean spirited, this change.
Could always name it SHUTDOWN (yay SCTP) , Adrian Cole EMAIL:
"International audience" here. I'm Armenian, English isn't my native language, not even my 2nd language. GTFO to me is more meaningful and more concise than GOAWAY, or any other option mentioned in the comments. GTFO to me doesn't produce any confusion and its actual definition of "General Termination of Future Operations" is actually nice, smart, and descriptive rather than "surprising" in any negative sense. It also formally de-crasses the word. Of course you can tell me that I'm just a single example, but then again you can tell that to any amount of people. Pretty much the only valid argument out of the posted ones is that GTFO is crass (see I didn't know what "crass" meant before reading this). Everything else about descriptiveness and understandability by "international audience" are in my opinion totally irrelevant and unfair.
NAME thanks for the internationalization datapoint and on-topic discussion! Can you elaborate on how GOAWAY is not clear, and how GTFO is clearer? To me, the main argument is that GTFO is not meaningfully more clear than GOAWAY.
If folks have serious contributions to make, they should be on the mailing list, not here, as per URL Now I get to try out NAME
NAME START
NAME Neither option is appropriate or clear... they're both childish choices and neither are semantically appropriate. I've seen some much better options in this thread. if this change were actually about caring about professionalism, clarity of meaning, or necessity, the innumerable amount of better choices (SHUTDOWN, ENDCONNECTION, QUENCH, etc...) should have been used over GOAWAY or GTFO... But its not.. this is about personal preference. this change made nothing better, it made nothing worse. In my opinion, for that reason, it should be reverted.
FWIW, and for lack of anyone else talking about a pro of GTFO. When at the working group, a lot of thick topics were discussed at length and everyone there seemed 100% dedicated to having the best spec there is.
GTFO, as a word, is harmless to implementation for reasons including the opcode is the same. IOTW, the binary representation is the same. There's no technical reason why it matters. I am one of the implementors of this specification. When the change was suggested towards GTFO, I felt motivated I mean the audience of this spec are implementors, some of which may be uptight about crassness others less so. If you look at github (ps this is on github) there's ample evidence that implementors are motivated by words that aren't boring. For example, there's a popular package manager called "fpm". Guess what that stands for? I'm not saying go back and re-word everything to be fresh, rather have patience with those who are literally implementing this, in open source, and are ok with the choice. Expect many more implementors to arise from github, a place relatively unburdened by crass-ness or location.
NAME I'll split the answer to 2 sections. AWAY vs. Out -- AWAY implies a certain longish physical distance, whereas Out seems to imply just "out". AWAY vs "General Termination of Future Operations" -- obviously the second is much more clear and descriptive.
GTFO would be my vote. No future operations, full connection termination, it describes the action best.
NAME if you feel strongly, mail on this thread as not everyone there are on github to see your pov URL
NAME - will do, thanks. I need to dig my W3C mailing list info; haven't used it in years. Cheers!
From the W3C mailing list: Thanks, NAME :) Cheers!
All made points aside, I couldn't find a very important one; to me actually being the most important. If you think about what "Get Out!" could also mean (the offensive TF part is actually interchangable...), it becomes even more confusing. An expression of disbelief is surely the very last thing this acronym should imply. But it did to me; even as a non-native speaker (German). "General Termination of Future Operations" is, also in my eyes, a made-up term to fit the joke.
It is more fitting than GOAWAY, but once you have read GTFO your mind is sort of made up, since you spelled GTFO in full in your head, as soon as reading the acronym. My suggestion on this one is: Simply get rid of "General" / "G" and add "of" to the acronym! TOFO still has a nice ring to it, is quick and easy to pronounce and "Termination Of Future Operations" would be sufficiant descriptive. regards (yes, that's my real lastname :P ) On Jan 29, 2014 8:31 AM, "Eugene Ciurana" EMAIL wrote:
Addresses
NAME NAME PTAL
RFC6265bis mentions the cookie length constraints in relation to parsing the Set-Cookie headers but doesn't in the more general Storage Model section. From chatting with NAME about this, it'd be desirable to have these constraints be listed in that section as well. Since there are other ways cookies can come in to the cookie store (Ex: Cookie Store API), having these constraints be enforced when adding cookies from any source to the cookie store would better ensure cookie format consistency.
IANA Consideration to register JWT Claim names and media types URL
Propose and as media types
same for jwt types?
Note that JWT values are actually media types URL which is a little odd sometimes but that's how it is - so you don't need anything different in terms of registration for a jwt type b/c it is a media type. And the JWT BCP does recommend explicit typing using URL for better or worse, which would suggest that be registered. But it and would also probably have utility in places like HTTP and headers so would make sense to register both. There are some media-type-registration requests in SD-JWT that could be borrowed from URL or you can look at entries in the registry URL
Text taken from existing statement in Location.
Ah, makes sense, of course. Thanks NAME
NAME - can you check again?
2616's definition of said: 7231 dropped that, thanks to . We should probably restore it, given it can cause misconceptions like .
NAME do you remember why you removed that text?
Yes, the requirement moved into the general section on all URI-references. That is not a special case. And, no, its presence or absence would have made no difference to the referenced bug report. If either one of them had correctly followed the spec, they would have been fine. Instead, npm sent a special value without a special scheme, and Cloudflare marked that for rate limiting based on incorrect assumptions of bad behavior rather than the actual specification. Excuses happen.
NAME - I wasn't talking about the actual bug; I was talking about NAME -- someone who has implemented a very good HTTP engine -- misinterpreting the spec in that comment because it was reader-unfriendly. That should concern us all, because if he and implementers like him misread the spec so easily, it will be mis-implemented. And, the fault here is definitely not with him; it's with the spec. It's not reasonable to expect people to hold the entire specification series in their heads as they interpret each phrase and requirement, especially considering that in most renderings it's not cross-referenced (and even where the renderings support it, we don't cross-reference consistently). I understand that we need to be terse sometimes, and that it's reasonable to have expectations of our readers. But, when we use arcane terms and overload widely-used terms (even if incorrectly) to the point where the only people who understand the spec on a good day are you, Julian and I (and on a bad day, just you), it doesn't do anyone any good.
I think there are two ways to resolve this: 1) Link back to the URI section in each case where it's used, and adjust language to make it clear that there are requirements there 2) Add language in each case where a URI is a protocol element, and state how it's resolved I think I prefer (2), because is vague about how it specifies this: Since Section 2 is about HTTP URIs in general -- not just as protocol elements -- it's not clear what the scope of this statement is.
It's also not a requirement, which doesn't seem good for interoperability.
Waiting for to land.
Places this will affect: Location Content-Location Referer
I still don't see any reason for this change. The spec already states how to do relative resolution in general, which it must do because it applies to all header fields (not just the ones we define). Saying it again on every occurrence of a relative or partial URI is just adding length to the spec.
We already said it for Location, and the amount of added text is minimal.
... and it's also said explicitly in . It may be obvious to you, but it's pretty clearly not to many implementers.
The only confusion has been our change in 7231 of the Location field to allow relative references. I am not aware of anyone ever being confused about the target URI being the base URI for all header fields, but I can live with more text if it says that consistently. To reiterate, this entire issue is based on a misreading of a completely mistaken assumption about the field content of "Referer: install" being flagged as a potential security issue by Cloudflare because it is unusual, not because Cloudflare somehow might not have been aware that the syntax is allowed by the spec as a relative reference. It's defense by spec-lawyering. These changes would not have changed Cloudflare's algorithm and would not have convinced npm to choose a more common default. Actually talking to their own CDN before deploying an HTTP change would have helped. Testing would have prevented it entirely.
NAME is right that the prose needs to be in sync with the actual ABNF. Will update the PR later today with a proposal.
All I did in that sentence is expand BDP. If you would like to change its content, please file a different PR.
Thanks Sean Turner: Questions: s3.2: This section includes the following: This document applies to proposals for congestion control algorithms that seek Experimental or Standards Track status. So ... if I get an Informational RFC I can do whatever I want? Wondering why Informational isn't listed here. s5.3.2: The 1st para invokes some like requirements language like "ought to" and "it would be helpful". Any reason there isn't BCP 1 4language used in this para? s6: Is "MUST find" another way of saying there must be coommunity consensus? If so maybe: OLD: Unless a proposed congestion control specification explicitly forbids use on the public Internet, the community MUST find that it meets the criteria in these scenarios for the proposed congestion control algorithm to progress. NEW: Unless a proposed congestion control specification explicitly forbids use on the public Internet, the community MUST reach consensus that it meets the criteria in these scenarios for the proposed congestion control algorithm to progress. Nits: s5.1.3, 2nd para: expand BDP. s7.9, lastt para: s/(see Section 4./(see Section 4).
I think this could be read as endorsing the change to BBR - but that isn't the case, maybe: /fixed/addressed/ or something similar, to show the intent.