jiebi/CodeConvo huggingface dataset:
Code change:
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 <del> its corresponding request is complete.  Likewise, clients are not expected to wait any specific amount of time for a response.  Clients (including intermediaries) might abandon a request if the response is not forthcoming within a reasonable period of time. </del> <ins> its corresponding request is complete (message.framing).  Likewise, clients are not expected to wait any specific amount of time for a response.  Clients (including intermediaries) might abandon a request if the response is not forthcoming within a reasonable period of time. </ins> A client that receives a response while it is still sending the associated request SHOULD continue sending that request, unless it

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:
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 <del> its corresponding request is complete.  Likewise, clients are not expected to wait any specific amount of time for a response.  Clients (including intermediaries) might abandon a request if the response is not forthcoming within a reasonable period of time. </del> <ins> its corresponding request is complete (message.framing).  Likewise, clients are not expected to wait any specific amount of time for a response.  Clients (including intermediaries) might abandon a request if the response is not forthcoming within a reasonable period of time. </ins> A client that receives a response while it is still sending the associated request SHOULD continue sending that request, unless it

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.
Code change:
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 <del> its corresponding request is complete.  Likewise, clients are not expected to wait any specific amount of time for a response.  Clients (including intermediaries) might abandon a request if the response is not forthcoming within a reasonable period of time. </del> <ins> its corresponding request is complete (message.framing).  Likewise, clients are not expected to wait any specific amount of time for a response.  Clients (including intermediaries) might abandon a request if the response is not forthcoming within a reasonable period of time. </ins> A client that receives a response while it is still sending the associated request SHOULD continue sending that request, unless it

Related discussion:
text: For instance, I can always GET a URI (such as for prefetch/preload/indexing) and if the server does do something stupid with that request (such as deleting a resource, or adding something to a shopping basked), it's their problem. Re idempotenty: this makes it possible to repeat a request.
The text states that intermediaries are allowed to collapse "an ordered subsequence of Via header field list members into a single member", and they can only do so "if the entries have identical received-protocol values." So I read 2 rules: the order matter, i.e. if (A,B) collapses to C, (B,A) does not map to C (A,B) must have identical recived-protocol values I was wondering about any additional rules that the intermediaries have to follow in order to collapse the list into one: for example, is it ever expected for the intermediary to remember that this single member was this collapsed ordered sequence? Are they ever requested to un-collapse?
Order matters for the purpose of collapsing. If you have "D, E, F", and E has a different protcol than D or F, you can't collapse. If "A, B" can be collapsed, so can "B, A" (because they have the same protocol) We are not saying that, so there is no expectation that the collapsing can be undone.
Ok, so yes I understand - the idea of this text is to say: "this is the intent, BUT be aware that implementations might do something stupid and not comply with this intent." I guess what I got stuck with was "the client can't be held accountable", as it wasn't clear to me what would it mean for a client to be held accountable, as clients in general are not aware of what's the action on the server their request will result in.
This might require a separate issue. A field value containing more than one list element and including "*" is invalid, and the spec really doesn't say what that means. The intent of saying "interoperable" is (IMHO) to prevent people from assuming the different servers will do the same thing with it. I believe we should clarify that a value like that is invalid, and thust MUST NOT be sent. NAME , NAME ?
That refers to URL - I guess we should cite that? NAME ?
Code change:
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 <del> its corresponding request is complete.  Likewise, clients are not expected to wait any specific amount of time for a response.  Clients (including intermediaries) might abandon a request if the response is not forthcoming within a reasonable period of time. </del> <ins> its corresponding request is complete (message.framing).  Likewise, clients are not expected to wait any specific amount of time for a response.  Clients (including intermediaries) might abandon a request if the response is not forthcoming within a reasonable period of time. </ins> A client that receives a response while it is still sending the associated request SHOULD continue sending that request, unless it

