jiebi/CodeConvo huggingface dataset:
Code change:
This section shows HTTP/1.1 requests and responses, with illustrations of equivalent HTTP/2 requests and responses. <del> An HTTP GET request includes request header fields and no body and is therefore transmitted as a single </del> <ins> An HTTP GET request includes request header fields and no payload body and is therefore transmitted as a single </ins> frame, followed by zero or more

Related discussion:
text: There were lots of small changes as a result of . The only change of note is URL, which adds text on what a receiver should expect and what they are obligated to do for streams in the "half closed (local)" state.
Code change:
6.5.1. The frame payload of a SETTINGS frame consists of zero or more <del> parameters, each consisting of an unsigned 16-bit setting identifier </del> <ins> settings, each consisting of an unsigned 16-bit setting identifier </ins> and an unsigned 32-bit value. 6.5.2. <del> The following parameters are defined: </del> <ins> The following settings are defined: </ins> An endpoint that receives a SETTINGS frame with any unknown or unsupported identifier MUST ignore that setting.

Related discussion:
text: In the spirit of the naming simplications of the recent HTTP changes, we can talk about settings in this revision. This aligns better with HTTP/3, though that still uses "settings parameters" (with that ugly double-plural). cc NAME
I mean, it's not too late to Auth48 the same change into H3.... Not quite, anyway.
Code change:
<del> (label: "13" pending CWT_CLAIM_COSE): A CWT representing the </del> <ins> (label: "15" pending CWT_CLAIM_COSE): A CWT representing the </ins> Issuer ("iss") making the statement, and the Subject ("sub") to correlate a collection of statements about an Artifact. Additional CWT_CLAIMS MAY be used, while "iss" and "sub" MUST be

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:
and on-link prefix just like any other router. However, some stub networks are more cooperative in nature, for <del> example IP mesh networks.  On such networks, multiple stub routers </del> <ins> example IP mesh networks.  On such networks, multiple SNAC routers </ins> may be present and be providing addressability and reachability. In either case, some SNAC router connected to the stub network MUST

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:
claim of the SD-JWT MUST be used. <del> For the verification, the claim in the SD-JWT MAY be used to retrieve the public key from the JWT Issuer Metadata configuration (as defined in jwt-issuer-metadata) of the SD-JWT VC issuer.  Alternative methods MAY be used to obtain the public key to verify the signature of the SD-JWT. </del> <ins> Furthermore, the recipient of the SD-JWT VC MUST verify that the public key used for verification of the Issuer-signed JWT belongs to the Issuer of the Issuer-signed JWT, as defined in public-key-for- issuer-signed-jwts-verification. </ins> If there are no selectively disclosable claims, there is no need to process the

Related discussion:
text: This PR does the following: make verification that the public key of the Issuer-signed JWT belongs to the Issuer mandatory introduce methods to perform this verification based on JWT Issuer Metadata, X.509 Certificates and DIDs Potentially . Partially Out-of-scope: Renaming and moving JWT Issuer Metadata Section
Addressed all suggestions, please review again NAME
I had to rename the section. I think now it is more precise.
Show possible options like JWT Issuer Metadata, being a DID URL etc.
We introduced a new section that talks about different key discovery methods during the verification process in PR
Code change:
A server MAY ignore the Range header field.  However, origin servers and intermediate caches ought to support byte ranges when possible, since they support efficient recovery from partially failed transfers <del> and partial retrieval of large representations.  A server MUST ignore a Range header field received with a request method other than GET. </del> <ins> and partial retrieval of large representations. A server MUST ignore a Range header field received with a request method which is unrecognized or for which range handling is not defined.  For this specification, is the only method for which range handling is defined. </ins> An origin server MUST ignore a Range header field that contains a range unit it does not understand.  A proxy MAY discard a Range

