jiebi/CodeConvo huggingface dataset:
Code change:
If char is a DIGIT, append it to input_number. <del> Else, if type is "integer" and char is ".", append char to input_number and set type to "float". </del> <ins> Else, if type is "integer" and char is ".": If input_number contains more than 12 characters, fail parsing. Otherwise, append char to input_number and set type to "decimal". </ins> Otherwise, prepend char to input_string, and exit the loop. If type is "integer" and input_number contains more than 15 characters, fail parsing. <del> If type is "float" and input_number contains more than 16 </del> <ins> If type is "decimal" and input_number contains more than 16 </ins> characters, fail parsing. If type is "integer":

Related discussion:
text: (modulo some number of 0's at either end) Any real value (regardless of storage implementation) in the range -(1e14-0.05) to (1e14-0.05), exclusive, should serialize to its closest valid sh-float representation. (rounding ties towards an even least-significant-digit) Is that reasonable?
Discussed in Singapore: will discuss on list, but sense in the room is to have a fixed point. Hum in the room prefers fixed point. (Need to still determine number of decimals; q-value uses 3).
Specifically pinging NAME NAME NAME for thoughts re: moving float to fixed-point (straw-man: three digits). This seemed to have strong support in the room, but wanted to make sure you're comfortable with it.
Would fixed point be materially different that what is currently specced? Currently, the spec implies a fixed-point with 6 digits of precision, and a maximum of 15 total digits, which (not at all coincidentally) is the same range that is guaranteed to round trip through an IEEE-754 binary64 representation, which is useful for actual implementations. Edit: I see the three-digit difference now; would the integer portion be restricted to 12 digits in that case?
Yes.
I don't have a strong opinion on switching to 12+3 fixed; I think it would cover all of the use cases that I can currently imagine (and I'm trying hard to discount any sunk costs from implementing the previous draft :stuckouttongue:) If implementation complexity (or perceived complexity) factors in to the decision at all, Chrome's current sh-float serializer, which passes the public test suite, is
If people think it's useful to have a fixed-point number, and can settle on the optimal number of digits for most of their use-cases, then
The (only!) two "real" reason we have float/decimal in the first place is values and subsecond resolution time-{intervals,stamps}, and the one "unreal" reason is that JSON offered that. I think has three decimals, either by norm or convention. Time-intervals such as "process-time for this request" are often sub-millisecond, and that has by and large been the argument for "at least six decimals".
Code change:
If char is a DIGIT, append it to input_number. <del> Else, if type is "integer" and char is ".", append char to input_number and set type to "float". </del> <ins> Else, if type is "integer" and char is ".": If input_number contains more than 12 characters, fail parsing. Otherwise, append char to input_number and set type to "decimal". </ins> Otherwise, prepend char to input_string, and exit the loop. If type is "integer" and input_number contains more than 15 characters, fail parsing. <del> If type is "float" and input_number contains more than 16 </del> <ins> If type is "decimal" and input_number contains more than 16 </ins> characters, fail parsing. If type is "integer":

Related discussion:
text: Time-intervals do not convincingly overcome Gettys 1st rule[1] or Phil Karltons rule[2]. so 12.3 would be fine with me. [1] Do not add new functionality unless an implementor cannot complete a real application without it. [2] The only thing worse than generalizing from one example is generalizing from no examples at all.
These days at least, it's by specification. It's a number in the range 0.000 to 1.000, and all algorithms I know of that use it would be just as well served by an integer from 0 to 1000. So the only reason to include the dot is if we want to backport existing headers as-is. Not backporting existing headers was a justification for some decisions earlier on, so if that's been reversed, should we revisit some of those other decisions?
Although thinking more about it, most of the earlier decisions are sort of OBE, so it's maybe not such a big deal.
PTAL
Code change:
7.3. <ins> The length of the randomly-generated portion of the salt MUST be at least 128 bits. 7.4. </ins> For the security of this scheme, the hash function is required to have the following property.  Given a claim value, a salt, and the resulting hash, it is hard to find a second salt value so that equals the hash. <del> 7.4. </del> <ins> Furthermore the hash algorithms MD2, MD4, MD5, RIPEMD-160, and SHA-1 revealed fundamental weaknesses and they MUST NOT be used. 7.5. </ins> TBD

