jiebi/CodeConvo huggingface dataset:
Code change:
robustness (see request.smuggling). HTTP does not place a predefined limit on the length of a request- <del> line, as described in Semantics-conformance.  A server that receives a method longer than any that it implements SHOULD respond with a </del> <ins> line, as described in Semantics.  A server that receives a method longer than any that it implements SHOULD respond with a </ins> status code.  A server that receives a request-target longer than any URI it wishes to parse MUST respond with a

Related discussion:
text: ... components, depending on the form of request-target, and when authority might be empty. This is an alternative to
In determining the request target, the following text is included after failing to find an authority in configuration, the authority form target, or the Host header: This is a security risk because it means that servers might not agree with clients about the identity of the resource that the request is directed to. This is especially bad as a TLS certificate is good for every port and often good for multiple names, which can mean a fairly large scope over which an attacker can exploit this confusion. The origin form description doesn't use 2119 language, it says "A Host header field is also sent", citing . And that section is a bit weaselly in that regard, using a "URL". If this were a "MUST ... unless" in -semantics, this problem would not exist (at least in theory). Just to confuse things, the absolute-form says , which might be read to imply that Host truly is mandatory: The asterisk-form is the only other option that naturally lacks an authority, and that says nothing, so that might be fixed up similarly.
Keep in mind that the first text is what to do when receiving a message without Host or absolute-form, whereas the other texts are requirements on generation. Yes, it is a security risk to not send Host, and I assume it would be one to provide service for an https resource without verifying that the client's request indicates one of the server's host (somehow). So, PR welcome, but the final text still needs to accept non-TLS HTTP/1.0 requests without a Host (for ass-backwards reasons).
BTW, the reason it says SHOULD here instead of MUST is because this requirement about the ordering of fields in the header section, not about whether or not Host needs to be sent.
OK, that's good. It's not a genuine problem, we just need to be clearer about generation requirements (and we might be able to carefully condition the inclusion of a default).
better again
Code change:
interactive media may have requirements that are significantly less than "ultra-low latency".  Within this document, we are also using <del> Ull-50 (less than 50 ms) </del> <ins> near real-time (less than 50 ms) </ins> Ull-200 (less than 200 ms) Perhaps obviously, these last two latency bands are the shortened

Related discussion:
text: I propose defining latencies less than 50 ms as near real-time latencies. These latencies can be used by musicians to play together in sync. And I guess the human ear or eye would mostly not notice any delay below 50 ms. Might be worth doing a bit of research around the topic to refine the ranges though. For instance, in this paper (URL) they conclude: In another source (URL) the following is defined: 150ms target performance 13ms > lower detectable limit
< 200 ms - comfortable latencies for conversation.
Apologies for not looking at this earlier, I've had to prioritise other work recently. Given that our draft and these values are an extension of , could you please also include the references and elaboration like you have in the PR as I think it will help quell any further bikeshedding on the subject.
The MOPS document now mentions near-realtime latencies (see URL), but does not define the exact values. Likely this PR still makes sense, but now as an attempt to define those type of latencies.
Code change:
A recipient MUST be able to parse and decode the chunked transfer coding. <del> Note that HTTP/1.1 does not define any means to limit the size of a chunked response such that an intermediary can be assured of buffering the entire response. </del> <ins> HTTP/1.1 does not define any means to limit the size of a chunked response such that an intermediary can be assured of buffering the entire response.  Additionally, very large chunk sizes may cause overflows or loss of precision if their values are not represented accurately in a receiving implementation.  Therefore, recipients MUST anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows or precision loss due to integer representation. </ins> The chunked encoding does not define any parameters.  Their presence SHOULD be treated as an error.

