jiebi/CodeConvo huggingface dataset:
Code change:
the authorization server's metadata document (RFC8414). The authorization endpoint URL MUST NOT include a fragment component, <del> and MAY include an "application/x-www-form-urlencoded" formatted query component WHATWG.URL, which MUST be retained when adding additional query parameters. </del> <ins> and MAY include a query string component query-string-serialization, which MUST be retained when adding additional query parameters. </ins> The authorization server MUST support the use of the HTTP "GET" method Section 9.3.1 of RFC9110 for the authorization endpoint and

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:
trust domains. A client in trust domain A that needs to access a resource server in <del> trust domain B requests an authorization grant from the authorization server for trust domain A via a token exchange.  The client in trust domain A presents the received grant as an assertion to the authorization server in domain B in order to obtain an access token for the protected resource in domain B.  The client in domain A may be a resource server, or it may be the authorization server itself. </del> <ins> trust domain B requests a JWT authorization grant from the authorization server for trust domain A via a token exchange.  The client in trust domain A presents the received grant as an assertion to the authorization server in domain B in order to obtain an access token for the protected resource in domain B.  The client in domain A may be a resource server, or it may be the authorization server itself. </ins> 2.1.

Related discussion:
text: when "authorization grant" refers to the actual JWT being passed around, it is clearer to call it "JWT authorization grant". RFC6749 uses "authorization grant" to refer to the general concept of any grant
Code change:
The upload resource URL is the identifier used for modifying the upload.  Without further protection of this URL, an attacker may obtain information about an upload, append data to it, or cancel it. To prevent this, the server SHOULD ensure that only authorized clients can access the upload resource.  In addition, the upload resource URL SHOULD be generated in such a way that makes it hard to be guessed by unauthorized clients. <ins> Some servers or intermediaries provide scanning of content uploaded by clients.  Any scanning mechanism that relies on receiving a complete file in a single request message can be defeated by resumable uploads because content can be split across multiple messages.  Servers or intermediaries wishing to perform content scanning SHOULD consider how resumable uploads can circumvent scanning and take appropriate measures.  Possible strategies include waiting for the upload to complete before scanning a full file, or disabling resumable uploads. </ins> 11. IANA is asked to register the following entries in the "Hypertext

Related discussion:
text: As brought up in , resumable uploads may interfere with intermediaries scanning the request content. This PR adds a paragraph in the security considerations. Closes URL
Some security measures that involve looking at incoming HTTP requests might be circumvented by resumable uploads. For example, a filter which looks for certain HTTP headers and corresponding text in the request payload might not be triggered when the header occurs in one request and the matching body fragment in a subsequent request. I don't believe there's anything we need to change about the protocol here, but it's probably mentioning this in Security Considerations. Perhaps guidance would be to ensure any security measures are either resumable-upload-aware or are explicitly called to inspect the final request between receipt of the last chunk and execution of the original request.
Thank you, that is a good point. I have opened to add a paragraph in this regard. Please let me know if that expresses the problem correctly.
Code change:
and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. <ins> Special appreciation is extended to Martin Thomson, who wielded his considerable intellect and influence to change a single occurrence of the word "to" to "with" in the midst of a significant proposal that would be integrated into this document six months later. </ins> The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway.

Related discussion:
text: Acknowledge Martin Thomson for his contribution: URL
Open for one week. No approvals. No objections. One minor editorial change applied. Will continue to wait.
If this is this acceptable, I love it
Code change:
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 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. </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 received in response which contains a prefix information option

