jiebi/CodeConvo huggingface dataset:
Code change:
as the preceding frame is on the same stream and is a HEADERS, PUSH_PROMISE, or CONTINUATION frame without the END_HEADERS flag set. <del> The CONTINUATION frame payload contains a FieldBlock. </del> <ins> The Length, Type, Unused Flag(s), Reserved, and Stream Identifier fields are described in FramingLayer.  The CONTINUATION frame payload contains a FieldBlock. </ins> The CONTINUATION frame defines the following flag:

Related discussion:
text: I haven't adjusted for vs. until that war is over. Note that I've explicitly added a format for the SETTINGS frame itself, which was missing.
+1 . This would make it easier to write extensions for both h2 and h3. Priorities draft suffers from the mixed presentation format right now.
OK, thanks for doing this NAME I merged this manually after fixing a few things up. From my commit: Use all caps for frame names Add a value for Type in frame definitions Change order of flag descriptions to match order in layout Make Exclusive field of PRIORITY optional Move PING ACK Flag to the right place Add SETTINGS ACK Flag Double-checking FTW. Of course, there's a good chance I also messed something up here. So feel free to check my work also.
I think the language about ordering is a bit weird, but it is clarified somewhat by the hex representations shortly after. I think those hex representations are doing the heavy lifting, as I’m not aware of any issue with interoperability caused by getting the flag indices wrong in practice. Nonetheless, if we’re really worried about it we could just delete “bit n” and replace it with “the x bit”, e.g. delete “bit 0” and replace it with “the bit”.
Code change:
discovered out of band and Registration Policies are not assured on the presence of these optional fields.  A Registration Policy that requires an optional field to be present MUST reject any Signed <del> Statements or Receipts that an invalid according to the policy. </del> <ins> Statements or Receipts that are invalid according to the policy. </ins> fig-signed-statement-edn illustrates a payload that is detached. This is to support very large supply chain artifacts, and to ensure

Related discussion:
text: Upon re-reading the draft to submit an unrelated PR, I noticed there is a missing verb in paragraph about Signed Statements.
LGTM!LGTM Thanks for the polish NAME
Code change:
Signed Statement is returned with the corresponding Registration Receipt embedded in the COSE unprotected header. <del> 2.1.3.2. </del> <ins> 3.1.3.2. </ins> One of the following:

Related discussion:
text: A few thoughts after IETF 117. Goals: Address identity up front (by not addressing it directly). Frame feeds in the context of the API Relate media types to feeds This PR is mostly placeholders for future work, but hopefully highlights some areas for follow up based on our in person discussions.
NAME I can't merge this, but we should unless there are changes requested.
fixed collaborator list
LGTM
Code change:
be interpreted by receivers to mean that the publish session is complete. <del> 7. </del> <ins> 8. </ins> ToDo <del> 8. </del> <ins> 9. </ins> This document creates a new entry in the "MoQ Streaming Format" Registry (see MoQTransport Sect 8).  The type value is 0x001, the

