jiebi/CodeConvo huggingface dataset:
Code change:
4.1. <del> Given sorted-variants, a list of lists, and key-stub, a string </del> <ins> Given key-facets, a list of lists, and key-stub, a string </ins> representing a partial key, and possible-keys, a list: <del> Let sorted-values be the first member of sorted-variants. </del> <ins> Let values be the first member of key-facets. </ins> <del> For each sorted-value in sorted-values: </del> <ins> For each value in values: </ins> If key-stub is an empty string, let this-key be a copy of <del> sorted-value. </del> <ins> value. </ins> Otherwise:

Related discussion:
text: For
Allow a response to associate itself with more than one variant. (moved from mnot/I-D)
Code change:
request to obtain an alternate representation.  Furthermore, this specification does not define a mechanism for supporting automatic selection, though it does not prevent such a mechanism from being <del> developed as an extension. </del> <ins> developed. </ins> 12.3.

Related discussion:
text: It may or may not be useful to have an HTTP extension in order to perform reactive negotiation -- one possible approach that does not require an extension would be policy in the user-agent. In the spirit of "less is more", and to not overly constrain our forward-looking statement, just remove the phrase "as an extension". (inspired by follow-up discussions on )
I almost made the same edit earlier.
Code change:
The DATA frame defines the following flags: <del> Bit 1 being set indicates that this frame is the last that the </del> <ins> Bit 0 being set indicates that this frame is the last that the </ins> endpoint will send for the identified stream.  Setting this flag causes the stream to enter one of StreamStates. <del> Bit 4 being set indicates that the Pad Length field and any </del> <ins> Bit 3 being set indicates that the Pad Length field and any </ins> padding that it describes is present. DATA frames MUST be associated with a stream.  If a DATA frame is

Related discussion:
text: Bits seem to be numbered from 1 to N, which is very confusing since almost every software starts at zero. Also it's common to find macros like : #define BIT(N) (1 << (N)) and here that would introduce mistakes since one constantly has to think about shifting bits before using the macro (eg: BIT(3) to check bit called "4" in the spec, corresponding to value 0x8). Since there are not that many places where this happens, this commit aims at fixing them. Note that the hexadecimal values for each of them were already correct and non-ambiguous.
Code change:
Identifier DID-CORE) of the signer, as a string. "did:web:example.com" is an example of a DID. <del> Feed (label: "TBD", temporary: "392"): The Issuer's name for the Artifact, as a string. </del> <ins> Subject (label: "TBD", temporary: "392"): The Subject to which the Statement refers, as a bytestring, chosen by the Issuer. </ins> Content type (label: "3"): Media type of payload, as a string. For example, "application/spdx+json" is the media type of SDPX in JSON encoding. Registration Policy info (label: "TBD", temporary: "393"): A map <del> of additional attributes to help enforce Registration Policies. </del> <ins> containing key/value pairs set by the Issuer which are sealed on Registration and non-opaque to the Transparency Service.  The key/ value pair semantics are specified by each Issuer or are specific to the Issuer and Feed tuple.  Examples include: the sequence number of signed statements on a feed, Issuer metadata, or a reference to other transparent statements (e.g., augments, replaces, new-version, CPE-for). </ins> Key ID (label: "4"): Key ID, as a bytestring.