Related discussion:
text: NAME The new sections need to go in just after all the "", otherwise the XML doesn't build (order is fixed).
Question on the cases included: isn't there a case possible where network is managed and is IPv6 only DHCPv6 addressing is used (as intended by operator) - assume DHCPv6 hands out ULA addresses no RA-Guard is applied user brings stub router, plugs it in, and it advertises a ULA prefix in PIO other devices on the link start configuring a SLAAC IPv6 address and try to use this to communicate (and routing fails because the DHCP managed ULA was not used as the source, but rather the SLAAC based ULA) But maybe this is not relevant because the source address selection algorithm would always pick the correct, managed ULA due to a better prefix match with the IPv6 destination address ?
Regarding the DHCPv6-only use case, we are assuming that the network operator wants to control which devices have addresses on the local link. In this case, they MUST use RA Guard. If they do not, then there is no protection against random devices sending RAs. So this would be a misconfiguration, and hence we don't need to do anything about it.
NAME Right, I also agree we don't have to do anything about solving this "problem" other than pointing to RA guard. But still I think it's worth mentioning: it's the one identified corner case where the SNAC router has unwanted side effects. I wasn't even sure if I was correct in predicting the effects. Considering that there is I think no other IETF-specified / IETF-compliant device that, when plugged in, would instantly disrupt this network in the way that the stub router does. If this is the worst case we can find, it should actually show that our stub router is good to go.
During email discussion in 2023, there were worries that placing a SNAC stub router in a network (with its default configurations) would disturb / harm the existing network / AIL. For example due to the advertising of extra prefixes, or advertising particular (deviating?) values of bits, routes or time-durations in the RA. One proposed solution was to provide a taxonomy (e.g.
Code change:
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 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. </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 received in response which contains a prefix information option

Related discussion:
text: an appendix) that explains which particular topologies/configurations a SNAC stub router can work, and in which ones it doesn't work, and in which ones it can cause malfunctions (if any). Some examples: stub router doesn't work in a network that has RA-guard in a network without RA guard, and where no suitable prefix is advertised on AIL, stub router can "disrupt" by advertising its ULA prefix. In this case we assume the ULA prefix is not intended by the admin. (Maybe the admin and/or network users should know better here, but anyhow it's a possibility.) Having a better overview of success/fail cases also helps reviewers of the document to judge the risk. FYI here's a pointer to one of the messages in the thread of 2023 that summarizes some cases and how it could be documented: URL
PR resolves this issue.
In -04, "'L' bit is set" is required for a suitable prefix. However section 5.1.2.3 allows sending PIO with L flag cleared, in particular cases. This leads to the issue that the generated PIO AIL prefix won't be recognized as a "suitable prefix" by other stub routers. So the requirement "'L' bit is set" must be relaxed for particular link layer technologies where L=0. Taking one step back – I just tried to summarize SNAC stub router scenario archetypes; both good and bad. Of the below it seems that only scenario 4 is now discussed as having a risk of breaking the network, correct? 1) Non-expert home user connects stub router to own unmanaged home network; it magically works and provides IPv6 stub/AIL routing – no matter whether user’s ISP offers IPv6 or not.
Code change:
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 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. </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 received in response which contains a prefix information option

Related discussion:
text: 2) Ignorant employee brings stub router to work and plugs it into well-managed network; companies’ IT network magically protects the network from ill effects (RA guard, and/or port-based access control, … ) 3) Ignorant employee brings stub router to work and plugs it into unmanaged (IPv6) network; nothing bad happens - there’s already a PIO prefix with ‘A’ on the AIL 4) Ignorant employee brings stub router to work and plugs it into not-so-well managed DHCPv6-only network; stub router sends RA PIO; many hosts on the link now autoconfigure a ULA which somehow breaks connectivity for these existing hosts. 5) Ignorant network admin connects stub router to company network without changing the default settings; then it becomes similar to 4. This case is btw probably out of our scope to solve and could be solved by the mantra “don’t do that then”. (The stub router is only intended for case 1, but of course the stub router cannot tell apart cases 1,4,5.) +1 on clearly defining the possible breakage scenarios. E.g. some devices may not configure multiple addresses and get stuck with a ULA only? Or known issues with source address selection; IPv4 interactions, etc. in presence of ULAs. When doing this the Type A, B and C IPv6 hosts may also be considered. If we find no issues then we may also state this in the draft in an Appendix – what was considered, and why it isn’t a problem. Esko From: Lorenzo Colitti Sent: Friday, September 8, 2023 11:38 To: Ole Trøan Cc: Lorenzo Colitti ; Ted Lemon ; Juliusz Chroboczek ; Esko Dijk ; Michael Richardson ; Handa Wang ; EMAIL Subject: Re: [Snac] Should a stub router learn RA header parameters from other routers? I am not OK with a SNAC router connecting to an existing IPv6 network and breaking it. If you can elaborate on the type of breakage you are concerned about, then we can discuss it and possibly design for it. FWIW, just the fact of the hosts getting new addresses does not qualify as breakage IMO. All IPv6 hosts have multiple addresses and source address selection generally gets hosts to do the right thing.
Code change:
the "*created" identifier. Its canonicalized value is an Integer String containing the <del> signature's Creation Time expressed as the number of seconds since the Epoch, as defined in Section 4.16 [2] of POSIX.1. </del> <ins> signature's Creation Time expressed in "Unix time". </ins> The use of seconds since the Epoch to canonicalize a timestamp simplifies processing and avoids timezone management required by