Related discussion:
text: Note that if we say it has serious security hazards and we don't mention that in Security Considerations, someone might complain.
PTAL
The text says I'd want to add: "Implementations must be careful about accurately parsing large values or rejecting the messages, as failure to accurately represent the advertised value due to overflows or loss of precision may have serious security consequences." I think it is important to remind, because implementations seem to have progressively shifted towards 64 bit repressentations since 7230, 32-bit ones are still much present, and the risk of desynchronization by advertising more than 4GB is high. By the way, some languages do no provide more than 52 bits of accuracy because they use floats to represent any number... The risk remains low (1 injected byte every 4 PB) but its worth asking to be careful.
Tweaked proposal:
WFM, but I'm still a bit concerned by the fact that we don't say what the receiver should do here, and it doesn't decide to receive too large a chunk :-/ Should we explicitly mention "a recipient must reject the message as invalid if it cannot accurately represent a received chunk size ?"
I think if we say something about that, we should align it with the language for Content-Length:
OK, but then conversion overflows is not the only issue (storing in a float or double is a huge problem, and nowadays sometimes developers don't know, they store it into a "number"). Probably that we should use the same wording for both and slightly adjust the end to say . We can hardly do more but this needs to be said. Using a float with 24-bit mantissa to represent a content-length is already a problem, but in a chunk, 48 MB are enough to miss 3 bytes and desynchronize on a final chunk!
Code change:
requirements in combining.byte.ranges. When combining the new response with one or more stored responses, a <del> cache MUST: </del> <ins> cache MUST use the header fields provided in the new response, aside from </ins> <del> delete any header fields in the stored response with warn-code 1xx (see header.warning); retain any header fields in the stored response with warn-code 2xx; and, use other header fields provided in the new response, aside from , to replace all instances of the corresponding header fields in the stored response. </del> <ins> , to replace all instances of the corresponding header fields in the stored response. </ins> 4.

Related discussion:
text: I'll have to update extract-header-URL so that it can generate entries with status "obsoleted".
NAME Go ahead and merge after you update extract-header-URL
Isn't implemented, generated, used or surfaced to users; can we deprecate?
Proposal: Replace 5.5 Warning with a section noting that the Warning header is deprecated, and should be ignored. Remove all requirements to generate Remove Warning-specific requirements in 3.3 Combining Partial Content Remove Warning-specific requirements in 4.3.4 Freshening Stored Responses upon Validation Remove Warning-specific requirements in 4.3.5 Freshening Responses via HEAD
+1, with big notes in the Changes section.
Just curious if anyone has any background, what would be a good alternative to the Warning header for cache limit warnings?
This isn't a good place for general discussion. You might want to ask the mailing list, though I am not aware of any cache limit warnings within HTTP because they are only relevant to the cache admin (who typically has an email or phone number stored for such notifications).
Code change:
9.5.19. <ins> RFC2324 was an April 1 RFC that lampooned the various ways HTTP was abused; one such abuse was the definition of an application-specific 418 status code.  In the intervening years, this status code has been widely implemented as an "Easter Egg", and therefore is effectively consumed by this use. Therefore, the 418 status code is reserved in the IANA HTTP Status Code registry.  This indicates that the status code cannot be assigned to other applications currently.  If future circumstances require its use (e.g., exhaustion of 4NN status codes), it can be re- assigned to another use. 9.5.20. </ins> The 422 (Unprocessable Entity) status code indicates that the server understands the content type of the request entity (hence a

Related discussion:
text: Looks good to me.
incorporate: URL
What do you want to incorporate exactly?
418 is reserved.
Well, not in the IANA registry right now. Wasn't the plan to do so without publishing something?
My recollection was that a publication is necessary; that's why it's here.
ok
Code change:
This document defines a mechanism for providing end-to-end integrity and authenticity for components of an HTTP message by use of a <del> detached signature.  The mechanism allows applications to create digital signatures or message authentication codes (MACs) over only the components of the message that are meaningful and appropriate for the application.  Strict canonicalization rules ensure that the verifier can verify the signature even if the message has been transformed in any of the many ways permitted by HTTP. </del> <ins> detached signature on HTTP messages.  The mechanism allows applications to create digital signatures or message authentication codes (MACs) over only the components of the message that are meaningful and appropriate for the application.  Strict canonicalization rules ensure that the verifier can verify the signature even if the message has been transformed in many of the ways permitted by HTTP. </ins> The signing mechanism described in this document consists of three parts:

Related discussion:
text: message signatures are just one part of an overall system, and this adds language to make that expectation more explicit in the introductory sections.
Code change:
A malformed request or response is one that is an otherwise valid sequence of HTTP/2 frames but is invalid due to the presence of extraneous frames, prohibited fields or pseudo-header fields, the <del> absence of mandatory fields or pseudo-header fields, or the inclusion of uppercase field names. </del> <ins> 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 HttpHeaders). </ins> A request or response that includes message content can include a

Related discussion:
text: See as an alternative.
Thanks everyone for your patience here. It's good to see this work out :)
Validating fields for characters has raised a concern where we don't have a clear delineation between framing and semantics. So the way that endpoints handle those cases is unclear. For requests in particular, the choice between resetting a stream and sending a 4xx response is unclear. It would be good if we could have more consistent overall behaviour here, but we have seen from the character composition issue (see ) that different implementations will enforce the rules at different layers. We probably need to allow for some flexibility. NAME has volunteered to help us navigate this somewhat nuanced issue.
I think this is reasonable. LGTM
Code change:
12.1. <del> Please update the "Message Headers" registry of "Permanent Message Header Field Names" at <https://www.iana.org/assignments/message- headers> with the header field names listed in the two tables of </del> <ins> Please update the "Hypertext Transfer Protocol (HTTP) Header Field Registry" registry at <https://www.iana.org/assignments/http-headers> with the header field names listed in the two tables of </ins> header.fields. 12.2.

Related discussion:
text: For
I believe the registry URI should actually say "http-header-fields". Can I change that?
The text might be confusing to IANA as the registry does not exist yet.
Code change:
explicit_typing for more details. It is the Issuer who decides which claims are selectively disclosable <del> and which are not.  End-User claims MAY be included as plaintext as well, e.g., if hiding the particular claims from the Verifier is not required in the intended use case.  See sd-validity-claims for </del> <ins> by the Holder and which are not.  Claims MAY be included as plaintext as well, e.g., if hiding the particular claims from the Verifier is not required in the intended use case.  See sd-validity-claims for </ins> considerations on making validity-controlling claims such as selectively disclosable.

Related discussion:
text: should prob add something in history just for posterity - even just a -14 with a "stuff from WGLC part deux"
Code change:
Recommended HTTP status code: The applicable 4xx status code <del> 3.31. </del> <ins> 3.30. </ins> Name: http_request_denied

Related discussion:
text: Signed-off-by: Piotr Sikora
cc NAME
This field uses for a specific purpose, but that's already in the generic parameters. Suggest or similar. /cc NAME
Looks like has the same issue. Should we use for both? Note that the identifier is context-based, since if proxy configured SHA256-based validation, then would be , if it configured SPKI-based validation, then would be , etc. We could also use and instead of (and for ), but that doesn't seem very future-proof. What do you think?
Hmm, that's awkward. Maybe two fields? E.g., : [, ... ] : ... Is there a registry we can refer to, maybe?
I'm afraid that there isn't any registry that we can refer to, at least none that I know of. (opaque type) and (opaque value) seem a bit awkward. Wouldn't it be easier to just have and params? Also, in Envoy, we actually configure list of acceptable and values, and matching against any of them works, so we should probably emit both of them anyway. I could envision merging and into a single status type that lists all 3 params, e.g. See . What do you think?
Better than what we had :)
Code change:
7. <del> The message/http media type can be used to enclose a single HTTP </del> <ins> The "message/bhttp" media type can be used to enclose a single HTTP </ins> request or response message, provided that it obeys the MIME restrictions for all "message" types regarding line length and encodings.

