jiebi/CodeConvo huggingface dataset:
Code change:
parameters in specific circumstances, each described in detail in their own sections: <ins> Multiple parameters MAY be specified together, though some combinations are redundant or incompatible.  For example, the "sf" parameter's functionality is already covered when the "key" parameter is used on a dictionary item.  The "bs" parameter, which requires the raw field values from the message, is not compatible with use of the "sf" or "key" parameters, which require the parsed data structures of the field values after combination. </ins> Additional parameters MAY be defined in a registry established in param-registry. 2.1.1. If the value of the the HTTP field in question is known by the <del> application to be a structured field (STRUCTURED-FIELDS), the component identifier MAY include the "sf" parameter to indicate it is a known structured field.  If this parameter is included with a component identifier, the HTTP field value MUST be serialized using the rules specified in STRUCTURED-FIELDS applicable to the type of the HTTP field.  Note that this process will replace any optional internal whitespace with a single space character, among other potential transformations of the value. </del> <ins> application to be a structured field (STRUCTURED-FIELDS), and the expected type of the structured field is known, the signer MAY include the "sf" parameter in the component identifier.  If this parameter is included with a component identifier, the HTTP field value MUST be serialized using the rules specified in STRUCTURED- FIELDS applicable to the type of the HTTP field.  Note that this process will replace any optional internal whitespace with a single space character, among other potential transformations of the value. Processing of this parameter MUST occur after multiple field values have been combined into a single List or Dictionary structure. </ins> For example, the following dictionary field is a valid serialization:

Related discussion:
text: This adds a binary wrapper for fields that don't follow the List or Dictionary format for multiple values, such as Set-Cookie. The wrapper is selected using the parameter, and the component value is made by wrapping each individual field value in a Byte Sequence and putting them into a List, then doing a strict serialization on those values.
In general, is this even needed or are we over-engineering here? If the main use case is , do we think it is likely to be signed?
Some fields, like , have an internal syntax that allows unquoted commas and messes things up when multiple lines are combined for the signature base, leading to the potential case where two semantically different inputs have the same signature base. This means that: And: Both produce the same signature input line: Even though the two-line and single-line versions are processed differently by the application. To counter this, we could have a distinct encoding flag that wraps the field values, similar to . This can be used to protect problematic fields like Set-Cookie so that we get something like this for the multiple line version: But you'd get this for the single-line version: The background of this has been discussed in and
Code change:
network SHOULD advertise reachability to all such prefixes on any AIL to which it is attached using router advertisements. <del> A SNAC router SHOULD NOT advertise itself as a default router on an AIL by setting a non-zero Router Lifetime value in the header of its Router Advertisements.  The exception to this rule is the case where the SNAC router itself is the default router for a particular AIL: for example, it may be the home router providing connectivity to an ISP. </del> <ins> A SNAC router MUST NOT advertise itself as a default router on an AIL by setting a non-zero Router Lifetime value in the header of its Router Advertisements. </ins> 5.4.

