jiebi/CodeConvo huggingface dataset:
Code change:
also required to include a statement in the abstract describing environments where the protocol is not recommended for deployment. There can be environments where the congestion control algorith is <del> deemed _safe_ for use, but it is still is not _recommended_ for use because it does not perform well for the user. </del> <ins> deemed _safe_ for use, but it is still is _not recommended_ for use because it does not perform well for the user RFC8890. </ins> As examples of such statements, RFC3649 specifying HighSpeed TCP includes a statement in the abstract stating that the proposed congestion control algorithm is Experimental, but may be deployed in <del> the current Internet.  In contrast, the Quick-Start document RFC4782 includes a paragraph in the abstract stating the mechanism is only being proposed for use in controlled environments.  The abstract specifies environments where the Quick-Start request could give false positives (and therefore would be unsafe for incremental deployment where some routers forward, but do not process the option).  The abstract also specifies environments where packets containing the Quick-Start request could be dropped in the network; in such an environment, Quick-Start would not be unsafe to deploy, but deployment would not be recommended because it could lead to unnecessary delays for the connections attempting to use Quick-Start. The Quick-Start method is discussed as an example in RFC9049. Alhough out of the scope of this document, a proponent of a new </del> <ins> the Internet.  In contrast, the Quick-Start document RFC4782 includes a paragraph in the abstract stating that the mechanism is only being proposed for use in controlled environments.  The abstract specifies environments where the Quick-Start request could give false positives (and therefore would be unsafe for incremental deployment where some routers forward, but do not process the option).  The abstract also specifies environments where packets containing the Quick-Start request could be dropped in the network; in such an environment, Quick-Start would not be unsafe to deploy, but deployment would not be recommended because it could lead to unnecessary delays for the connections attempting to use Quick-Start.  The Quick-Start method is discussed as an example in RFC9049. Alhough out of the scope of this document, proponents of a new </ins> algorithm could alternatively seek publication as an Informational or Experimental RFC via the Internet Research Task Force (IRTF).  In general, these algorithms are expected to be less mature than ones

Related discussion:
text: Make it clear this is about guidelines for authors, not status of this document avoid redundant guidance avoid "subjective" guidance such as "believes"
thanks
Code change:
Note to Readers Source code and issues for this draft can be found at <del> https://github.com/fiestajetsam/draft-gruessing-moq-requirements [1]. </del> <ins> https://github.com/moq-wg/moq-requirements [1]. </ins> Discussion of this draft should take place on the IETF Media Over QUIC (MoQ) mailing list, at https://www.ietf.org/mailman/listinfo/moq