Related discussion:
text: Sounds like a good idea to me.
from the editor's copy >7. "message/bhttp" Media Type The message/http media type can be used to enclose a single HTTP request or response message, provided that it obeys the MIME restrictions for all "message" types regarding line length and encodings. is this a typo and it should be >The message/bhttp media type ? Also defining this type at section 7 seems quite late. The first instance of is in examples in section 5, easily missed due to the similarity and prevalence of that is mentioned as a contrasting type. I think it would help a bit to talk about the bhttp type earlier. Probably in the introduction, just after you talk about the old type.
LGTM thank you
Code change:
stream risks being ignored due to the peer having discarded priority state information for that stream. <ins> A PRIORITY frame with a length other than 5 octets MUST be treated as a ConnectionErrorHandler of type . </ins> 6.4. The RST_STREAM frame (type=0x3) allows for abnormal termination of a

Related discussion:
text: If an http2 implementation receives a frame with an unexpectedly large size, what should it do? As one example, a WINDOW_UPDATE should be 4 bytes. Or should it be at least 4 bytes? The Extending HTTP/2 notes at URL aren't clear about whether an unexpectedly long frame is okay. The closest I can find is: "Implementations MUST ignore unknown or unsupported values in all extensible protocol elements. " But I can't find a definition of an "extensible protocol element". It seems that the spirit of Section 5.5 would be to permit overly long frames.
I forgot to mention: there is FRAMESIZEERROR, but it only says: "If a frame size exceeds any defined limit, or is too small to contain mandatory frame data, the endpoint MUST send a FRAMESIZEERROR error." But only PING and SETTINGS mention it or a limit. What is the intended behavior for PRIORITY, RSTSTREAM and WINDOWUPDATE?
Code change:
14.5. <ins> This specification establishes the IANA "Status Types" registry for Status List values.  The registry records the a human readable label, the bit representation and a common description for it. 14.5.1. Status Type Name: Status Type Description: Status Type value: Change Controller: Specification Document(s): 14.5.2. Status Type Name: VALID Status Type Description: The status of the Referenced Token is valid, correct or legal. Status Type value: "0x00" Change Controller: IETF Specification Document(s): status-types of this specification Status Type Name: INVALID Status Type Description: The status of the Referenced Token is revoked, annulled, taken back, recalled or cancelled. Status Type value: "0x01" Change Controller: IETF Specification Document(s): status-types of this specification Status Type Name: SUSPENDED Status Type Description: The status of the Referenced Token is temporarily invalid, hanging, debarred from privilege.  This state is reversible. Status Type value: "0x02" Change Controller: IETF Specification Document(s): status-types of this specification Status Type Name: APPLICATION_SPECIFIC_3 Status Type Description: The status of the Referenced Token is implicitly given by the particular use case and the meaning of this value is known out-of-band. Status Type value: "0x03" Change Controller: IETF Specification Document(s): status-types of this specification Status Type Name: APPLICATION_SPECIFIC_14 Status Type Description: The status of the Referenced Token is implicitly given by the particular use case and the meaning of this value is known out-of-band. Status Type value: "0x0E" Change Controller: IETF Specification Document(s): status-types of this specification Status Type Name: APPLICATION_SPECIFIC_15 Status Type Description: The status of the Referenced Token is implicitly given by the particular use case and the meaning of this value is known out-of-band. Status Type value: "0x0F" Change Controller: IETF Specification Document(s): referenced-token-jose of this specification 14.6. </ins> This section requests registration of the following media types RFC2046 in the "Media Types" registry IANA.MediaTypes in the manner described in RFC6838.