Related discussion:
text: A note from the We'll be iterating on this a bit more, to create some use cases and examples for how feeds help producers and consumers benefit from SCITT.
See: URL There are several problems with this definition. It conflates using aggregations over an header parameter, with the header parameter. It confuses how the TS uses the attribute with how the uses the attribute (same problem as above). Suggested changes: Registration policies only apply to the feed identifier, they do not apply to the feed resource. See URL regarding the Transparency Service exposing the Feed Resource.
LGTM!LGTM
Code change:
3.1.1. <ins> The alternate congestion control mechanism should not cause increased overhead under adverse network conditions. This criteria can be evaluated by counting the total bytes (data and headers) arriving at the receiver when delivering a fixed workload over varying network conditions.  The total delivered bytes should remain constant, independent of network conditions over the entire operating range for the protocol.  For general transport protocols such as TCP this means over any path in the Internet. There are known exceptions to this guideline, for example spurious Retransmission Timeouts RFC7765 and TCP loss Probe RFC8985.  These algorithms can substantially improve application performance in certain environments at the cost of additional network overhead due to spurious retransmissions. Alternate congestion control mechanisms should be carefully evaluated for exceptions.  That evaluation should appropriately reflect on any the inherent trade-offs. This criteria can also be applied protocol layers above transport. 3.1.2. </ins> The alternate congestion control mechanism should either stop sending when the packet drop rate exceeds some threshold RFC3714, or should include some notion of "full backoff".  For "full backoff", at some

Related discussion:
text: Define congestion collapse in terms of excess overhead. Rename the prior congestion collapse section "Implement full backoff" Closes issue
Editors: This metric is very interesting, but wonder if it's really a requirement for loss recovery, not congestion control (granted, these two are often intertwined). This would put it out of scope. Our proposal would be to revert this, though perhaps we are misunderstanding the intent.
Define congestion collapse in terms of excess overhead under adverse conditions. This is how it was defined circa 1987. Rename the current "congestion collapse" section.
NAME would you like to take a crack at finding some text that would be in scope to address the intent behind this issue?
Closing this issue, as it's through IETF Last Call.
Code change:
Because Txn-Tokens are short-lived, the Txn-Token response from the Txn-Token service does not contain the "refresh_token" field.  A Txn- <del> Token is also cannot be issued by presenting a "refresh_token". </del> <ins> Token cannot be issued by presenting a "refresh_token". </ins> The "expires_in" and "scope" fields of the OAuth 2.0 Token Exchange specification RFC8693 are also not used in Txn-Token responses.  The

Related discussion:
text: Constrain Txn-Token to be shorter than the Access Token Lifetime (upper bound on lifetime) Editorial update to security considerations
Code change:
, which are unfit for security applications). <del> Furthermore, the hash algorithms MD2, MD4, MD5, RIPEMD-160, and SHA-1 revealed fundamental weaknesses and they MUST NOT be used. </del> <ins> Furthermore, the hash algorithms MD2, MD4, MD5, and SHA-1 revealed fundamental weaknesses and they MUST NOT be used. </ins> 8.6.

Related discussion:
text: RIPEMD-160 is usable, but not its predecessors. For this reason this PR removes RIPEMD-160 from the list of the weak algs by saying that only -160 predecessors must not be used.
Thank you!
Code change:
(field.etag).  Additional metadata that reflects resource state has been defined by various extensions of HTTP, such as Web Distributed Authoring and Versioning WEBDAV, that are beyond the scope of this <del> specification.  A resource metadata value is referred to as a when it is used within a precondition. </del> <ins> specification. </ins> 8.8.1.

Related discussion:
text: … (now entirely handled by HTTP/1.1 messaging). Include LF in discussion of what characters are invalid in field values. Require obs-fold to be processed when consuming message/http data.
Citing Ben Kaduk (URL): (i.e., that has any field line value that contains a match to the obs-fold rule) unless [...] other production, and field-value excludes CRLF, it seems that any such field line value would already be in violation of the ABNF and thus forbidden. I don't really want to advocate for including obs-fold in the field-value production in -semantics, though, so maybe accepting this nit is the least bad choice here. In RFC723x, field-value allowed obs-fold. We need to: tune the prose above, and somehow properly allow it in message/http (maybe by modifying the field-value for that specific case???)
see also URL
This is a good change. A few things that might be worth considering, when comparing this to recent HTTP/2 changes. HTTP/2 prohibits additional things in field names: SP (0x20), COLON (0x3a), 0x01-0x1f, and 0x7f-0xff (inclusive), specifically. The other things in h2 are specific to that. That includes leading and trailing space in values (you just say "A field value does not include leading or trailing whitespace") and uppercase field characters are version-specific.
Code change:
attribute-name of "SameSite" and an attribute-value of "enforcement". <del> Note: This algorithm maps the "None" value, as well as any unknown value, to the "None" behavior, which is helpful for backwards compatibility when introducing new variants. </del> 5.3.7.1. Same-site cookies in "Strict" enforcement mode will not be sent along