Related discussion:
text: Edit: opened URL
On the other hand, people complain about the spec being too long already. I don't think we should add examples unless they are needed to make things easier to understand.
Ok! (As I said, these are so minor that they are definitely up to you. Same with references and terminology comments)
I believe the simplest possible fix would be to remove "to be used in references", making this: NAME ? Edit: -> URL
I think that we should probably convert this one (and similar) to MUST NOT -- there isn't any situation where we recommend this behaviour, as it has interoperability and security implications.
Not convinced at all. The "SHOULD NOT" requirement is new and was controversial already. There is code out there using GET with body (in controlled environments) which just works.
That's not HTTP; that's a private protocol.
Tell that Google :-) Anyway. This is a normative requierement and we are past WG LC. If you want to change it, this absolutely needs to be confirmed explicitly by the WG (and would deserve a seaparate issue).
Maybe "The process for determining whether access is granted is defined..."? Edit: -> URL
You mean generally, for the fields we define? I don't think that's true; they're defined for the semantics they specify. If a use isn't specified, it might be extended in the future, so we rarely prohibit such a use. Saying that they can be used with any method or status code would imply that they have meaning in each circumstance, and that's often not true.
authentication. This isn't important for interoperability, it's just a bad idea. Maybe 'The From header field is not intended or suitable for use as a means of access control or authentication.'?
FWIW, the requirement is from RFC 7231, and widely accepted (I guess), so I don't think we should change it.
For 4, proposed rewrite:
WRT -- I don't think I'd use the word "widely" in conjunction with this header field. Again, if we use SHOULD NOT, we should explain the qualification.
In the sense that it's an interoperability requirement on a sender (not a recipient), I agree.
"MUST NOT be generated" maybe?
MUST NOT be generated, because recipient behaviour is not interoperable.
Code change:
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 <del> its corresponding request is complete.  Likewise, clients are not expected to wait any specific amount of time for a response.  Clients (including intermediaries) might abandon a request if the response is not forthcoming within a reasonable period of time. </del> <ins> its corresponding request is complete (message.framing).  Likewise, clients are not expected to wait any specific amount of time for a response.  Clients (including intermediaries) might abandon a request if the response is not forthcoming within a reasonable period of time. </ins> A client that receives a response while it is still sending the associated request SHOULD continue sending that request, unless it

Related discussion:
text: URL already say "MUST NOT generate ABNF-invalid messages" in general. So maybe we don't want to repeat BCP14 terms here... -> URL
I've reviewed the most recent commits, think this can be closed now.
Thanks for addressing my comments. I checked the commits and your answers: I can see everything was addressed, either by changes or by answers clarifying what I found confusing, except for: the one which is now issue point 14: giving context around the "SHOULD NOT" for the 'From' header field. Note that I am not asking you to make any change (such as removing the BCP 14 text), but following what BCP 14 defines: it seems important that the reader understands, or at least gets a hint of what these reasons and particular circumstances are, in order to be able to understand the full implications. This is why I think it's important to clarify the context around the SHOULD / SHOULD NOT, and was also my comment for the GET requirement, but I see that that comment has now transformed in a bigger issue the wg needs to find consensus on.
I disagree. You are presuming that we know those particular circumstances, and that is almost always false when SHOULD is being used. When we have a detailed list of conditions, we use "MUST NOT unless ...". The SHOULD is literally saying that the reader needs to take care and understand the risk/benefit for their own context, not that we need to explain to them based on our own imagination. It is fine to suggest additional text to address a specific concern, but I personally think that this one is self-explanatory. If we added a general description about why auth parameters shouldn't be sent in fields that are not expected to be treated as auth parameters by every recipient, such as within a security consideration, then we could reference it here.
I don't think we should know all possible circumstances, but I presume we do have an inkling that implementations going against the RECOMMENDations exist, for whatever reason, right? As a reader, putting myself in a new implementer shoes, I personally would have found it useful to get that hint of what to consider, but if you think that this one is self-explanatory, I won't insist.
Code change:
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 <del> its corresponding request is complete.  Likewise, clients are not expected to wait any specific amount of time for a response.  Clients (including intermediaries) might abandon a request if the response is not forthcoming within a reasonable period of time. </del> <ins> its corresponding request is complete (message.framing).  Likewise, clients are not expected to wait any specific amount of time for a response.  Clients (including intermediaries) might abandon a request if the response is not forthcoming within a reasonable period of time. </ins> A client that receives a response while it is still sending the associated request SHOULD continue sending that request, unless it

Related discussion:
text: The type of sentence I was thinking about would be something like: (Just trying to explain myself here, again, feel free not to take this suggestion if you and the wg don't think it helps the reader)
Okay, I have added URL because I think we should explain it if it isn't obvious to others.
Thank you NAME !
Code change:
cases, as the URI is more likely to be logged than the request content.  If a server creates a temporary resource to represent the results of a QUERY request (e.g., for use in the Location or Content- <del> Location field), the URI of this resource SHOULD NOT expose the original request content in plaintext. </del> <ins> Location field) and the request contains sensitive information that cannot be logged, then the URI of this resource SHOULD be chosen such that it does not include any sensitive portions of the original request content. </ins> 6.