Related discussion:
text: The first few entries are valid, revoked, suspended. There may be future well defined values that issuers and verifiers want global interoperability around. There may also be a need for private use of this space. This document should describe the "reserved for private use range", and leave room for enough globally interoperable and registered status values
We had similar ideas and totally agree
The section 7 explains how to setup the registry (URL) but we are missing a corresponding section in the IANA appendix
Code change:
the dependencies is assumed to match that of the track declaring the dependencies. <del> 3.2.18. </del> <ins> 3.2.19. </ins> A number identifying the temporal layer/sub-layer encoding of the track, starting with 0 for the base layer, and increasing with higher temporal fidelity. <del> 3.2.19. </del> <ins> 3.2.20. </ins> A number identifying the spatial layer encoding of the track, starting with 0 for the base layer, and increasing with higher fidelity. <del> 3.2.20. </del> <ins> 3.2.21. </ins> A string defining the codec used to encode the track.  For LOC packaged content, the string codec registrations are defined in Sect 3 and Section 4 of WEBCODECS-CODEC-REGISTRY.  For CMAF packaged content, the string codec registrations are defined in XXX. <del> 3.2.21. </del> <ins> 3.2.22. </ins> A string defining the mime type MIME of the track.  This parameter is typically supplied with CMAF packaged content. <del> 3.2.22. </del> <ins> 3.2.23. </ins> A number defining the framerate of the track, expressed as frames per second. <del> 3.2.23. </del> <ins> 3.2.24. </ins> A number defining the bitrate of track, expressed in bits second. <del> 3.2.24. </del> <ins> 3.2.25. </ins> A number expressing the encoded width of the track content in pixels. <del> 3.2.25. </del> <ins> 3.2.26. </ins> A number expressing the encoded height of the video frames in pixels. <del> 3.2.26. </del> <ins> 3.2.27. </ins> The number of audio frame samples per second.  This property SHOULD only accompany audio codecs. <del> 3.2.27. </del> <ins> 3.2.28. </ins> A string specifying the audio channel configuration.  This property SHOULD only accompany audio codecs.  A string is used in order to provide the flexibility to describe complex channel configurations for multi-channel and Next Generation Audio schemas. <del> 3.2.28. </del> <ins> 3.2.29. </ins> A number expressing the intended display width of the track content in pixels. <del> 3.2.29. </del> <ins> 3.2.30. </ins> A number expressing the intended display height of the track content in pixels. <del> 3.2.30. </del> <ins> 3.2.31. </ins> A string defining the dominant language of the track.  The string MUST be one of the standard Tags for Identifying Languages as defined

