jiebi/CodeConvo huggingface dataset:
Code change:
Track Name: Identifies the track name as defined in (track-name). <del> StartGroup: The start Group ID, plus 1.  A value of 0 means the latest group. </del> <ins> Filter Type: Identifies the type of filter, which also indicates whether the StartGroup/StartObject and EndGroup/EndObject fields will be present.  See (sub-filter). StartGroup: The start Group ID.  Only present for "AbsoluteStart" and "AbsoluteRange" filter types. </ins> <del> StartObject: The start Object ID, plus 1.  A value of 0 means the latest object.  This field is not present when Start Group is 0. </del> <ins> StartObject: The start Object ID within the StartGroup.  Only present for "AbsoluteStart" and "AbsoluteRange" filter types. </ins> <del> EndGroup: The end Group ID, plus 1.  A value of 0 means the subscription is open-ended and continues to the end of the track. </del> <ins> EndGroup: The end Group ID.  Only present for the "AbsoluteRange" filter type. </ins> EndObject: The end Object ID, plus 1.  A value of 0 means the <del> entire group is requested.  This field is not present when End Group is 0. </del> <ins> entire group is requested.  Only present for the "AbsoluteRange" filter type. </ins> Track Request Parameters: The parameters are defined in

Related discussion:
text: I think we should eventually bring back Locations so the publisher can do this conversion too without an additional RTT, but the desire was to simplify start/end ranges.
FWIW, I thought/intended start_group=0 to correspond to b. Also +1 to removing case 2.
Thanks for summary. +1 to remove case 2 (abs/latest). I also thought we had b. today but we need case b so lets update to make it clear we have b (latest/0). I don't think we have a use case for a (latest/abs), +1 on remove. I originally was in favor of case c (next/0) but I have changed my mind for now. IF you need this, you just do case 1 (latest/latest) and toss out object until you get to the next group. If there was not enough bandwidth to do this, then there is probably not enough bandwidth for the next group when it arrives. If we get a bunch of code running and can show that (latest/latest) is not good enough and we really need (next/0), then I will change my mind but for now, I think we can live without (next/0). And +1 to point that TRACKSTATUSREQUEST solves most problems.
A +1 to all these points Regarding starting at the latest group at the beginning, this seems like the default starting use case for many players. Therefore per Luke's comment -
Fixed by
Code change:
CTL characters that lead to set-cookie-string rejection, as it is considered whitespace, which is handled separately. <ins> NOTE: The set-cookie-string may contain octet sequences that appear percent-encoded as per Section 2.1 of RFC3986.  However, a user agent MUST NOT decode these sequences and instead parse the individual octets as specified in this algorithm. </ins> A user agent MUST use an algorithm equivalent to the following algorithm to parse a set-cookie-string:

Related discussion:
text: ~~
Thanks! This Lgtm but I'll let Steven take a look too
This looks to me as well, thanks!
UAs should not decode any URL-encoded (or otherwise encoded) characters while storing a cookie, e.g. a cookie such as should not be interpreted as a cookie. I landed some WPTs for this in URL Chrome, Edge, Firefox, and Safari do the right thing. I think this could just be a clarifying note in the parsing algorithm section.
I'll take this one
Let's make sure we are consistent for names and attributes.
Code change:
This documents extends the verifiable data structure registry of I- D.ietf-cose-merkle-tree-proofs with the following value: <del> This document defines inclusion proofs for CCF ledgers.  Verifiers MUST reject all other proof types </del> <ins> This document defines inclusion proofs for CCF ledgers. Corresponding CCF Verifiers MUST reject proof types they do not support. </ins> 2.1.