Related discussion:
text: Because CE routers are infrastructure
This addresses
NAME could we change "customer edge router" to "home gateway" (per our official terminology )? I see now also the RFC reference in the PR is incorrect (rfc 704).
the text in this section can be confusing when dealing with 2 usable prefixes (see section 5.2.1.4 - ULA/non-ULA). In MCR's words: if there are two suitable prefixes, one of them will still need to be deprecated. According to Ted, this issue is orthogonal to reachability. Perhaps, we should explain that this state-machine does not talk about reachability for both the suitable prefixes. At least give forward reference to section 5.4 for complete behavior. This will explain that we can only transition to STATE-BEGIN-ADVERTIZING and in no case we transition to STATE_USABLE
I think the issue here is not about usable prefixes, but about routes. Suppose we have a DHCPv6 prefix, and the DHCPv6 server doesn't renew it. In this case, we probably want to stop advertising it at some point and start advertising a prefix based on our site ULA. We should talk about the timing of this switch-over. Separately, whenever we have advertised a prefix on either link, we need to continue advertising a route to that prefix until the prefix is no longer valid on the link on which we advertised it. So if we switch from DHCPv6 prefix to ULA prefix on infrastructure, we need to be advertising routes to both for as long as both are valid. Similarly, if we advertise a prefix on the stub network and later withdraw it because a higher-priority prefix is advertised there, we need to continue advertising a route to that prefix on the infrastructure link until the valid lifetime of the prefix we advertised has expired. I think all routers that have seen the prefix need to do this. Then there's the case where a stub router advertising a prefix reboots. We can't assume that it's written anything to stable storage other than what prefix it's allocated for the stub network and for the infrastructure network. So when the router comes up after booting, it needs to advertise routes to these prefixes on the appropriate link until the maximum possible valid lifetime for the prefix has expired.
Code change:
network SHOULD advertise reachability to all such prefixes on any AIL to which it is attached using router advertisements. <del> A SNAC router SHOULD NOT advertise itself as a default router on an AIL by setting a non-zero Router Lifetime value in the header of its Router Advertisements.  The exception to this rule is the case where the SNAC router itself is the default router for a particular AIL: for example, it may be the home router providing connectivity to an ISP. </del> <ins> A SNAC router MUST NOT advertise itself as a default router on an AIL by setting a non-zero Router Lifetime value in the header of its Router Advertisements. </ins> 5.4.

Related discussion:
text: And finally there's the DHCPv6 case, where we got a prefix to advertise on the stub network via DHCPv6. In this case, I think we need to write the DHCPv6 prefix to stable storage when we get it, and remove it from stable storage when it expires. We should limit the lifetime we advertise on the stub network to a constant value (e.g. 30 minutes), and then if we find the DHCPv6 prefix recorded in stable storage, we advertise a route to it on infrastructure for 30 minutes after reboot. After 30 minutes, we can erase it from stable storage so that this doesn't repeat. I think if the BR doesn't have stable storage, then if it reboots with a DHCPv6 prefix still valid on the stub network, we just have to hope that it gets the same prefix when it comes back. If it does not, then that prefix may become unreachable while hosts on the stub network are still using it. We could have the stub network snoop source addresses to discover prefixes still in use on the stub network to ameliorate this situation, but that's somewhat problematic because it's a lot of work.
I think the conclusion of the WG is that we need to have an explicit state machine for the stub router on-link prefix because it's actually quite different from the state machine for infrastructure, where for example we do not need to do DHCP. Important to mention that we need to explicitly deprecate the DHCP prefix if we switch to ULA and vice versa.
One of the things that this state machine needs to talk about is what happens if the SNAC router sees an RIO on /its/ stub network that does not have the SNAC router flag bit set. In this case, the SNAC router should treat this network as an infrastructure network and should not perform SNAC router routing functions or service discovery functions between the two networks. Essentially in this case the SNAC router functionality should be completely disabled while such an RA is seen on the stub network.
Code change:
4.1.5. <del> Given a decimal_number as input_decimal, return an ASCII string </del> <ins> Given a decimal number as input_decimal, return an ASCII string </ins> suitable for use in a HTTP field value. <ins> If input_decimal is not a decimal number, fail serialisation. If input_decimal has more than three significant digits to the right of the decimal point, round it to three decimal places, rounding the final digit to the nearest value, or to the even value if it is equidistant. If input_decimal has more than 12 significant digits to the left of the decimal point after rounding, fail serialisation. </ins> Let output be an empty string. If input_decimal is less than (but not equal to) 0, append "-" to

