jiebi/CodeConvo huggingface dataset:
Code change:
For example: <del> 2.4. When a HTTP server responds with a resource that is encoded with a dictionary the server MUST send the hash of the dictionary that was used in the "Content-Dictionary" response header. The "Content-Dictionary" response header is a Structured Field STRUCTURED-FIELDS Byte Sequence containing the SHA-256 hash of the contents of the dictionary that was used to encode the response. If the HTTP response contains a "Content-Dictionary" response header with the hash of a dictionary that the client does not have available then the client cannot decode or use the HTTP response. For example: </del> 3. This specification defines the 'compression-dictionary' link relation

Related discussion:
text: If we were to do that, having a fixed length hash as part of the format would make things more complex.
Having a fixed-length hash (or fixed hash) as part of a content coding is perfectly fine. If there is a need to update hashes, it is easy to define a new content coding.
NAME the doesn't use skippable frames and uses the same custom header for Brotli and Zstandard (with different magic numbers). I can switch to using a skippable frame instead (which effectively just becomes an 8-byte magic number since the frame length is always the same) but I'm wondering if it makes sense and is worth adding 4 bytes. It won't help in creating the files so it's just for decode time and the main benefit you get is that you can use the existing zstd cli and libraries to decode the stream without skipping the header but those also won't verify the dictionary hash, they will just skip over it. That might not be a problem but part of the decode process will be to fail the request if the hashes don't match.
In talking to the Brotli team, it looks like Brotli already and validates it during decode to select the dictionary to use. It uses a "256-bit Highwayhash checksum" so we can't use the hash to lookup a dictionary indexed by SHA-256 but we can use it to guarantee the decompression doesn't use a different dictionary (and the existing libraries and cli tools already use it). NAME when you were concerned about the , was it for both lookup and validation or just validation? I'm just wondering if we can use the existing brotli streams as they already exist or if we should still add a header to support locating the dictionary by SHA-256 hash.
There are a few places in HTTP where the interpretation of a response depends on something in the request. Everyone one of those turns out to be awful for generic processing of responses. That's my main reasoning, so I'd say both: lookup first, then validation. That is, my expectation is not that the client has a singular candidate dictionary, or that it commits to one in particular. So in the original design, when you had the client pick one, that didn't seem like a great idea to me. For validation, Highwayhash (NIH much?)
Code change:
For example: <del> 2.4. When a HTTP server responds with a resource that is encoded with a dictionary the server MUST send the hash of the dictionary that was used in the "Content-Dictionary" response header. The "Content-Dictionary" response header is a Structured Field STRUCTURED-FIELDS Byte Sequence containing the SHA-256 hash of the contents of the dictionary that was used to encode the response. If the HTTP response contains a "Content-Dictionary" response header with the hash of a dictionary that the client does not have available then the client cannot decode or use the HTTP response. For example: </del> 3. This specification defines the 'compression-dictionary' link relation

Related discussion:
text: doesn't appear to be pre-image resistant, so I'd be concerned if we were relying on the pre-image resistance properties of SHA-2. Can we be confident that this is not now subject to potential ployglot attacks if we relied on that hash alone? That is, could two clients think that they have the same resource, but do not?
I wouldn't be comfortable switching hashes given the wider and proven use of SHA-256 and agree on the lookup case to allow content-encoding with different and multiple dictionary negotiations. Looks like a separate header is still the cleanest so the main remaining question is if we use the same style of header for both or a skippable frame for Zstandard. I also need to update the brotli citations to point to the shared dictionary draft format instead of the original brotli format. On Sun, May 12, 2024 at 7:58 PM Martin Thomson NAME wrote: >
Sorry for the late comment. It seems to me that conveying this information in the content eases the integration with Signatures and Digest. It is not clear to me if there are still possible cases where the response does not contain all the information required for processing.
Thanks
Looks like you just need to update the PR summary to reflect this change.LGTMOverall, I like this. I want to flag for others that it doesn't use the skippable frame concept.
Code change:
TIPS uses this directory schema to generate template URIs which allow clients to construct the location of incremental updates after receiving the tips-view-uri path from the server.  The generic <del> template for the location of the update item on the edge from node i to node j in the updates graph is: </del> <ins> template for the location of the update item on the edge from node 'i' to node 'j' in the updates graph is: </ins> Due to the sequential nature of the update item IDs, a client can long poll a future update that does not yet exist (e.g., the

Related discussion:
text: Please add captions to all figures and call them in the text rather than "below" thing :-) Thanks.
Code change:
a Transparency Service MAY additionally support verifiability of client authentication and access control <del> 5.2.3.4. </del> <ins> 5.2.4.4. </ins> Transparency Services MAY document their governance rules and procedures for operating the Transparency Service and updating its

