jiebi/CodeConvo huggingface dataset:
Code change:
authorization requests automatically without user consent or interaction, except when the identity of the client can be assured. This includes the case where the user has previously approved an <del> authorization request for a given client ID -- unless the identity of </del> <ins> authorization request for a given client ID - unless the identity of </ins> the client can be proven, the request SHOULD be processed as if no previous request had been approved.

Related discussion:
text: uses the ::boilerplate macro of URL
I'm not sure what I'm doing wrong but when I try this I get an error: I'm using kramdown-rfc2629 version 1.4.3
fixed in URL NAME
Friendly reminder ;)
PTAL
Code change:
Append-only Log, some Transparency Services may provide limited support for historical queries on the Signed Statements they have registered, and accept the risk of being blamed for inconsistent <del> Registration or Issuer equivocation. </del> <ins> Registration or Issuer Equivocation. </ins> Verifiers and Auditors may also witness (1, 4) but may not be able to collect verifiable evidence for it.

Related discussion:
text: Define equivocation and non-equivocation and cite the article that coined the term in analyzing Lamport. Closes ietf-wg-scitt/draft-ietf-scitt-architecture.
I think this reference from the CT rfc is useful. URL "and (2) by violating its append-only property by presenting two different, conflicting views of the Merkle Tree at different times and/or to different parties." this is equivocation. If we replace "Merkle Tree" with "collection of statements". And that reference is also careful to cast things interms of detectability rather than prevention
This is very useful, thanks. I will adjust with this and your other feedback, most appreciated!
Who reads papers anyway? Jokes aside, thanks for the contributions and making me think about how to communicate clearly on this one.
Define the term non-equivocation formally as it relates to this architecture document, per URL
I like those changes. Reads clean to me thanksLGTM Thanks, NAME for the iterations. This was a tricky one to summarize an entire paper in a few sentences
Code change:
2. <ins> 2.1. Protocol developers have been considering the implications of the QUIC protocol (RFC9000) for media transport for several years, resulting in a large number of possible meanings of the term "Media Over QUIC", or "MOQ".  As of this writing, "Media Over QUIC" has had at least these meanings: any kind of media carried directly over the QUIC protocol, as a QUIC payload any kind of media carried indirectly over the QUIC protocol, as an RTP payload any kind of media carried indirectly over the QUIC protocol, as an HTTP/3 payload any kind of media carried indirectly over the QUIC protocol, as a WebTransport payload the encapsulation of any Media Transport Protocol (mtp) in a QUIC payload an IETF mailing list (MOQ-ml) "... for discussion of video ingest and distribution protocols that use QUIC as the underlying transport" There may be IETF participants using other meanings as well. As of this writing, the second bullet ("any kind of media carried indirectly over the QUIC protocol, as an RTP payload"), seems to be in scope for the IETF AVTCORE working group, and was discussed at some length at the February 2022 AVTCORE working group meeting AVTCORE-2022-02.  So, perhaps, that possible meaning is out of scope for "Media over QUIC". It will be SUPER HELPFUL if interested parties can come up with a term that unambiguously describes what we're trying to achieve. 2.2. </ins> Within this document, we use the term "Media Transport Protocol". This is easier to understand if the reader assumes that we are starting with a protocol stack that looks like this:

Related discussion:
text: I've been using the phrase "live media", defining it as "media that is actively being produced and consumed". It's not perfect but neither is drawing a numeric latency number in the sand.
NAME - just so that I understand (better) - are you saying that the media is being consumed at (roughly) the rate it's being produced? Any answer is fine, I just want to make sure I know what we're talking about here.
We have been talking about "Media Over QUIC" as a broad term that would include any media transport protocol running over QUIC, which (apparently) would include RTP over QUIC SRP over QUIC RUSH, which runs over QUIC If we are doing "Media over QUIC", all of these (and potentially others) would be in scope. If the scope of this document is "Media over RTP over QUIC", that would be fine, but we should say that. Thoughts?
I think we've fixed this one - I'll close it for now.
Code change:
One of the most basic use cases for workload identity is authentication of one workload to another, such as in the case where <del> one service is making a request to another service within a larger application.  Even in this simple case the identity of a workload is </del> <ins> one service is making a request to another service as part of a larger, more complex application.  Following authentication, the request to the service offered by the workload it needs to be authorized.  Even in this simple case the identity of a workload is </ins> often composed of many attributes such as: Trigger Information