Related discussion:
text: Round to three decimal places first, then check the domain, then do all the actual serialising. It's potentially not very l13n-friendly; feel free to change "decimal point" or "to the left" etc., if something is more appropriate.
... still isn't right, as Kari noticed. E.g., a value of won't get rounded to .
Step 1 of all serialisation algorithms could be related to sanitising/casting/failing-on noncanonical data. Turn your random number into a Decimal, including rounding to three digits. Fail if it's or no worries from here on Actually, Key, Integer, String, Token, Byte Sequence, and Boolean already do this, so Decimal is the only scalar type that doesn't.
With the current algorithm, if it is allowed as input, -0.0004 will get serialized as , rather than . corrects that as well.
Code change:
the protected resource MAY respond with a new "WWW-Authenticate" challenge that includes a value for the protected resource metadata URL to indicate that its metadata MAY have changed.  If the client <del> receives such a "WWW-Authenticate" response, the client SHOULD retrieve the protected resource metadata again, and SHOULD use the new metadata values obtained.  Among other things, this enables a resource server to change which authorization servers it uses without any other coordination with clients. </del> <ins> receives such a "WWW-Authenticate" response, it SHOULD retrieve the updated protected resource metadata and use the new metadata values obtained.  Among other things, this enables a resource server to change which authorization servers it uses without any other coordination with clients. </ins> 5.3.

Related discussion:
text: cc NAME
[ ] Step 5, add reference to how to validate: "...according to the validation steps described in Section 2.1 (validation of signed resource metadata if it applies) and Section 3.3" [ ] Step 5.2: rephrase to "If the client receives such a WWW-Authenticate response, it SHOULD retrieve the updated protected resource metadata and use the new metadata values obtained."
Looks good to me.
Code change:
the others deprecated.  By using this approach, it is not necessary for the routers to coordinate in advance. <del> 6.5. </del> <ins> 8. </ins> In order to provide network access, stub routers must provide some network services to the stub network.  We have previously discussed

Related discussion:
text: Didn't have time to add a state machine, but documented the ways that NAT64 advertising can happen.
There is a set of possible circumstances that we need to think about for infrastructure-provided NAT64: There is PD support, and infra is providing NAT64 There is no PD support, infra is providing NAT64, and there is no IPv4 on infra There is no PD support, infra is providing NAT64, and there is IPv4 on infra There is PD support, infra is not providing NAT64, infra is providing IPv4 In case (1), we can (and should) use the infrastructure-provided NAT64 service. In case (2), we have no way to do NAT64, because we don’t have a infrastructure-routable OMR prefix on the Thread mesh. So in this case, reachability to the cloud, both for IPv4 and IPv6, is not available. In case (3), although infrastructure is providing NAT64, we can’t use it. There is no IPv6 reachability to the internet, but a BR can provide its own NAT64 service to enable reachability to the internet over IPv4. In case (4), BR can provide NAT64 for IPv4 reachability to the internet, but additionally IPv6 reachability to the internet is present. Add text to the document to describe how we handle these situations, including state machine if appropriate.
Code change:
An 8-bit field reserved for frame-type specific boolean flags. <del> The least significant bit (0x1) - the FINAL bit - is defined for all frame types as an indication that this frame is the last the endpoint will send for the identified stream.  Setting this flag causes the stream to enter the StreamHalfClose.  Implementations MUST process the FINAL bit for all frames whose stream identifier field is not 0x0.  The FINAL bit MUST NOT be set on frames that use a stream identifier of 0. </del> <ins> The least significant bit (0x1) - the END_STREAM bit - is defined for all frame types as an indication that this frame is the last the endpoint will send for the identified stream.  Setting this flag causes the stream to enter the StreamHalfClose. Implementations MUST process the END_STREAM bit for all frames whose stream identifier field is not 0x0.  The END_STREAM bit MUST NOT be set on frames that use a stream identifier of 0. </ins> The remaining flags can be assigned semantics specific to the indicated frame type.  Flags that have no defined semantics for a

Related discussion:
text: This branch also renames the FINAL flag to ENDSTREAM and the CONTINUES flag to ENDHEADERS.
Address
I'll take it, and we can continue to discuss the redundant bit.
Code change:
Upon parsing this name, "dot%5C.label" MUST be treated as a single label. <del> Similarly the "\" character in a label MUST be escaped as "\\". Other uses of "\" MUST NOT appear in the label after percent- decoding. </del> <ins> Similarly the "\" character in a label MUST be escaped as "\\" and then percent-encoded.  Other uses of "\" MUST NOT appear in the label after percent-decoding.  For example, if there is a DNS name "backslash\name.example.com", it would first be escaped as "backslash\\name.example.com", and then percent-encoded as follows: </ins> 3.