Related discussion:
text: Extending the architecture with Transparent Statements recording the Transparency Service configuration, notably its registration policy. The syntax of the configuration (notably its supported registration policies) are still TBC.
Code change:
from tracking the usage of the Referenced Token when the status is being checked.  If an Issuer offers status information by referencing a specific token, this would enable him to create a profile for the <del> issued token by correlating the date and identity of Verifiers, that are requesting the status. </del> <ins> issued token by correlating the date and identity of Relying Parties, that are requesting the status. </ins> The Status List approaches these privacy implications by integrating the status information of many Referenced Tokens into the same list. Therefore, the Issuer does not learn for which Referenced Token the <del> Verifier is requesting the Status List.  The privacy of the Holder is protected by the anonymity within the set of Referenced Tokens in the Status List, also called herd privacy.  This limits the possibilities of tracking by the Issuer. </del> <ins> Relying Party is requesting the Status List.  The privacy of the Holder is protected by the anonymity within the set of Referenced Tokens in the Status List, also called herd privacy.  This limits the possibilities of tracking by the Issuer. </ins> The herd privacy is depending on the number of entities within the Status List called its size.  A larger size results in better privacy

Related discussion:
text: Use term Relying Party and Issuer URL
Sometimes we use Verifier, sometimes we use Relying Party. After deciding this, we should add them to the Terminology
As this is moving to OAuth Security working Group, we should adopt Relying Party as terminology
Code change:
The resource is specified by the effective request URI and any "validator field" contained in the message. <del> The relationship between Content-Location (see Section 6.2.5 of I- D.ietf-httpbis-semantics) and Digest is demonstrated in post-not- request-uri.  A comprehensive set of examples showing the impacts of representation metadata, payload transformations and HTTP methods on Digest is provided in examples-unsolicited and examples-solicited. </del> <ins> The relationship between Content-Location (see Section 6.2.5 of SEMANTICS) and Digest is demonstrated in post-not-request-uri.  A comprehensive set of examples showing the impacts of representation metadata, payload transformations and HTTP methods on Digest is provided in examples-unsolicited and examples-solicited. </ins> A Digest field MAY contain multiple representation-data-digest values.  This could be useful for responses expected to reside in

Related discussion:
text: References I-D.httpbis-semantics using an inline referece to {{SEMANTICS}}. This will ease the transition once SEMANTICS is updated to RFC.
Code change:
FIDO credential is not available on the consumption device.  It MAY be used as an authentication method with the Authorization Code Grant RFC6749 and PKCE RFC7663, to grant authorization to an Consumption <del> Device (e.g., Smart TV or interactive whiteboard) using a mobile </del> <ins> Device (e.g., smart TV or interactive whiteboard) using a mobile </ins> phone as the authenticating device.  This combination of FIDO2/ WebAuthn and Authorization Code Flow with PKCE enables cross device authorization flows, without the risks posed by the Device

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:
Name: http_response_status <del> Description: The intermediary has received a 4xx or 5xx status code from the next hop and forwarded it to the client. </del> <ins> Description: The intermediary has received a response from the next hop and forwarded it to the client. </ins> Extra Parameters: None.

Related discussion:
text: Signed-off-by: Piotr Sikora
This is effectively editorial, since the error restriction was removed in URL, where this type was renamed from to , but the description didn't reflect that change. cc NAME
Code change:
a HTTP header value. If input_key is not a sequence of characters, or contains <del> characters not in lcalpha, DIGIT, "*", "_", or "-", fail </del> <ins> characters not in lcalpha, DIGIT, "_", "-", ".", or "*" fail </ins> serialisation. Let output be an empty string.