Related discussion:
text: feat: Minimum length of the salt feat: weak hash algorithms to not use
mh ... we already have in Section
NAME I commited your suggestion I'm not sure that the normative language could be used in the considerations but it's good anyway to me, it's intellegibile :)
Code change:
In protocols that deliver data out of order (such as QUIC HQ) early data can arrive after the handshake completes.  A server MAY process <del> requests received in early data after handshake completion if it can rely on other instances correctly handling replays of the same </del> <ins> requests received in early data after handshake completion only if it can rely on other instances correctly handling replays of the same </ins> requests. 7.

Related discussion:
text: This will conflict with the changes ekr suggested, but I integrated them, so merging shouldn't lose the important changes.
For "sent in early data on another connection", I think Spencer's proposal "sent in early data on a previous hop" would make it even clearer regarding the hop chain so as not to confuse this with another connection from the same user-agent. OK for the rest.
Code change:
The component identifier is a dictionary member identifier or a named query parameter identifier that references a member that is not present in the component value, or whose value is malformed. <del> E.g., the identifier is ""x-dictionary";key="c"" and the value of the "x-dictionary" header field is "a=1, b=2" </del> <ins> E.g., the identifier is ""example-dictionary";key="c"" and the value of the "Example-Dictionary" header field is "a=1, b=2", which does not have the "c" value. </ins> In the following non-normative example, the HTTP message being signed is the following request: The covered components consist of the "@method", "@path", and <del> "@authority" derived component identifiers followed by the "Cache- Control", "X-Empty-Header", "X-Example" HTTP headers, in order.  The signature parameters consist of a creation timestamp is "1618884475" and the key identifier is "test-key-rsa-pss".  The signature input string for this message with these parameters is: </del> <ins> "@authority" derived component identifiers followed by the "Content- Digest", "Content-Length", and "Content-Type" HTTP header fields, in order.  The signature parameters consist of a creation timestamp of "1618884473" and a key identifier of "test-key-rsa-pss".  Note that no explicit "alg" parameter is given here since the verifier is assumed by the application to correctly use the RSA PSS algorithm based on the identified key.  The signature input string for this message with these parameters is: Note that the example signature input here, or anywhere else within this specification, does not include the final newline that ends the example. </ins> 3.

Related discussion:
text: update canonicalization rules, remove weird headers from examples changed dictionaries and messages. updated crypto primative functions regenerate examples
Code change:
protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. <del> This document obsoletes RFC 2818, RFC 7231, RFC 7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC 7694, and portions of RFC 7230. </del> <ins> This document updates RFC 3864 and obsoletes RFC 2818, RFC 7231, RFC 7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC 7694, and portions of RFC 7230. </ins> Editorial Note

Related discussion:
text: I am seeing a lot of warnings about lines being too long (longer than 72 characters), but they are unrelated to these changes.
This changed "previous authors, editors, and Working Group Chairs" to "current and previous authors"; that's misleading, as it actually does not contain any current authors. Originally posted by NAME in URL
This is what I had in mind in terms of bringing back the original acks.
Code change:
protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. <del> This document obsoletes RFC 2818, RFC 7231, RFC 7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC 7694, and portions of RFC 7230. </del> <ins> This document updates RFC 3864 and obsoletes RFC 2818, RFC 7231, RFC 7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC 7694, and portions of RFC 7230. </ins> Editorial Note

Related discussion:
text: Nits on semantics flags this: -- The draft header indicates that this document updates RFC3864, but the abstract doesn't seem to mention this, which it should.
Can you point to a document that states this?
Code change:
This specification registers the following entry in the Permanent Message Header Field Names registry established by RFC3864: <del> Header field name: Upload-Offset, Upload-Incomplete </del> <ins> Header field name: Upload-Offset, Upload-Complete </ins> Applicable protocol: http