Related discussion:
text: From the list: At the end of Section 2.1 in URL, there is this: Can that last line be expounded on and clarified? Will a "\" character in a label be 'eventually' encoded as "\" or "%5C%5C" or some combination of them?
I think we can add an example for this
Code change:
A client cannot push.  Thus, servers MUST treat the receipt of a PUSH_PROMISE frame as a ConnectionErrorHandler of type <del> PROTOCOL_ERROR.  Clients MUST reject any attempt to change the SETTINGS_ENABLE_PUSH setting to a value other than 0 by treating the message as a ConnectionErrorHandler of type PROTOCOL_ERROR. </del> <ins> PROTOCOL_ERROR.  A server cannot set the SETTINGS_ENABLE_PUSH setting to a value other than 0 (see SettingValues). </ins> 8.2.1.

Related discussion:
text: The previous text implied that a value of 1 was a problem, which was somewhat in tension with the default being 1 and servers mostly not sending the setting. So clearly what was being checked by client was the frame, not the value. This changes to checking the setting as it arrives, changes where that text lives. Also, this changes from "endpoint" to "client" or "server" as appropriate to match actual practice.
The definition of ENABLEPUSH implies that it can be set to 0 by a server, but the effect of that is meaningless as it results in treating PUSHPROMISE as an error. PUSH_PROMISE can't be sent by a client. Should we update the definition?
I don't think it's a good idea to start forbidding ENABLEPUSH = 0 from servers. It's clearly acceptable from the perspective of the RFC, and while it's a silly waste of bytes it doesn't introduce any protocol ambiguity. I do think we should clean up the text in § 6.5.2, which currently reads: However, Section 8.2 implies the default value for servers is 0: Arguably these two sections should be reconciled. In principle we could simply say that the value of ENABLEPUSH has no effect for servers, as the protocol forbids servers from pushing anyway, and remove the requirement that clients error.
I think that you mean clients are forbidden from pushing, but otherwise I would agree. The initial value for ENABLE_PUSH is defined as 1, which muddies things further. I think that we can change the definition to say that the setting has no effect when sent by a server and drop the connection error requirement.
Would we leave the connection error as an option?
I'm inclined to remove it as being inconsistent with reality. Though we might have to note that some implementations might do that (because they haven't updated) and so advise strongly against servers sending any value for this setting.
Is it inconsistent with reality? Presumably some implementations actually do police the MUST here.
Code change:
A client cannot push.  Thus, servers MUST treat the receipt of a PUSH_PROMISE frame as a ConnectionErrorHandler of type <del> PROTOCOL_ERROR.  Clients MUST reject any attempt to change the SETTINGS_ENABLE_PUSH setting to a value other than 0 by treating the message as a ConnectionErrorHandler of type PROTOCOL_ERROR. </del> <ins> PROTOCOL_ERROR.  A server cannot set the SETTINGS_ENABLE_PUSH setting to a value other than 0 (see SettingValues). </ins> 8.2.1.

Related discussion:
text: Two things are in tension: policing probably happens in the sense that if a server sends ENABLEPUSH with any value (especially 1) a client might choke on it the initial value is 1, so those clients should probably choke on a connection preface from the server as well Removing the requirement that ENABLEPUSH result in an error avoids the second, but you need to keep a recommendation not to send it or you hit the first.
I suspect most implementations treat initial values somewhat specially, and while they enforce that they cannot receive a value of 1 from a server, they don’t prevent the server’s setting value having the value of 1.
This might be one worth circulating with the WG tbh, if only to get a sense of what existing clients actually do. We can also investigate putting together a test suite.
One minor language nit, otherwise seems great.
Code change:
graphical user agent could send a "visible" parameter to indicate if the resource being requested is within the viewport. <ins> Generic parameters are preferred over vendor-specific, application- specific or deployment-specific values.  If a generic value cannot be agreed upon in the community, the parameter's name should be correspondingly specific (e.g., with a prefix that identifies the vendor, application or deployment). 3.3.1. New Priority parameters can be defined by registering them in the HTTP Priority Parameters Registry. Registration requests are reviewed and approved by a Designated Expert, as per RFC8126, Section 4.5.  A specification document is appreciated, but not required. The Expert(s) should consider the following factors when evaluating requests: Community feedback If the parameters are sufficiently well-defined and adhere to the guidance provided in new-parameters. Registration requests should use the following template: Name: [a name for the Priority Parameter that matches key] Description: [a description of the parameter semantics and value] Reference: [to a specification defining this parameter] See the registry at https://iana.org/assignments/http-priority [4] for details on where to send registration requests. </ins> 4. The Priority HTTP header field can appear in requests and responses.