Related discussion:
text: Updated figure in
NAME I made a slight update to remove the word authentication in the text since authentication is one specific type of interaction, there may be many others. This might also be a good place to introduce "context" that is propagated (although that seems to be more a topic of the next section
Code change:
time at which the JWT was issued. The JWT MAY contain a "jti" (JWT ID) claim that provides a unique <del> identifier for the token.  The authorization server MAY ensure that JWTs are not replayed by maintaining the set of used "jti" values for the length of time for which the JWT would be considered valid based on the applicable "exp" instant. </del> <ins> identifier for the token. </ins> The JWT MAY contain other claims.

Related discussion:
text: Addresses issues with language about the jti claim in the client attestation and pop jwt.
The spec states: "The JWT MUST contain a "jti" (JWT ID) claim that provides a unique identifier for the token. The authorization server MAY ensure that JWTs are not replayed by maintaining the set of used "jti" values for the length of time for which the JWT would be considered valid based on the applicable "exp" instant." However the is not shown in the example in the same section.
The text says jti is required URL but the example doesn't have jti URL
Duplicate of
The Client Attestation JWT seems like a long(er) lived credential that should be reusable so the client instance doesn't have to go get a new one each time (right?). But this text for the Client Attestation JWT has 'The authorization server MAY ensure that JWTs are not replayed by maintaining the set of used "jti" values for the length of time for which the JWT would be considered valid based on the applicable "exp" instant' that suggests the AS might limit them to single use. I think that sentence can just be removed. \ right: URL
Agreed, need to remove this sentence from step 7 of 4.1.1.
Code change:
full backoff mechanism must be identical to that of TCP RFC2988. As an example, this bullet does not preclude full backoff mechanisms that would give flows with different round- trip times <del> comparable bandwidth during backoff. </del> <ins> comparable caapcity during backoff. </ins> Protection Against Bufferbloat

Related discussion:
text: at the time 5033 was written, only TCP, DCCP and SCTP were around, using CC; nowadays, many more protocols use CC - with QUIC standing out as a here, probably warranting it's explicit mentioning.
Yes. Note that there is a bit of sadness here, because QUIC was forced to describe use of Reno in RFC 9002, while most deployments use Cubic or BBR. But the WG could not go beyond Reno... because of RFC 5033!
This one seems simple, but is not. The introduction text says: This formulation, "Impact on standard TCP", assumes that the congestion control algorithm is an integral part of the TCP specification. The situation has changed, and I think this part should be rewritten as: The reference here should be RFC9000, the specification of the transport protocol, rather than RFC9002, the specification of default loss recovery and congestion control algorithms. And the text should then be modified to mention that our goal is to not wantonly disrupt existing deployments -- whether they use Reno, Cubic or BBR. The point is "don't disrupt the Internet", not "don't offend the pride of the IETF".
Looks good.
Code change:
full backoff mechanism must be identical to that of TCP RFC2988. As an example, this bullet does not preclude full backoff mechanisms that would give flows with different round- trip times <del> comparable bandwidth during backoff. </del> <ins> comparable caapcity during backoff. </ins> Protection Against Bufferbloat

Related discussion:
text: The guidelines section as discussion of "Difficult Environments", starting with "The proposed algorithms should be assessed in difficult environments such as paths containing wireless links." Opinion may vary, but wireless links are probably now part of something between "a vast majority" and "a plurality" of the paths on the Internet.
I agree. Wireless serves the vast majority and are still increasing.
Gorry and Martin: wireless constraints deserve their own section. Three different phenomena to discuss Non-congestion loss Variable bandwidth on the path Jitter due to media access and link-layer retransmission
I changed based on the thread with Christian, and agreed to these insights. I think this ready.
Code change:
5.4. <del> Extending the IRD example in Section 8.1 of RFC8895, below is the IRD of an ALTO server supporting ALTO base protocol, ALTO/SSE, and ALTO TIPS. </del> <ins> Extending the IRD example in Section 8.1 of RFC8895, ex-ird is the IRD of an ALTO server supporting ALTO base protocol, ALTO/SSE, and ALTO TIPS. </ins> Note that it is straightforward for an ALTO server to run HTTP/2 and support concurrent retrieval of multiple resources such as "my-

Related discussion:
text: Please add captions to all figures and call them in the text rather than "below" thing :-) Thanks.
Code change:
Transparency Service has added this Signed Statement to its Append- only Log. <del> The WG is discussing if existing CWT claims might better support these design principles. </del> fig-transparent-statement-cddl illustrates a normative CDDL definition of Transparent Statements.