Related discussion:
text: URL As promised at the meeting last week I have reviewed both: URL URL This is my review of the Birkholtz draft profile. REVIEW NOTES Overall very good, just a few comments: BIRKHOLTZ [Section 2]: “This document defines inclusion proofs for CCF ledgers. Verifiers MUST reject all other proof types” It’s unclear to me how useful this normative language is. Does it pollute the implementer’s wider implementation of cose-merkle-tree-proofs? In which case I think it’s wrong: verifiers might well verify many different transparent statements from a plurality of logs with a plurality of proof types. Of course for any given transparent statement they need to implement the proof verification correctly but I don’t see the value of this rejection statement. Privacy Considerations could do with some content (or removal if we consider that leaves and log activity are not relevant leakage of privacy info) Security Considerations could do with some content: CCF ledgers have certain trade-offs and assumptions about the environment they run in: should these be noted? Possibly a small nit, but “Historical transaction ledgers produced by Trusted Execution Environments” feels wrong to me. The ledger isn’t produced ‘by’ the TEE. It’s produced by a lump of code running in a TEE protected environment of some flavour. Or at least you have to hope it is. See comment on security considerations. [Section 7] reference to cose-merkle-tree-proofs is broken. Please fix. [Appendix A. Attic]: Casual language “Not ready to throw these texts into the trash bin yet.” … but there’s nothing else in there! Please remove. Jon
Code change:
Reference: RFC4960 appendix B, this document. <del> Status: deprecated. </del> <ins> Status: insecure </ins> To allow sender and recipient to provide a checksum which is independent from "Content-Encoding", the following additional digest-

Related discussion:
text: Thanks, nice solution.
The latest draft of the Digest Fields RFC [0] deprecates all non-cryptographically secure algorithms (notably, MD5 and CRC32c). Given that the RFC is "not intended to be a general protection against malicious tampering with HTTP messages," I'd like to propose not deprecating at least these two algorithms, or changing "deprecated digest algorithms MUST NOT be used" to "should be used with caution" or similar. CRC32c is a very useful algorithm because it is composable (crc(A+B) == combine(crc(A), crc(B))). See [1] for an explainer and [2] for an implementation of combine() in zlib. MD5 is ubiquitous. AWS S3 and Google Cloud Storage both use it (see [3], which has similar syntax to this RFC except that the crc32c is base64 instead of hex). [0] URL [1] URL [2] URL [3] URL Sorry if this is the wrong forum. I saw some links from the w3c mailing list archive that looked like more discussions were happening here than there.
Hi NAME this is the right place, thanks for opening the issue. Do you have a use case where you'd like to use these algorithms with the Digest or Content-Digest header? They are pretty old and pretty bad at their intended purpose - what caution can we offer? The statement comes from URL, which is really about making it clear that applications do care about protecting messages also need to apply signatures that protect HTTP header or trailer sections. Otherwise, an attacker could just change the header at the same time as changing the representation.
Thanks for the fast reply. My use case is for detecting file corruption in internal HTTP communication, where we trust the network/server/client. Since it's internal, we don't have to obey a standard, but I was hoping to provide the CRC32C and MD5 that we already store to our end users -- provide something instead of nothing. Those algorithms provide an adequate level of error detection by our rough calculation (considering that TCP and other layers also checksum). Intel's implementation of CRC32C [0] runs at >19 GB/s, whereas SHA256 runs at only ~360 MB/s.
Code change:
Reference: RFC4960 appendix B, this document. <del> Status: deprecated. </del> <ins> Status: insecure </ins> To allow sender and recipient to provide a checksum which is independent from "Content-Encoding", the following additional digest-

