jiebi/CodeConvo huggingface dataset:
Code change:
A gateway that forwards requests that were received in early data MUST only do so if it knows that the origin server that receives those requests understands the "Early-Data" header field and will <del> correctly generate a 425 (Too Early) status code.  A gateway that isn't certain about origin server support SHOULD either delay forwarding the request until the TLS handshake with its client completes, or send a 425 (Too Early) status code in response.  A gateway that is uncertain about whether an origin server supports the "Early-Data" header field SHOULD disable early data. </del> <ins> correctly generate a 425 (Too Early) status code.  A gateway that is uncertain about origin server support for a given request SHOULD either delay forwarding the request until the TLS handshake with its client completes, or send a 425 (Too Early) status code in response. A gateway without at least one potential origin server that supports "Early-Data" header field expends significant effort for what can at best be a modest performance benefit from enabling early data.  If no origin server supports early data, disabling early data entirely is more efficient. </ins> 6.2.

Related discussion:
text: Hopefully none of this collides with other PRs in flight.
I think it's fine with this. Adding a bit of pragmatism as you did in the last commit also reminds that the low cost of retrying is not worth a lot of trouble :-)
Code change:
will be available to support them. An Issuer that knows of a changed state of quality for an Artifact, <del> SHOULD Register a new Signed Statement, using the same "13" CWT "iss" </del> <ins> SHOULD Register a new Signed Statement, using the same "15" CWT "iss" </ins> and "sub" claims. Issuers MUST ensure that the Statement payloads in their Signed

Related discussion:
text: Define equivocation and non-equivocation and cite the article that coined the term in analyzing Lamport. Closes ietf-wg-scitt/draft-ietf-scitt-architecture.
I think this reference from the CT rfc is useful. URL "and (2) by violating its append-only property by presenting two different, conflicting views of the Merkle Tree at different times and/or to different parties." this is equivocation. If we replace "Merkle Tree" with "collection of statements". And that reference is also careful to cast things interms of detectability rather than prevention
This is very useful, thanks. I will adjust with this and your other feedback, most appreciated!
Who reads papers anyway? Jokes aside, thanks for the contributions and making me think about how to communicate clearly on this one.
Define the term non-equivocation formally as it relates to this architecture document, per URL
I like those changes. Reads clean to me thanksLGTM Thanks, NAME for the iterations. This was a tricky one to summarize an entire paper in a few sentences
Code change:
where "d(0)" is the payload.  This algorithm takes no extra data. <ins> 4.2. The "CCF_SHA256" tree algorithm uses the Merkle tree definition from TBD with SHA-256 hash algorithm. For n > 1 inputs, let k be the largest power of two smaller than n. where "d(0)" is computed as: with extra data defined as: </ins> 5. TBD

Related discussion:
text: Informal references: URL URL TODO: Add CCF reference to Merkle tree definition (including details on the leaves). Change target branch to after is merged.
Code change:
stored response) or if transmission of the representation body is not desired even if it has changed. <del> When a cache makes an inbound HEAD request for a given request target and receives a </del> <ins> When a cache makes an inbound HEAD request for a given target URI and receives a </ins> response, the cache SHOULD update or invalidate each of its stored GET responses that could have been selected for that request (see

Related discussion:
text: NAME please review.
Roy noticed that we use a special meaning of "invalidate" and then define it pretty casually below. This can be improved.
Code change:
A number indicating the streaming format type.  Every MoQ Streaming Format normatively referencing this catalog format MUST register <del> itself in the "MoQ Streaming Format Type" table.  See iana for additional details. </del> <ins> itself in the "MoQ Streaming Format Type" table.  See ianaconsiderations for additional details. </ins> 3.2.2.

Related discussion:
text: I suggest creating an IANA registry for catalog fields with values auto-populated from Section 3.2.
What is the point of shifting the catalog fields definitions to IANA? IANA is useful for ensuring global uniqueness. If a single specification defines the catalog format, then that spec if a much more efficient and natural place to define the fields used by that format.
If we end up needing new fields (which we certainly will), we don't need a revised RFC. The fields table can be amended/expanded in a number of ways.
Code change:
The endpoint detected that its peer violated the flow control protocol. <del> The endpoint received a frame for an inactive stream. </del> The endpoint received a frame after a stream was half-closed. The endpoint received a frame that was larger than the maximum

Related discussion:
text: It is no longer used after d5a8faeaa605bdff7b96287d72913b4b742104cf
I've avoided renumbering of codes when removing things. We probably need to have a big renumber event at some point, but there is no harm in having gaps for now.
Thanks Martin. It makes it easier for us on the SPDY side :) On Wed Jun 12 2013 at 9:37:50 AM, martinthomson EMAIL wrote:
NAME I've updated the commit just to remove only the unused error code. Please don't forget to renumber others in the future.
Code change:
_RFC Editor: please remove this section before publication_ Source code and issues for this draft can be found at <del> https://github.com/fiestajetsam/I-D/tree/main/draft-gruessing-moq- requirements [1]. </del> <ins> https://github.com/fiestajetsam/draft-gruessing-moq-requirements [1]. </ins> 1.