Related discussion:
text: reuses existing definitions for S-F and Unix time.
Doesn't make this PR redundant? (or regressive, really, because references the exact definitions to use - and from structured headers)
This probably
Code change:
If input_item is an integer, return the result of running Serializing an Integer (ser-integer) with input_item. <del> If input_item is a float, return the result of running Serializing a Float (ser-float) with input_item. </del> <ins> If input_item is a decimal, return the result of running Serializing a Decimal (ser-decimal) with input_item. </ins> If input_item is a string, return the result of running Serializing a String (ser-string) with input_item.

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 input_item is an integer, return the result of running Serializing an Integer (ser-integer) with input_item. <del> If input_item is a float, return the result of running Serializing a Float (ser-float) with input_item. </del> <ins> If input_item is a decimal, return the result of running Serializing a Decimal (ser-decimal) with input_item. </ins> If input_item is a string, return the result of running Serializing a String (ser-string) with input_item.

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 input_item is an integer, return the result of running Serializing an Integer (ser-integer) with input_item. <del> If input_item is a float, return the result of running Serializing a Float (ser-float) with input_item. </del> <ins> If input_item is a decimal, return the result of running Serializing a Decimal (ser-decimal) with input_item. </ins> If input_item is a string, return the result of running Serializing a String (ser-string) with input_item.

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 input_item is an integer, return the result of running Serializing an Integer (ser-integer) with input_item. <del> If input_item is a float, return the result of running Serializing a Float (ser-float) with input_item. </del> <ins> If input_item is a decimal, return the result of running Serializing a Decimal (ser-decimal) with input_item. </ins> If input_item is a string, return the result of running Serializing a String (ser-string) with input_item.

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:
11. <del> This specification registers the following entry in the Permanent Message Header Field Names registry established by RFC3864: </del> <ins> IANA is asked to register the following entries in the "Hypertext Transfer Protocol (HTTP) Field Name Registry": </ins> <del> Header field name: Upload-Offset, Upload-Complete Applicable protocol: http Status: standard Author/change controller: IETF Specification: This document Related information: n/a This specification registers the following entry in the "HTTP Status </del> <ins> IANA is asked to register the following entry in the "HTTP Status </ins> Codes" registry: <del> Code: 104 (suggested value) Description: Upload Resumption Supported Specification: This document </del>

Related discussion:
text: IANA early review highlighted that we were attempting to register to the old table. Lets fix that and do a little more tidyup.
Thank you!
Code change:
[2] https://www.iana.org/assignments/params/params.xhtml <del> [3] https://www.iana.org/assignments/media-types/media-types.xhtml </del> <ins> [3] https://www.iana.org/assignments/jwt/jwt.xhtml [4] https://www.iana.org/assignments/media-types/media-types.xhtml </ins>

Related discussion:
text: [8:31 AM May 30 in slack] To summarize the near term plan: Joe: security considerations and interaction with TLS Brian: ID Token and DPoP-inspired Yaron: Message Signatures this is the "DPoP-inspired" part A preview editors' copy of this PR can be seen at URL