Related discussion:
text: We also take advantage of the ability of CRC32C to be combined, so we can concatenate files in O(1) time and get their CRC32C without calculating a SHA256/512 or MD5 over the whole content. We serve some millions of files. Google Cloud Storage and AWS S3 probably store many trillions of files and provide CRC32C+MD5 and MD5, respectively.1 It would be pretty impactful for servers to be able to pass along these digests and might make it worthwhile for browsers to start verifying digests for downloads (e.g. revive [1]). I might be under-appreciating the security intents of this RFC, but there is clear mention of the other benefits of the RFC (below), which are ones that non-cryptographically secure hashes are often good enough for. [0] URL [1] URL Edit: 1 Clarification: The S3 object is an MD5 in many scenarios, and S3 uses for integrity checks during uploads. They do not explicitly store the MD5 for all objects though.
Corruption in the network does happen, but HTTPS is a far better way of managing that risk. I know that you say that you trust them, but I would be worried about the network/server/client being - or becoming - untrustworthy. Obviously, if you are into high-volume transfers of bulk data, you are going to do what you need to do; specialized applications have specialized constraints. But that doesn't make unsecured transfers any less inadvisable; I'd stand by the deprecation here as a general statement.
Hi NAME Thanks for joining the discussion! Let me clarify one point: This just means that the part protected by Digest (the representation) is only a subset of an HTTP message. For the rest, while I agree on some of your considerations, eg. we had a very long discussion on that URL Maybe, since crc32 & co - while deprecated - are still defined in the digest algorithm table, I think that you wouldn't have particular interoperability issues if you need to use them in a specific environment.
Thanks NAME for the pointers to the earlier discussions. I'd thought I'd searched but somehow missed those.
Code change:
Reference: RFC4960 appendix B, this document. <del> Status: deprecated. </del> <ins> Status: insecure </ins> To allow sender and recipient to provide a checksum which is independent from "Content-Encoding", the following additional digest-

Related discussion:
text: I'll yield, although I remain in favor of saying these "SHOULD NOT" instead of "MUST NOT" be used at least because of their ubiquity, performance and the composability of CRCs. One last question: does the Digest header provide better security than, or any additional beyond, what TLS provides? My reading of the RFC is that TLS is the typical primary protection layer (since doesn't protect headers; indeed, itself could be altered) and is primarily useful for finding ~bugs. (PS: I really like the digests, nice idea.)
NAME you've made some good points. Adding accommodation for these algorithms, given the proliferation of e.g. MD5 for this kind of integrity checking could be better than nothing, or hoping that everyone would run a SHA-algo over all of their existing assets. The thorny part is how to square the circle on relaxing the rule and providing clear, meaningful guidance to implementers. The MUSTNOT helps set a clear bar, this means its unambiguous what the spec thinks about the relationship of Digest to secure usage scenarios. Anything else needs careful wording and is hard to get right. The current MUSTNOT is slightly odd in so far as we don't state the ramifications if it is used. Part of that is a product of how Digest has been defined and how apps use it
NAME The actual work on digest was driven by its usage in signing http messages (eg URL and URL ) This is at a different layer wrt TLS. So you can see Digest as a building block for creating non-repudiable HTTP exchanges without altering the payload (since signatures are conveyed via http headers). Hth, R.
Personally -- I think there's something here worth considering. AIUI the primary use case for headers is not adversarial -- it's end-to-end (i.e., through various intermediaries, toolkits, perhaps a data store) integrity. If someone has lots of content they've calculated CRC or MD5 for, it seems reasonable to allow them to use it in ; not only is it more efficient, but it saves them recalculating a value for all of that content (and possibly getting it wrong -- that's effectively "end-to-end over time"). OTOH, there are adversarial use cases for too -- mostly, signing the digest as a proxy for signing the content.
Code change:
Reference: RFC4960 appendix B, this document. <del> Status: deprecated. </del> <ins> Status: insecure </ins> To allow sender and recipient to provide a checksum which is independent from "Content-Encoding", the following additional digest-