Related discussion:
text: Allow "." in . Also consistently reorders character lists for key.
I'm getting a high failure rate on parsing (but with a very low number of occurrences; it's not exactly a popular header). The failure seems to occur because of keys like this: Allowing in key would address this, but I'm not sure it's worth the change. Additionally, key currently only allows lowercase alpha; this is mainly to avoid confusion between and , etc. So far this seems to be pretty supportable in cache-control, accept- and elsewhere, with the vast majority of headers seeming to choose the lowercase form. However, it does cause issues in a couple of cases: In , the parameter isn't compatible, leading to a high failure rate for that header In cookies, this makes a number of things incompatible, but it's not clear that we can treat them as a direct mapping anyway.
I have no opinion about dots. As to case, though; I think the options are: say lower-case only – the current option we should probably instruct individual headers' specifications to define how to get into/out of SH, which is harder for extant specs open it up to anycase and be case-sensitive this means that parses to and if someone wants to collapse / they have to do it after the fact open it up to anycase and be case-insensitive still requires instructions for individual headers' specs to define how to get out of SH Incidentally we don't say anything about case for tokens, not that it matters as far as SH is concerned (we never have to compare them.) It might not hurt to say something to the effect that "tokens are case-sensitive so you aren't allowed to change them, but an individual specification that uses sh-token may have special rules for comparing tokens that only differ in case".
WRT lower-case -- I think your analysis is correct; my inclination is to either stay lc only, or to force to LC when parsing textual headers (much like H2 does for field names). WRT instructions for existing headers -- that's out of scope for SH "officially."
Your patch for looks good. Force-lowercasing makes me a bit nervous, because the wire form for h1 will be materially different than what appears in the data model. We'll have to be careful to distinguish between the h1 wire format and the abstract model for keys (which we currently are pretty sloppy about).
Code change:
a HTTP header value. If input_key is not a sequence of characters, or contains <del> characters not in lcalpha, DIGIT, "*", "_", or "-", fail </del> <ins> characters not in lcalpha, DIGIT, "_", "-", ".", or "*" fail </ins> serialisation. Let output be an empty string.

Related discussion:
text: More seriously, even if we did force-lc, I realise it wouldn't be possible to round-trip things like includeSubDomains, so it probably isn't going to be useful on its own; there will always need to be some application knowledge / mapping. So, I'm inclined to leave casing in keys as-is.
I don't know what you mean by "force-lowercasing". Is that different from leaving it as-is?
i.e., forcing LC when parsing textual headers, as per above.
Oh, do you mean converting "FooBar" to "foobar" as part of some algorithm? Right, yeah, no, I don't like the idea of coercing data into the model if it can't be round-tripped back out. If an individual header field's spec supports a different data model (e.g. strings), then it's up to that header field's spec to define how to convert their string to an sh-key, and back again. I.e. don't do anything in SH, and punt it to RFC6797bis (or draft-mnot-bsh).
Agreed. Could you make the change into a PR?
It is.
Code change:
The "origins" member of the root object has a value of an array of strings, one of which is a case-insensitive character-for- character match for the origin in question, serialised into <del> Unicode as per RFC6454, Section 6.1, and </del> <ins> Unicode as per Section 6.1 of RFC6454. </ins> This specification defines one additional, optional member of the root object, "commit" in commit.  Unrecognised members MUST be

Related discussion:
text: I think that I caught everything in the first round of discussion. There aren't any substantial changes here, but it's a PR so that others can confirm.
Code change:
4.3. <ins> TODO: Confirm these requirements, consider looking at how RFC 8836 applies to this requirement. 4.4. </ins> TODO: confirm scope of this draft to describe lossless media transport, lossy media transport, or both lossless and lossy transport. <del> 4.4. </del> <ins> 4.5. </ins> Media should be able to flow in either direction from client to server or vice-versa, either individually or concurrently. <del> 4.5. </del> <ins> 4.6. </ins> TODO: Unsure if this should be a requirement.  If it is, we have to consider two things: WebTransport supports HTTP/2, are we going to

Related discussion:
text: Hi, NAME I think this looks mostly fine (it looks like the abstract is a tiny bit garbled, but we can fix stuff like that in an editorial pass). Based on the changed title, I'm assuming that we aren't worrying about SRT and RUSH in this draft - that's probably a good call, because I don't think their requirements are going to look much like RTP over QUIC requirements. There will be some places that I will need to tighten up what I wrote, because they were still in scope when I was typing. I'll merge this, and see where I end up in an hour or two of typing.
I needed a bit more context for this: I'm probably confused by "The protocol". URL says it provides this authentication using TLS 1.3 handshake. Are you thinking of something in addition to the QUIC cryptographic handshake? (Assuming the definition of "Media Transport Protocol" in ), something provided by the Media Transport Protocol level? Or something else?
Something in addition to the QUIC cryptographic handshake (in which I am talking about TLS mutual authentication here, where client presents a valid certificate to server, and verifies the server certificate). Consider: Existing protocols in this space usually offer some "shared secret" of some variety as part of either/or an authentication handshake, and encryption of media: which are just secret values set in the field during connection handshake (see § 6.4) - but note they also support a cert-based approach which more closely matches TLS mutual auth where the Stream ID and user define the authorisation Before RIST Main profile there hasn't been a need for a lot of certificate-based authentication and so existing folk in field would use these types of shared secret patterns, and that having to keep PKI for devices may be problematic. Consider things like encoding hardware deployed in remote locations. Other options could be considered, like using a more SIP-like approach, but we would have to be careful not to bring the rest of the SIP kitchen sink with its round peg that might not fit in the square QUIC slot. I get this requirement presently is a bit flaky in part because the requirements are a bit unclear. Perhaps I put a little more description on the requirement, or remove it from the draft now, and leave it for a "ask later". Thoughts?
Code change:
4.3. <ins> TODO: Confirm these requirements, consider looking at how RFC 8836 applies to this requirement. 4.4. </ins> TODO: confirm scope of this draft to describe lossless media transport, lossy media transport, or both lossless and lossy transport. <del> 4.4. </del> <ins> 4.5. </ins> Media should be able to flow in either direction from client to server or vice-versa, either individually or concurrently. <del> 4.5. </del> <ins> 4.6. </ins> TODO: Unsure if this should be a requirement.  If it is, we have to consider two things: WebTransport supports HTTP/2, are we going to

