jiebi/CodeConvo huggingface dataset:
Code change:
octets associated with a stream.  One or more DATA frames are used, for instance, to carry HTTP request or response payloads. <del> The DATA frame does not define any type-specific flags. </del> <ins> The DATA frame defines the following flags: Bit 1 being set indicates that this frame is the last that the endpoint will send for the identified stream.  Setting this flag causes the stream to enter the StreamHalfClose. Bit 2 is reserved for future use. </ins> DATA frames MUST be associated with a stream.  If a DATA frame is received whose stream identifier field is 0x0, the recipient MUST

Related discussion:
text: Also reservers flag 0x2 in DATA and HEADERS frames and renumbers flags accordingly.
Please feel free to exercise editorial privilege with respect to wording. Reserving 0x2 at NAME requests.
Code change:
specifies a desired certificate.  This describes the certificate the sender wishes to have presented. <del> The "CERTIFICATE_REQUEST" frame SHOULD NOT be sent to a peer which has not advertised support for HTTP-layer certificate authentication. </del> <ins> The "CERTIFICATE_REQUEST" frame SHOULD NOT be sent to a client which has not advertised the "SETTINGS_HTTP_CLIENT_CERT_AUTH", or to a server which has not advertised the "SETTINGS_HTTP_SERVER_CERT_AUTH" setting. </ins> The "CERTIFICATE_REQUEST" frame MUST be sent on stream zero.  A "CERTIFICATE_REQUEST" frame received on any other stream MUST be

Related discussion:
text: Instead of a four-byte exporter, uses an eight-byte exporter and splits into two values. Support for exchanging server certificates and client certificates is now indicated separately.
The current advertisement scheme does not allow for a client to decide it is willing to implement secondary server certificates but not client certificates or vice versa. It may be worth having two SETTINGS values, one for whether you're willing to do either of the two flows.
Code change:
Some of the most common include: TLS authentication of the server using X.509 certificates and <del> bearer token, encoded as JWTs. </del> <ins> client bearer token, encoded as JWTs. </ins> Mutual TLS authentication using X.509 certificate for both client and server.

Related discussion:
text: Fixed some of the wording and parallelism in the intro to keep the same ordering of X.509 certificates followed by Workload identity tokens. Generalized some of the phrasing. Removed concepts that aren't well defined in the document, such as "bottom turtle". I'm not opposed to adding these, I just don't think they make sense without an explanation of the analogy either inline or by-reference; so I tended towards keeping the document self-contained. Provided initial content for the Delegation and Impersonation, and Asynchronous and Batch Requests sections.
Code change:
Change Controller: IETF Provisional registration?  No <del> 9.  References 9.1.  URIs [1] https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/ issues/79 </del>

Related discussion:
text: In case there is no rough consensus to keep federation section, I raised URL to remove it.
I'd suggest we've had a few different conversations about federation of everything in a transparency service, vs. selective promotion of a subset of information across Transparency Services. The later being the ability for a consumer of one or more Transparency Services to promote the content for a subset of their software. Microsoft ships lots of software, However a consumer may only want to promote the Office suite of products into their Transparency Service for internal validation. I'd suggest the wording, as current, isn't well defined and I'd vote to cut this section until more well defined.
If this PR is dropped then we should create an issue to address the underspecification of unpotected headers at registration, especially the idea to preserve unprotected headers. Federation is a simple use case that highlights this problem
Its not simple, and we have seen no implementation support for it to date.
If we are at the point where we need to start from scratch on configuration/registration policy and scrap the initialization section, I personally do not see how we can keep federation and not just remove it (not to drive you and others mad, we can always add back later).I think the new text is too specific. To me (and as in the prior text) Federation refers to having multiple TS, and one TS accepting receipts from another TS at registration time is just an advanced case, for which we don't have clarity yet. As discussed earlier, letting the TS decide what unprotected headers to authenticate in its receipts is a major complication. My preference would be (1) keep a general placeholder on Federation --- better than nothing; or else (2) cut the section. But this leaves many questions unanswered, starting with the two TS in the arch diagram.
Code change:
Warp encodes the delivery information for a stream via OBJECT headers (message-object). <del> A relay SHOULD prioritize streams (prioritization) based on the delivery order.  A relay MAY change the delivery order, in which case it SHOULD update the value on the wire for future hops. </del> <ins> A relay SHOULD prioritize streams (prioritization) based on the send order.  A relay MAY change the send order, in which case it SHOULD update the value on the wire for future hops. </ins> A relay that reads from a stream and writes to stream in order will introduce head-of-line blocking.  Packet loss will cause stream data