Related discussion:
text: It looks like this was forgotten in , when unknown values were switched from None to Default. /cc NAME this caused us some confusion over in Go, if you have time I'd appreciate hearing what you think we should do in golang/go. Thank you!
Thanks! LGTM.
Code change:
does not provide such control to the user MUST NOT send an Accept- Language header field. <del> 12.2. With (a.k.a., ), selection of the best response representation (regardless of the status code) is performed by the user agent after receiving an initial response from the origin server that contains a list of resources for alternative representations.  If the user agent is not satisfied by the initial response representation, it can perform a GET request on one or more of the alternative resources, selected based on metadata included in the list, to obtain a different form of representation for that response.  Selection of alternatives might be performed automatically by the user agent or manually by the user selecting from a generated (possibly hypertext) menu. Note that the above refers to representations of the response, in general, not representations of the resource.  The alternative representations are only considered representations of the target resource if the response in which those alternatives are provided has the semantics of being a representation of the target resource (e.g., a response to a GET request) or has the semantics of providing links to alternative representations for the target resource (e.g., a response to a GET request). A server might choose not to send an initial representation, other than the list of alternatives, and thereby indicate that reactive negotiation by the user agent is preferred.  For example, the alternatives listed in responses with the and status codes include information about the available representations so that the user or user agent can react by making a selection. Reactive negotiation is advantageous when the response would vary over commonly used dimensions (such as type, language, or encoding), when the origin server is unable to determine a user agent's capabilities from examining the request, and generally when public caches are used to distribute server load and reduce network usage. Reactive negotiation suffers from the disadvantages of transmitting a list of alternatives to the user agent, which degrades user-perceived latency if transmitted in the header section, and needing a second request to obtain an alternate representation.  Furthermore, this specification does not define a mechanism for supporting automatic selection, though it does not prevent such a mechanism from being developed as an extension. 12.2.1. </del> <ins> 12.5.5. </ins> The "Vary" header field in a response describes what parts of a request message, aside from the method and target URI, might

Related discussion:
text: initial commit is just moving sections and updating headings; second commit will update some of "the following" comments to refer to the specific fields.
I believe it needs to be under "Proactive Negotiation" , or be a sibling of these...
Code change:
415 Unsupported Media Type (status code) 416 Range Not Satisfiable (status code) 417 Expectation Failed (status code) <ins> 422 Unprocessable Entity (status code) </ins> 426 Upgrade Required (status code) 4xx Client Error (status code class)

