jiebi/CodeConvo huggingface dataset:
Code change:
Since concatenation might be done by an upstream intermediary, the results are not under the control of the serializer or the parser. <del> Tokens, Integers, Floats and Byte Sequences cannot be split across </del> <ins> Tokens, Integers, Decimals and Byte Sequences cannot be split across </ins> multiple headers because the inserted commas will cause parsing to fail.

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:
Since concatenation might be done by an upstream intermediary, the results are not under the control of the serializer or the parser. <del> Tokens, Integers, Floats and Byte Sequences cannot be split across </del> <ins> Tokens, Integers, Decimals and Byte Sequences cannot be split across </ins> multiple headers because the inserted commas will cause parsing to fail.

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:
Since concatenation might be done by an upstream intermediary, the results are not under the control of the serializer or the parser. <del> Tokens, Integers, Floats and Byte Sequences cannot be split across </del> <ins> Tokens, Integers, Decimals and Byte Sequences cannot be split across </ins> multiple headers because the inserted commas will cause parsing to fail.

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:
Since concatenation might be done by an upstream intermediary, the results are not under the control of the serializer or the parser. <del> Tokens, Integers, Floats and Byte Sequences cannot be split across </del> <ins> Tokens, Integers, Decimals and Byte Sequences cannot be split across </ins> multiple headers because the inserted commas will cause parsing to fail.

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:
proof of Registration by a Transparency Service, in the form of a Receipt that countersigns the Signed Statement and witnesses its inclusion in the Append-only Log of a Transparency Service.  By <del> extension, the document may say an Artifact (a firmware binary) is transparent if it comes with one or more Transparent Statements from its author or owner, though the context should make it clear what type of Signed Statements is expected for a given Artifact. </del> <ins> extension, the Signed Statement may say an Artifact (for example, a firmware binary) is transparent if it comes with one or more Transparent Statements from its author or owner, though the context should make it clear what type of Signed Statements is expected for a given Artifact. </ins> Transparency does not prevent dishonest or compromised Issuers, but it holds them accountable.  Any Artifact that may be verified, is

Related discussion:
text: changes "document" to "Signed Statement" (was a weird nit close to the suggested change)LGTM
Code change:
4.2.2. <ins> While a media is being contributed in real time via an ingest point to a streaming platform, there may be a need to distribute the media between several servers and/or perform a load balancing of the incoming traffic.  The platform may peform transcoding at one or several points, or distribute (route) the media as is to one or many egress points.  Such a distribution and load balancing may happen with or without the access to the encrypted payload. 4.2.3. </ins> Distribution from platform to audience.  Whilst use of WebRTC or RTSP today for On-Demand media streaming is not typical with adaptive streaming like HLS and DASH being predominantly used as WebRTC is