Related discussion:
text: Condensed version of .
Thanks, this looks good to me. It provides a more formal scaffold for the intent that the editors (and design team before them) had in mind for this scheme's extensibility. I do wonder if we might want to name the registry as the slightly more verbose "extensible priority parameters" but since we are not yet establishing a registry it is easy to iterate on that.
Code change:
2.5.2. <del> All of RFC7521 (Section 5.2 in specific) applies, along with the following processing rules: </del> <ins> All of Section 5.2 RFC7521 applies, in addition to the following processing rules: </ins> <del> The request MUST be denied if the presented authorization grant does not include an "aud" claim identifying the authorization server that processes the request. </del> <ins> The "aud" claim MUST identify the Authorization Server as a valid intended audience of the assertion using either the token endpoint as described Section 3 RFC7523 or the issuer identifier as defined in Section 2 of RFC8414. </ins> The authorization server SHOULD deny the request if it is not able to identify the subject.

Related discussion:
text: See
Feedback from Brian Campbell This requirement for the audience [URL] is already a requirement of [URL] (3rd bullet) and also [URL] (also 3rd bullet). But the way it's listed here makes it sound like an additional thing. It might be worthwhile to use the bullet here to be more specific about the aud value (it's been a bit of an interop pain point w/ JWT client auth fwiw) and say that it has to be the token endpoint or AS issuer identifier.
Code change:
and for n >= 1 and m > 1: <del> For compatibility with legacy list rules, a recipient MUST parse and ignore a reasonable number of empty list elements: enough to handle common mistakes by senders that merge values, but not so much that they could be used as a denial-of-service mechanism.  In other words, a recipient MUST accept lists that satisfy the following syntax: </del> <ins> Empty elements do not contribute to the count of elements present.  A recipient MUST parse and ignore a reasonable number of empty list elements: enough to handle common mistakes by senders that merge values, but not so much that they could be used as a denial-of- service mechanism.  In other words, a recipient MUST accept lists that satisfy the following syntax: Note that because of the potential presence of empty list elements, the RFC 5234 ABNF cannot enforce the cardinality of list elements, and consequently all cases are mapped is if there was no cardinality specified. </ins> <del> Empty elements do not contribute to the count of elements present. </del> For example, given these ABNF productions: Then the following are valid values for example-list (not including

Related discussion:
text: () work in progress, feedback appreciated. is the actual rule mapping correct? prose in the convered ABNF, should I add the cardinality as comment?
re 3) turns out to be hard as long as we have productions that mix list with something else (see separate issue), because we can't inline comments inside and ABNF production
NAME - your turn to review...
See . Mailing list discussion starts here:
See also
A simple fix for this would be to simplify the list expansion to just map , and to put all other constraints in prose (the current approach doesn't work anyway due to the rules for empty list elements which are not counted).
Proposal for recipient list rule mapping: More eyes requested :-) NAME NAME
The current proposal is incorrect as it does not allow a singleton element.
Maybe: better... for readability:
PR updated
And maybe 1#element => element *( OWS "," OWS [ element ] ) right?
NAME that'd outlaw , which seems wrongish?
Closed by commit e475f36 for the recipient case. Note that this may become obsolete if we switch to only providing ABNF for what is good to send.