jiebi/CodeConvo huggingface dataset:
Code change:
be safely retried using a new connection. Activity on streams numbered lower or equal to the last stream <del> identifier might still complete successfully.  The sender of a GTFO frame might gracefully shut down a connection by sending a GTFO </del> <ins> identifier might still complete successfully.  The sender of a GOAWAY frame might gracefully shut down a connection by sending a GOAWAY </ins> frame, maintaining the connection in an open state until all in- progress streams complete.

Related discussion:
text: 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.
Code change:
be safely retried using a new connection. Activity on streams numbered lower or equal to the last stream <del> identifier might still complete successfully.  The sender of a GTFO frame might gracefully shut down a connection by sending a GTFO </del> <ins> identifier might still complete successfully.  The sender of a GOAWAY frame might gracefully shut down a connection by sending a GOAWAY </ins> frame, maintaining the connection in an open state until all in- progress streams complete.

Related discussion:
text: 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.
Code change:
be safely retried using a new connection. Activity on streams numbered lower or equal to the last stream <del> identifier might still complete successfully.  The sender of a GTFO frame might gracefully shut down a connection by sending a GTFO </del> <ins> identifier might still complete successfully.  The sender of a GOAWAY frame might gracefully shut down a connection by sending a GOAWAY </ins> frame, maintaining the connection in an open state until all in- progress streams complete.

Related discussion:
text: 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:
Code change:
3.7. <ins> An attacker creates a message to all employees of a company, claiming to be from a trusted technology provider investigating a suspected security breach.  They ask employees to send them the QR code typically used to transfer a session.  The employee, eager to assist, initiates the process to transfer a session.  They authenticate and obtain a QR code and then send the QR code to the attacker.  The attacker scans the QR code with their mobile phone and access the users data and resources. </ins> 3.8. In all of the attack scenarios listed above, a user is tricked or

Related discussion:
text: Added examples to illustrate cases when the authenticated flow is not an effective as a mitigation.
Code change:
based on the resumption offset from a single offset retrieving (offset-retrieving) request. <del> The response SHOULD include "Cache-Control: no-store" header to prevent HTTP caching. </del> <ins> In order to prevent HTTP caching, the response SHOULD include a "Cache-Control" header field with the value "no-store". </ins> If the server does not consider the upload resource to be active, it <del> MUST respond with "404 (Not Found)" status code. </del> <ins> MUST respond with a "404 (Not Found)" status code. </ins> The resumption offset can be less than or equal to the number of bytes the client has already sent.  The client MAY reject an offset

Related discussion:
text: See URL Lots of boring editorial tweaks to ensure better consistency both within the document and other HTTP specs.
One related question: The style guide also mentions that "examples should be in HTTP/1.1 format unless they are specific to another version of the protocol", but the draft uses a notation that resembles HTTP/2. Should we change the example messages to HTTP/1.1?
Thank you very for this tedious work! I only spotted a few minor typos.
Code change:
Object Send Order: An integer indicating the object send order send-order or priority ordering-by-priorities value. <ins> Object Payload Length: The length of the following Object Payload. The sender MAY encode a zero in this field, which means that the message continues to the end of the stream. </ins> Object Payload: An opaque payload intended for the consumer and SHOULD NOT be processed by a relay.

Related discussion:
text: and . if messages must be known, explicit message lengths are redundanct except for OBJECT and messages with parameters. This also eliminates a whole class of potential errors where the message length does not match the actual parsing of the message. Not checking this -- and not have any message type be potentially zero-length -- greatly simplifies the parser.
And trying to use messages without negotiating an extension/version just won't work for MoQ. We're designing a protocol explicitly for relays so you do need relay cooperation, or at the very least some information on how to forward unknown messages.
Also I love that you're using "parameter count" instead of "parameter size (bytes)". It makes it much easier to build a streaming encoder/decoder without allocating temporary buffers.
I thought we agreed to allow extensibility by allowing new message types to be created.
Like to see us agree on a extensibility strategy before deciding what to do on this. We also need to decide if messages can have optional fields
We have version negotiation, and presumably we'll have extension negotiation too. What's the use-case for adding new messages without negotiating them? The problem is that we can't relay unknown messages, so all it takes is a single uncooperative relay on the chain to shallow them. I think we need explicit negotiation as a result.
If we have extension negotiation, I agree. But if our extension negotiation mechanism relies on not getting an error on unknown messages .... PR is wrong place to discuss this but I think what I would like to see is a good way to do extension negotiation, and then like you have here, error on any message that is not part of a negotiated extension. I think I would lean that way if we had an extension negotiation mechanism. Note this is the opposite direction of HTTP which is often our model for things. HTTP just skips past unknown headers.
Fail, or pass over?
IMO fail. We have version negotiation and should add extension negotiation so it should never happen. The problem with ignoring messages is that MoqTransport is designed for relays. If an intermediate relay doesn't support a message, it then gets silently dropped. At the very least we need enough information on where to forward unknown messages.
Code change:
Object Send Order: An integer indicating the object send order send-order or priority ordering-by-priorities value. <ins> Object Payload Length: The length of the following Object Payload. The sender MAY encode a zero in this field, which means that the message continues to the end of the stream. </ins> Object Payload: An opaque payload intended for the consumer and SHOULD NOT be processed by a relay.