Related discussion:
text: This PR adds a definition for a timeline track format, along with details about how to identify timeline tracks in the catalog and how to update timeline tracks. and
I like it! Regarding "The publisher MUST publish a complete timeline in the first MOQT Object of each MOQT Group." it means that the first object of the group strictly inflates with time. For an open range track (for example a 24/7 video channel), it may become excessively long. We may allow summarization of old times in the timeline csv.
A special ‘timeline’ track is produced which describes the availability of groups and objects with respect to media time and wallclock time. May also carry media time events which can be used by the player in constructing a UI, for example “Goal”, “Penalty”. This track can be used by the player for seeking to request specific portions of a DVR window in a live stream, or to any portion of a VOD asset. This may be used for advertising insertion at a later date. In the proposed structure below, the metadata field may be empty. If present, it must be enclosed inside double quotes and may hold any string data. In this example, JSON and XML metadata entires are shown.
I like the idea. Note that some have advocated for KLV as the support for timed metadata for live video. Here is a Demuxed talk about it a couple of years ago URL
Code change:
Note: so far agreed to define holder binding (user's public key contained inside an SD-JWT) as an option.  It is not mandatory since holder binding is use case specific and orthogonal to the general <del> mechanism of selective disclosure we are trying to define here. </del> <ins> mechanism of selective disclosure defined here. </ins> 1.1.

Related discussion:
text: Some minor edits: consistency of hyphenation in base64url-encode(d) use transaction instead of use case in one place because selective might be needed or not within one use case, depending on the interaction with RP explicitly called out period character to avoid misinterpreting as missing word some typos
changed six . separated to four per Christian's separate comment
What did I miss? The presentation should be six dot separated elements. Three for the SD-JWT, three for the SD-JWT-R.
Why would you need to merge both? I don't understand the proposed flow between issuer, holder, and verifier; perhaps a data flow section would help. I would think the holder gets a 3+1 part JWS with SVC (which can be -concatenated). Then all you need to present to a verifier is the same data, along with some user proof key signature if the JWT is bound to a user key (for which a property is added in the SD-JWT-R, if I understood correctly; more details would be helpful here).
creating a separate issue on six vs four period separated elements to merge this editorial PR
LGTM
Code change:
upload's final size is the "Content-Length" field value and the server MUST record it to ensure its consistency. <ins> The following example shows an upload creation.  The client transfers the entire 100 bytes in the first request.  The server generates two informational responses to transmit the upload resource's URL and progress information, and one final response to acknowledge the completed upload: The next example shows an upload creation, where only the first 25 bytes are transferred.  The server acknowledges the received data and that the upload is not complete yet: </ins> If the client received an informational response with the upload URL in the Location field value, it MAY automatically attempt upload resumption when the connection is terminated unexpectedly, or if a

Related discussion:
text: This PR adds descriptions to all message exchange examples in the draft. It should make their purpose clearer and also help distinguish the two separate examples in section 4, as pointed out in .
Thank you all!
نزت
I think there's two different creation examples being shown in URL but the presentation of them isn't great and could be a source of confusion. If so, lets break them apart by having a short sentence before each example expliaining it.
Yes, these are two separate examples, which are confusing. Most of the example are in need of a proper description. I can open a PR to address this. Thank you!
Code change:
the IANA Hash Algorithms for HTTP Digest Fields registry; see establish-hash-algorithm-registry. <del> The "standard" algorithms listed in this document are suitable for many purposes, including adversarial situations where hash functions might need to provide resistance to collision, first-preimage and second-preimage attacks.  Algorithms listed as "insecure" either provide none of these properties, or are known to be weak (see NO-MD5 and NO-SHA). For adversarial situations, which of the "standard" algorithms are acceptable will depend on the level of protection the circumstances demand.  As there is no negotiation, endpoints that depend on a digest for security will be vulnerable to attacks on the weakest algorithm they are willing to accept. </del> Transition from weak algorithms is supported by negotiation of hashing algorithm using "Want-Content-Digest" or "Want-Repr-Digest" (see want-fields) or by sending multiple digests from which the

Related discussion:
text: Murray suggested some things that we could change about the way new IANA registry was being handled. This change: tries to make it clearer that this document uses a new registry that we will need IANA to create moves rote IANA instructions to the IANA considerations better highlights interesting hash algorithm considerations for implmenters clarifies the registration procedure and expands on the expectations for the Designated Expert(s)
Code change:
Such applications are not exempt from the requirements in this section.  Furthermore, applications without such legacy or history ought to follow the guidance for using algorithms with the status <del> value "standard". </del> <ins> value "Active". </ins> Discussion of algorithm agility is presented in sec-agility.

Related discussion:
text: During the SEC AD review, a DISCUSS was raised about the current status values. This change modifies the values to better align with Signatures. The guidance for registration and/or usage of an algorithm based on the status is not affected.
Code change:
Formally, an alternative service is identified by the combination of: <del> An Application Layer Protocol Negotiation (ALPN) protocol name, as </del> <ins> An Application-Layer Protocol Negotiation (ALPN) protocol name, as </ins> per A host, as per

Related discussion:
text: Fully editorial; "Application-Layer Protocol Negotiation" instead of "Application Layer Protocol Negotiation". URL
This fills me with joy
Code change:
("7").  All bits of the byte array at a particular index are set to a status value. <del> The complete byte array is compressed using gZIP RFC1952. </del> <ins> The complete byte array is compressed using the "DEFLATE" RFC1951 compression method and stored using the "ZLIB" RFC1950 data format.  Implementations are RECOMMENDED to use the highest compression level available. </ins> <del> The result of the gZIP compression is then base64url-encoded, as </del> <ins> The result of the compression is then base64url-encoded, as </ins> defined in Section 2 of RFC7515. 4.2.

Related discussion:
text: and . Switches to zlib instead of gzip encoding and adds the recommendation to use the best available compression.
I'm working on a TypeScript implementation of this spec, and have the encoding / decoding of the status list implemented. It seems to work based on the example in the spec and the example python scripts, with one slight difference. When I encode either the 1 or 2 bit example it will output one character difference , while mine outputs an . The decoding seems to work fine, and maybe this is a gzip thing, but I'm wondering if the examples use certain gzip features to get this output? I've adapted my implementation to use compression level 9 (default for python lib) and set the mtime to the same value The input byte array is the same as for the python implementation and the examples in the spec, so it's really something that is happening during the gzip encoding (the output byte array here is different) any idea what is going on here? The implementation and tests can be found here: URL
Seems to be a difference in the header - from the position I would assume the timestamp (even though you seem be setting it to the fixed value used in the examples in the draft)? There is also a header entry for the operating system - that would also be a very likely candidate for the difference. I will take a look at it when I am back from IIW. We were discussing switching from gzip to zlib (or deflate directly) for that reason - we don't really need these headers and most languages seem to support both gzip and zlib (which was our concern when we initially thought about this). Related Issue:
Thanks for testing! There is a header as well in zlib, but it's considerably smaller. The zlib header does not include a timestamp which makes it better for reproducible results and test vectors. I think we should also give a recommendation for the used compression level, I suspect either default or highest. It would be interesting if the underscore vanishes in zlib?
I changed the python implementation to use zlib with level 9 and did the same for your typescript implementation --> both resulted in the same: We should really change that imho (and also add the text to recommend compression level).
I'm a proponent of using zlib instead of gzip. As suggested in the other issue, we don't really need the other metadata. And the result is smaller as well :)
Code change:
would mean: "I prefer Danish, but will accept British English and other types of English". <del> A request without any Accept-Language header field implies that the user agent will accept any language in response.  If the header field is present in a request and none of the available representations for the response have a matching language tag, the origin server can either disregard the header field by treating the response as if it is not subject to content negotiation or honor the header field by sending a response.  However, the latter is not encouraged, as doing so can prevent users from accessing content that they might be able to use (with translation software, for example). </del> Note that some recipients treat the order in which language tags are listed as an indication of descending priority, particularly for tags that are assigned equal quality values (no value is the same as q=1).