Related discussion:
text: Mostly editorial, but touches normative text.
I'm looking for an additional qualification on the statement, something like: Originally posted by NAME in URL
NAME also suggested a reframing to "SHOULD": Originally posted by NAME in URL (Also, should we rename the "safe-method-w-body" label to "query-method", now that that naming thing is settled. It took me a while to remember the right label.)
I'm not confident that implementers will always know what might be sensitive and probably should not expose any of the payload in the URL. I think the qualifier doesn't reduce the suggestion's practical scope at all, so if it gets us to consensus, let's add it.
I'm less concerned about this ending up in logs than you are, it seems :) For me, the risk that a server log might have sensitive information is already at 100%, which means that log processing needs to include considerable care as far as privacy and security risks go.
Both variants work for me, and IMHO are better than what we have now. Mike, pick one :-)
Query media types could evolve whose syntax allows for specification of elements that the user/user-agent considers "sensitive", and also the server could know from the schema of the underlying data. But really I think a big hammer is needed here: the default should be that servers encode none of the query contents into the resulting user-agents should be able to request that behavior with a request header (e.g., ) But user-agents should also be able to request that the resulting encode as much as possible of the request body so that the user can end up having a URI that can form part of the UI. This should be completely as far as the server is concerned, and will not always be possible due to URI length constraints and/or the difficulty of encoding complex queries in URI local-parts and q-params.
I believe that should be completely up to the server.
I'm inclined to agree with Julian here. From the client's perspective, the server is a monolith -- in the course of handling the request, the server necessarily sees the contents and the data (multi-party compute schemes notwithstanding) and the client trusts it to do so according to whatever privacy policy exists. It's the server operator's issue whether they wish to keep certain information out of their logs in order to reduce how tightly access to their logs must be managed.
Code change:
cases, as the URI is more likely to be logged than the request content.  If a server creates a temporary resource to represent the results of a QUERY request (e.g., for use in the Location or Content- <del> Location field), the URI of this resource SHOULD NOT expose the original request content in plaintext. </del> <ins> Location field) and the request contains sensitive information that cannot be logged, then the URI of this resource SHOULD be chosen such that it does not include any sensitive portions of the original request content. </ins> 6.

Related discussion:
text: Plus, it's implementation guidance at this point, not protocol conformance. We point out the concern and let people in the real world figure out how they navigate it.
An optional header by which the client can request a URI that encodes the query (which may not be feasible, but often will be) vs. not, seems like a good idea to me -- the server doesn't have to grant the client's wish, but having this request header specified will result in better usability. (To go with this an optional response header by which to indicate which option the server went with would be nice.)
This is all so conditional that I wonder whether it even needs a SHOULD (NOT). Would it be enough to say instead. The other options are fine.
Code change:
prioritize streams (priority-congestion) based on the send order/ priority. <ins> A sender SHOULD begin sending incomplete objects when available to avoid incurring additional latency. </ins> A relay that reads from a stream and writes to stream in order will introduce head-of-line blocking.  Packet loss will cause stream data to be buffered in the QUIC library, awaiting in order delivery, which

Related discussion:
text: Also, can someone explain what the following paragraph is saying, because I'm having a difficult time parsing it.
The next paragraph is trying to say that if you receive HoL blocked stream data at a relay you should try to forward what you have. The goal is to mitigate accumulating latency at every relay hop. I think this makes sense in two cases: You receive data that you know to be within an object you have already seen the header for. Eg: the object length is 100 and you miss bytes 0-49 but get 50-99, you can forward 50-99, as long as your QUIC library supports out of order reads and writes to a stream (not many presently do). This also applies when the object has no length and occupies the entire stream. You are missing some object data for object N on a stream, but you receive the header for object N + 1. This is (potentially) less problematic since the relay might be able to open a new stream to forward it, so out-of-order stream write APIs are not required. In any case, the text probably needs clarification, and perhaps moving from SHOULD (but we know you won't) to MAY is warranted?
Should we mention that a relay should start sending object as soon as the object can be identified (after the header)? Since the draft points out latency as a big deal, it seems this is a must have if we want to cover ULL cases
+1.
It used to be in but was removed. The text was pretty simple: I think and the agreement was to put it into some non-existent latency section.
+1 We should add a recommendation text for Relays to address the request from NAME
sooner is better I do think this might be interpreted by some people in an over zealous sort of way ( like turning off nagle type things ). I do wonder about just using MAY. But happy either way. SHOULD and MAY mean the same thing.