Related discussion:
text: If it's going to Fail, then most Message types don't need a length field at all (OBJECT and ANNOUNCE_OK would be the exceptions)
Individual Comment: Is there any reasonable action a relay can take on an unknown message, besides discarding it? See how HTTP recently added a "Capsule" concept which is an envelop with a default relay action of "forward", which allows for end-to-end extensions without upgrading all intermediaries. Given that MoQ handles forwarding on a per-track level, I think there probably isn't any way to generically forward a message that isn't associated with an active subscription. That said, it makes me wonder if we want to add a capsule-like extension message, or does the existing OBJECT definition give enough flexibility?
Yeah exactly. It's impossible to know the intended destination of an unknown message with the current ANNOUNCE/SUBSCRIBE mechanisms. I'm using the (as the track namespace) and instead of . This actually does let you forward unknown messages from publisher -> subscribers and subscribers -> publisher since each session is associated with only a single track namespace. Session pooling is always the issue...
I think we need extensibility. We want the protocol to be extensible so a given server might support extension A and C and another server supports extension A and B. It is very hard to do that using just a version number.
Rereading all this - II think this whole issue just need to be uplevel to what is the extensibility strategy then this detailed part of it will be easy.
There was support for not requiring a length and failing on unknown message types at the Interim, so the intent is to land PR after review.
LG. The agreement at the interim was to follow up with separate frame types for object with and without length, but do that in a separate PR.I love it. It also means you can implement streaming encoders. Prefixing each message with the length required a temporary buffer or 2nd pass to compute the length.LGTM
Code change:
5. <del> Digest algorithm values are used to indicate a specific digest computation.  For some algorithms, one or more parameters can be supplied. </del> <ins> Digest-algorithm values are used to indicate a specific digest computation.  For some digest-algorithms, one or more parameters can be supplied. </ins> The BNF for "parameter" is defined in Section 5.4.1.4 of SEMANTICS. All digest-algorithm values are case-insensitive.