Related discussion:
text: : "A server MUST ignore a Range header field received with a request method other than GET." : "Likewise, if the new method might have some use for partial response semantics (Section 14.2), it ought to document this, too."
I can see why someone might want to use it with SEARCH as well, though they would more likely use a page parameter. I can't think of any other use case.
FWIW, that's exactly how it was used by MS in Exchange SEARCH: We need to decide which of the statements in our spec is correct.
Huh, that's news for me. We could have used that example for Range extensions.
Change requirement to MUST ignore Range when not defined for that method or the method is unrecognized.
Code change:
MUST either be represented as a quoted string, or MUST NOT include ";" or "," in the character sets used for the encoding. <del> 3.1. A representation digest is the value of the output of a digest algorithm, together with an indication of the algorithm used (and any parameters). As explained in resource-representation the digest is computed on the entire selected "representation data" of the resource defined in RFC7231: The encoded digest output uses the encoding format defined for the specific digest-algorithm. 3.1.1. The "sha-256" digest-algorithm uses base64 encoding.  Note that digest-algorithm values are case insensitive. The "UNIXsum" digest-algorithm uses ASCII string of decimal digits. 4. The Want-Digest message header field indicates the sender's desire to receive a representation digest on messages associated with the request URI and representation metadata. If a digest-algorithm is not accompanied by a qvalue, it is treated as if its associated qvalue were 1.0. The sender is willing to accept a digest-algorithm if and only if it is listed in a Want-Digest header field of a message, and its qvalue is non-zero. If multiple acceptable digest-algorithm values are given, the sender's preferred digest-algorithm is the one (or ones) with the highest qvalue. Two examples of its use are 5. The Digest header field provides a digest of the representation data. "Representation data" might be: fully contained in the message body, partially-contained in the message body, or not at all contained in the message body. The resource is specified by the effective request URI and any "validator" contained in the message. For example, in a response to a HEAD request, the digest is calculated using the representation data that would have been enclosed in the payload body if the same request had been a GET. Digest can be used in requests too. The "Digest" value depends on the representation metadata. A Digest header field MAY contain multiple representation-data-digest values.  This could be useful for responses expected to reside in caches shared by users with different browsers, for example. A recipient MAY ignore any or all of the representation-data-digests in a Digest header field.  This allows the recipient to chose which digest-algorithm(s) to use for validation instead of verifying every received representation-data-digest. A sender MAY send a representation-data-digest using a digest- algorithm without knowing whether the recipient supports the digest- algorithm, or even knowing that the recipient will ignore it. Two examples of its use are </del> 6. POST and PATCH requests may appear to convey partial representations

Related discussion:
text: Moves Digest Algorithms down
I verified the formatting here URL
This looks good but note the similar comment I made elsewhere about the trailing spaces after colons e.g. we need or else the formatting seems to get screwed up
Code change:
Web features that require a secure context SECCTXT will likely treat a new scheme as insecure. <del> See RFC7595 for more information about minting new URL schemes. </del> <ins> See RFC7595 for more information about minting new URI schemes. </ins> 4.4.3.

Related discussion:
text: This change switches from "URL" to "URI" specifically for two contexts: URI schemes URI syntax (It might be good to also add an explanation somewhere in the Introduction; I can make a proposal if needed)
It is a PR, no?
Weird, it didn't show the UX for PRs before, but does now. shrug
See URL
Code change:
4.3.1. <del> ** James, can you fill this section in?** </del> <ins> *Senders/Receivers*: One to Many *Bi-directional*: No *Latency*: On Demand Where media is ingested and processed for a system to later serve it to clients as on-demand media.  This may be media captured from live output or provided as a pre-recorded source, and may optionally be transcoded upon ingest. </ins> 4.3.2.

Related discussion:
text: We should talk about whether the MOPS latency constraints make sense, or whether we should stop suffering and switch to something that's not about transport latency, but more about end-to-end workflow duration, which is what I think we're talking about in the "On Demand Media" section. But we can do that another day.
I think it's hard to really define latency for on demand for a whole host of reasons: The non-functional requirements for a system to process an on demand asset can vary dramatically. For example, it's common for news clips to have an SLA of clip duration to ingest, transcode, deliver, and be playable. Whereas for high resolution content, this stage of ingest and processing can take many multiples of duration and may be done hours/days in advance of its availability to playback. It's not really live, so the measurement of "latency" is a bit weird here. The latency between the origin storage serving the media to presentation on screen is, in general irrelevant from a playback perspective provided it doesn't stall out playback due to poor network conditions. Throughput and jitter have a greater affect.
Code change:
is communicated using PACI Extensions defined in [RFC7798] Section 4.4.4.2. A WebRTC implementation that has negotiated use of RTP header extensions containing TSCI information (such as the Dependency Descriptor [DD]) SHOULD <del> NOT send TSCI information within the PACI, and where TSCI information is being received in RTP header extensions MUST ignore TSCI information contained in the PACI. </del> <ins> NOT send TSCI information within the PACI.  If TSCI information is being received in an RTP header extension, implementations MUST ignore TSCI information contained in the PACI. </ins> Implementations of the H.265 codec have utilized a wide variety of optional parameters.  To improve interoperability, the following