Related discussion:
text: The text is almost the same as in RFC 4918, except that I removed the somehow bogus claim that status code 400 wouldn't be right.
Are we updating the IANA registry to point to this document? The only slight concern I have here is that this may unintentionally reinforce the view that "real" status codes are required to be in the core document. If we can find a way to discourage that view, that would be great (but that's a separable issue).
Yes. For all codes. That occurred to me as well.
Ok, should I merge this one?
It's commonly used, but defined in RFC 4918 (WebDAV),, which continues to confuse people. Should we include it in the core specs?
For reference: URL
+1
Discussed in Montreal; support for doing this.
Code change:
the interface.  This prefix has a valid and preferred lifetime of STUB_PROVIDED_PREFIX_LIFETIME seconds.  The stub router sends a router advertisement (RA) containing this prefix in a Prefix <del> Information Option (PIO).  In the PIO, the A (autonomous configuration) flag RFC4861 MUST be set and the L (on-link) flag SHOULD be set.  The exception cases where the L flag can be cleared is where the specific link-layer technology and/or configuration requires clearing the L flag. </del> <ins> Information Option (PIO).  In the PIO, the 'A' flag bit (autonomous configuration) flag RFC4861 MUST be set and the 'L' flag bit (on-link prefix) MUST be set.  Link-layer technologies that require the 'L' flag bit to be cleared are out of scope of this document. </ins> The Stub Router flag (I-D.hui-stub-router-ra-flag) MUST be set in the RA flags field.  The values of the M and O flags MUST be copied from

Related discussion:
text: Current Github text (May 9) still has the text In the last SNAC interim and a recent PR we changed this to L flag MUST be set (case of L=0 is out of scope). Above text still needs to be updated accordingly.
Code change:
the interface.  This prefix has a valid and preferred lifetime of STUB_PROVIDED_PREFIX_LIFETIME seconds.  The stub router sends a router advertisement (RA) containing this prefix in a Prefix <del> Information Option (PIO).  In the PIO, the A (autonomous configuration) flag RFC4861 MUST be set and the L (on-link) flag SHOULD be set.  The exception cases where the L flag can be cleared is where the specific link-layer technology and/or configuration requires clearing the L flag. </del> <ins> Information Option (PIO).  In the PIO, the 'A' flag bit (autonomous configuration) flag RFC4861 MUST be set and the 'L' flag bit (on-link prefix) MUST be set.  Link-layer technologies that require the 'L' flag bit to be cleared are out of scope of this document. </ins> The Stub Router flag (I-D.hui-stub-router-ra-flag) MUST be set in the RA flags field.  The values of the M and O flags MUST be copied from

Related discussion:
text: Closing issue This PR is not building, so need to clean it up before commit. Comments appreciated during that process.
NAME PR is still needed before anything can build ;-)
NAME NAME sorry I didn't intend to close this PR, Github did that somehow after me pushing to the branch. But it's good to have this one closed and replaced by , because the merge direction was specified here the wrong way around. The build is now fixed in the branch and also updated to make it merge-able into main. I prefer to merge rather sooner than later - nits can be corrected with future PRs easily.
Code change:
server is unable or unwilling to buffer the entire request before processing. <del> A user agent that sends a request containing a message body MUST send a valid header field if it does not know the server will handle HTTP/1.1 (or later) requests; such knowledge can be in the form of specific user configuration or by remembering the version of a prior received response. </del> <ins> A user agent that sends a request that contains a message body MUST send either a valid header field or use the chunked transfer coding.  A client MUST NOT use the chunked transfer encoding unless it knows the server will handle HTTP/1.1 (or later) requests; such knowledge can be in the form of specific user configuration or by remembering the version of a prior received response. </ins> If the final response to the last request on a connection has been completely received and there remains additional data to read, a user

Related discussion:
text: This text: URL a condition on the conformance requirement that suggests that clients that do know the server will support HTTP/1.1 (or later) can do something else. But it doesn't really address what constraints then apply. I think that this was just to permit the use of the chunked transfer encoding for delimiting the message body, but that does not follow. I think that this might be rephrased as follows:
It reads the same to me, but +1.
Code change:
If a client makes concurrent requests with the incremental parameter set to false, there is no benefit serving responses with the same <del> urgency in parallel because the client is not going to process those </del> <ins> urgency concurrently because the client is not going to process those </ins> responses incrementally.  Serving non-incremental responses with the same urgency one by one, in the order in which those requests were generated is considered to be the best strategy. If a client makes concurrent requests with the incremental parameter <del> set to true, serving requests with the same urgency in parallel might be beneficial.  Doing this distributes the connection bandwidth, meaning that responses take longer to complete.  Incremental delivery is most useful where multiple partial responses might provide some value to clients ahead of a complete response being available. </del> <ins> set to true, serving requests with the same urgency concurrently might be beneficial.  Doing this distributes the connection bandwidth, meaning that responses take longer to complete. Incremental delivery is most useful where multiple partial responses might provide some value to clients ahead of a complete response being available. </ins> The following example shows a request for a JPEG file with the urgency parameter set to "5" and the incremental parameter set to

