jiebi/CodeConvo huggingface dataset:
Code change:
cookie when sending it to the user agent.  The scope indicates the maximum amount of time in which the user agent should return the cookie, the servers to which the user agent should return the cookie, <del> and the URI schemes for which the cookie is applicable. </del> <ins> and the connection types for which the cookie is applicable. </ins> For historical reasons, cookies contain a number of security and privacy infelicities.  For example, a server can indicate that a

Related discussion:
text: (I believe this is intended by latest draft, but as NAME pointed this might need some changes to the Storage Model section) NAME Could you help clarify more about "2 min Lax+POST mitigation"? I see it mentioned above but it would be great to discuss how the mitigation should behave exactly.
URL is the spec language around the behavior. As a quick refresher: the goal is to allow unsafe http methods (commonly POST) to attach cookies that do not specify a attribute but are being treat as "lax by default". This behavior is intended for newly created cookies and so has a lifetime limit of up to 2 minutes. Let me know if you have any more specific questions.
We (NAME NAME NAME and I) discussed this at TPAC and came to the following suggestion: We think that browsers have to apply a compatibility measure here, and it could be including cookies on cross-site redirects if they’re younger than, for example, 2 minutes. We’ll collect metrics to get a better understanding of what that number should be. We will update "Lax-Allowing-Unsafe" in the spec to document that behavior, which would make Chromium compliant to that and Firefox could (AFAIU) ship a compliant version as well. We’ll continue to recommend "Lax-Allowing-Unsafe" as the default behavior in the spec. We’ll note that this is a compatibility mechanism that browsers may support or not support at their own discretion. It's not a behavior sites should opt into.
I believe the "same-site redirect chain consideration" change should be removed from RFC6265bis, with the intention of adding it back to RFC6265Tris. RFC6265bis contains a number of improvements over RFC6265 that are being stalled due to UAs being unable to implement "same-site redirect chain consideration" in a web compatible way. My efforts examining metrics collected by Chrome haven't yet offered much insight into how this issue could be solved and I have no idea how much longer it could take. Because no UAs (to my knowledge) have shipped "same-site redirect chain consideration" I don't believe reverting the language will have any practical effect and shouldn't weaken any active protections. But publishing RFC6265bis as a new spec will have a number of benefits, including security/privacy benefits for the web's users.
This seems like a reasonable, pragmatic step to me.
Code change:
cookie when sending it to the user agent.  The scope indicates the maximum amount of time in which the user agent should return the cookie, the servers to which the user agent should return the cookie, <del> and the URI schemes for which the cookie is applicable. </del> <ins> and the connection types for which the cookie is applicable. </ins> For historical reasons, cookies contain a number of security and privacy infelicities.  For example, a server can indicate that a

Related discussion:
text: The current limbo state isn't helping anyone :) cc NAME
Yes, +1 to documenting reality and no longer blocking the IETF process for 6265bis on this particular item (which I do agree we should treat as a security bug to be eventually solved).
Not an editor, but LGTM (given that it reflects reality).LGTM, given the context.
Code change:
cookie when sending it to the user agent.  The scope indicates the maximum amount of time in which the user agent should return the cookie, the servers to which the user agent should return the cookie, <del> and the URI schemes for which the cookie is applicable. </del> <ins> and the connection types for which the cookie is applicable. </ins> For historical reasons, cookies contain a number of security and privacy infelicities.  For example, a server can indicate that a

