jiebi/CodeConvo huggingface dataset:
Code change:
The "Upload-Complete" header field MUST only be used if support by the resource is known to the client (feature-detection). <ins> 8.4. The "Upload-Length" request and response header field indicates the number of bytes to be uploaded for the corresponding upload resource, counted in bytes.  The "Upload-Length" field value is an Integer. </ins> 9. The "application/partial-upload" media type describes a contiguous

Related discussion:
text: Closes URL A client can express its interest in digests using during upload creation. The server can then respond with after POST and PATCH requests to share its digest with the client. The client computes its digest as well during the upload and compares the digest to spot issues. The representation digest of an upload resource covers the entire bytes that have been uploaded so far (i.e. right until the upload offset). NAME NAME Is this in line with the semantics of RFC 9530?
NAME Need a week for the review :)
Preliminary feedback: I'd simplify the language/split text on multiple lines; Describe processing in separate subsections, e.g.
Thank you for the feedback, Roberto. I added subsections for representation and content digests in URL I think this division helps the reader and also makes sense since representation digests can cover the entire upload, while content digests only cover one request. Let me know if you think differently.
URL added some guidelines on how a client may include integrity fields to upload requests for protecting the integrity of a single request or the entire upload. However, this either requires the client to compute the digest upfront (before sending a request or starting the upload), or the use of request trailers, which is not very widespread and not always possible (e.g. the ). Instead of requiring the client to compute the digest upfront, the server and client could calculate the digests while the upload is ongoing. Once the upload is completed, the server can send its digest to the client in the response to the request that completed the upload. The client can then compare the server's digest to its computed value. If they don't match, it can raise an error to the end user and decide to not continue using the uploaded data. The client should indicate its interest in the server's digest when an upload is created, so the server is not required to compute the digest if the client has no interest. I am wondering if the from can be used for this. Can a client include in the first upload creation request, but the server delivers the digest potentially later in a response for a subsequent request? An upload may be spread across multiple requests.
Should also be supported? For multi request uploads, there's really no use to continue if request 3 of 100 got corrupted.
Code change:
The "Upload-Complete" header field MUST only be used if support by the resource is known to the client (feature-detection). <ins> 8.4. The "Upload-Length" request and response header field indicates the number of bytes to be uploaded for the corresponding upload resource, counted in bytes.  The "Upload-Length" field value is an Integer. </ins> 9. The "application/partial-upload" media type describes a contiguous

Related discussion:
text: As NAME mentioned in URL, is not directly applicable here because it asks the server to send the digest corresponding to the response content, not the received request content. Good point that a client may validate digests while a multi-request upload is progressing. A server could respond with the latest digest of the entire uploaded data (not just the data from the last request) using after POST and PATCH requests. The client can then validate and decide to abort if the digests don't match. This usage would be in line with the PATCH example in . The server responds with the digest of the representation after the PATCH has been applied. The example also notes that the server is not required to respond with the representation itself and could also have returned a 204 (as is done for resumable uploads):
Makes sense, thanks for clarifying. is most likely good enough given that it indicates the current checksum of what the server received.
NAME please, stalk me for a review in the next week :)
NAME It took me a bit more than a week, but here we go: URL Happy to hear your feedback :)
Code change:
location that is more local to the client. An origin server might wish to offer access to its resources using <del> a new protocol, such as HTTP/2 HTTP2, or one using improved </del> <ins> a new protocol, such as HTTP/3 HTTP3, or one using improved </ins> security, such as Transport Layer Security (TLS) RFC5246. An origin server might wish to segment its clients into groups of

Related discussion:
text: The changes here are relatively small, but please ensure I didn't miss anything. Because not all HTTP/3 streams are framed, I restated "on any other stream" to specify "request and push streams," language which I believe remains appropriate for HTTP/2. In order to keep the frames as identical as possible, I haven't restructured the H3 version with varints, but that's certainly an option. It would require defining the frame payloads separately, but that's possible.
LGTM. Nice and simple. Suggestions are all things you can ignore.
Code change:
known security attacks, and which has a bounded memory requirement for use in constrained environments. <ins> The HPACK format is intentionally simple and inflexible.  Both characteristics reduce the risk of interoperability or security issues based by implementation error.  No extensibility mechanisms are defined; changes to the format are only possible by defining a complete replacement. </ins> 1.1. The format defined in this specification treats a list of header