Related discussion:
text: Paraphrasing NAME in S 4.2 we say Resources are not sent in parallel (implying "at the same time"), but rather multiplexed vs sequential. We don't want to leave the impression that setting i=1 would give better perf due to actual "parallel" sending.
Code change:
8.6. For the security of this scheme, the hash algorithm is required to be <del> preimage and collision resistant, i.e., it is infeasible to calculate the salt and claim value that result in a particular digest, and it is infeasible to find a different salt and claim value pair that result in a matching digest, respectively. </del> <ins> preimage resistant and second-preimage resistant, i.e., it is infeasible to calculate the salt and claim value that result in a particular digest, and, for any salt and claim value pair, it is infeasible to find a different salt and claim value pair that result in the same digest, respectively. Hash algorithms that do not meet the aforementioned requirements MUST NOT be used.  Inclusion in the "Named Information Hash Algorithm" registry IANA.Hash.Algorithms alone does not indicate a hash algorithm's suitability for use in SD-JWT (it contains several heavily truncated digests, such as </ins> <del> Furthermore the hash algorithms MD2, MD4, MD5, RIPEMD-160, and SHA-1 </del> <ins> and , which are unfit for security applications). Furthermore, the hash algorithms MD2, MD4, MD5, RIPEMD-160, and SHA-1 </ins> revealed fundamental weaknesses and they MUST NOT be used. 8.7.

Related discussion:
text: A bit more in security considerations for Choice of a Hash Algorithm (1st & 2nd preimage resistant and not majorly truncated) for issue
While looking at this I noticed URL only allows hash algs from the registry. URL removed the JOSE HMAC stuff but also removed allowing the hash alg to be "a value defined in another specification and/or profile of this specification" which I thought we wanted to have - for Christian's type use cases and extensibility in general. This isn't the right place for a discussion but wanted to note it somewhere before our call.
I think we intentionally removed “a value defined in another specification and/or profile of this specification” Because using that would require a separate profile and not just defining an identifier.
from this PR URL
Code change:
5.1. Here, a successful HTTP GET response has been encrypted using input <del> keying material that is identified by a URI. </del> <ins> keying material that is identified by the string "a1". </ins> The encrypted data in this example is the UTF-8 encoded string "I am the walrus".  The input keying material is included in the Crypto-Key

Related discussion:
text: This moves the values that were in the Encryption header field to the start of the payload. This provides a meagre efficiency gain as well as removing the need to have two correlated header fields. This should go most of the way to address WGLC comments.
Looks good to me in general. That said; this removes the parsing weirdness for "Encryption" (good), but not for "Crypto-Key", right?
NAME happy to correct any parsing weirdness, but need to know precisely what it is first.
Code change:
12.7. When "Digest" is used in trailer fields, the receiver gets the digest <del> value after the payload data and may thus be tempted to process the data before validating the digest value.  It is prefereable that data is only be processed after validating the Digest. </del> <ins> value after the content and may thus be tempted to process the data before validating the digest value.  It is prefereable that data is only be processed after validating the Digest. </ins> If received in trailers, "Digest" MUST NOT be discarded; instead, it MAY be merged in the header section (See Section 6.5.1 of SEMANTICS).

Related discussion:
text: Use "content" instead of "payload data".
to reference semantics-14, including "payload data" --> "content".
Code change:
The HTTP/2 specification is split into four parts: <del> starting covers how a HTTP/2 connection is initiated. </del> <ins> starting covers how an HTTP/2 connection is initiated. </ins> The FramingLayer and StreamsLayer layers describe the way HTTP/2 frames are structured and formed into multiplexed streams.

Related discussion:
text: l.815 before: An endpoint MUST NOT send frames other than than HEADERS/x:ref or fix: An endpoint MUST NOT send frames other than HEADERS/x:ref or