Related discussion:
text: Rephrases the requirements for the attribute to be slightly broader in order to support . Currently the requirements specifically ask for a secure protocol, with this change they'll ask for a secure connection (as defined by the user agent). This allows UAs to support cookie access on http://localhost
No WPT that I can see. According to , Firefox fully supports localhost, Chrome supports but not cookie prefixes, and Safari doesn't have support but does have an open bug.
Got it, thanks. If you're taking care of Chromium, and WebKit has an open bug, landing this seems reasonable. Thanks!
We are reporting inconsistent browser behavior regarding cookies and and prefixed cookies on . delegates the decision of what is a "secure protocol" to the user agent when describing how to handle cookies with the attribute. The affects both cookies with the attribute and cookies with name prefixes ( and ). rfc6265bis-12 states the following (): According to our tests: Firefox allows cookies to be set/sent on , as well as and prefixed cookies. Chrome also allows cookies to be set/sent with the attribute. However, and cookies are not allowed. Safari does not allow cookies to be set/sent, and consequently, and cookies are also discarded since they require that the cookie's be set to true via the cookie attribute. The table below summarises browser behavior when setting cookies on , localhost subdomains, and . We noticed these inconsistencies after interacting with developers of Web frameworks while discussing cookie integrity issues. Allowing cookies with the attribute and cookie name prefixes to be used on , would enable adopters of Web frameworks to test their applications locally, removing the burden of setting up HTTPS locally to use these security features. As shown in the table above, Firefox fully supports this behavior, while Chrome's support is still partial. Following , Firefox moved from a "secure protocol" check when handling cookies, to using the definition of specification, where is considered "Potentially Trustworthy". The states that: >An environment is a secure context if the following algorithm returns true: Chrome made the same decision following , and support for and prefixed cookies on has been deemed "in scope" (). Safari is aware of this inconsistency, but there is still no decision regarding changing their behavior (, , ).
Code change:
cookie when sending it to the user agent.  The scope indicates the maximum amount of time in which the user agent should return the cookie, the servers to which the user agent should return the cookie, <del> and the URI schemes for which the cookie is applicable. </del> <ins> and the connection types for which the cookie is applicable. </ins> For historical reasons, cookies contain a number of security and privacy infelicities.  For example, a server can indicate that a

Related discussion:
text: As the cookie specification does not clearly define the behavior on localhost, we could consider reusing the notion of from the Secure Context specification, instead of suggesting a user-agent-dependent "secure protocol" check on the scheme of the request-URI, in point 13 of . Best regards
I think it's reasonable to modify the phrasing to include potentially trustworthy origins.
This is a good change, thanks. I don't think we have WPT in place for this (and I'm not entirely sure that we can?), but have you looked into the support for this change across browser engines? I'm generally in favor of landing it as long as it's reflecting (near) reality.
Code change:
Abstract <del> The IETF's standard congestion control schemes have been widely shown to be inadequate for various environments (e.g., high-speed networks, wireless technologies such as 3GPP and WiFi, long distance satellite links) and also in conflict with the needed, more isochronous, behaviors of VoIP, gaming, and videoconferencing traffic.  Recent research has yielded many alternate congestion control schemes that significantly differ from the IETF's congestion control principles. Using these new congestion control schemes in the global Internet has possible ramifications to both the traffic using the new congestion control and to traffic using the currently standardized congestion control.  Therefore, the IETF must proceed with caution when dealing with alternate congestion control proposals.  The goal of this document is to provide guidance for considering alternate congestion control algorithms within the IETF. </del> <ins> There have been proposals to extend or update the standard IETF congestion control schemes.  Recent research has yielded many alternate congestion control schemes that significantly differ from the IETF's congestion control principles.  Using these new congestion control schemes in the global Internet has possible ramifications to both the traffic using the new congestion control and to traffic using the currently standardized congestion control.  Therefore, the IETF must proceed with caution when dealing with alternate congestion control proposals.  The goal of this document is to provide guidance for considering alternate congestion control algorithms within the IETF. </ins> 1.

Related discussion:
text: If merged this
Our abstract starts: "The IETF's standard congestion control schemes have been widely shown to be inadequate for various environments (e.g., high-speed networks, wireless technologies such as 3GPP and WiFi, long distance satellite links) and also in conflict with the needed, more isochronous, behaviors of VoIP, gaming, and videoconferencing traffic." ... is it just me, or does "inadequate" and "at conflict" seem an odd BCP statement from the IETF itself.
Agreed. How about something closer to: "The IETF's standard congestion control schemes have been shown to have performance challenges in various environments (e.g., high-speed networks, cellular and WiFi wireless technologies, long distance satellite links) and also for interactive traffic workloads (VoIP, gaming, and videoconferencing)." cc: NAME NAME
Code change:
An "exp" claim, whose value is the time at which the Txn-Token expires. <del> A "txn" claim, whose value is the unique identifier of entire call chain. </del> <ins> A "txn" claim, whose value is the unique transaction identifier as defined in Section 2.2 of RFC8417.  When used in the transaction token, it identifies the entire call chain. </ins> A "sub_id" claim, whose value is the unique identifier of the user or workload on whose behalf the call chain is being executed.  The

Related discussion:
text: See issue
Implementation feedback. The "tid" claim clashes with a claim commonly used in AAD for the tenant ID. Perhaps we can use an alternative like idt, txi, txnid, txn_id or tti?
Discussed in the identity chaining call. Recommendation is to use the 'txn' claim name as defined in RFC 8417.
Add reference to SET add RFC 8417
Code change:
12.1. <del> Please update the "Hypertext Transfer Protocol (HTTP) Field Registry" registry at <https://www.iana.org/assignments/http-fields> with the </del> <ins> Please update the "Hypertext Transfer Protocol (HTTP) Field Name Registry" at <https://www.iana.org/assignments/http-fields> with the </ins> field names listed in the two tables of header.field.syntax. 12.2.