Related discussion:
text: NAME I think (1) adding the explanation that this is beyond the authentication mechanism provided by QUIC, and (2) leaving it in the draft, with a note that more detail is needed, and will be added as discussion proceeds, is all that's needed for now.
Closing this as I think it has been addressed, please by all means speak up if we still should do work here.
I THINK what we are doing, is roughly Start with current "Media - Media Transport Protocol", where "Media Transport Protocol" might be RTP Encapsulate in QUIC, to give "Media - Media Transport Protocol - QUIC" If that's right, we should be using "Media Transport Protocol" to describe the first layer under "Media", and what we're doing might better be described as something like "Media Transport Protocol Encapsulation" ("in QUIC"). Whatever we choose, we should be consistent - the Abstract says which would make me believe that we're designing a replacement for existing media transport protocols, but then under "Non-requirements, we have I think that the second quote is correct, so we just need to be clearer in the first quote.
I agree with this, and it should be fixed. Would you like me to clean it up or do you want to roll it in with other changes?
Hi, NAME would it be OK if you did this cleanup? I think adding the picture of the two protocol stacks, in some form, will be super helpful for readers.
I think we can close this as our nomenclature for the document is kind of done now the -00 is out.
We have been talking about "Media Over QUIC" as a broad term that would include any media transport protocol running over QUIC, which (apparently) would include RTP over QUIC SRP over QUIC RUSH, which runs over QUIC If we are doing "Media over QUIC", all of these (and potentially others) would be in scope. If the scope of this document is "Media over RTP over QUIC", that would be fine, but we should say that. Thoughts?
I think we've fixed this one - I'll close it for now.
Code change:
dependencies, which avoids these issues. frame describes considerations for server buffering of <del> PRIORITY_UPDATE frames.  HTTP/3 implementations might have practical barriers to determining reasonable stream concurrency limits depending on the information that is available to them from the QUIC transport layer. </del> <ins> PRIORITY_UPDATE frames. </ins> server-scheduling presents examples where servers that prioritize responses in a certain way might be starved of the ability to

Related discussion:
text: Editorial change related to . This may not close the issue on its own, so lets resolve that separate.
Simplification; but WFM either way.
Code change:
is unsupported (e.g. a live media server signalling it does not support receiving from a given client). <del> 4.2. </del> <ins> 4.3. </ins> In the initiation of a session both client and server must perform negotiation in order to agree upon a variety of details before media

Related discussion:
text: This is short, but we should say something about why we're working on this section. Comments are, of course, encouraged.
NAME is hoping that discussion of some requirements at a level that is not protocol-specific would be helpful. It's not helpful to include protocol-specific requirements in this document. This document should explain that.
Code change:
authority component, an empty Host header field will be sent in this case. <del> To allow for the possibility of a transition to the absolute-form for all requests in some future version of HTTP, a server MUST accept the absolute-form in requests, even though HTTP/1.1 clients will only send them in requests to proxies. </del> <ins> A server MUST accept the absolute-form in requests even though most HTTP/1.1 clients will only send the absolute-form to a proxy. </ins> 3.2.3.

Related discussion:
text: This is related to the suggestion in but provides the modern reason why all servers work this way.
'This allows servers to be deployed in non-traditional configurations, such as within a custom service mesh or content distribution network, where the proxy/origin distinction is handled upstream.' I don't really buy this; suggest just removing this sentence.
Code change:
setting of the peer endpoint is set to 0. <del> The HEADERS frame payload has the following fields: </del> <ins> The PUSH_PROMISE frame payload has the following fields: </ins> Padding size high bits.  This field is only present if the PAD_HIGH flag is set.

Related discussion:
text: I believe that PADLOW and PADHIGH bits in DATA frame were not updated when the dependency based priority was merged. It is quite a headache for implementors if these bits differ across frames.
Yeah, my bad. I missed one.