Related discussion:
text: Closes URL
NAME brought up that during the WG meeting that reusing Upload-Complete on requests and responses can be confusing. They don’t mean exactly the same thing: on the server means it has received the full upload, while on the client means the body it will send is a complete upload.
We discussed this internally and prepared a response: Upload-Complete is used on both requests and responses because it is symmetrical. Upon a typical successful transaction, an request results in an response, and an request results in an response. A server implementation can simply echo the field. However, they are also meanings that we can take advantage of. The presence on the request means it’s a resumable request, and the presence on the response is also a useful signal. Since we are upgrading regular uploads, there are cases where 4xx/5xx responses are intentional and we can't just eat it by attempting to resume. We would be much more confident that the response came from the real server rather than a middlebox which shouldn’t randomly add . The server can also use to terminate a request early if it does not care about the body, similar to the early response mechanism in HTTP/3.
I am having second thoughts about this as well. While debugging a server implementation, the naming of the headers also confused me for a moment (even though I wrote parts of the draft). The reason is that in a response (or how it is currently called) refers to the current state of the upload, while in a request refers to the potential state in the future, if the request completed successfully. I don't think that we have a general issue with the concept of and have to change much. But maybe a simple name change can help here already to alleviate the confusion. We could use for the response header to indicate that it represents the current state. And for request headers to indicate that process the request successfully will complete the upload. We loose the symmetry of the names in request and response, but maybe this makes their relation even clearer.
I think for both client and server works because it represents their own perspectives of the upload. For the client, sending means "the upload is complete on my end, I've included all the data to complete it."
Code change:
This specification registers the following entry in the Permanent Message Header Field Names registry established by RFC3864: <del> Header field name: Upload-Offset, Upload-Incomplete </del> <ins> Header field name: Upload-Offset, Upload-Complete </ins> Applicable protocol: http

Related discussion:
text: The client isn't making assumptions about whether the server has received all the data; it's only expressing to the server that from its perspective, the upload data supplied is now whole. For the server, responding acknowledges the client's view of the complete upload and says, "Yes, the upload is complete on my end, too." Same goes for .
At IETF 117, we agreed on using for requests and responses: URL I will open a PR for this and then we can close this issue.
Code change:
The HEADERS frame changes the connection state as described in HeaderBlock. <del> The HEADERS frame includes optional padding.  Padding fields and flags are identical to those defined for DATA. </del> <ins> The HEADERS frame can include padding.  Padding fields and flags are identical to those defined for DATA. </ins> Prioritization information in a HEADERS frame is logically equivalent to a separate

Related discussion:
text: Only if it makes sense to do so. It's a perfectly good word that has been spoiled by an unnecessary inclusion in some popular RFC (2119, I think).
Code change:
field identified by a content negotiation mechanism that the implementation supports: <del> Let request-value be the field-value(s) associated with field-name in incoming-request. </del> <ins> Let request-value be the field-value associated with field-name in incoming-request (after being combined as allowed by Section 3.2.2 of RFC7230), or null if field- name is not in incoming-request. </ins> Let available-values be a list containing all available- value for variant.

Related discussion:
text: This change passes 'null' to the content-negotiation algorithm if the request header is absent. For list headers, the algorithms can always turn that into the empty list, but for non-list headers they need to come up with something appropriate to do. This also tries to do better about , but may not completely fix it.
Thanks.
URL says "... For each variant in variants-header ... Let request-value be the field-value(s) associated with field-name in incoming-request." I don't see any handling of the case where there is no header in . The algorithms in URL then also don't handle the case where request-value is empty. Sorry if I've just missed where you handle the empty case.
Code change:
artifact against a Reference Integrity Manifest (RIM).  Corresponding procedures are often called authenticated, measured, or secure boot. The output of these high assurance boot procedures is often used as <del> input to more complex verification known as remote attestation </del> <ins> input to more complex verifications known as remote attestation </ins> procedures. If measurements before execution are not possible, static after-the-