Related discussion:
text: by adding in a new field to indicate if delta updates (patches) will be used by the publisher. Also updated the examples to match.
Code change:
12.11. This section registers the "Digest" field in the "Hypertext Transfer <del> Protocol (HTTP) Field Name Registry" I-D.ietf-httpbis-semantics. </del> <ins> Protocol (HTTP) Field Name Registry" SEMANTICS. </ins> Field name: "Digest"

Related discussion:
text: References I-D.httpbis-semantics using an inline referece to {{SEMANTICS}}. This will ease the transition once SEMANTICS is updated to RFC.
Code change:
Application of additional restrictions and policy are at the discretion of the verifying party. <del> The following is a non-normative example for a decoded payload of a Referenced Token: </del> <ins> The following is a non-normative example of a Referenced Token in CWT format in Hex: The following is the CBOR Annotated Hex output of the example above: </ins> 6.4.

Related discussion:
text: Changes the CWT example to a Hex and annotated Hex version instead of diagnstic. Rendered version: URL Did you have time to check this example with your team NAME
We have a CWT in 6.3 in diagnostic notation and decided to add a raw (hex) example to the annex
Code change:
representation, or conveys a partial representation of a resource eg. Range Requests (see Section 14.2 of SEMANTICS). <del> Changes are semantically compatible with existing implementations and better cover both the request and response cases. </del> <ins> This document replaces RFC3230 to better align with SEMANTICS and to provide more detailed description of "Digest" usage in request and response cases.  Changes are intended to be semantically compatible with existing implementations but note that negotiation of "Content- MD5" is deprecated deprecate-contentMD5, "Digest" field parameters are obsoleted obsolete-parameters, "md5" and "sha" digest-algorithms are obsoleted broken-algorithms and the "adler32" algorithm is deprecated deprecated-algorithms. </ins> The value of "Digest" is calculated on selected representation, which is tied to the value contained in any "Content-Encoding" or "Content-

Related discussion:
text: This ended up being more changes than I first intended but I think most of them are uncontroversial and simply improve consistency through the document.
LGTM. Thanks NAME and Happy New Year!