Related discussion:
text: We should explicitly tell them to reserve it.
I think the last comma is bad, but not enough to tweak it myself.
Code change:
calculated using the representation data that would have been enclosed in the payload body if the same request had been a GET. <del> Digest can be used in requests too.  Returned value depends on the representation metadata header fields. </del> <ins> Digest can be used in requests too. The "Digest" value depends on the representation metadata. </ins> A Digest header field MAY contain multiple representation-data-digest values.  This could be useful for responses expected to reside in

Related discussion:
text: Clarifies the "returned value" expression.
There are two occurences of the fragment This is not the most helpful of statements, when we say "returned value" what exactly are we trying to convey. I think it would help to be a bit more exact.
Thanks. Longer term, I'd like to do an broad editorial sweep to tighten up document and this is an enabling step that I think this takes us most of the way there. I made some suggestions to move words around a bit.
Code change:
(DQUOTE and "(),/:;<=>?@[\]{}"). <del> Tokens are short textual identifiers that do not include whitespace or delimiters. </del> 5.6.3. This specification uses three rules to denote the use of linear

Related discussion:
text: The first paragraph of the section 5.6.2 on Tokens, which describes delimiters, is misplaced. It should either be the last paragraph in that section or the first paragraph in the parent (Common Rules).
Moving it up would be a bit strange because to the reference to tokens. Moving to the end of the section seems good though.
Code change:
payload, whereas the Holder includes only the Disclosures selected for the given presentation. <del> Alternative methods for conveying the disclosures MAY be used (such </del> <ins> Alternative methods for conveying the Disclosures MAY be used (such </ins> as including them in a member of an outer JSON structure also containing the JSON Serialized

Related discussion:
text: Editorial updates for more consistent treatment of a Disclosure vs the contents of a Disclosure (to Confusing terminology) Editor's draft PR preview: URL
Hi, Disclosure is used at least two ways in the document. to refer to the array containing the salt, (maybe name), and value. to refer to the base64url encoded string It's easy to understand how this could have happened, as both contain logically the same information. I propose explicitly calling these: disclosure array, and disclosure presentation I also propose calling the hash/digest of the disclosure the disclosure digest in full in every use. The only time we would use "disclosure" without one of these modifiers is talking about the process of disclosing in general. As for the plaintext of the claims that can be disclosed, I propose blinded claim. So the first paragraph of Section 4.1 would read: An SD-JWT consists of: a signed JSON document, a list of disclosure presentations (each of which reveals a blinded claim), and optionally an issuer key binding (discussed in Section 4.3). The signed JSON document (the JWT body) contains plaintext claims; and disclosure digests, each of which either refers to a specific blinded claim or is a decoy. The holder can include zero or more disclosure presentations without breaking the signature of the JWT body. The contents of the blinded claims cannot be modified, because the corresponding digest would no longer match any digest in the JWT body. Blinded claims can be individual object properties (key-value pairs) or array elements.
This is appreciated! I agree that we should be more consistent with our terms. I'm not sure about "disclosure presentation" as "presentation" suggests a specific meaning. Maybe just "disclosure" and "disclosure contents" is fine.
The current document attempts to mostly use "Disclosure" to mean the base64url encoded string. I think that works okay. Places where it's referring to the decoded JSON array should be fixed to be more clear. So I think I agree that "disclosure" and where needed "disclosure contents" would be good.
PR has editorial updates for more consistent treatment of a Disclosure vs the contents of a Disclosure
made one suggestion, but overall, looks good to me! thank you!
Code change:
The HTTP/3 stream closure is also analogous to the TCP connection closure of RFC6455.  Orderly TCP-level closures are represented as a <del> FIN bit on the stream (HTTP/3).  RST exceptions are represented with a stream error (HTTP/3) of type H3_REQUEST_CANCELLED (HTTP/3). </del> <ins> FIN bit on the stream (HTTP3).  RST exceptions are represented with a stream error (HTTP3) of type H3_REQUEST_CANCELLED (HTTP3). </ins> 4.

Related discussion:
text: NAME I think I did the needful here by cargo-culting . Does this look good to you?
Thanks for the suggestions!
(not tested, but if it ends generating the desired output...)
Code change:
responses) can be sent at any time after a request is received, even if the request is not yet complete.  A response can complete before <del> its corresponding request is complete.  Likewise, clients are not expected to wait any specific amount of time for a response.  Clients (including intermediaries) might abandon a request if the response is not forthcoming within a reasonable period of time. </del> <ins> its corresponding request is complete (message.framing).  Likewise, clients are not expected to wait any specific amount of time for a response.  Clients (including intermediaries) might abandon a request if the response is not forthcoming within a reasonable period of time. </ins> A client that receives a response while it is still sending the associated request SHOULD continue sending that request, unless it

Related discussion:
text: Hi! I post here my combined comments for draft-ietf-httpbis-semantics-16, as I don't think they deserve one issue each :) I hope that's fine. My comments range from minor to very minor to nit, and are mostly editorials and clarifications. As this can possibly be me, I'll leave it up to you to decide if they can be useful to improve readability, or not. Thanks for your work! Francesca [x] 1. ----- Additional (social) requirements are placed on implementations, FP: I am not sure I understand the meaning behind the term "social requirement". Editors: URL (URL) [x] 2. ----- When a major version of HTTP does not define any minor versions, the minor version "0" is implied and is used when referring to that protocol within a protocol element that requires sending a minor version. FP: I had a hard time parsing this sentence (starting at "and is used..."), maybe breaking it up with commas would be enough. Especially the two "that" are unclear to me. Editors: URL (URL) [x] 3. ----- RFC 3986, which allows for an empty path to be used in references, FP: very minor, I'd prefer "in URI references". Editors: URL, change applied in URL [x] 4. ----- The process for determining that access is defined by the URI scheme and often uses data within the URI components, such as the authority component when the generic syntax is used. However, authoritative FP: I had to read the sentence above 3 times before realizing that the subject of "is defined" is not "access", but "The process", and understanding it. Editors: URL, change applied in URL [x] 5. ----- A client MAY discard or truncate received field lines that are larger FP: I assume and It might have been good to clarify that "truncate" a field lines is equivalent to dropping a member of the list of values. Editors: URL [x] 6. ----- Note that double-quote delimiters are almost always used with the quoted-string production; using a different syntax inside double- FP: I am not sure I understand "quoted-string production" Editors: added missing fwd reference - URL [x] 7.
Code change:
responses) can be sent at any time after a request is received, even if the request is not yet complete.  A response can complete before <del> its corresponding request is complete.  Likewise, clients are not expected to wait any specific amount of time for a response.  Clients (including intermediaries) might abandon a request if the response is not forthcoming within a reasonable period of time. </del> <ins> its corresponding request is complete (message.framing).  Likewise, clients are not expected to wait any specific amount of time for a response.  Clients (including intermediaries) might abandon a request if the response is not forthcoming within a reasonable period of time. </ins> A client that receives a response while it is still sending the associated request SHOULD continue sending that request, unless it