Related discussion:
text: Here, using CRC or MD5 can be bad, and shouldn't be encouraged (or perhaps allowed) by the spec. This leads me to think that deprecating them isn't the right thing to do; instead, what about marking them as insecure in the registry, and putting language into the spec to explain how to use that? If folks think that's a good idea, I can do a PR.
Thanks for the background NAME . NAME NAME I think that sounds reasonable to state something like "insecure digests {MUST NOT be used|are not suitable} for protection against malicious actors." The final part of this I think would be allowing for the insecure digests.
I like NAME idea of introducing "insecure". It's not trivial how to state that insecure algorithms must not be used in signatures/adversarial use cases. I'm waiting for Mark's proposal :)
Maybe "Checksum Only" to imply a more narrow purpose. "Insecure" is not the opposite of "secure".
LGTMA pragmatic approach.
Code change:
Signature may be verified multiple times, potentially by different entities. <del> The term "Unix time" is defined by POSIX.1 section 4.16 [2]. </del> <ins> The term "Unix time" is defined by POSIX.1 section 4.16 [5]. </ins> This document contains non-normative examples of partial and complete HTTP messages.  To improve readability, header fields may be split

Related discussion:
text: This removes the in-document "issues" list and background introduction note paragraph, in line with the document's status as a working group draft backed with an issue tracker. All removed items should have corresponding issues tagged with in this repository's issue tracker (some have already been closed), so keeping them in the document was redundant and artificially inflated the page count.
NAME good idea, note added to the top, following the pattern in other drafts
LGTM. You might want to add a note at the top directing folks to the issues list, etc.; see other drafts.
Code change:
provides a join point for subscriptions, so a subscriber that does not want to receive the entire track can opt to receive only the latest group(s).  The publisher then selectively transmits objects <del> based on their group membership. </del> <ins> based on their group membership.  Groups can contain any number of objects. </ins> Groups are ordered numerically by their Group ID.

Related discussion:
text: How big can a group be? I know we (probably) won't be able to set a fixed limit, but I feel like we need to answer this in order to know what kind of design assumptions to make. Is a single group expected to be small enough to fit in the cache? Will the protocol work if a media track is just a single group that is being appended to for hours if not days? I was thinking about stream mapping and the resource-use-at-relays problem earlier today, and realized we might not currently have a conclusive answer for those.
As it stands today, the group ID is merely an annotation used by SUBSCRIBE hints. It's a sync point only by convention; in actuality the relay has no idea if objects within a group depend on each other. The relay is expected to cache/serve/evict objects independently so the group size is irrelevant. For example, a valid use-case is a single audio group with an object per frame. Each OBJECT would have an expires field of 30s, effectively dropping the head of the group as time progresses. The total number of objects per group is unbounded but the cache size is bounded. I strongly disagree with this. I want groups to actually be sync points, in which a relay knows that it should not evict OBJECT N without also evicting OBJECT N+1. Then the maximum size of the group actually matters.
IMO the size of a group (in bytes, or object count, or wallclock duration) should not be defined by the moq-transport spec. Limits such as these are driven by the physical characteristics of the caches and therefore should be provided by the relay (cache) provider. A streaming format (such as WARP) may choose to define a minimum object size to be supported for interop reasons between relays, but this should probably stay outside of moq-transport.
+1 to will's point. Group Size vary depending on the application - video, audio, chat, something new If any application needs to be aware of this, we can do the following Have catalog specify the group size per track Have a MOQT message updated where the Publisher can specify it per track in Subscribe OK. This might help as hint to caches if need be.
Individual Comment: There may be something interesting for moqt here in expressing more information that's useful to a cache.
Code change:
provides a join point for subscriptions, so a subscriber that does not want to receive the entire track can opt to receive only the latest group(s).  The publisher then selectively transmits objects <del> based on their group membership. </del> <ins> based on their group membership.  Groups can contain any number of objects. </ins> Groups are ordered numerically by their Group ID.

