jiebi/CodeConvo huggingface dataset:
Code change:
credential.  In preserving the context, it should be clear to the user who invoked the flow, why it was invoked and what the consequence of completing the authorization, authentication or <del> credential presentation is.  The user experience should reinforce the </del> <ins> credential presentation is.  The user experience SHOULD reinforce the </ins> message that unless the user initiated the authorization request, or was expecting it, they should decline the request. <ins> This information MAY be communicated graphically or in a simple message (e.g., "It looks like you are trying to access your files on a digital whiteboard in your city center office.  Click here to grant access to your files.  If you are not trying to access your files, you should decline this request and notify the security department"). It SHOULD be clear to the user how to decline the request.  To avoid accidental authorization grants, the "decline" option SHOULD be the default option or given similar prominence in the user experience as the "grant" option. </ins> If the user uses an application on a mobile device to scan a QR code, the application MAY display information advising the user under which conditions they should expect to be asked to scan a QR code and under

Related discussion:
text: Moved paragraphs to improve the flow of the section. Removed references to User Education (which is now a mitigation itself, so all the details are already in the ad hoc section). Fix case for keywords should and may.
Code change:
HTTP/3 payload any kind of media carried indirectly over the QUIC protocol, as a WebTransport payload <del> the encapsulation of any Media Transport Protocol (mtp) in a QUIC </del> <ins> the encapsulation of any Media Transport Protocol in a QUIC </ins> payload an IETF mailing list (MOQ-ml), which was requested "... for discussion of video ingest and distribution protocols that use