Related discussion:
text: Matches the terminology used by W3C is generally much better. This is the order at which objects are sent, but does not guarantee delivery in this order. Doesn't preclude further conversations about prioritization.
This is just a rename so maybe merge it after fixing conflicts (you'll need another approval), or abandon? Based on the discussion today we'll be updating the priority section to indicate other possibilities for expressing priority.
Looks good to me. I would like to see this merged soon, so we can make the proper references to "send order" in the additional PRs.I do think that send order make more sense than delivery order but the parts of this that have to do with the prioritization scheme should probably be moved to a new section of the draft where we talk about the algorithms to decide what to send next.
Code change:
A literal header without indexing causes the emission of a header without altering the header table. <del> This representation starts with the '011' 3-bit pattern. </del> <ins> This representation starts with the '01' 2-bit pattern. </ins> If the header name matches the header name of a (name, value) pair stored in the Header Table, the index of the pair increased by one <del> (index + 1) is represented as an integer with a 5-bit prefix.  Note that if the index is strictly below 31, one byte is used. </del> <ins> (index + 1) is represented as an integer with a 6-bit prefix.  Note that if the index is strictly below 63, one byte is used. </ins> If the header name does not match a header name entry, the value 0 is <del> represented on 5 bits followed by the header name </del> <ins> represented on 6 bits followed by the header name </ins> (header.name.representation). Header name representation is followed by the header value

Related discussion:
text: We've seen varying amounts of advantage from having header table substitution enabled. Most are fairly minimal, even assuming perfect foresight. Some tests show single digit percentage improvements, others are much less. The feature adds some complexity. Is this complexity justified? Should we remove this feature?
Offline discussions: NAME and NAME agree that if this isn't removed, we should swap the opcodes so that substitution gets a worse (the longer) opcode.
Discussion in Seattle resulted in a conclusion to remove the substitution opcode from the draft.
Fixed in .
Code change:
5.2. How addressability is managed on stub networks depends on the nature <del> of the stub network.  For some stub networks, the stub router can be </del> <ins> of the stub network.  For some stub networks, the SNAC router can be </ins> sure that it is the only router.  For example, a SNAC router that is providing a Wi-Fi network for tethering will advertise its own SSID and use its own joining credentials; in this case, it can assume that

Related discussion:
text: Update draft version "stub router flag" -> SNAC router flag fix a few cases where Esko (I think!) missed changing stub router to SNAC router but should have (there are some cases where "stub router" is correct and I hope I did not change any of those.
In the update to the 'SNAC router' name () the flag name was not yet taken along in the update. This issue is to decide on that change also, and if needed make the change. (The 6man document would also need to change the flag name then, first.)
Code change:
server's disinterest in changing the client-provided value.  This is different from the logic being defined for the request header field, in which omission of a priority parameter implies the use of their <del> default values (see #parameters). </del> <ins> default values (see parameters). </ins> As a non-normative example, when the client sends an HTTP request <del> with </del> <ins> with the urgency parameter set to "5" and the incremental parameter set to "true" </ins> and the origin responds with the intermediary might alter its understanding of the urgency from "5" to "1", because it prefers the server-provided value over the <del> client's.  The incremental value continues to be "1", the value </del> <ins> client's.  The incremental value continues to be "true", the value </ins> specified by the client, as the server did not specify the incremental("i") parameter.

Related discussion:
text: Address some build warnings and fix typos.
and
Thank you for the fix. Merged.
Changes in structured headers means that boolean parameter values are reduced to their parameter name: -- URL
Q: should this be labeled ?
No, this issue addresses the minor editorial problem that needs fixing in the priorities spec e.g. URL just needs some tweaks to be compliant with structured headers.
The lowercase headings in the document imply that they represent field or parameter names, but these are concepts. For instance "incremental" doesn't appear on the wire, "i" does.
Code change:
streams in a particular order using priority.  Expressing priority is therefore only ever a suggestion. <del> Providing prioritization information is optional, so default values are used if no explicit indicator is provided (pri-default). </del> <ins> Prioritization information can be omitted from messages.  Defaults are used prior to any explicit values being provided (pri-default). </ins> 5.3.1.

Related discussion:
text: Only if it makes sense to do so. It's a perfectly good word that has been spoiled by an unnecessary inclusion in some popular RFC (2119, I think).
Code change:
method does not matter as long as it does not depend on the original order of elements. <del> For example, using the digest of the object property Disclosure created above, the Issuer could create the following SD-JWT payload to make </del> <ins> For example, using the digest of the Disclosure from hashing_disclosures, the Issuer could create the following SD-JWT payload to make </ins> selectively disclosable:

Related discussion:
text: URL
Danke! Thanks Neil, That is indeed an error. Thanks for catching that. We'll get it fixed. I see how that other part is a bit confusing too and will look at improving how those pieces flow together. And also maybe fix some other stuff in that area while we're at it, like inadequate salt length in at least one of the disclosures in 5.2.3. On Wed, Sep 4, 2024 at 9:17 AM Neil Madden wrote: CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
Code change:
10.11. <del> Section 3.11 of RFC8725 describes the use of explicit typing to prevent confusion attacks in which one kind of JWT is mistaken for another.  SD-JWTs are also potentially vulnerable to such confusion attacks, so it is RECOMMENDED to specify an explicit type by including the </del> <ins> RFC8725 describes the use of explicit typing as one mechanism to prevent confusion attacks (described in RFC8725) in which one kind of JWT is mistaken for another.  SD-JWTs are also potentially subject to such confusion attacks, so in the absence of other techniques, it is RECOMMENDED that application profiles of SD-JWT specify an explicit type by including the </ins> header parameter when the SD-JWT is issued, and for Verifiers to check this value. <del> When explicit typing is employed for an SD-JWT, it is RECOMMENDED that a media type name of the format "application/example+sd-jwt" be used, where "example" is replaced by the identifier for the specific kind of SD-JWT.  The definition of </del> <ins> When explicit typing using the header is employed for an SD-JWT, it is RECOMMENDED that a media type name of the format "application/example+sd-jwt" be used, where "example" is replaced by the identifier for the specific kind of SD- JWT.  The definition of </ins> in Section 4.1.9 of RFC7515 recommends that the "application/" prefix be omitted, so "example+sd-jwt" would be the value of the header parameter. <ins> Use of the content type header parameter to indicate the content type of the SD- JWT payload can also be used to distinguish different types of JSON objects, or different kinds of JWT Claim Sets. </ins> 11. The privacy principles of ISO.29100 should be adhered to.

Related discussion:
text: From this conversation URL this PR tries to somewhat better explain that explicit typing, per JWT BCP before it, is about distinguishing different types of SD-JWTs. And also be a little more open to other ways of typing, such as cty.
Thanks, looks COMPLETELY REASONABLE to me. inline this time... On Mon, Sep 30, 2024 at 6:30 AM Dick Hardt wrote: While the use of "typ" is unnecessary. So this first choice issue didn't need to be an issue at all. That's the issue. Elevating an unnecessary and arguable flawed construct to a MUST would only further engrain the issue. that we are still talking past one another and there remains some misunderstanding as distinguishing between an sd-jwt and other tokens isn't what explicit typing is about. I'll take another look at the language in the draft around typing and see if there's anything that can reasonably be done to make it less confusing or potentially problematic. CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
Code change:
To request a replacement Txn-Token, the requester makes a Txn-Token Request as described in txn-token-request but includes the Txn-Token <del> to be replaced as the value of the "subject_token" parameter. </del> <ins> to be replaced as the value of the "subject_token" parameter.  The "scope" value in the replacement request, if different from that in the original Txn-Token, MUST NOT increase the authorization surface beyond that of the original Txn-Token. </ins> 7.5.3.

Related discussion:
text: Added text to address issue
The following text in 2.2.2 is too open ended and should be refactored. First, the text should include specific guidance on replacement tokens to require scopes to remain the same or be down-scoped on replacement. Second, the draft should include a mechanism to ensure that scopes cannot be increased, or an increase in scope can be detected by downstream services. Finally, add text to the security considerations section regarding the risks of replacement tokens and/or a malicious txn-token-sts.
As far as I understand it, replacement txn-tokens is just a profile to Token Exchange. The Token Exchange RFC defines that an issued token can only have the same or a smaller scope than the presented token. I would assume this applies to replacement tokens as well. If the replacement token mechanism is intended to deviate from Token Exchange in this regard, this should probably be mentioned specifically.
NAME please review PR and see if I addressed your comments.
Completed. Looks good to me.
LGTM.
Code change:
The special value "*", if present in the Accept-Charset header field, matches every charset that is not mentioned elsewhere in the field. <del> 12.1.4. </del> <ins> 12.5.3. </ins> The "Accept-Encoding" header field can be used to indicate preferences regarding the use of content codings (content.codings).

Related discussion:
text: initial commit is just moving sections and updating headings; second commit will update some of "the following" comments to refer to the specific fields.
I believe it needs to be under "Proactive Negotiation" , or be a sibling of these...
Code change:
(dependencies).  This field is optional and the default value is an empty array. <del> 5.2. A "SEGMENT" message consists of a segment in a fragmented MP4 container. </del> <ins> The payload of the SEGMENT message is a fragmented MP4 container. </ins> Each segment MUST start with an initialization fragment, or MUST depend on a segment with an initialization fragment.  An

Related discussion:
text: Shared between and
Merging because I don't think this is controversial, and we have two PRs doing the same thing.
This sounds a bit like an extension that just gets forwarded when not understood by a relay? How does APP interact with caches, for example? Can a single QUIC stream have SEGMENT and APP data interleaved? Might be too vague to leave in
The intention was to cache/forward it the same way as media. It's just meant for arbitrary metadata and as a replacement for the current approach of shoving metadata into the media bitstream. For example, in h.264 land it's common to put arbitrary content (non-standardized) in SEI messages. Even if we don't cache/forward the stream, it would still be nice to let the application use unidirectional streams. This basically says prefix the stream with a 2 if it's used by the application instead of Warp. This wouldn't work with relays which is why I had the idea of reusing HEADERS to tell the relay which application streams should be forwarded/cached and how.
Oh and it's missing because there's no encoding yet, but I was envisioning that SEGMENT and APP frames do not specify a length. They would consume the remainder of the stream so there's no way to use them in conjunction.
Is there an MP4 box that we can just use as a part of the layer? That would provide some form of uniformity.
That was my thought too, although it means every container will need some way of specifying application data. MP4 atoms require a length up-front so they would be limited to messages instead of unbounded streams.
the RTCP APP message never turned out to be as useful in RTP as people thought it would be ... that said, fan of being able to send whatever data in the payload. If it happens to be a protobuf app message instead of media, seem like MOQ shoudl not care, it should just deliver the bytes with not much care if they are audio, vidie, haptics, or an app custom media
We need to define the difference of APP message and Media data in terms of what is inside and how it is interacted with caching and dropping. Otherwise there is a risk that the APP message becomes the container for “whatever does not fit in the current RFC“ which renders the standard useless.
Code change:
between overhead and latency.  It is RECOMMENDED that a media fragment consists of a single frame to minimize latency. <del> 5.3. The "APP" message contains arbitrary contents.  This is useful for metadata that would otherwise have to be shoved into the media bitstream. Relays MUST NOT differentiate between streams containing "SEGMENT" and "APP" frames.  The same forwarding and caching behavior applies to both as specified in the"HEADERS" frame. 5.4. </del> <ins> 5.2. </ins> The "GOAWAY" message is sent by the server to force the client to reconnect.  This is useful for server maintenance or reassignments

Related discussion:
text: Shared between and
Merging because I don't think this is controversial, and we have two PRs doing the same thing.
This sounds a bit like an extension that just gets forwarded when not understood by a relay? How does APP interact with caches, for example? Can a single QUIC stream have SEGMENT and APP data interleaved? Might be too vague to leave in
The intention was to cache/forward it the same way as media. It's just meant for arbitrary metadata and as a replacement for the current approach of shoving metadata into the media bitstream. For example, in h.264 land it's common to put arbitrary content (non-standardized) in SEI messages. Even if we don't cache/forward the stream, it would still be nice to let the application use unidirectional streams. This basically says prefix the stream with a 2 if it's used by the application instead of Warp. This wouldn't work with relays which is why I had the idea of reusing HEADERS to tell the relay which application streams should be forwarded/cached and how.
Oh and it's missing because there's no encoding yet, but I was envisioning that SEGMENT and APP frames do not specify a length. They would consume the remainder of the stream so there's no way to use them in conjunction.
Is there an MP4 box that we can just use as a part of the layer? That would provide some form of uniformity.
That was my thought too, although it means every container will need some way of specifying application data. MP4 atoms require a length up-front so they would be limited to messages instead of unbounded streams.
the RTCP APP message never turned out to be as useful in RTP as people thought it would be ... that said, fan of being able to send whatever data in the payload. If it happens to be a protobuf app message instead of media, seem like MOQ shoudl not care, it should just deliver the bytes with not much care if they are audio, vidie, haptics, or an app custom media
We need to define the difference of APP message and Media data in terms of what is inside and how it is interacted with caching and dropping. Otherwise there is a risk that the APP message becomes the container for “whatever does not fit in the current RFC“ which renders the standard useless.