Related discussion:
text: Fix for
NAME PTAL
NAME PTAL
(moved to issue)
PACI packet is defined in RFC7798 ((URL, section 4.4.4). According to 4.4.4.2 it defines only a single payload header extension for Temporal Scalability Control Information (TSCI) in RFC7798, and a new payload type 50 is introduced for the PACI packet. In WebRTC, TSCI is included in generic info and sent through RTP video header extension, there is no need to implement payload type 50 to transfer TSCI as RTP payload specifically. We may ignore payload type 50 in H265 depacketizer.
Virtual interm slide is here: URL
Through the GFD (somewhat deprecated) and DD extensions?
yes. through GFD or DD depending on if it's perfectly layered according to spec.
URL NAME made a good point here about SFUs. If you negotiate DD on the sending leg, you can not strip it in the SFU or you loose the information about temporal layer. Do we need to capture this or is it more of a "middleboxes gonna middlebox" problem?
NAME I modified the PR to say that if RTP header extensions supporting TSCI are negotiated, then TSCI SHOULD NOT be sent in the PACI and if TSCI is being received in the header extension, then PACI MUST be ignored. I think this covers the broken SFU case.
Closing. At IETF 118, the proposed text was presented, and there were no objections.
Code change:
figtxtokenresponse shows a non-normative example of a Txn-Token Response. <del> 7.3. </del> <ins> 7.4. </ins> A workload within a call chain may request the Transaction Token Server to replace a Txn-Token.

Related discussion:
text: Updated the text to more clearly profile the token exchange specification for use with Transaction Tokens.
In PR , the token exchange parameter is profiled to carry the purpose or intent of the transaction and its value is copied into the claim of the resulting Txn-Token. Is this how we want to handle the 'purp' claim?
I propose that the draft should allow value of the claim in the TraT request be independent of the claim in the TraT, because the requesting service may not know sufficient details about how the TraT is actually going to be used. For example, the requester may say the is "buy stock", whereas the claim could have a value like "equity trade"
Ok, so allow the TTS to transform the input scope to the appropriate value (if necessary). I'm ok with that.
Recommended change that the TTS MUST take the value of the parameter to determine the claim of the TraT.
Based on this feedback, the claim is being made REQUIRED.
Should we allow the use of and to be used as a means of client authentication for the Transaction Token Service? If not, should explicitly prohibit the use of these parameters in the profile of the Token Exchange spec.
Since RFC8693 (Token Exchange) refers to the as "A security token that represents the identity of the acting party", we should not use it in the TraT request. I thought we wanted to have some way to convey the inbound token to the TraT service, and that's why we were using , but that is inconsistent with RFC8693. I think we should neither require nor disallow the use of because some implementations may want that for client auth, and some implementations may want to do something else (e.g. mTLS) for client auth.
This is kind of what the spec says today. It's not required and up to the implementation. It is just referenced as an example. However, I'm fine removing the example and just being silent in the spec on the topic.
Recommendation to update example and be silent on use of and . Add a section to Security Considerations to talk about client authentication and add some non-normative examples.
Removed the additional text regarding possible client authentication methods and just left it that the client MUST authenticate itself to the Transaction Token Service and that the specific client authentication method is out of scope for this specification.
Code change:
figtxtokenresponse shows a non-normative example of a Txn-Token Response. <del> 7.3. </del> <ins> 7.4. </ins> A workload within a call chain may request the Transaction Token Server to replace a Txn-Token.

Related discussion:
text: PR raised a number of issues around processing of authorization details How are these details determined by the Transaction Token Service (i.e. where do they come from)? Should all the claims be visible to all workloads? or should they be restricted to a subset of workloads? Who is authoritative for specifying the claims of the object
Some thoughts: I think the spec should be un-opinionated about how the TraT service generates the value of claim. I can see in some instances that the requester has more control over what goes into the claim, and in some cases, the TraT service has more control. A TraT service could implement selective disclosure, although we could recommend in the spec that one should implement it by encrypting certain fields. Stating this makes the actual mechanism for selective disclosure outside the scope of the spec. I believe the TraT service MUST be authoritative for the claims of the object, because it is signing the TraT.
Regarding (1) -- I think we still need a way for the client to pass in data to the TTS that it can use to generate the values. Even if how all that works is out of scope for the specificatio. Regarding (2) and (3) -- I'm ok with leaving the rules out of scope for the specification. The TTS will be authoritative for the resulting object and whether it should be protected in some way or not. I am curious to hear from others as to their thoughts.
Suggestion to rename to and then add a processing rule to the effect of... "The TTS SHOULD propagate the data from the object into claims in the object as authorized by the TTS authorization policy for the requesting client"
This has been fixed AFAIK. Please reopen the issue if it hasn't been fixed by George's PR.
I suspect in many cases the AS that issues an accesstoken used to obtain an Txn-Token is going to be different than the Transaction Token Service. In that context, the issuer of the 'subject' of the transaction token is different than the issuer of the transaction token itself. Section 3.2.3 of RFC 9493 allows for the specification of an issuer and sub within the object. Should we require this format? or just leave out of scope of the specification what values are present in the claim of the transaction token?
I would definitely not require that format.
Code change:
figtxtokenresponse shows a non-normative example of a Txn-Token Response. <del> 7.3. </del> <ins> 7.4. </ins> A workload within a call chain may request the Transaction Token Server to replace a Txn-Token.

Related discussion:
text: And would again suggest that RFC 9493 isn't needed in the Txn-Token context and good enough.
My concern with relying on the JWT's subject is that the Transaction Token is issued by the Transaction Token Service which is potentially different than the AS that say issued the access token from which the claim is determined. In that context, I think the Transaction Token should carry the issuer of the claim which means the default and claims of the JWT are not sufficient. Or if the entity requesting the Transaction token is the service that receives inbound mail, and that service wants a transaction token with a purpose of , is the Transaction Token Service the correct issuer of the which is an email address?
I feel like there might be an undue emphasis on a relationship between and that doesn't truly exist. RFC7519 only mentions uniqueness in the context of an issuer URL but not ownership or correctness or semantic meaning.
In the context of OpenID and id_tokens there is a clear relationship between the and the such that the globally unique identification is the combination of and . I've always viewed the relationship of those two claims in that light. Maybe that is an OpenID Connect centric view.
Yeah, I am somewhat familiar with OpenID Connect ;) But this isn't OpenID Connect. With a Transaction Token the subject just needs to be identified within a single trust domain.
So that assumes that the claim MUST be unique within the single trust domain as identified by the claim. This might require the Transaction Token Service (TTS) to do some sort of identifier transformation as well as requiring both the AS and the TTS to both be authoritative for the claim value. This is easy if the AS is managing the transaction token request endpoint but if the TTS is it's own service and deployed in a distributed way, would that still be true? I can see the TTS being authoritative for the single trust domain but not necessarily for the identifier. However, I'm ok with moving in the direction you are suggesting Brian; I just want to make sure we aren't prohibiting some deployments by making that simplification.
From discussion... 'iss' claim is optional be clear that there is no relationship between iss and sub claim sub is unique within context of the 'aud' or trust domain go back just supporting the claim (no sub_id)
Added a new commit to PR to address this issue.
A few months ago, I also suggested to support the sub claim as per JWT RFC.
Code change:
figtxtokenresponse shows a non-normative example of a Txn-Token Response. <del> 7.3. </del> <ins> 7.4. </ins> A workload within a call chain may request the Transaction Token Server to replace a Txn-Token.

Related discussion:
text: As the current spec has replaced sub_id with sub, I appreciate that the sub claim is supported now.
Hi Kai, Thanks so much for your input in this process. Atul
Since we have removed sub_ids now, I will close this issue.
Wkn
Code change:
2. <del> The CACHE_DIGEST frame type is 0xf1.  NOTE: This is an experimental value; if standardised, a permanent value will be assigned. </del> <ins> The CACHE_DIGEST frame type is 0xd (decimal 13). </ins> The CACHE_DIGEST frame payload has the following fields:

Related discussion:
text: The header needs to be registered if it's going to appear in an RFC. Looking at 7540, I think the frame type needs to be registered as well, since "Experimental Use" is private / local only.
Thank you very much!