Related discussion:
text: This adds a few requirements ripped from my blog post, and cleans out use cases and such.
I have some thoughts about the content of this PR, but let's merge it, and see if my thoughts turn into text :-)
Code change:
service, or introduce a wide range of malicious side-effects. The authorization server and client MUST sanitize (and validate when <del> possible) any value received -- in particular, the value of the </del> <ins> possible) any value received - in particular, the value of the </ins> "state" and "redirect_uri" parameters. 7.18.

Related discussion:
text: uses the ::boilerplate macro of URL
I'm not sure what I'm doing wrong but when I try this I get an error: I'm using kramdown-rfc2629 version 1.4.3
fixed in URL NAME
Friendly reminder ;)
PTAL
Code change:
verified. The security of the Issuer-signed JWT depends on the security of the <del> signature algorithm.  Any of the JSON Web Signature and Encryption Algorithms registered in IANA.JWS.Algorithms can be used, including </del> <ins> signature algorithm.  Any of the JWS asymmetric digital signature algorithms registered in IANA.JWS.Algorithms can be used, including </ins> post-quantum algorithms, when they are ready. 9.2.

Related discussion:
text: first pass at addressing Issue and .
Does this touch all the mentions of random in URL and convey what the feedback was looking for? I'm honestly not sure. But I also think it doesn't really need changes in that area so I'm not too worried about it. So why am I writing this note? Good question. Just trying to "contribute" I guess.
Approved with the proposed changes.
Code change:
A consumer of a released software wants: to understand if a particular provider is actually the original <del> provider or a promoter, </del> <ins> provider or a promoter </ins> to know if and how the source, or resulting binary, of a promoted <del> software component differs from the original software component, </del> <ins> software component differs from the original software component </ins> to check the provenance and history of a software component's <del> source back to its origin, and </del> <ins> source back to its origin </ins> <del> to assess whether to trust a promoter or not. </del> <ins> to assess whether to trust a promoter or not </ins> There is no standardized way to:

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:
of 401 (Unauthorized).  Such authentication failures can be caused for example by: * absence of the Authorization field * failure to parse the Authorization field * use of the Signature authentication <del> scheme with an unknown key ID * failure to validate the signature. </del> <ins> scheme with an unknown key ID * failure to validate the verification parameter * failure to validate the signature. </ins> Such servers MUST also ensure that the timing of their request handling does not leak any information.  This can be accomplished by

