jiebi/CodeConvo huggingface dataset:
Code change:
Our goal in this section is to understand the requirements that result from the use cases described in overallusecases. <ins> 4.1. Note: the intention for the requirements in this document is that they are useful for MOQ working group participants, to recognize constraints, and useful for readers outside the MOQ working group to understand the high-level functionality of the MOQ protocol, as they consider implementation and deployment of systems that rely on the MOQ protocol. </ins> *Note: the initial high-level organization for this section is taken from Suhas Nandakumar's presentation, "Progressing MOQ" Prog-MOQ, at the October 2022 MOQ virtual interim meeting, which was in turn taken

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:
REQUIRED A unique transaction identifier as defined in Section 2.2 of RFC8417.  When used in the transaction token, it identifies the <del> entire call chain. </del> <ins> entire call chain.  It is strongly RECOMMENDED to provide an identifier unique within the trust domain.  If providing such an identifier is not possible, then a fixed value of "N_A" MAY be supplied. </ins> REQUIRED A unique identifier for the subject within the context of the "aud" trust domain.  Unlike OpenID Connect, the "sub" claim is

Related discussion:
text: Added text to address issue regarding the value of the claim within the Txn-Token
From Yaron's
Text from Yaron's email: : I think txn should be OPTIONAL. While it is very useful, there may be architectural reasons why transaction ID issuance in an organization is independent of transaction tokens.
I'm curious to the use cases? I'd prefer a way to make the claim REQUIRED and allow an organization to provide it's own value in that context. Maybe we could go with RECOMMENDED? This is one of those cases where people who know what they are doing can potentially remove it or possibly provide a "N_A" value and it will be fine. However, if it's OPTIONAL most developers will not specify the value and then they will lose a lot of value from the Transaction Token.
No specific use cases, it's just that we're assuming that an organization can easily integrate its (preexisting) transaction ID-issuing service with this one. Sometimes it can, sometimes it can't. I'm good with RECOMMENDED.
NAME please review PR which addresses this issue
Code change:
The Priority HTTP header field (header-field) is an end-to-end way to transmit this set of parameters when a request or a response is issued.  In order to reprioritize a request, HTTP-version-specific <del> frames (h2-update-frame and h3-update-frame) are used by clients to transmit the same information on a single hop.  If intermediaries want to specify prioritization on a multiplexed HTTP connection, they SHOULD use a PRIORITY_UPDATE frame and SHOULD NOT change the Priority header field. </del> <ins> PRIORITY_UPDATE frames (h2-update-frame and h3-update-frame) are used by clients to transmit the same information on a single hop.  If intermediaries want to specify prioritization on a multiplexed HTTP connection, they SHOULD use a PRIORITY_UPDATE frame and SHOULD NOT change the Priority header field. </ins> In both cases, the set of priority parameters is encoded as a Structured Fields Dictionary (see Section 3.2 of STRUCTURED-FIELDS).