Related discussion:
text: This is how a SCITT Signed Statement associates an Issuer making a statement about an Artifact, which has been core to the draft from the start. Previously, these were properties in the protected header, aligned with DIDs: See The use of was to align with other existing standards, for how we associate these concepts. An alternative is to lift these two properties, independently, to the protected header. We already have an in the protected header for additional properties, reducing the duplicity of in the cwtclaims and protected header, potentially simplifing the model. The approach of using cwt claims allows users to benefit from existing cwt libraries, which seemed the better of the choices.
OK so the answer is yes then. I am happy with it, but this is a small, tight PR deleting the editors note, I wanted to understand the implication before I (and maybe others) understand before I approve.
Resolve Section :
LGTM
Code change:
worker.  This protects against re-authorization from XSS-injected code. <del> 6.3.2.2. </del> <ins> 6.4.2.2. </ins> A successful XSS attack on an application using this Service Worker pattern would be unable to exfiltrate existing tokens stored by the

Related discussion:
text: I moved the considerations about XSS to a general section: all architectures are concerned. I added some words about bypassing the Service Worker: this would need a very broad successful XSS, with a much broader attack surface than what is typically the case. This can be mitigated by making sure that registering the service worker is the very first thing happening. There is also no API for unregistering a SW, so it can't be removed after the fact.
I haven't dug too deep yet but isn't this an API to unregister a service worker? URL
Indeed, this mitigation won't work. I oversaw the registration itself and focused on URL . I'll rework this and focus on what can be guaranteed by specs.
I removed the part about service workers for now. I'll see if I can further improve it in another PR.
Code change:
Note that a Structured Header token allows the characters as the "token" ABNF rule defined in RFC7230, with the exceptions that the <del> first character is required to be ALPHA, and ":" and "/" are also allowed. </del> <ins> first character is required to be either ALPHA or "*", and ":" and "/" are also allowed in subsequent characters. </ins> 3.3.5.