Related discussion:
text: In the current draft, the header is composed as: The server computes the nonce from the TLS key material exporter and verifies the signature. This doesn't actually guarantee freshness, because its possible for parties to construct signatures which are valid for any message/nonce. This means that a party which does not have access to the TLS Export material can still inject a valid Auth header. I don't think that's a major problem, but it is a bit unintuitive and its hard to predict how drafts like this will eventually get deployed. A simple fix would be in to add an additional parameter, say which is or similar and have servers check its been correctly computed. This ensures that only parties that can access TLS key material can inject valid headers. Behind the scenes, this attack / fix works because hash functions have to be collision resistant for all inputs, whereas signatures don't have to satisfy any properties if the associated public key was generated maliciously. has a longer discussion.
Thanks! This sounds like an easy fix. Instead of a hash, we could also generate more bytes from the key exporter and use some for the nonce and some for the parameter
Wrote up to fix this
Code change:
4.1. <del> (TODO: Describe properties of wired networks.) Proposals should be investigated for robust performance with different queueing mechanisms in the routers, especially Random Early Detection (RED) FJ03 and Drop-Tail.  This evaluation is often not included in the internet-draft itself, but in related papers cited in the draft. </del> <ins> Wired networks are characterized by extremely low rates of packet loss except for those due to queue drops.  They tend to have stable aggregate bandwidth, usually higher than other types of links, and low non-queueing delay.  Because the properties are relatively simple, wired links are typically used as a "baseline" case even if they are not always the bottleneck link in the modern Internet. </ins> 4.2.

Related discussion:
text: Also eliminated obsolete/redundant discussion of AQM.
We missed a TODO in "Wired Networks"
Approved. Is "As" really "Because" ?
Code change:
attribute-name of "Path", and the cookie's path is "/". If the cookie-name is empty and either of the following conditions <del> are true, abort these steps and ignore the cookie: </del> <ins> are true, abort these steps and ignore the cookie entirely: </ins> the cookie-value begins with a case-insensitive match for the string "__Secure-"

Related discussion:
text: A number of minor misc changes and corrections to improve readability, usability, and consistency throughout the spec.
6265bis is nearly ready, but after years of changes there are probably some minor editorial issues that should be corrected. Someone (me) should proofread it and fix any problems found.
The RFC Editor will help with that.
Ah, good to know. I'll still give it a first pass to clean it up a bit.
LGTM.
Code change:
At any point, for any reason determined by the resource server, the protected resource MAY respond with a new "WWW-Authenticate" challenge that includes a value for the protected resource metadata <del> URL to indicate that its metadata MAY have changed.  If the client </del> <ins> URL to indicate that its metadata may have changed.  If the client </ins> receives such a "WWW-Authenticate" response, it SHOULD retrieve the updated protected resource metadata and use the new metadata values obtained, after validating them as described in

Related discussion:
text: from review comments from John Scudder
Please also add John Scudder to the acknowledgements.
Code change:
If the final character of input_number is ".", fail parsing. If the number of characters after "." in input_number is <del> greater than six, fail parsing. </del> <ins> greater than three, fail parsing. </ins> <del> Parse input_number as a float and let output_number be the product of the result and sign. </del> <ins> Parse input_number as a decimal number and let output_number be the product of the result and sign. </ins> Return output_number.

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:
If the final character of input_number is ".", fail parsing. If the number of characters after "." in input_number is <del> greater than six, fail parsing. </del> <ins> greater than three, fail parsing. </ins> <del> Parse input_number as a float and let output_number be the product of the result and sign. </del> <ins> Parse input_number as a decimal number and let output_number be the product of the result and sign. </ins> Return output_number.

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:
If the final character of input_number is ".", fail parsing. If the number of characters after "." in input_number is <del> greater than six, fail parsing. </del> <ins> greater than three, fail parsing. </ins> <del> Parse input_number as a float and let output_number be the product of the result and sign. </del> <ins> Parse input_number as a decimal number and let output_number be the product of the result and sign. </ins> Return output_number.

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 the final character of input_number is ".", fail parsing. If the number of characters after "." in input_number is <del> greater than six, fail parsing. </del> <ins> greater than three, fail parsing. </ins> <del> Parse input_number as a float and let output_number be the product of the result and sign. </del> <ins> Parse input_number as a decimal number and let output_number be the product of the result and sign. </ins> Return output_number.

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:
OPTIONAL.  JSON array containing a list of the OAuth 2.0 Bearer Token RFC6750 presentation methods that this protected resource <del> supports.  Defined values are "["header", "fragment", "query"]", </del> <ins> supports.  Defined values are "["header", "body", "query"]", </ins> corresponding to Sections 2.1, 2.2, and 2.3 of RFC 6750.

Related discussion:
text: This fixes the definition, it incorrectly used "fragment" when it meant "body" as later shown in section-3.2