Related discussion:
text: (alternative approach)
AcceptAccept-CharsetAccept-Encoding`](URL) request headers is of very limited use, because: With a qvalue higher than another value, it says "send anything in preference to something specific", which isn't useful With a qvalue lower than another media type, it says "send a more specific value in preference to something else", which is already implied by HTTP With a qvalue of 0, it says "don't ever send other value" -- but a server can always ignore that, because this is an optional-to-implement extension In media types (e.g., ), it has been cargo culted a lot, but doesn't actually give the server information it can use. Can we deprecate in these headers, or at least restrict its use / give better guidance?
Discussed in Montreal; support for documenting limitations / caveats.
We can't deprecate it. We can explain when and where it isn't useful.
+1 to generalize this. However, we may want to still reference these rules from each individual header field definition.I think the first sentence needs some editorial work, but +1 to committing this first.
Code change:
character sets used for the encoding. Insecure digest algorithms MAY be used to preserve integrity against <del> accidental change, but MUST NOT be used in a potentially adversarial </del> <ins> corruption, but MUST NOT be used in a potentially adversarial </ins> setting; for example, when signing the digest of content for authenticity.

Related discussion:
text: Spotted another mention of accidental while I was at it, so changed that too.
From NAME WGLC review: Corruption could also be non-accidental. Let's remove the accidental qualifier or add words about explicit manipulation (for good or bad purposes).
Agree, but I think that accidental/bad implementation has to be mentioned. See URL iirc there were some comments regarding the fact that Digest alone (eg. without other mechanisms) is not enough to protect against malicious agents... NAME do you remember anything on that? The current text imho is correct, since it adds:
NAME NAME I'd close with no-action :)
NAME Removing "accidental" from the sentence in question would fix the issue.
I completely agree, I'll do that!
LGTM
Code change:
4. <del> The "br-d" content encoding identifies a resource that is a </del> <ins> The "dcb" content encoding identifies a resource that is a </ins> "Dictionary-Compressed Brotli" stream. <del> A "Dictionary-Compressed Brotli" stream is a Brotli RFC7932 stream for a response that has been compressed with an external dictionary using a compression window not larger than 16 MB. </del> <ins> A "Dictionary-Compressed Brotli" stream has a fixed header that is followed by a Shared Brotli SHARED-BROTLI stream.  The header consists of a fixed 4 byte sequence and a 32 byte hash of the external dictionary that was used.  The Shared Brotli stream is created using the referenced external dictionary and a compression window that is at most 16 MB in size. The 36-byte fixed header is as follows: </ins> <del> Clients that announce support for br-d content encoding MUST be able </del> <ins> Clients that announce support for dcb content encoding MUST be able </ins> to decompress resources that were compressed with a window size of up to 16 MB.

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:
7. <del> We explain how multiple, independent Transparency Services can be composed to distribute supply chains without a single transparency authority trusted by all parties. Multiple SCITT instances, governed and operated by different organizations. For example, - a small, simple SCITT instance may keep track specifically of the software used for operating SCITT services.  - an air-gapped data center may operate its own SCITT Registry to retain full control and auditing of its software supplies. </del> <ins> Editor's note: This section needs work. </ins> <del> How? - Policy-based.  Within an organization, local Verifiers contact an authoritative SCITT that records the latest policies associated with classes of Artifacts; these policies indicate which Issuers and Registries are trusted for verifying signed Transparent Claims for these Artifacts. </del> <ins> Multiple, independently-operated transparency services can help secure distributed supply chains, without the need for a single, centralized service trusted by all parties.  For example, multiple SCITT instances may be governed and operated by different organizations that do not trust one another. </ins> <del> Other federation mechanisms? </del> <ins> This may involve registering the same Claims at different transparency services, each with their own purpose and registration policy.  This may also involve attaching multiple Receipts to the same Claims, each Receipt endorsing the Issuer signature and a subset of prior Receipts, and each TS verifying prior Receipts as part of their registration policy. </ins> <del> We'd like to attach multiple Receipts to the same signed Claims, each Receipt endorsing the Issuer signature and a subset of prior Receipts.  This involves down-stream Registries verifying and recording these Receipts before issuing their own Receipts. </del> <ins> For example, a supplier TS may provide a complete, authoritative Registry for some kind of Claims, whereas a consumer TS may collect different kinds of Claims to ensure complete auditing for a specific use case, and possibly require additional reviews before registering some of these claims. </ins> 8. <del> Editor's Note: this may be moved to appendix. </del> <ins> Editor's Note: This may be moved to appendix. </ins> 8.1.

Related discussion:
text: Cleaning up the Federation section, still TBD.
Also:
Linting errors need to be addressed. NAME if this blocks publishing / merging perhaps we can merge and then fix?
Yes, I can fix the lint after merging. If this would be a branch and not a fork, I could do it here more easily.
lgtm, any objections? still in early stage
Code change:
15.3. <ins> HTTP's most widely used extensibility point is the definition of new header and trailer fields. New fields can be defined such that, when they are understood by a recipient, they override or enhance the interpretation of previously defined fields, define preconditions on request evaluation, or refine the meaning of responses. However, defining a field doesn't guarantee its deployment or recognition by recipients.  Most fields are designed with the expectation that a recipient can safely ignore (but forward downstream) any field not recognized.  In other cases, the sender's ability to understand a given field might be indicated by its prior communication, perhaps in the protocol version or fields that it sent in prior messages, or its use of a specific media type.  Likewise, direct inspection of support might be possible through an OPTIONS request or by interacting with a defined well-known URI RFC8615 if such inspection is defined along with the field being introduced. </ins> 15.3.1. The "Hypertext Transfer Protocol (HTTP) Field Name Registry" defines

Related discussion:
text: I believe that we said this could be merged when Julian's issue was addressed, which Roy's suggestion did, so merging.
Some guidance about how and if new preconditions can be defined would be helpful. See .
Code change:
TODO: More details are required here <del> 6. </del> <ins> 7. </ins> This section covers topics that are explicitly out of scope for the time being. <del> 6.1. </del> <ins> 7.1. </ins> From Section 8.2 of RFC9000:

Related discussion:
text: This is just a starting point, but brings the document closer to alignment with our spreadsheet. I've also added some additional details which should cover themes raised in the current BoF agenda.