Related discussion:
text: Account for nits of punctionation, consistent Title Case usage and consistency with bulleted content. This PR does not change the definition or examples of the use cases.
The GitHub UX makes it look more than it is. This is just re-formatting of existing content into bullets.
More then spelling nits & style in , but I am okay with the addition.
Code change:
3.2.3. <ins> A boolean that if true indicates that the publisher MAY issue incremental (delta) updates - see patch.  If false or absent, then the publisher gaurantees that they will NOT issue any incremental updates and that any future updates to the catalog will be independent.  The default value is false.  This field MUST be present if its value is true, but may be omitted if the value is false. 3.2.4. </ins> An array of track objects trackobject.  If the 'tracks' field is present then the 'catalog' field MUST NOT be present. <del> 3.2.4. </del> <ins> 3.2.5. </ins> An array of catalog objects catalogobject.  If the 'catalogs' field is present then the 'tracks' field MUST NOT be present.  A catalog MUST NOT list itself in the catalog array. <del> 3.2.5. </del> <ins> 3.2.6. </ins> A catalog object is a collection of fields whose location is specified as 'RC', 'TC' or 'RTC' in Table 1. <del> 3.2.6. </del> <ins> 3.2.7. </ins> A track object is a collection of fields whose location is specified as 'RT', 'TC' or 'RTC' in Table 1. <del> 3.2.7. </del> <ins> 3.2.8. </ins> The name space under which the track name is defined.  See section 2.3 of MoQTransport.  If the track namespace is declared in the root

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:
requests can be highly redundant, so compression can reduce the size of requests and responses significantly. <ins> HTTP/2 also supports HTTP Alternative Services (see AltSvc) using the alt-frame, to allow servers more control over traffic to them. </ins> 2.1. The HTTP/2 specification is split into four parts:

Related discussion:
text: HTTP/2 has different properties to HTTP/1 regarding server-side load, because load balancers etc. currently exploit HTTP/1's short connections. HTTP/2 has much longer-lived connections, making it more difficult to load balance traffic. A mechanism to direct the client to use a different server/port would mitigate this. While GOAWAY could be used to do this, it introduces latency as the new connection is set up.
Alt-Svc?
URL
NAME is this really in the next milestone? It doesn't seem like we're ready yet.
Should get out a draft momentarily; if we don't make it, that's fine, but if we can, it'd be good to have a bit of discussion first.
NAME this missed the boat. Can I request that you put together something we can discuss in London instead.
Yes, it's on the list for discussion there. The boat technically is delayed at dock...
Discussed in London; agreed to using ALTSVC frame for this.
Code change:
Abstract <del> This memo introduces an informational status code for HTTP that can be used for indicating hints to help a client start making preparations for processing the final response. </del> <ins> This memo introduces an informational HTTP status code that can be used to convey hints that help a client make preparations for processing the final response. </ins> Note to Readers

Related discussion:
text: ... for your consideration; feel free to take, discard, or do whatever else you like :)
Thank you so much for the improvements. This PR is a tremendous opportunity for me to improve my skills (both in terms of writing a specification and in terms of English).
Code change:
The client constructs the request URI by adding the following parameters to the query component of the authorization endpoint URI <del> using the "application/x-www-form-urlencoded" format, per application-x-www-form-urlencoded: </del> <ins> as described by query-string-serialization: </ins> REQUIRED.  The authorization endpoint supports different sets of request and response parameters.  The client determines the type

Related discussion:
text: This moves the description of serializations to the appendix part of
Though i wonder whether the Authorization Response () section should account for the extension - URL with text like "unless specified otherwise by an extension".
yeah I can add that, sounds reasonable
added a lot of text around how clients form authorization requests, the language does not however account for the optional POST binding at the authorization endpoint. Sections and do not account for the optional POST binding which uses the request body to carry the encoded parameters. In OIDC there's the request parameters.
This has been resolved in , there is now a section that describes the serialization methods in an appendix, which is referenced elsewhere in the spec: URL
LGTM
Code change:
the scalability and cost effectiveness associated with content delivery networks. <del> MOQT is a generic protocol is designed to work in concert with multiple MoQ Streaming Formats.  These MoQ Streaming Formats define how content is encoded, packaged, and mapped to MOQT objects, along with policies for discovery and subscription. </del> <ins> MOQT is a generic protocol designed to work in concert with multiple MoQ Streaming Formats.  These MoQ Streaming Formats define how content is encoded, packaged, and mapped to MOQT objects, along with policies for discovery and subscription. </ins> model describes the object model employed by MOQT.

Related discussion:
text: 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.