Related discussion:
text: Maybe an explicit expiry time would be more useful than a TTL, or a TTL at the group rather than the object level? Caches will evict stuff and can go fetch it if someone asks for it later. Maybe what needs to be specified is what happens when a cache receives Objects 0-10, evicts 0-3, then gets a SUBSCRIBE for Absolute/0-10?
Yeah, the cache needs some dependency information if it has any hope of evicting objects before the maximum TTL. That should be the purpose of group in my opinion.
I think we should allow it to be pretty much any size and as we use a VarInt for the object id so it does not matter. I guese I am not seeing a problem here from what we have today with pretty much no limit on number of of objects or number of groups. So I guess I am saying whatever max of VarInt is which I assume will be at least 2^60.
NAME are you fine with NAME point? If so, please close the issue.
I think we should add a note that groups can be in practice arbitrarily big.
Code change:
security analysis tools on the same product.  The intention is to identify any security weaknesses or vulnerabilities in the package. <del> Initially a particluar analysis can identify itself as a simple </del> <ins> Initially a particular analysis can identify itself as a simple </ins> weakness in a software component.  Over a period of time, a statement from another third-party illustrates that the weakness is exposed in the same software component in a way that it is an exploitable

Related discussion:
text: Thanks for merge. I realize these are minor things (especially in developing a draft), so know that I am reading and digesting/thinking on the actual content. Thanks for your and the others' efforts.
LGTM! Sincere thanks for spotting them!
Code change:
Connection. One exception to this is the TE header field, which MAY be present in <del> a HTTP/2 request, but when it is MUST NOT contain any value other </del> <ins> an HTTP/2 request, but when it is MUST NOT contain any value other </ins> than "trailers". HTTP/2 purposefully does not support upgrade to another protocol.

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
Code change:
as shown here. Conformance criteria and considerations regarding error handling are <del> defined in Semantics-conformance. </del> <ins> defined in Semantics. </ins> 1.2.

Related discussion:
text: ... components, depending on the form of request-target, and when authority might be empty. This is an alternative to
In determining the request target, the following text is included after failing to find an authority in configuration, the authority form target, or the Host header: This is a security risk because it means that servers might not agree with clients about the identity of the resource that the request is directed to. This is especially bad as a TLS certificate is good for every port and often good for multiple names, which can mean a fairly large scope over which an attacker can exploit this confusion. The origin form description doesn't use 2119 language, it says "A Host header field is also sent", citing . And that section is a bit weaselly in that regard, using a "URL". If this were a "MUST ... unless" in -semantics, this problem would not exist (at least in theory). Just to confuse things, the absolute-form says , which might be read to imply that Host truly is mandatory: The asterisk-form is the only other option that naturally lacks an authority, and that says nothing, so that might be fixed up similarly.
Keep in mind that the first text is what to do when receiving a message without Host or absolute-form, whereas the other texts are requirements on generation. Yes, it is a security risk to not send Host, and I assume it would be one to provide service for an https resource without verifying that the client's request indicates one of the server's host (somehow). So, PR welcome, but the final text still needs to accept non-TLS HTTP/1.0 requests without a Host (for ass-backwards reasons).
BTW, the reason it says SHOULD here instead of MUST is because this requirement about the ordering of fields in the header section, not about whether or not Host needs to be sent.
OK, that's good. It's not a genuine problem, we just need to be clearer about generation requirements (and we might be able to carefully condition the inclusion of a default).
better again
Code change:
effort attempt to remove the information from volatile storage as promptly as possible after forwarding it. <del> This directive is NOT a reliable or sufficient mechanism for ensuring privacy.  In particular, malicious or compromised caches might not recognize or obey this directive, and communications networks might be vulnerable to eavesdropping. </del> <ins> This directive is a reliable or sufficient mechanism for ensuring privacy.  In particular, malicious or compromised caches might not recognize or obey this directive, and communications networks might be vulnerable to eavesdropping. </ins> Note that if a request containing this directive is satisfied from a cache, the no-store request directive does not apply to the already

Related discussion:
text: "This directive is NOT a reliable or sufficient mechanism for ensuring privacy." Should be lowercase. Could use .
also in 5.2.2.4