Related discussion:
text: NAME noted a bunch of minor editorial issues, so this fixes them.
Thank you for working on the changes. They look like great improvements to me modulo the concern below.
Code change:
Optional parameters: n/a <del> Encoding considerations: binary; </del> <ins> Encoding considerations: See status-list-token-cwt of this specification </ins> <del> Security considerations: See (#Security) of [ this specification ] </del> <ins> Security considerations: See Security of this specification </ins> Interoperability considerations: n/a <del> Published specification: [ this specification ] </del> <ins> Published specification: this specification </ins> <del> Applications that use this media type: Applications using [ this specification ] for updated status information of tokens </del> <ins> Applications that use this media type: Applications using this specification for updated status information of tokens </ins> Fragment identifier considerations: n/a <del> Additional information: File extension(s): n/a Macintosh file type code(s): n/a </del> <ins> Additional information: n/a </ins> Person & email address to contact for further information: Paul Bastian, paul.bastian@posteo.de

Related discussion:
text: fixes the list rendering (missing newline) clarifies IANA text to just reference other tokens Rendered version: URL
I did further fixes on media types
Code change:
specification defines types for existing cookie attributes in cookie- params. <del> The Expires attribute is mapped to an Integer representation of parsed-cookie-date (see COOKIES) expressed as a number of seconds delta from the Unix Epoch (00:00:00 UTC on 1 January 1970, excluding leap seconds). </del> <ins> The Expires attribute is mapped to a Date representation of parsed- cookie-date (see COOKIES). </ins> For example, these unstructured fields:

Related discussion:
text: I still believe this change should end up in the revision of SF.
That's
Some have pushed back on using integers for dates, see eg URL As I suggested there, one accommodation would be to define a new structured type for them. That could be done in retrofit, or separately.
I see no mention of fractional seconds ? I think we need to ponder that, if the goal is (eventual) convergence for all timestamps in HTTP ? Considering how much effort we spend on speeding up HTTP, I find the "human readable" argument utterly bogus. Only a very tiny fraction of these timestamps are ever read by humans, and most are in a context where software trivially can render the number in 8601 format if so desired. In terms of efficiency, I will concede that, in a HTTP context, it is almost always possible to perform the necessary calculations and comparisons on raw ISO-8601 timestamps, without resorting to the full calendrical conversions, but once all the necessary paranoia is included, I doubt it is an optimization. My preference is seconds since epoch, (and this is largely why has three decimals in the first place), because it gives us fast processing, good compression and millisecond resolution. PS: A Twitter poll with only 40 respondents, carried out on the first monday after new-years ? Really ?!
One argument against any "seconds since epoch" representation is that (at least under the ) it is incapable of representing an instant within a positive leap second (since "each and every day shall be accounted for by exactly 86400 seconds_", any such time would be interpreted as being in the first second of the following UTC day).
For HTTP I think subsecond precision is an overkill due to RTT / intermediaries.
IMHO: I like structured format. There are a lot of diagnostics and other software that would not want to do additional transcoding of header elements but just represent them verbatim as they occur. Those are helped if the verbatim representation is already easier readable. I do not think TZ belongs into a time/date representation. Aka: all date/times in UTC please. TZ can be added somehow as a "location" information, ideally in a different header field. If it is in the same header field, it would be confusing to show the time in UTC but ALSO to indicate the TZ.
Code change:
specification defines types for existing cookie attributes in cookie- params. <del> The Expires attribute is mapped to an Integer representation of parsed-cookie-date (see COOKIES) expressed as a number of seconds delta from the Unix Epoch (00:00:00 UTC on 1 January 1970, excluding leap seconds). </del> <ins> The Expires attribute is mapped to a Date representation of parsed- cookie-date (see COOKIES). </ins> For example, these unstructured fields:

Related discussion:
text: Maybe this can be resolved by coming up that would make it as obvious as possible that the date/time is NOT adjusted for the TZ shown. Maybe not call it "TZ" but "LOC" so that the "the date/time it TZ adjusted" recognition is not triggered. And of course waste the three characters on "UTC" in the representation. I do not believe the processing speed argument to be valid. The level of processing speed where just a (sub)second unstructured value would help goes IMHO into the space of CoAP, not HTTP. I'd first try to make HTTP better where it does not just duplicate CoAP efforts. All that binary stuff CoAP needs to do is severely making toolchains more complex IMHO. I do like the leap-second argument. I do think msec accuracy should be an option. RTTs within lan/metro environments can easily be in the single digit msec range and you want to be able to diagnose e.g.: REST based broker/bus-type transaction speeds, relative ordering of request/replies.
Seems reasonable to me. +1 Not sure this is an "interface" that HTTP exposes / should be relied upon.
I suspect the experience of pretty much everybody writing and deploying HTTP intermediaries and servers at scale is different -- at those rates, cycles wasted on parsing do matter, especially when architectures have many layers of intermediaries to go through.
See linked PR for a proposal.
Re leapseconds: as written ("excluding leap-seconds") means that timestamps will be illegal, effectively mandating POSIX leap-second (non-)handling. To make able to handle leap-seconds requires that every HTTP handling entity needs an up to date file, either at system level or application level, and that the upper limit on the "internal data model range" becomes indeterminable, since we cannot predict how many leap seconds will happen in the future, nor what sign they may have. That is a total no-go from a systems engineering and complexity point of view, in particular as the rest of the world converges on either papering over leap-seconds or abolishing them. If the textual format cannot handle leap-seconds (without requiring a boat-load of complexity), then, why take the extra expense in CPU-load and code complexity ? As stated earlier, we should go for the more efficient and less error-prone solution: POSIX time_t (with optional milliseconds) as a .
Code change:
specification defines types for existing cookie attributes in cookie- params. <del> The Expires attribute is mapped to an Integer representation of parsed-cookie-date (see COOKIES) expressed as a number of seconds delta from the Unix Epoch (00:00:00 UTC on 1 January 1970, excluding leap seconds). </del> <ins> The Expires attribute is mapped to a Date representation of parsed- cookie-date (see COOKIES). </ins> For example, these unstructured fields:

Related discussion:
text: (If we want to designate the timestamps with a senteniel, 'NAME is a particular bad choice, since the HPACK huffmann assigns it 13 bits.) PS: In context of four digit years: Century scale predictions, based on orbital considerations, expect the current leap-second regieme to break down in approx 2000 years, because we will need leap seconds more often than every month.
Do any current HTTP implementations take leap seconds into account? Regarding HPACK - it's one character. Let's not over-optimise here.
I don't know, but leap seconds are explicitly supported by : And the difference between 23:59:60 and following-day 00:00:00 would certainly be relevant for e.g. Last-Modified.
I have spent a lot of time over the years searching, but I have yet to see a 23:59:60 timestamp in the wild...
Now there's a picture in my mind of PHK walking the wilds, searching for an elusive date stamp.
I don't know what counts as "in the wild", but there is certainly documentation of and .
Discussion at IETF114 wasn't conclusive, but we now seem to be focusing on these options: Do nothing. Dates in SF are Integers (unless folks fall back to Strings), and recipients need to know that they're dates and how to handle them. Create a Date SF type along the lines of the PR. The textual representation is human-friendly, and it's identified as a date in a machine-readable way without special knowledge. Create a Date SF type but use an Integer; e.g., . The textual representation is not human-friendly, but it is identified as a date in a machine-readable way without special knowledge. I'll observe that if we believe that we'll eventually have a binary representation of structured fields widely in use, (2) is preferable in that it has the best properties -- it's both efficient and human-friendly. Of course, that's not at all certain. I'll also observe that in the discussions I've had, the people who want human-friendly representation are generally those who are working with tools and developers, "closer" to the application. The infrastructure folks and "lower layer" folks tend to minimise this aspect.
PR updated to reflect (3) above.
I personally support (2) or because it covers similar use cases than HTTP-date.
Code change:
specification defines types for existing cookie attributes in cookie- params. <del> The Expires attribute is mapped to an Integer representation of parsed-cookie-date (see COOKIES) expressed as a number of seconds delta from the Unix Epoch (00:00:00 UTC on 1 January 1970, excluding leap seconds). </del> <ins> The Expires attribute is mapped to a Date representation of parsed- cookie-date (see COOKIES). </ins> For example, these unstructured fields:

Related discussion:
text: In case of (3) I think we can just use an Integer SF, like we do Signatures and other specs. Side note: we sometimes hear that RFC3339 is ambiguous. I think it is, and after ~20 years it probably requires a RFC3339bis that clearly specifies a basic profile ( T, Z uppercase; Always ). I'd be happy to start this work.
Why do the number of decimals need to be specified? Surely we could just say the format is nnnnn[.ddddddd] or similar where an integer-only parser stops at whitespace or a '.' while those who care about sub-second parsing continue on until they are satisfied with the resolution or they run out of digits. The senders decides how many decimals to provide, perhaps with a recommendation of three or upto their clock resolution? So "123456789" and "123456789.1" and "123456789.123456789" are all equally valid.
I like this direction; thanks.
Code change:
intent of the transaction. "requested_token_type" REQUIRED.  The value MUST be <del> "urn:ietf:params:oauth:token-type:txn-token" </del> <ins> "urn:ietf:params:oauth:token-type:txn_token" </ins> "subject_token" REQUIRED.  The value MUST represent the subject of the transaction.  This could be an inbound token received by an

Related discussion:
text: We currently use the URI: "urn:ietf:params:oauth:token-type:txn-token" to denote a Txn-Token in requests or in the token itself. However, if I look at other entries in the OAuth URI Subregistry here (URL), they use the "token" style for the token types. We also use that style when the subject-token-type is "selfsigned". So I'd like to propose that we use the URI: "urn:ietf:params:oauth:token-type:txn_token" for the transaction token URI.
Agreed with aligning to the common practices elsewhere.
Code change:
are capitalized.  To ensure readability, only a core set of terms is included in this section. <ins> Verifiers use the Feed to ensure completeness and Non-equivocation in supply chain evidence by identifying all Transparent Statements linked to the Artifact they are evaluating. </ins> 4. In this document, the definition of transparency is intended to build

Related discussion:
text: Explains Feed as the logical collection, with (Subject) as the property to represent the collection.
That seems pretty reasonable to me. Are there any reasons to keep both?
While I'd agree less is more, this keeps coming back when we try to explain it. A feed is a known concept for a collection of related data We're using CWTClaims , which also makes sense to align with existing specs We avoided Artifact ID Attempting to describe a collection of statements as a subject doesn't resonate. We can keep Feed as the concept, and simply say CWTClaims is how you set an identifier for the feed. How does that work?
Then we should deprecate the term feed in discussions, too, and just explain how a subject is used as a subject in this context?
Updated to merge in PR feedback
NAME NAME NAME PTAL as I've made some updates.
Code change:
other uses of bidirectional streams, a peer MAY currently close the connection if it receives a second bidirectional stream. <del> The control stream MUST NOT be abruptly closed at the QUIC layer. Doing so results in the session being closed as a 'Protocol Violation'. </del> <ins> The control stream MUST NOT be abruptly closed at the underlying transport layer.  Doing so results in the session being closed as a 'Protocol Violation'. </ins> 3.3. <del> QUIC streams aside from the control stream MAY be canceled due to </del> <ins> Streams aside from the control stream MAY be canceled due to </ins> congestion or other reasons by either the sender or receiver.  Early <del> termination of a QUIC stream does not affect the MoQ application state, and therefore has no effect on outstanding subscriptions. </del> <ins> termination of a stream does not affect the MoQ application state, and therefore has no effect on outstanding subscriptions. </ins> 3.4.

Related discussion:
text: Given this also runs over WebTransport, it's best to avoid QUIC unless it's specifically referring to the transport.
Though MOQT is optimized for QUIC, it technically can go over WebTransport over HTTP/1 or HTTP/2. There are a number of cases when QUIC is used when it could be something else and in most cases, specifying QUIC is not critical to the design. For example "Consumer: A QUIC endpoint receiving media over the network." Also, the definitions in 1.2 frequently reference terms defined later in the list.
Absolutely. Stream prioritization and congestion control is better with QUIC, and thus can support lower latencies, but MoQ over TCP should still work well enough.
For what its worth, we did did say during chartering that were were not going to focus on solving any of the problems that happen with fallback to TCP. Clearly we are not going to go and brak whatever fallback WebTransport does, but they key thing is this work when then WebTransport is over QUIC, not other cases
I completely agree. This is an editorial point that there are times when 'QUIC' is used when it may not actually be QUIC. In many cases, just removing that word makes the sentence both slightly more accurate and shorter.
Code change:
The must-revalidate directive is necessary to support reliable operation for certain protocol features.  In all circumstances a <del> cache MUST obey the must-revalidate directive; in particular, if a cache is disconnected, the cache MUST generate a </del> <ins> cache MUST NOT ignore the must-revalidate directive; in particular, if a cache is disconnected, the cache MUST generate an error response rather than reuse the stale response.  The generated status code SHOULD be </ins> <del> response rather than reuse the stale response. </del> <ins> unless another error status code is more applicable. </ins> The must-revalidate directive ought to be used by servers if and only if failure to validate a request on the representation could cause

Related discussion:
text: This issue is from a related discussion on Apache httpd, which was trying to comply by sending a 504 even though the revalidation error was a 502. That's nuts. The current text for says: However, if a proxy/gateway received a 5xx response while trying to revalidate, this requirement forces it to toss that information and supply a useless 504 instead. That isn't desirable. The entire purpose of this requirement is to make sure that the cache does not respond with its stale entry. Hence, any 5xx code is sufficient.
To fill in more detail, the change in question is this one: URL And covers the wide question of "which 5xx response is returned in low level network failure cases, such as DNS error, connection refused, connection timed out, etc". The commit message referred to RFC2616 14.9.4 Cache Revalidation and Reload Controls, but this seems to be a wider issue.
Yes, that MUST is too strong; I suspect it's there to make the mechanism reliable, not override other potential status codes. Will work on a PR.
Code change:
uses HTTPS exclusively. Servers can partially mitigate these attacks by encrypting and <del> signing the contents of their cookies.  However, using cryptography does not mitigate the issue completely because an attacker can replay a cookie he or she received from the authentic site.example server in the user's session, with unpredictable results. </del> <ins> signing the contents of their cookies, or by naming the cookie with the "__Secure-" prefix.  However, using cryptography does not mitigate the issue completely because an attacker can replay a cookie he or she received from the authentic site.example server in the user's session, with unpredictable results. </ins> Finally, an attacker might be able to force the user agent to delete cookies by storing a large number of cookies.  Once the user agent

Related discussion:
text: The "Weak Integrity" section correctly notes that non-secure cookies can be set by network attackers, and will be sent to secure origins. This commit notes that the prefix is a mitigation against that attack.
NAME WDYT?
LGTM, thanks!
Code change:
8. <ins> 8.1. A Txn-Token is not resistant to replay attacks.  A long-lived Txn- Token therefore represents a risk if it is stored in a file, discovered by an attacker, and then replayed.  For this reason, a Txn-Token lifetime must be kept short, not exceeding the lifetime of a call-chain.  Even for long-running "batch" jobs, a longer lived access token should be used to initiate the request to the batch endpoint.  It then obtains short-lived Txn-Tokens that may be used to authorize the call to downstream services in the call-chain. Because Txn-Tokens are short-lived, the Txn-Token response from the Txn-Token service does not contain the "refresh_token" field.  A Txn- Token cannot be issued by presenting a "refresh_token". The "expires_in" and "scope" fields of the OAuth 2.0 Token Exchange specification RFC8693 are also not used in Txn-Token responses.  The "expires_in" is not required since the issued token has an "exp" field, which indicates the token lifetime.  The "scope" field is omitted from the request and therefore omitted in the response. 8.2. Although Txn-Tokens are short-lived, they MAY be sender constrained as an additional layer of defence to prevent them from being re-used by a compromised or malicious workload under the control of a hostile actor. 8.3. When creating Txn-Tokens, the Txn-Token MUST NOT contain the Access Token presented to the external endpoint.  If an Access Token is included in a Txn-Token, an attacker may extract the Access Token from the Txn-Token, and replay it to any Resource Server that can accept that Access Token.  Txn-Token expiry does not protect against this attack since the Access Token may remain valid even after the Txn-Token has expired. 9. 9.1. Some "req_ctx" claims may be considered personal information in some jurisdictions and if so their values need to be obsfucated.  For example, originating IP address ("req_ip") is often considerd personal information and in that case must be protected through some obsfucation method (e.g.  SHA256). 10. </ins> This specification registers the following claims defined in Section txn-token-header to the OAuth Access Token Types Registry defined in RFC6749, and the following claims defined in Section txn-token-claims in the IANA JSON Web Token Claims Registry defined in <del> 8.1. </del> <ins> 10.1. </ins> Name: "txn_token"

Related discussion:
text: I moved the Security Considerations section before the IANA registry text and added a Privacy Considerations section as raised in the IETF 118 meeting.