Related discussion:
text: is preliminary to Consistently use instead of . In case we need to further focus on the value, we can say or . Looking at "content-coding" vs "content coding" in URL I think that this choice makes the document more readable.
Code change:
Fields (fields) that are located within a <del> are are referred to as "trailer fields" (or just "trailers", </del> <ins> are referred to as "trailer fields" (or just "trailers", </ins> colloquially).  Trailer fields can be useful for supplying message integrity checks, digital signatures, delivery metrics, or post- processing status information.

Related discussion:
text: Hi! I post here my combined comments for draft-ietf-httpbis-semantics-16, as I don't think they deserve one issue each :) I hope that's fine. My comments range from minor to very minor to nit, and are mostly editorials and clarifications. As this can possibly be me, I'll leave it up to you to decide if they can be useful to improve readability, or not. Thanks for your work! Francesca [x] 1. ----- Additional (social) requirements are placed on implementations, FP: I am not sure I understand the meaning behind the term "social requirement". Editors: URL (URL) [x] 2. ----- When a major version of HTTP does not define any minor versions, the minor version "0" is implied and is used when referring to that protocol within a protocol element that requires sending a minor version. FP: I had a hard time parsing this sentence (starting at "and is used..."), maybe breaking it up with commas would be enough. Especially the two "that" are unclear to me. Editors: URL (URL) [x] 3. ----- RFC 3986, which allows for an empty path to be used in references, FP: very minor, I'd prefer "in URI references". Editors: URL, change applied in URL [x] 4. ----- The process for determining that access is defined by the URI scheme and often uses data within the URI components, such as the authority component when the generic syntax is used. However, authoritative FP: I had to read the sentence above 3 times before realizing that the subject of "is defined" is not "access", but "The process", and understanding it. Editors: URL, change applied in URL [x] 5. ----- A client MAY discard or truncate received field lines that are larger FP: I assume and It might have been good to clarify that "truncate" a field lines is equivalent to dropping a member of the list of values. Editors: URL [x] 6. ----- Note that double-quote delimiters are almost always used with the quoted-string production; using a different syntax inside double- FP: I am not sure I understand "quoted-string production" Editors: added missing fwd reference - URL [x] 7.
Code change:
Fields (fields) that are located within a <del> are are referred to as "trailer fields" (or just "trailers", </del> <ins> are referred to as "trailer fields" (or just "trailers", </ins> colloquially).  Trailer fields can be useful for supplying message integrity checks, digital signatures, delivery metrics, or post- processing status information.

Related discussion:
text: ----- content, it is often desirable for the sender to supply, or the recipient to determine, an identifier for a resource corresponding to that representation. FP: It might have been good here to give a hint or example on why such identifiers could be desirable. Editors: URL (URL) [x] 8. ----- Fields (Section 5) that are located within a trailer section are are referred to as "trailer fields" (or just "trailers", FP: s/are are/are Editors: URL [x] 9. ----- All responses, regardless of the status code (including interim responses) can be sent at any time after a request is received, even if the request is not yet complete. A response can complete before FP: I think at this point in the text there is no definition of what qualifies a request or response being "complete". Editors: actually, the definition is earlier in the text; added a reference anyway: URL [x] 10. ----- An intermediary MAY combine an ordered subsequence of Via header field list members into a single member if the entries have identical received-protocol values. For example, FP: Is there any requirement on the intermediary to be able to collapse the ordered sequence into a single member (such as storing and being able to expand this information)? Might want to expand a little. Editors: Declined because there is no requirement to do so. We already explain that one might want to do so for information hiding of intermediaries within a private network (URL and URL) [x] 11. ----- This definition of safe methods does not prevent an implementation from including behavior that is potentially harmful, that is not entirely read-only, or that causes side effects while invoking a safe method. What is important, however, is that the client did not request that additional behavior and cannot be held accountable for it. For example, most servers append request information to access FP: I might be missing the motivation for it, but this paragraph seems strange to me. Why is it important that the client cannot be held accountable for it? The concern I have is that the text seems to be saying "safe is essentially read only/not harmful/..., but not really". (And same for idempotent) Editors: URL [x] 12. ----- referring to making a GET request.
Code change:
Fields (fields) that are located within a <del> are are referred to as "trailer fields" (or just "trailers", </del> <ins> are referred to as "trailer fields" (or just "trailers", </ins> colloquially).  Trailer fields can be useful for supplying message integrity checks, digital signatures, delivery metrics, or post- processing status information.

Related discussion:
text: A successful response reflects the quality of "sameness" identified by the target URI. In turn, FP: I am confused by this terminology: quality of "sameness". Editors: URL [x] FP: The text could add something for when it is acceptable or expected to make sense (so why this is a SHOULD). Editors: Because the protocol has historically preferred to separate semantics from parsing requirements so that the semantics can be extended over time without breaking parsers. It is a SHOULD NOT for GET because the original protocol did not define a meaning for such message content and some implementations took advantage of that leniency to implement and deploy features that work among consenting implementations but are non-interoperable with intermediaries and other implementations. Hence, it's a bad idea, but the protocol does not prevent it from happening. See for why this is impossible to change. [x] 14. ----- A server SHOULD NOT use the From header field for access control or authentication. FP: Same as the previous comment, when is it acceptable to use the From header field for access control or authentication? Editors: URL [If it is acceptable to the server that does it, then HTTP doesn't care in terms of interop, but it is still a bad idea because the protocol has other mechanisms for doing access control and authentication which are less likely to be leaked by accident (URL)] [x] 15. ----- FP: I don't know if I missed it, and please correct me if I did, but I was hoping to find a sentence stating something of the sort for the header fields: "If not otherwise stated, these fields can be used with any method or response code". Editors: URL [x] 16. ----- FP: Most of the header fields contain examples, which I find helpful. I think it would be good to have examples for all of them (including TE, Trailer). Editors: URL [x] 17. ----- | Accept. Future media types are discouraged from registering | any parameter named "q". FP: I wonder if it would be worth making a not out of it in the media type registry (so that it's easily remembered by experts) Editors: URL [x] 18. ----- Note that an If-None-Match header field with a list value containing "\" and other values (including other instances of "\") is unlikely to be interoperable.
Code change:
Fields (fields) that are located within a <del> are are referred to as "trailer fields" (or just "trailers", </del> <ins> are referred to as "trailer fields" (or just "trailers", </ins> colloquially).  Trailer fields can be useful for supplying message integrity checks, digital signatures, delivery metrics, or post- processing status information.

Related discussion:
text: FP: what does it mean for a header field specific value to be not-interoperable? I am also not sure how "*" between the list of values would be processed. 2. above does not specify it, only stating: If the field value is a list of entity-tags, the condition is false if one of the listed tags matches the entity-tag of the selected representation. FP: I would possibly interpret this as "search for tags matching the entity tag - ignore all others". Editors: URL and URL [x] 19. ----- senders might send erroneously send multiple values, and both FP: remove one "send". Editors: URL [x] 20. ----- the String data type of [RFC8941]), or a field-specific encoding). FP: remove the first parenthesis. Editors: URL [x] 21. ----- FP: This is more of a check, but I see that all references only point to sections. I hope this will be translated into "x.x.x of RFCthis", is that correct? Editors: URL
You mean in the tables for IANA registrations? That's for brevity; IANA knows how to deal with that.
The media type registry is not owned by "us". I don't think we have the authority to change it.
I will look into this with IANA and the DEs and get back. Just to be clear, the document states "future media types are discouraged..." but what we really mean is "experts should be conservative with assigning ..." , is that accurate? Yes, in theory we'd like to discourage media types to be registering "q", but the practical way to make sure that doesn't happen is to make the DEs react to it if it does.
maybe "...whenreferring to that protocol version..."? NAME ?
Yes, thanks!
I don't think it's restricted to that.
For instance, to provide a bookmark/make something accessable for a subsequent GET... NAME - do you want to add that?
I don't get that question. The spec allows collapsing. It doesn't require it. Could you please clarify your question?
The motivation is that if something is defined as "safe", I can URL do that operation without being held accountable.