Related discussion:
text: had a few actionable comments that seemed relatively easy to handle. In the absence of feedback from NAME and NAME I responded. Of note: the introductory text in URL about the choice to make the format inflexible.
Code change:
Given an ASCII string as input_string, return a number. input_string is modified to remove the parsed value. <del> NOTE: This algorithm parses both Integers (integer) and Floats (float), and returns the corresponding structure. </del> <ins> NOTE: This algorithm parses both Integers (integer) and Decimals (decimal), and returns the corresponding structure. </ins> Let type be "integer".

Related discussion:
text: (Related to now-closed ) Should implementations be able to store parsed floats in IEEE754 binary64? And if so, should we expect that they round trip between parsing and serialization? It seems like the current limits were designed to support that notion, but there are cases where they do not. (Note, this isn't about being able to serialize arbitrary C++ doubles; the spec sensibly only supports a tiny subset of all possible 64-bit floats. This is about whether should always be true) IEEE 754 guarantees that if a string with no more than 15 digits is converted to a double and then back to a string, it should result in the original string, but that appears to require rounding in some cases; truncation, which the serialization algorithm calls for, can change the string representation. Parsing the string "12345678901234.1" as a float, for instance, results in a binary64 representation with value 0x42a674e79c5fe433, whose exact decimal expansion is 12345678901234.099609375. Following the text of the serialization algorithm, will be 1, and so the number will be serialized as "12345678901234.0" It appears, as an implementer, that the only way to ensure that a float parsed from a valid string can be serialized back to the original string is to store it as a fixed point decimal in two parts, or else use a float with >64 bits of precision for storage.
Would it be adequate to change truncation to rounding in step 9 of Serializing a Float?
That's a can of worms. Which rounding? (nearest-or-even, nearest-or-away from zero, to zero, up, down?)
I know nearest-or-even is the recommended rounding technique. Can we specify that?
Round, nearest-or-even, to fractionaldigitsavail digits? While we're at it, should the spec be stricter about trailing zeros? My implementation currently strips any trailing zeros after the first position past the decimal point (so 1.230000 is serialized as 1.23, but 1.000000 is serialized as 1.0, as is 1.0000001, after rounding/truncation), which passes the test cases in URL The spec just says "at most fractionaldigitsavail digits, but that allows multiple "correct" serializations of a given float.
Code change:
Given an ASCII string as input_string, return a number. input_string is modified to remove the parsed value. <del> NOTE: This algorithm parses both Integers (integer) and Floats (float), and returns the corresponding structure. </del> <ins> NOTE: This algorithm parses both Integers (integer) and Decimals (decimal), and returns the corresponding structure. </ins> Let type be "integer".

Related discussion:
text: It's also weird to only require roundtripping for floats that can be represented in binary64. The simplest might solution here might be to just accept that floats are lossy. If an implementer needs precision, use a string. This trade-off seems to work well enough for JSON parsers.
The spec already restricts floats to those which can theoretically be round-tripped into a binary64 and back; this is just about ensuring that that actually happens, if a binary64 is used as the backing store (which is natural for at least C++ and JS implementations)
nearest-or-even SGTM. Stripping trailing zeros as well as leading ones in the integer component sounds good as well. I'll do a PR...
PTAL at the commit. I've added a test for this ("tricky precision float") -- NAME are you using the tests?
/me reads above - yes you are, sorry for the noise.
I do not think we should make stripping trailing zeros decimal digits a strict requirement, the number of decimals presented can be out-of-band metadata about the actual precision involved. For instace a timeinterval serialized as 3.0 vs 3.000 vs. 3.000000 might be used to communicate the precision of the measurements as tenths of seconds / milliseconds / microseconds respectively. But we should probably recommend stripping trailing zero decimal digits for bandwidth reasons, if there is no communicative reason to retain them.
If someone wants to use the precision of measurement that way, it'd need to be available in all implementations to be interoperable -- i.e., we'd have to require implementations to preserve that precision. I'm pretty dubious on that being possible and correctly implemented across the board. E.g., requiring every implementation to parse "0.42000" and make the trailing zeros correctly available.
If we're going to round, we probably need to do it before serializing the integer part, since the rounded fractional part may round up to 1.0, as well.
For floats, I think there are two things that we want from this spec (and please let me know if that's not right): Any string which parses as an float can have that float's value stored in a binary64, and serializing that value should reproduce the original string.
Code change:
Given an ASCII string as input_string, return a number. input_string is modified to remove the parsed value. <del> NOTE: This algorithm parses both Integers (integer) and Floats (float), and returns the corresponding structure. </del> <ins> NOTE: This algorithm parses both Integers (integer) and Decimals (decimal), and returns the corresponding structure. </ins> Let type be "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:
Given an ASCII string as input_string, return a number. input_string is modified to remove the parsed value. <del> NOTE: This algorithm parses both Integers (integer) and Floats (float), and returns the corresponding structure. </del> <ins> NOTE: This algorithm parses both Integers (integer) and Decimals (decimal), and returns the corresponding structure. </ins> Let type be "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:
enabled. A TTRP negotiates the use of a mutually-authenticated TLS connection <del> with the client, such as is described in TLS or RFC5246, and validates the client certificate per its policy and trusted certificate authorities.  Each HTTP request on the underlying TLS connection are dispatched to the origin server with the following modifications: </del> <ins> with the client, such as is described in TLS or TLS1.2, and validates the client certificate per its policy and trusted certificate authorities.  Each HTTP request on the underlying TLS connection are dispatched to the origin server with the following modifications: </ins> The client certificate is placed in the "Client-Cert" header field of the dispatched request, as described in header.

Related discussion:
text: correcting: The reference to RFC8740 is obsoleted by RFC9113 There are two separate references to RFC5246, once as "RFC5246" and once as "TLS1.2".
Code change:
Track namespace is an ordered N-tuple of bytes where N can be between 1 and 32.  The structured nature of Track Namespace allows relays and applications to manipulate prefixes of a namespace.  Track name is a <del> sequence of bytes. </del> <ins> sequence of bytes.  If an endpoint receives a Track Namespace tuple with an N of 0 or more than 32, it MUST close the session with a Protocol Violation. </ins> In this specification, both the Track Namespace tuple fields and the Track Name are not constrained to a specific encoding.  They carry a

Related discussion:
text: Current definition specifies namespace is an N-tuple, with 132 is it expected to return a protocol violation, or do we leave that undefined?
+1 I think we should address this as part of refactoring the tuple type
I put up a PR addressing the issue but didn't do a larger refactor of the tuple type, which seems editorial.
Editorial suggestion, but LG
Code change:
link in a Prefix Information option (RFC4861) with the following Prefix Information option header values: <del> A prefix is not considered a suitable on-link prefix if the 'L' bit is set, but the 'A' bit is not set.  This indicates that node addressability is being managed using DHCPv6.  Nodes are not required to use DHCPv6 to acquire addresses, so a prefix that requires the use of DHCPv6 can't be considered "suitable"&#151;not all hosts can actually use it. </del> <ins> A prefix is not considered a suitable on-link prefix if the 'L' flag bit is set, but the 'A' flag bit is not set.  This indicates that node addressability is being managed using DHCPv6.  Nodes are not required to use DHCPv6 to acquire addresses, so a prefix that requires the use of DHCPv6 can't be considered "suitable"&#151;not all hosts can actually use it. </ins> Note: there can be layer two networks where neighbor discovery is not <del> supported and therefore we cannot set the 'L' bit, but could set the 'A' bit.  The behavior of stub networks when connecting to such networks is out of scope for this document. </del> <ins> supported and therefore we cannot set the 'L' flag bit, but could set the 'A' flag bit.  The behavior of stub networks when connecting to such networks is out of scope for this document. </ins> A prefix is considered to be advertised on the link if, when a Router Solicit message (RFC4861) is sent, a Router Advertisement message is

Related discussion:
text: Flag bits can be referred to as "bit", "flag", or "flag bit". This issue is an editorial reminder to update to a consistent term later on. E.g. "flag" or "flag bit" is most clear I think.
Assigning to myself, to make a PR later on. Everyone and NAME feel free to suggest preferred term. I find "flag bit" the most clear.
Code change:
and the value string. If the sum of the lengths of the name string and the value string <del> is more than 4096 bytes, abort these steps and ignore the set- </del> <ins> is more than 4096 octets, abort these steps and ignore the set- </ins> cookie-string entirely. The cookie-name is the name string, and the cookie-value is the

Related discussion:
text: Addresses
NAME NAME PTAL
RFC6265bis mentions the cookie length constraints in relation to parsing the Set-Cookie headers but doesn't in the more general Storage Model section. From chatting with NAME about this, it'd be desirable to have these constraints be listed in that section as well. Since there are other ways cookies can come in to the cookie store (Ex: Cookie Store API), having these constraints be enforced when adding cookies from any source to the cookie store would better ensure cookie format consistency.
Code change:
optional.  If it is not declared at the root or track level, then each track MUST inherit the namespace of the catalog track. <del> 3.2.8. </del> <ins> 3.2.9. </ins> A string defining the name of the track.  See section 2.3 of MoQTransport.  Within the catalog, track names MUST be unique per namespace. <del> 3.2.9. </del> <ins> 3.2.10. </ins> A string defining the type of payload encapsulation.  Allowed values are strings as defined in Table 2. Table 2: Allowed packaging values <del> 3.2.10. </del> <ins> 3.2.11. </ins> Each track description can specify an optional operation value that identifies the catalog producer's intent.  Track operation is an

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:
FIDO2/WebAuthn SHOULD be used for cross-device authentication scenarios whenever the devices are capable of doing so and a suitable <del> FIDO credential is not available on the consumption device.  It MAY </del> <ins> FIDO credential is not available on the Consumption Device.  It MAY </ins> be used as an authentication method with the Authorization Code Grant <del> RFC6749 and PKCE RFC7663, to grant authorization to an Consumption Device (e.g., smart TV or interactive whiteboard) using a mobile phone as the authenticating device.  This combination of FIDO2/ WebAuthn and Authorization Code Flow with PKCE enables cross device authorization flows, without the risks posed by the Device Authorization Grant RFC8628. </del> <ins> RFC6749 and PKCE RFC7663, to grant authorization to a Consumption Device (e.g., smart TV or interactive whiteboard) using a device serving as the FIDO authenticator (e.g. a mobile phone) for authentication.  This combination of FIDO2/WebAuthn and Authorization Code Flow with PKCE enables cross device authorization flows, without the risks posed by the Device Authorization Grant RFC8628. </ins> 6.2.4.

Related discussion:
text: Addresses issue NAME
From WGLC Current text: "supports a new cross-device authentication protocol, called "hybrid"" Proposed text: "supports a new cross-device transport protocol, called "hybrid transports" Propose adding the following at the end of the first paragraph: "CTAP 2.2 hybrid transports is implemented by the client and authenticator platforms." Current text: "The main device and authenticator" Proposed text: "The main device (CTAP client) and authenticator" Current text: "The user will receive a push notification on the authenticator." Proposed text: "The user will typically receive a push notification on the device serving as the FIDO authenticator." Current text: "Both the Consumption Device and the authenticator require BLE support." Proposed text: "Both the Consumption Device and the authenticator require BLE support and also need access to the internet" s/hybrid transport/hybrid transports Current text: "The mobile phone must support CTAP 2.2+ to be used as a cross-device authenticator." Proposed text: "The device serving as the FIDO authenticator must support CTAP 2.2+ to be used as a cross-device authenticator." see: URL NAME
Code change:
3. <del> The "Digest" field contains a list of one or more representation digest values as defined in representation-digest.  It can be used in both requests and responses. </del> <ins> The "Digest" field contains a comma-separated list of one or more representation digest values as defined in representation-digest.  It can be used in both requests and responses. </ins> For example:

Related discussion:
text: [x] 3. It's probably worth mentioning that they're comma-separated in prose. [x] 3. Disagreeing plurals in 'an incremental digest-algorithms'. [x] 4. Is Want-Digest a request field, a response field, or both? In either or both cases, what's the scope of the assertion? [x] 4. A reference to SEMANTICS 12.4.2 is necessary. See