Related discussion:
text: ... and allow token to start with "*".
I'm running my SH implementation against the HTTP Archive dumps (400,000,000+ HTTP requests) to see how the from BSH parse in something like the real world. It looks like some headers are failing because AcceptAccess-Control-Allow-Origin`. If we were to use a different character to delimit Byte Sequences, we could include in Token (necessarily as a first character, as well as in the rest, I assume). Worthwhile? If so, what should we use for Byte Sequences?
(via ) already allows , but not as a first character. '%' is short in HPACK and unlikely to trigger funny handling, but maybe it will conflict with pct-encoding to start. '=' has the virtue of being already allowed. It has the drawback of causing byte array parameters to look funny ( for instance). Interestingly, it makes removal of padding easier (base64 padding is silly).
How about ? I don't' think is a good idea; if an implementation enforces padding (which we caution against, but do not prohibit), it's confusing.
Checking with NAME NAME - any issues changing byte sequence delimiters from to ?
(the only conflicting use that comes to mind ATM for is that if someone wants to refer to H2 pseudo-headers like in a field that uses tokens, they'll be out of luck. I think that's OK, because existing fields that take header names as a list-of-tokens don't refer to pseudo-headers, and new fields can be defined as lists of tokens-or-strings.)
is free
Code change:
status code indicates that the server is successfully fulfilling a range request for the target resource by transferring one or more <del> parts of the selected representation that correspond to the satisfiable ranges found in the request's header field (header.range). </del> <ins> parts of the selected representation. </ins> When a 206 response is generated, the server MUST generate the following header fields, in addition to those required in the

Related discussion:
text: See URL
Mailing list discussion:
We might want to clarify the nature of the response elsewhere, but this seems fine.
Code change:
2.3.2. <del> Either one of resource or audience is required to indicate for what authorization server the authorization grant should be audienced. The authorization server MUST deny the request if neither is set.  An authorization server SHOULD deny the request on an unknown resource/ audience.  In cases where federation to any authorization server is deliberate unknown resource or scope identifiers MAY be allowed. 2.3.3. </del> <ins> An authorization server SHOULD deny the request on an unknown resource or audience.  In cases where federation to any authorization server is deliberate unknown resource or audience identifiers MAY be allowed. </ins> The authorization server MAY deny the request due to policy.  For instance if federation to the requested domain/authorization

Related discussion:
text: parameter removed from token exchange request section as this is already specified in RFC8693 Resource/audience section merged into request section. added more author details
Code change:
IANA.well-known.  Examples of this construction can be found in PRConfigurationRequest. <ins> The term "application", as used below (and as used in RFC8414), encompasses all the components used to accomplish the task for the use case.  That can include OAuth clients, authorization servers, protected resources, and non-OAuth components, inclusive of the code running in each of them.  Applications are built to solve particular problems and may utilize many components and services. </ins> Different applications utilizing OAuth protected resources in application-specific ways MAY define and register different well- known URI path suffixes for publishing protected resource metadata

Related discussion:
text: I could add an introductory remark derived from the above, if that would work for you. (Although I would try to make it more concise.)
Looks good to me.
Code change:
9.3. <del> The "Cookie Attribute Registry" defines the name space of attribute used to control cookies' behavior.  The registry is maintained at https://www.iana.org/assignments/cookie-attribute-names [4]. </del> <ins> IANA is requested to create the "Cookie Attribute Registry", defining the name space of attribute used to control cookies' behavior.  The registry should be maintained at https://www.iana.org/assignments/ cookie-attribute-names [4]. </ins> 9.3.1.

Related discussion:
text: The IANA Cookie Attribute Registry does not exist yet. It is requested that IANA create it. Clarify wording to reflect this. Addresses
The section titled "Cookie Attribute Registry" has a link to the attribute registry maintained by the IANA. This link is broken. Moreso, a cursory look through the IANA site doesn't turn up any similar pages suggesting that this section is obsolete.
The registry does not exist yet. The text about it was added in URL The prose should actually tell IANA that the registry needs to be created, not "updated".
Addressed by
Code change:
6. <del> The message body (if any) of an HTTP message is used to carry the payload body (payload.body) of that request or response.  The message body is identical to the payload body unless a transfer coding has been applied, as described in field.transfer-encoding. </del> <ins> The message body (if any) of an HTTP/1.1 message is used to carry payload data (payload) for the request or response.  The message body is identical to the payload data unless a transfer coding has been applied, as described in field.transfer-encoding. </ins> The rules for determining when a message body is present in an HTTP/1.1 message differ for requests and responses.

Related discussion:
text: I think we discussed this last week and Julian has pending changes to be made before review.
This just moves the ABNF, not the definition of the transfer codings.
This is the remaining ABNF production that Semantics imports from Messaging (for the definition of "TE"). Maybe we should move the production to messaging, reversing the dependency.
Discussed on call; worth a try.
URL out that there are a few more things to consider: Semantics currently claims there are regular parameters here, but transfer-parameter is special wrt BWS should we move the special case of "trailers" in the grammar into prose? In any case, what would it mean to have a ranking on "trailers"? Invalid, thus ignore? "t-ranking" seems to duplicate "weight"
Fine to merge, but shouldn't we also move the extensibility and IANA registry sections?
Code change:
6. <del> The message body (if any) of an HTTP message is used to carry the payload body (payload.body) of that request or response.  The message body is identical to the payload body unless a transfer coding has been applied, as described in field.transfer-encoding. </del> <ins> The message body (if any) of an HTTP/1.1 message is used to carry payload data (payload) for the request or response.  The message body is identical to the payload data unless a transfer coding has been applied, as described in field.transfer-encoding. </ins> The rules for determining when a message body is present in an HTTP/1.1 message differ for requests and responses.

Related discussion:
text: This eliminates confusion with the message body protocol element of HTTP/1.1 and other usage of multipart body parts, and should make it easier to describe HTTP/2 and HTTP/3 data frames.
except for multipart body parts or when referring specifically to HTTP/1.1 message body.
See related comment: URL
I believe this is good; but more eyes are needed :-) If we go ahead with that, we may want to call out the new terminolody in one of the "changes from 723x" sections.
Code change:
proxies).  This means that a client does not have to consider the transfer codings to compute the upload offset, while a server is responsible for transfer decoding the message before computing the <del> upload offset.  Please note that the "Content-Length" header field cannot be used in conjunction with the "Transfer-Encoding" header field. </del> <ins> upload offset.  The same applies to the value of "Upload-Length". Please note that the "Content-Length" header field cannot be used in conjunction with the "Transfer-Encoding" header field. </ins> 15. The integrity of an entire upload or individual upload requests can be verifying using digests from DIGEST-FIELDS. <ins> 15.1. Representation digests help verify the integrity of the entire data that has been uploaded so far, which might strech across multiple requests. </ins> If the client knows the integrity digest of the entire data before creating an upload resource, it MAY include the "Repr-Digest" header field when creating an upload (upload-creation).  Once the upload is

Related discussion:
text: As NAME mentioned in URL, is not directly applicable here because it asks the server to send the digest corresponding to the response content, not the received request content. Good point that a client may validate digests while a multi-request upload is progressing. A server could respond with the latest digest of the entire uploaded data (not just the data from the last request) using after POST and PATCH requests. The client can then validate and decide to abort if the digests don't match. This usage would be in line with the PATCH example in . The server responds with the digest of the representation after the PATCH has been applied. The example also notes that the server is not required to respond with the representation itself and could also have returned a 204 (as is done for resumable uploads):
Makes sense, thanks for clarifying. is most likely good enough given that it indicates the current checksum of what the server received.
NAME please, stalk me for a review in the next week :)
NAME It took me a bit more than a week, but here we go: URL Happy to hear your feedback :)