Related discussion:
text: One more use case "Distribution withing a platform" is suggested. It does not seem to be covered by other use cases, but might be worth describing it as well. Some minor suggestions like UDP multicast instead of QUIC as the last mile transport, etc.
Thanks!
Code change:
2.1.1. The "match" value of the Use-As-Dictionary header is a String value <del> that provides the URLPattern to use for request matching (https://urlpattern.spec.whatwg.org/). </del> <ins> that provides the URL Pattern URLPattern to use for request matching. </ins> <del> The URLPattern used for matching does not support using Regular </del> <ins> The URL Pattern used for matching does not support using Regular </ins> expressions. The following algorithm will return TRUE for a valid match pattern

Related discussion:
text: Changed it to a proper normative reference. For
Merging this. Can always clean it up more if it is still a concern.
For example: Usually, we add something like URLPattern to the references, then that.
Sorry, didn't mean to close the issue. Feel free to close this out if the current language looks OK (also happy to update it if it needs some more tweaking).
Going to close this out now. Thanks for taking the time on this.
Code change:
personal information and in that case must be protected through some obsfucation method (e.g.  SHA256). <del> 10. </del> <ins> 11. </ins> This specification registers the following claims defined in Section txn-token-header to the OAuth Access Token Types Registry defined in RFC6749, and the following claims defined in Section txn-token-claims in the IANA JSON Web Token Claims Registry defined in <del> 10.1. </del> <ins> 11.1. </ins> Name: "txn_token"

Related discussion:
text: Addresses Issue
We need to add in the section, information on how services may use Txn-Tokens securely, by possibly using them in conjunction with SPIFFE or other service-to-service security mechanisms. (based on feedback by Kai Lehmann (NAME
talks about the same issue, but this is a broader statement.
We will use a new header named "Txn-Token"
Code change:
(protocol.version).  Response message control data includes a status code (status.codes), optional reason phrase, and protocol version. <del> In HTTP/1.1 Messaging and earlier, control data is sent as the first line of a message.  In HTTP/2 (RFC7540) and HTTP/3 (HTTP3), control data is sent as pseudo-header fields with a reserved name prefix (e.g., ":authority"). </del> <ins> In HTTP/1.1 (Messaging) and earlier, control data is sent as the first line of a message.  In HTTP/2 (RFC7540) and HTTP/3 (HTTP3), control data is sent as pseudo-header fields with a reserved name prefix (e.g., ":authority"). </ins> Every HTTP message has a protocol version.  Depending on the version in use, it might be identified within the message explicitly or

Related discussion:
text: I think it would be better to separate this into the purely editorial changes (all except TRACE), and then give the change to TRACE the full treatment separately (it's a normative change after all). Will work on the former first.
Sorry for this being a question. I answered the same question for -caching by searching through and realizing that while caching might be a version-independent extension, a practical consequence of the structure of documents is that it is inextricably linked to -semantics. That's cool. Having the definition of HTTP/N rely on -caching is eminently sensible. There is a normative reference to -messaging though. Why would HTTP/3 care about that? If this were software, I'd be horrified by pulling in a dependency like that. Most of the references to -messaging are strictly examples. I could only see two cases where there was a potentially normative dependency: recommends "message/http" and . These seem like they could be broken (the second easier than the first, certainly) and the reference made normative.
I agree that this would be good.
A SHOULD-level requirement to use message/http. Moving the media type definition over is not going to help, because it essentially defines the HTTP/1.1 wire format as media type. It seems the only way to fix this would be to relax the SHOULD. That one could probably be replaced with a reference to the transfer coding registry (which is what counts here), and the pointer to the spec text would then become informative.
History in and linked issues.
Concrete recommendation for 1: a server (intermediary) responding to TRACE MUST generate a representation of the request that it received in any format. The message/http is one possible way to represent a request message, so that can be an informative reference instead.
Code change:
(protocol.version).  Response message control data includes a status code (status.codes), optional reason phrase, and protocol version. <del> In HTTP/1.1 Messaging and earlier, control data is sent as the first line of a message.  In HTTP/2 (RFC7540) and HTTP/3 (HTTP3), control data is sent as pseudo-header fields with a reserved name prefix (e.g., ":authority"). </del> <ins> In HTTP/1.1 (Messaging) and earlier, control data is sent as the first line of a message.  In HTTP/2 (RFC7540) and HTTP/3 (HTTP3), control data is sent as pseudo-header fields with a reserved name prefix (e.g., ":authority"). </ins> Every HTTP message has a protocol version.  Depending on the version in use, it might be identified within the message explicitly or

Related discussion:
text: Make sure that all references to MESSAGING which are not normative are clearly informative. (This ticket is not about those references which right now are indeed normative, see ).
Code change:
Digest Algorithm: sha-512 Description: The SHA-512 algorithm RFC6234.  The output of this <del> algorithm is encoded using the base64 encoding RFC4648. </del> <ins> algorithm is encoded using base64 RFC4648. </ins> Reference: RFC6234, RFC4648, this document.

Related discussion:
text: There's not really any reason to describe anything other than the algorithm used and the format of encoding.
From NAME WGLC review This seems like cruft. The important things for the table are clear pointers to the algorithm definition and the encoding of values created by the algorithm.
If it's not broken, don't fix it :P I think we spent too much time wrt old algorithms. I'm in favor of anyone that wants to provide a PR that has consensus.
It is broken -- let's fix it. :)
LGTM
Code change:
latest version, Issuers SHOULD use the "sequence_no" or "issuer_ts" attributes. <del> Once all the Envelope headers are set, an Issuer SHOULD use a standard COSE implementation to produce an appropriately serialized Signed Statement (the SCITT tag of "COSE_Sign1_Tagged" is outside the scope of COSE, and used to indicate that a signed object is a Signed </del> <ins> Once all the Envelope headers are set, an Issuer MUST use a standard COSE implementation to produce an appropriately serialized Signed Statement (the SCITT tag of "COSE_Sign1_Tagged" is outside the scope of COSE, and used to indicate that a signed object is a Signed </ins> Statement). 6.3.

Related discussion:
text: NAME PTAL
Since the use of COSE is mandatory, shouldn't this be MUST? Originally posted by NAME in URL
It would seem more appropriate to just say , rather than introduce the notion of a "standard COSE implementation". The latter would seem to involve a need to have a certification program for COSE implementations or something unnecessarily involved like that. I don't follow the implications of this. Can it be spelled out some more? I'll also note LGTM!
Code change:
authorization by verifying that the authenticated identity has the appropriate permissions to access the requested resources and perform required actions.  This process involves evaluating the security <del> context described previously.  The workload validates security context, checks validity of permissions against its security policies to ensure that only authorized actions are allowed. </del> <ins> context described previously.  The workload validates the security context, and checks the validity of permissions against its security policies to ensure that only authorized actions are allowed. </ins> 3.2.4. <del> TBD. </del> <ins> When source workloads send authenticated requests to destination workloads, those destination workloads may rely on upstream dependencies to fulfill such requests.  Such access patterns are increasingly common in a microservices architecture.  While X.509 certificates can be used for point-to-point authentication, such services relying on upstream microservices for answers, may use delegation and/or impersonation semantics as described in RFC 8693 OAuth 2.0 Access Token Exchange. WIMSE credentials constrain the subjects and actors identified in delegation and impersonation tokens to be bound by TrustDomains, and to follow their issuing authorities' trust configurations.  Upstream workloads should consider the security context of delegation and/or impersonation tokens within and across Trust Domains, when arriving at authorization decisions. </ins> 3.2.5. <del> TBD. </del> <ins> Source workloads may send authenticated asynchronous and batch requests to destination workloads.  A destination workload may need to fulfill such requests with requests to authorized upstream protected resources and workloads, after the source workload credentials have expired.  Credentials identifying the original source workload as subject may need to be obtained from the credential issuing authority with appropriately-downscoped context needed access to upstream workloads.  These credentials should identify the workload as the actor in the actor chain, but may also identify other principals that the action is taken on behalf.  To mitigate risks associated with long-duration credentials, these credentials should be bound to the workload identity credential such as an X.509 certificate or Workload Identity Token (WIT) of the acting service performing asynchronous computation on the source workload's behalf. </ins> 3.2.6.

Related discussion:
text: Fixed some of the wording and parallelism in the intro to keep the same ordering of X.509 certificates followed by Workload identity tokens. Generalized some of the phrasing. Removed concepts that aren't well defined in the document, such as "bottom turtle". I'm not opposed to adding these, I just don't think they make sense without an explanation of the analogy either inline or by-reference; so I tended towards keeping the document self-contained. Provided initial content for the Delegation and Impersonation, and Asynchronous and Batch Requests sections.
Code change:
The must-revalidate directive is necessary to support reliable operation for certain protocol features.  In all circumstances a cache MUST obey the must-revalidate directive; in particular, if a <del> cache cannot reach the origin server for any reason, it MUST generate a </del> <ins> cache is disconnected, it MUST generate a </ins> response.

Related discussion:
text: For .
Caching still refers to a "disconnected" state, as well as "cannot reach" and similar states. This needs to be rationalised. See thread: URL
Should wait for resolution of .
I'm inclined to move the definition of "disconnected" up into "overview of cache operation" and refer to it consistently -- including when "cannot be reached" is used.
Wow, that is a bad choice of word for that definition in the old text, but +1 to the change. I used to know what the right term was for that ... drawing a blank at the moment. I think it was something like "origin unreachable" or "upstream unavailable". Bah.