Related discussion:
text: NAME I think this is ready for review and merging .
Duplicated "without without waiting" in Section 2.1. I wish I had spotted "where a user wishes to observe or control the graphical user interface of another computer through local user interfaces" in 3.1.2 - I'd suggest saying this as "where a user wishes to observe or control the graphical user interface of another computer through user interfaces that are local to the user". I think "This may include audio from both microphone(s) and/or cameras, or may include "screen sharing" or inclusion of other content such as slide, document, or video presentation" in 3.1.3 might need adjusting. Doesn't this need to say, "This may include audio from microphone(s) and/or cameras, and may include "screen sharing" or inclusion of other content such as slide, document, or video presentation"? (Also, we named everything except video as a media type, but if we're changing that paragraph anyway, we can add video as well) in 3.2, I had difficulty parsing "As this has a much larger total number of participants - as many as Live Media Streaming , but with the bi-directionality of conferencing, this should be considered a "hybrid"." I wasn't sure "much larger than what?" Is this intended to say something like "This use case can have an audience as large as Live Media Streaming as described in Section 3.3.3, but also relies on the interactivity and bi-directionality of conferencing as in Video Conferencing as described in Section 3.1.3. For this reason, this type of use case can be considered a "hybrid". (if we're forward-referencing section 3.3.3 in Section 3.2, this might be clearer if we swapped the order of Sections 3.2 and 3.3) In section 3.3.1, are there any non-hypothetical media types beyond "audio and/or video"? In Section 3.3.3, I asked you to distinguish between the live edge and the trailing edge (thank you for that), but I didn't realize that "either because the local player falls behind edge" was now unqualified. Is this "either because the local player falls behind the live edge**"?
Code change:
Note to Readers Source code and issues for this draft can be found at <del> https://github.com/fiestajetsam/draft-gruessing-moq-requirements [1]. </del> <ins> https://github.com/moq-wg/moq-requirements [1]. </ins> Discussion of this draft should take place on the IETF Media Over QUIC (MoQ) mailing list, at https://www.ietf.org/mailman/listinfo/moq

Related discussion:
text: In 4.9.1, "this is infeasible in many use cases where provisioning of client TLS certificates is unsupported or infeasible." has two "infeasible"s. Perhaps one could be "impractical"? Your choice which, of course.
In submitting the -00 working group version, we tripped over an incompatibility between XML2RFC and google-i18n-address 3.0.0. The details are at URL and at URL I took the shortcut of removing the country: attributes for the authors in -00, but (per the comments on those issues, a version of XML2RFC that has been deployed, so we can add our country attributes back when we're fixing the nits identified in this issue. And NAME says it's "The Netherlands", but I'll let NAME and NAME wrestile that one out ... :zippermouthface:
Code change:
In this scenario, the connection between the browser and Application Server SHOULD be a session cookie provided by the Application Server. <del> 6.2.1. </del> <ins> 6.3.1. </ins> Security of the connection between code running in the browser and this Application Server is assumed to utilize browser-level

Related discussion:
text: I moved the considerations about XSS to a general section: all architectures are concerned. I added some words about bypassing the Service Worker: this would need a very broad successful XSS, with a much broader attack surface than what is typically the case. This can be mitigated by making sure that registering the service worker is the very first thing happening. There is also no API for unregistering a SW, so it can't be removed after the fact.
I haven't dug too deep yet but isn't this an API to unregister a service worker? URL
Indeed, this mitigation won't work. I oversaw the registration itself and focused on URL . I'll rework this and focus on what can be guaranteed by specs.
I removed the part about service workers for now. I'll see if I can further improve it in another PR.
Code change:
This specification intentionally defines strict parsing and serialization behaviors using step-by-step algorithms; the only error <del> handling defined is to fail the operation altogether. </del> <ins> handling defined is to fail the entire operation altogether. </ins> It is designed to encourage faithful implementation and good interoperability.  Therefore, an implementation that tried to be

Related discussion:
text: ... or it's a clarification that aligns the text in the two different sections. Sounds like we should discuss on list.
I still dont understand why we have some of the "strict" stuff in 1.1 and some in 4.2. I would move the paragraph from 4.2 to 1.1 to improve the chance people actually read it.
Disagree; implementers are more likely to look at the parsing section, not what they perceive as boilerplate at the top. 1.1 covers the philosophy and general approach; 4.2 talks about the implementation details.
"This is intentionally strict […]" sounded philosophical to me, but whatever :-)
URL It appears that some read the last sentence: as saying that the generic draconian handling of parsing errors can be relaxed.
It's saying that a generic parser will fail, but the field-specific handling of that failure might do somthing else, including try to parse the field using an alternative method. SF cannot constrain what a field does with the output of parsing.
That sounds like "we require draconian error handling, but if there's an error, you are free to do something else". Of course we can't force anybody not to do that, but we should be clear that this is not what the spec says.
Code change:
2. <del> Clients include the Tunnel-Protocol header field in an HTTP CONNECT request to indicate the application layer protocol that will be used within the tunnel, or the set of protocols that might be used within the tunnel. </del> <ins> Clients include the ALPN header field in an HTTP CONNECT request to indicate the application layer protocol that will be used within the tunnel, or the set of protocols that might be used within the tunnel. </ins> 2.1.

Related discussion:
text: Last call discussion identified this as a solution to the confusion that exists around the intent of the header field.
Apparently, this is confusing. Picking a new name might help.
Code change:
contents of the Registry at the time of registration, and must then yield the same result. <del> The ordering of entries, their cryptographic contents, and the </del> <ins> the ordering of entries, their cryptographic contents, and the </ins> Registry governance may be non-deterministic, but they must be verifiable. <del> A Transparency Services SHOULD store evidence about the resolution </del> <ins> a Transparency Services SHOULD store evidence about the resolution </ins> of distributed identifiers into manifests. <del> A Transparency Service MAY additionally support verifiability of </del> <ins> a Transparency Service MAY additionally support verifiability of </ins> client authentication and access control. 5.2.3.4.

Related discussion:
text: This is a long sentence, maybe break it up into multiple 80 character lines? A policy could be 'unrecognized', 'unparsable', or 'not implemented'. Does 'unknown' imply all of these? Originally posted by NAME in URL
Code change:
Field Registry maintained at <https://www.iana.org/assignments/ message-headers>. <ins> 8.1.2.1. </ins> While HTTP/1.x used the message start-line (see RFC7230) to convey the target URI and method of the request, and the status code for the response, HTTP/2 uses special pseudo-header fields beginning with ':'

Related discussion:
text: Now that we have decided to remove the reference set, the hacks we added to address header field ordering are no longer entirely necessary. This change does the following: remove the requirement to concatenate with '\0' require pseudo-header fields to all appear before regular header fields change 'header set' to 'header list'
This has implications beyond ordering w.r.t. compression efficiency, especially now that the number of items incurs a cost per item. , Martin Thomson EMAIL wrote:
nice, more red than green :)
Included into HPACK. Encoder and decoder SHOULD preserve ordering. :headers MUST appear before normal headers (in both encoded and decoded lists).
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: This PR removes the requirement of checking the request's redirect chain during the computation of same-site-ness. This is being done because RFC6265bis is blocked by this work but we have yet to find a way to implement it in a web compatible way. In the interest of moving RFC6265bis forward the requirement is being removed.
The work to re-add the requirement back into RFC6265tris is being track by issue
Yeah, we did implement this - but we had to back it out (and re-spin stable, IIRC?) because it broke too many sites. :(
Correct, Chrome had to disable the change. Firefox had a similar experience.
We noticed a difference between Firefox & Chrome’s behavior for same-site cookies. Specifically, if a web page is requesting a resource whose final redirect target is same-site with the web page, . Firefox follows what was originally decided in URL and specified in recent i.e., Firefox looks at the whole redirect chain. For context: Firefox shipped SameSite=Lax by default this January and had to backpedal due to this (and some other webcompat issues). Firefox does not ship SameSite=Lax as the default setting for new cookies as of now. While we’re still working on our own metrics, we’ve noticed that Chrome is seeing about 1% of page loads potentially affected, which seems prohibitively high. At the same time, we would prefer not to weaken our implementation of explicit SameSite cookies, given that the redirect check was specifically added to prevent CSRF abuse scenarios. With these things in mind, we’ve been exploring the idea that we might treat cookies differently depending on whether the cookie was set to lax by default or is an explicit samesite cookie. NAME NAME it would be nice to hear some thoughts about this idea and also NAME how other browsers may have implemented . CC: NAME NAME NAME NAME NAME NAME
Yeah, I agree this is unfortunate. We did , but it broke a few sites and was backed out (or rather, put behind an off-by-default feature flag). NAME has been collecting better metrics so we can hopefully make progress on this. Can you give some more detail what you're thinking here? (also cc NAME


With these things in mind, we’ve been exploring the idea that we might treat cookies differently depending on whether the cookie was set to lax by default or is an explicit samesite cookie.
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: Firefox is already enforcing that all redirects are same-site for cookies that have an explicit or strict attribute. We would like to keep that restriction of course. From my understanding the idea would be that only cookies that don't define their own SameSite attribute and are then "lax-by-default" we would ignore the redirects.
As a side note, Chrome does send with these redirected sub-resource requests, so internally the networking code does seem to know the correct same-site value of the request. Obviously we'd like to do the more secure behavior all the time, but we are committed to doing the specified secure behavior for explicit SameSite cookies. Firefox has enforced this for explicit SameSite cookies for maybe around a year and has not suffered a noticeable amount of web incompatibility. We are in the (slow!) process of gathering telemetry to measure the impact of this on laxByDefault vs explictly SameSite cookies. Our hope is that we can convince Chrome folks to honor the spec for explicit SameSite cookies so that users and sites will be secure as promised by the spec, and that Firefox will be less likely to run into Web Compatibility problems in the future because of this. And that if we must weaken the behavior of laxByDefault (as it appears we must based on site breakage) that we explicitly change the spec to say "lax-ish by default" cookies follow Chrome's current behavior of ignoring redirects and comparing only the originator and the final request URL.
Hello and sorry for my late response. Our (Chrome's) metrics continue to show around 1% of page loads containing 1 or more cookies that would be blocked by this enforcement. While I'm unable to share numbers (yet, I'll add them to URL once they're approved) I can say that the vast majority of values triggering this are unspecified (lax by default). I wonder then if many of these cookies are likely those being accessed after a POST request from some login or payment flow redirect chain. I don't have any data to back this hunch up but URL hints this may be the case. If it is then perhaps we can tie the redirect chain enforcement to the 2 min Lax+POST mitigation. I.e.: Allow unspecified cookies to be accessible after cross-site redirects for up to 2 minutes.
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: While I worry this will further ossify that "temporary" mitigation it feels better than a blanket except for unspecified cookies. Given our metrics I don't think your proposal is unreasonable, but the more we can tighten the restriction the better. Any thoughts? Does Firefox have any data that could support or refute my idea? (Tangentially: I'd still like to see the 2 min exception removed, but I get a headache even thinking about it.)
tagging NAME NAME for visibility to the above comment. I think tying this to the 2 minute exception is fairly reasonable - 1% of page loads is sadly much too high to ship what the spec describes in any reasonable time frame. Perhaps some pages would still break, but it's worth a shot. And I agree we should change the spec to match (whatever becomes) reality here.
What about the idea of differentiating between explicit and -defaulted ? Not ideal, but then at least there won't be a security regression for those who opt into . Then for -defaulted we could do something along the lines you propose, in name of webcompat.
Right, we already differentiate between explicitly Lax () and unspecified () when it comes to the 2 min Lax+POST mitigation. Only the unspecified cookies qualify for that mitigation, explicitly Lax do not. (Perhaps it would have been better to name it Unspecified+POST, oh well) I'm suggesting to continue that pattern for the redirect chain exception, so I think we're in agreement.
NAME Yes, that's aligned with our thinking right now. Do you have numbers that can help us gain more clarity for these exact cases (a redirect where the final URL is same-site, but the overall chain is to be considered cross-site, also called "boomerang redirect") and split up into explicit-lax and default-lax? We're still in the process of collecting those within Firefox, but are obviously interested in your insights so far.
NAME I think URL has what you want. Those numbers are from roughly a week ago. tl;dr Between 80-90% of cookies are unspecified/default lax. Cookies that are being newly written are on the higher end of the range, cookies being read are lower.
Hi! John from Apple WebKit here.
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: If we standardize different behavior for default vs explicit SameSite=lax … We increase the complexity of SameSite cookies significantly. Is that desirable? Will developers be able to know the difference without this effectively being displayed as an additional cookie attribute in developer tools? Are we arriving at the desired end state or piling on more legacy and technical debt? It looks to me like this should instead be a fourth SameSite value, beside none, lax, and strict. Then we’ll have to decide if the new, fourth value is the default or the old explicit lax. I generally don’t like fixing legacy problems by increased spec complexity since it doesn’t help the web/Internet progress. I will bring this up with the CFNetwork folks at Apple to see what they have to say.
Hi John, You bring up some good points. I'm curious if the CFNetwork folks had anything to add.
I think what's under discussion is making the fourth value explicit in the specification. It apparently is already a thing in some implementations. I'm not sure we have a good reason to expose it in syntax though. But yeah, a clear name in the specification would help with tooling and such.
+1
"Default" is an explicit value for the in the algorithms and storage model defined in Section 5. It's not a part of the syntax. Unfortunately it looks like the algorithm only sets the if there's an explicit SameSite attribute in step 17 ("Default" is used for an otherwise unknown value). Presumably the should be initialized to "Default" somewhere, but that's an assumption and not explicit. The value of same-site-flag is technically undefined if there isn't a SameSite attribute and that's clearly not the intent.
Hi, Zhenchao Li from Apple working on CFNetwork. This change sounds quite complex to me. Although, if it means minimizing website breakage and tightening cookie restriction, I'm in favor of explicitly adding the behavior to the RFC. It does sound like we need to move from "SameSite=lax by default" to "SameSite=[fourth value] by default". Also, "default" still needs to be a separate state persisted in "Storage Model" so as not to be conflated any time.