Related discussion:
text: Move "considerations" to a separate draft, and do various related cleanup work (for example, removing unneeded references that supported text that has been deleted.
(but document focus is on all media categories, not just live media) (moving the considerations section to its own draft) (moving this diagram to the considerations draft)
Our diagram shows "media transport protocol" as one layer, which can be true, but the text points out that anything running over HTTP/3, or even WebTransport over HTTP/3, will have multiple media transport protocols. It would be helpful for readers if we showed this.
Sports fans of this draft may remember that this section was called Requirements, and true sports fans may remember that the contents had changed very little from when James and I thought this draft would be focused on Interactive use cases - and now it's focused on live media use cases. Rather than go into the BOF with a "Requirements" section that was a natural attraction for protocol designers, and almost completely mistargeted, I provided text for some of the considerations that I could type off the top of my head, before the I-D deadline. The existing list of considerations is not a complete list, and some of the considerations that are described in this section are "To Do", where the first thing To Do is to decide whether that consideration is a consideration for Live Media. To mention one significant example, the discussion about WebTransport doesn't mention one of the biggest advantages - the use of existing CDN infrastructure for live media streaming. But there are other examples - and I may think about this issue, and let other people also provide thoughts here, before I try to resolve the issue with PRs. (tagging the group, so you can be thinking about this as well) NAME NAME NAME NAME NAME
NAME and NAME - It is occurring to me that all the use cases we're recommending in this draft, and all the use cases that are named in , are pointing towards LIVE media. This document is even explaining why we think that's what matters first.
Code change:
HTTP/3 payload any kind of media carried indirectly over the QUIC protocol, as a WebTransport payload <del> the encapsulation of any Media Transport Protocol (mtp) in a QUIC </del> <ins> the encapsulation of any Media Transport Protocol in a QUIC </ins> payload an IETF mailing list (MOQ-ml), which was requested "... for discussion of video ingest and distribution protocols that use

Related discussion:
text: If we renamed the document as "Live Media Over QUIC", it would be more accurate, and the BOF proponents could point to this draft and ask people with other use cases if their use cases overlap with the live media use cases, perhaps allowing the BOF to recommend doing the live media use cases in this draft, and inviting people to provide comments on this draft explaining their use cases, so the IESG would know what to do with them. Your thoughts?
I don't object to the name change but I don't feel strongly.
That name works for me too.
We should revisit after the BOF, when we know what the scope of the document will be. :sunglasses:
So, this is slightly more complicated than I had hoped. The use cases in the draft span "Media Over QUIC". The considerations (and, if we get that far, requirements) in the draft only cover "LIVE Media Over QUIC". So, let's leave this one open, until we find out the right thing to do, and then we can Do The Right Thing. :innocent:
I would propose we rename (again) to "Media over QUIC Use Cases and Requirements", for a few reasons: Scope of use cases that the WG will work on isn't yet settled, and it's likely that we may need to cover some (but not all) interactive use cases as well as hybrid interactive/live. I still think we should set the protocol requirements in the document - this frees up the charter to describe scope and milestone, and our draft (if WG adopted) to set the use cases and what we will require of the deliverables. If WG adopted, the details of what is in and out can be made via WG consensus. This follows a similar title format to and other documents like it. NAME thoughts?
Code change:
specification, and allows clients to choose their preferred authentication scheme. <del> A fair question is whether allowing clients to choose from among supported authentication methods represents an opportunity for a downgrade attack.  Since resource servers will only enumerate authentication methods acceptable to them, by definition, any choice made by the client from among them is one that the resource server is OK with.  Thus, the resource server allowing the use of different supported authentication methods does not represent an opportunity for a downgrade attack. </del> 6. Processing some OAuth 2.0 messages requires comparing values in the

Related discussion:
text: Removed extraneous paragraph about downgrade attacks discussing an issue that's already addressed elsewhere in the specification.
Code change:
scenario provides these advantages, and can be accomplished by any of the architectural patterns described below. <del> 6.2. </del> <ins> 6.3. </ins> In this architecture, commonly referred to as "backend for frontend" or "BFF", the JavaScript code is loaded from a dynamic Application

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:
when choosing the required set of component identifiers, care has to be taken to make sure that the coverage is sufficient for the application, as discussed in security-coverage and security-message- <del> content. </del> <ins> content.  This specification defines only part of a full security system for an application.  When building a complete security system based on this tool, it is important to perform a security analysis of the entire system of which HTTP Message Signatures is a part. Historical systems, such as AWS-SIGv4, can provide inspiration and examples of how to apply similar mechanisms in a secure and trustable fashion. </ins> 2.

Related discussion:
text: message signatures are just one part of an overall system, and this adds language to make that expectation more explicit in the introductory sections.
Code change:
The "Early-Data" header field is not intended for use by user agents (that is, the original initiator of a request).  Sending a request in early data implies that the client understands this specification and <del> is willing to retry a request in response to a 4NN (Too Early) status </del> <ins> is willing to retry a request in response to a 425 (Too Early) status </ins> code.  A user agent that sends a request in early data does not need to include the "Early-Data" header field.

Related discussion:
text: (I accidentally put this on master without noticing earlier, sorry.)
Can we just have 425 now that it's official-ish? From martinthomson/http-replay
Code change:
Client Initiated Back-Channel Authentication (CIBA) CIBA: A standard developed in the OpenID Foundation that allows a device or service <del> (e.g., a personal computer, Smart TV, Kiosk) to request the OpenID </del> <ins> (e.g., a personal computer, smart TV, Kiosk) to request the OpenID </ins> Provider to initiate an authentication flow if it knows a valid identifier for the user.  The user completes the authentication flow using a second device (e.g., a mobile phone).  In this flow the user

Related discussion:
text: Addresses issue NAME
From WGLC Nit: "SmartTV" and "Smart TV" are used interchangeably throughout the doc. No preference on which one is used, but should be consistent. URL NAME Looks great! Some small proposed tweaks: Nit: "SmartTV" and "Smart TV" are used interchangeably throughout the doc. No preference on which one is used, but should be consistent. 6.2.3.1 Current text: "supports a new cross-device authentication protocol, called "hybrid"" Proposed text: "supports a new cross-device transport protocol, called "hybrid transports" Propose adding the following at the end of the first paragraph: "CTAP 2.2 hybrid transports is implemented by the client and authenticator platforms." Current text: "The main device and authenticator" Proposed text: "The main device (CTAP client) and authenticator" Current text: "The user will receive a push notification on the authenticator." Proposed text: "The user will typically receive a push notification on the device serving as the FIDO authenticator." 6.2.3.3 Current text: "Both the Consumption Device and the authenticator require BLE support." Proposed text: "Both the Consumption Device and the authenticator require BLE support and also need access to the internet" s/hybrid transport/hybrid transports Current text: "The mobile phone must support CTAP 2.2+ to be used as a cross-device authenticator." Proposed text: "The device serving as the FIDO authenticator must support CTAP 2.2+ to be used as a cross-device authenticator." tim On Mon, Apr 22, 2024 at 10:57 AM Rifaat Shekh-Yusef wrote: >
Code change:
The Use-As-Dictionary response header is a Structured Field STRUCTURED-FIELDS sf-dictionary with values for "match", "match- <del> query", "match-dest", "ttl", "type" and "hashes". </del> <ins> query", "match-dest", "ttl", and "type". </ins> 2.1.1.

Related discussion:
text: This removes the hashes negotiation and changes the Available-Dictionary request header to explicitly use sha-256 as discussed in URL If sha-256 becomes insufficient, the hash negotiation can then be added (or different mechanisms can be used). This is a rebased version of the (sorry, it got messy so it was cleaner to resubmit a clean one).
Code change:
The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information <del> systems.  This document defines the semantics of HTTP: its architecture, terminology, the "http" and "https" Uniform Resource Identifier (URI) schemes, core request methods, request header fields, response status codes, response header fields, and content negotiation. </del> <ins> systems.  This document defines the semantics shared by all versions of HTTP, including its architecture, terminology, core protocol elements, and extensibility mechanisms, along with the "http" and "https" Uniform Resource Identifier (URI) schemes. </ins> This document obsoletes RFC 2818, RFC 7231, RFC 7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC 7694, and portions of RFC 7230.

Related discussion:
text: "This document defines the semantics of HTTP: its architecture, terminology, the "http" and "https" Uniform Resource Identifier (URI) schemes, core request methods, request header fields, response status codes, response header fields, and content negotiation." replace by just "fields"?
I think it's useful to retain the current text, because those phrases are more likely to be recognised by readers coming to the document.
No real opinion, but it should be rewritten anyway: This document defines the semantics shared by all versions of the Hypertext Transfer Protocol (HTTP), including its architecture, terminology, and core protocol elements, along with the "http" and "https" identifier schemes. It could go on from there to describe the core elements, and maybe the core features as well, but shrug.
Code change:
long enough to validate the signature of the response that uses this component identifier. <ins> Note that the ECDSA algorithm in use here is non-deterministic, meaning a different signature value will be created every time the algorithm is run.  The signature value provided here can be validated against the given keys, but newly-generated signature values are not expected to match the example.  See security-nondeterministic. </ins> The "@request-response" component identifier MUST NOT be used in a request message.

Related discussion:
text: update canonicalization rules, remove weird headers from examples changed dictionaries and messages. updated crypto primative functions regenerate examples
Code change:
Response MUST NOT be compressed by an available dictionary. <del> 7. </del> <ins> 9. </ins> Since dictionaries are advertised in future requests using the hash of the content of the dictionary, it is possible to abuse the

Related discussion:
text: This changes the maximum ZStandard compression window to be the larger of 8 MB and the size of the dictionary. This allows for clients to limit the maximum window size to as low as 8 MB if they like (by not advertising support) while also allowing for clients to use larger dictionaries with ZStandard than they would be able to if the global limit was 8 MB.
NAME and NAME could you also take a look and see if the language looks ok?
Context: URL aims to clarify the window size limit for the Content Encoding token as it wasn't clear in RFC8878. Since the Compression Dictionary Transport draft hasn't been published yet, we should also add some window size considerations to it for and to maintain interoperability. I think in Chrome we ended up using . NAME
NAME could you comment on how this impacts Brotli dictionary decode? Is the dictionary independent from the compression window (so we can adopt the same defaults as or do we need to specify something relative to the size of the dictionary? NAME NAME for ZStandard, to allow for delta-encoding large resources, is reasonable or should it be ? We have use cases for delta-encoding wasm applications where the dictionary can easily be upwards of 50 MB.
For Zstandard, the states that the entirety of the dictionary is accessible as long as the input is <= Window Size. Therefore, to give an extreme case, it's possible to have a 50 MB dictionary, and it's entirely accessible even if the Window Size is only 1 KB, but only as long as the data to de/compress is <= 1 KB. As soon as we reach 1 KB + 1, reaching the dictionary is no longer valid. For delta compression, this has consequences. Presuming the reference is ~50 MB, and the updated content is also ~50 MB, one would need a window size of ~50 MB to ensure access into the dictionary during the entire reconstruction process. But if the updated content is just a bit bigger, say ~51 MB, a ~50 MB window size would allow delta operation only during the first ~50 MB, the last ~1 MB would have to be compressed without dictionary. If follows that the size of the dictionary is irrelevant for the Window size. What matters is for how long one wants to access the dictionary while rebuilding the content.
Code change:
Response MUST NOT be compressed by an available dictionary. <del> 7. </del> <ins> 9. </ins> Since dictionaries are advertised in future requests using the hash of the content of the dictionary, it is possible to abuse the

Related discussion:
text: And as a general approximation, one wants this dictionary during the entire reconstruction process, so the window size is effectively the size of the content to rebuild. Zstandard has a "windowless" mode which states exactly that : the size of the "window" is the size of the content. For this to work, one has to set the size of the content at the beginning of the compression process . Setting the content size is either an automatic operation when data is provided entirely upfront (), or, when data is provided in small increments (), it must be stated explicitly at the beginning (). will automatically trigger the "windowless" mode when the declared content size is smaller than the set Window size (effectively reducing the memory requirement for the decoder side). I'm not sure if there is another way to trigger it. Note that the decoder will be informed of the Window Size requirement by reading the frame header, and may decide to not proceed if this value is deemed too large. For example, has a default 128 MB limit, and will refuse to decompress payload requiring more that that, unless explicitly authorized to employ more memory (). Just for reference, offers a "large delta compression" mode with the command . It has made us somewhat familiar with some of these issues. In situations where the amount of data to compress and compare is very large, we now prefer to both the dictionary content and the destination file. It has proven useful to reduce memory pressure.
Thanks. That makes things a bit more complicated for the case where we want to require a minimum window size that the server can trust that all clients advertising content-encoding will be able to decode. For the dictionary case it might be cleanest to use the same 128MB limit for window sizes as the default zstd limit (knowing that the client won't allocate that much unless it actually gets a stream that uses it).
Hello. Shared dictionary is placed in the address space between backward reference window and static dictionary. In other words it does not interfere with normal compression window, but using it makes "static dictionary" references more expensive. We decided to order it that way, because shared dictionary works almost the same way as extra window. Sorry for the late response. Best regards, Eugene.
Extra note. As you can see brotli allows backward distances behind window.
Code change:
Response MUST NOT be compressed by an available dictionary. <del> 7. </del> <ins> 9. </ins> Since dictionaries are advertised in future requests using the hash of the content of the dictionary, it is possible to abuse the

Related discussion:
text: IIRC, regular (as opposed to large-window) brotli allows distances up to ~56MiB, i.e. larger shared dictionaries would not be useful (== referenced)
Thanks. For the dictionaries to be usable for a broad set of apps (including large wasm bundles), I'm considering spec'ing: Brotli: Regular 16MB window, allowing for delta-compression of resources up to ~50MB. ZStandard: 128MB window, allowing for delta compression of resources up to around that size, depending on where the duplicated bytes are in the updated resource. The main difference with regular content-encoding is on the ZStandard side where the window is 8MB. For platforms that are resource constrained and are not willing to support a 128MB window they would be limited to Brotli (and then decide how large of a dictionary they are willing to keep and use). Another option on the ZStandard side would be to allow for a maximum window that is a multiple of the dictionary size (i.e. 8MB or 2 * dictionary size whichever is larger with a 128MB max). That way the client can have an upper limit that it knows in advance before advertising as being available. That adds complexity to the encoding side though. We have already seen cases where people want to delta-compress resources > 50MB (wasm apps) where they had to use ZStandard instead of Brotli because of the Brotli limits so I don't think a small limit like 8MB for ZStandard would work with this use case.
That massive resources exist is not sufficient justification to build a system that will not be available to some users. I would prefer a far smaller default. If only to encourage the use of smaller resources overall. Defining a separate codepoint for massive windows is possible, say . The scalable option also seems reasonable. Clients can then choose to offer dictionaries when they exceed available resources.
I'm ok using the same 8MB window ( I believe) that we use for for and note that the effectiveness of delta compression for responses > 8MB using may be limited. The scalable option concerns me that people are likely to get it wrong and it won't be obvious and the decompression will start to fail as the dictionary and resource size changes. NAME does that sound about right?