Related discussion:
text: ----- content, it is often desirable for the sender to supply, or the recipient to determine, an identifier for a resource corresponding to that representation. FP: It might have been good here to give a hint or example on why such identifiers could be desirable. Editors: URL (URL) [x] 8. ----- Fields (Section 5) that are located within a trailer section are are referred to as "trailer fields" (or just "trailers", FP: s/are are/are Editors: URL [x] 9. ----- All responses, regardless of the status code (including interim responses) can be sent at any time after a request is received, even if the request is not yet complete. A response can complete before FP: I think at this point in the text there is no definition of what qualifies a request or response being "complete". Editors: actually, the definition is earlier in the text; added a reference anyway: URL [x] 10. ----- An intermediary MAY combine an ordered subsequence of Via header field list members into a single member if the entries have identical received-protocol values. For example, FP: Is there any requirement on the intermediary to be able to collapse the ordered sequence into a single member (such as storing and being able to expand this information)? Might want to expand a little. Editors: Declined because there is no requirement to do so. We already explain that one might want to do so for information hiding of intermediaries within a private network (URL and URL) [x] 11. ----- This definition of safe methods does not prevent an implementation from including behavior that is potentially harmful, that is not entirely read-only, or that causes side effects while invoking a safe method. What is important, however, is that the client did not request that additional behavior and cannot be held accountable for it. For example, most servers append request information to access FP: I might be missing the motivation for it, but this paragraph seems strange to me. Why is it important that the client cannot be held accountable for it? The concern I have is that the text seems to be saying "safe is essentially read only/not harmful/..., but not really". (And same for idempotent) Editors: URL [x] 12. ----- referring to making a GET request.