jiebi/CodeConvo huggingface dataset:
Code change:
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 <del> 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. </del> <ins> AVTCORE-2022-02, although no drafts in this space have been adopted by the AVTCORE working group.  So, perhaps, that possible meaning is out of scope for "Media over QUIC". </ins> 2.2.

Related discussion:
text: From NAME
NAME and NAME - I agree with Magnus in his email (cut and pasted in the description), where he said "what about RMTP and SRT?", but I'm thinking that since we already have a "Why QUIC?" section, we should probably have a "Why NOT other protocols" section, rather than trying to talk about that in (what was) Section 6.1. That could also conveniently map into saying why we're not looking at "Interactive Media" in this document (and, transitively, in the BOF), and why we're not looking at "On Demand" (Media) in this document (and in the BOF). Please let me know if this is a BAD idea soon (I'm typing PRs).
NAME for media ingest, Magnus has a good point about covering not just HLS and DASH, but also making (even brief) reference to non-segmented protocols like RTMP and SRT (but really, this can be expanded to RIST, ZiXi, etc etc etc). This can just be a sentence or two; I'm happy to write it.
NAME - I had a complicated day yesterday, which became less complicated last night, so I'm not coherent enough to type text. I'll see what I can do in the next couple of hours, and if I can include these NAME suggestions.
The current definition of latency targets in the draft is based on specific numeric ranges. Those do make sense (since they ultimately come from use case requirements), but I believe we should focus more on what consequences those have for the protocol design. Reflecting on our experience with QUIC used for live video vs QUIC used for video conferencing, my proposed definition of the latency target for live video would be "latency an order of magnitude higher than one RTT". Two major examples of why this is important: When the target latency is on the order of one RTT, it makes sense to use FEC and codec-level packet loss concealment. When the target latency is in the range of many, many RTTs, selectively retransmitting only lost packets is almost always better than FEC. When the target latency is on the order of one RTT, it is impossible to use congestion control schemes like BBR, since BBR has probing mechanisms that rely on temporarily inducing delay and amortizing the consequences of that over multiple RTTs.
Code change:
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 <del> 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. </del> <ins> AVTCORE-2022-02, although no drafts in this space have been adopted by the AVTCORE working group.  So, perhaps, that possible meaning is out of scope for "Media over QUIC". </ins> 2.2.

Related discussion:
text: I think the first point illustrates nicely why protocols like RTP have low-level control over packetization, while the existing MoQ proposals defer it entirely to the QUIC stack.
NAME - that's super helpful. It helps us explain a few things - why we need to know this, in order to explain why we're shooting for One Protocol, and why we think the first three use cases in the draft are different (they're all RTPish), and why we're not looking at RTP in the BOF - right now, the draft just says AVTCORE is looking at RTP over QUIC, which really isn't much of a justification, engineering-wise.
Victor's points are well made, though I think picking the boundary of the number of round trips necessary to rely on standard QUIC loss detection is a challenge. 5 RTTs provides almost 5 opportunities to repair a loss, which in my experience is almost always enough. Similarly, I'd expect it's enough for BBR to complete various probing cycles. It's also important to understand what RTT we have in mind here. I think the RTT used to understand what domain you're in is approximately smoothed RTT (not min RTT), because the number of rounds for loss recovery or BBR gain cycling or Cubic packet conservation matter the most.
I agree that the numeric ranges are not useful when designing a protocol but they're useful enough as product requirements. However focusing on the RTT completely misses the point. Network latency involves fixed delays (min RTT) but most of it is caused by queuing (primarily congestion control). This includes any queues within the application, the network layer, intermediate routers, and even the receiver. You can think of latency as the "frame RTT" which is decoupled from the packet RTT. Of course the packet RTT is important, but it just doesn't factor in how much data has been queued. For example, it's just useless to talk about RTMP and HLS/DASH latency in terms of network RTTs. In my opinion, the problem with those protocols is that they impose unnecessary dependencies, making it slow to drop the bitrate to reduce queue sizes. Sending media over a single stream means that every frame depends on every previous frame regardless of the GoP structure (no frame dropping), and it also means that new GoPs are dependent on the previous GoPs (no skipping ahead).
Code change:
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 <del> 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. </del> <ins> AVTCORE-2022-02, although no drafts in this space have been adopted by the AVTCORE working group.  So, perhaps, that possible meaning is out of scope for "Media over QUIC". </ins> 2.2.

Related discussion:
text: WebRTC avoids these unnecessary dependencies which is how it's able to rapidly respond to congestion to keep latency low. I've been working on a "latency theory" document if any of these ideas are resonating with people. I feel like it's too early though, and we should be focusing on the use-cases and requirements instead.
NAME - please let me know when you think it's not too early to focus on "latency theory". I'd love to know more (in particular, I'd love to know if I'd be able to contribute effectively to that important topic). Just filing this away for now, as you suggest.
Code change:
5.1.8. <del> An attacker can be prevented from initiating a cross device flow </del> <ins> An attacker can be prevented from initiating a cross-device flow </ins> protocol by only allowing the protocol to be initiated on a trusted network or within a security perimeter (e.g., a corporate network). A trusted network may be defined as a set of IP addresses and joining

Related discussion:
text: See issue
Closing issue
Hyphenate all uses of cross device (e.g. cross-device).
Code change:
Furthermore, the hash algorithms MD2, MD4, MD5, and SHA-1 revealed fundamental weaknesses and MUST NOT be used. <del> 10.6. </del> <ins> 10.5. </ins> Key Binding aims to ensure that the presenter of an SD-JWT credential is actually the legitimate Holder of the credential.  An SD-JWT with

Related discussion:
text: Attempt to better explain how salt in the Disclosure makes guessing the preimage of the digest infeasible Consolidate salt entropy and length security consideration subsections
question from an email, my response: The exchange makes me think a brief mention/explanation what salt does/provides in the SD-JWT context would be a worthwhile addition. Maybe just add or modify a sentence or two in sec 10.3. And/or something in URL where the salt value in the Disclosure is introduced/described.
Hi Brian, just check for understanding: does the issuer send the clear text values of the disclosed claims to the holder and verifier or does the issuer only send the salted hashes? +------------+ +------------+ | Issues SD-JWT including all Disclosures | v +------------+ +------------+ | Presents SD-JWT including selected Disclosures | v +-------------+ + + +-------------+ +-------------+| +-------------+
I'm sorry but I don't quite understand the question or how it relates to the small change I'm suggesting in this issue.
FYI, I was asked what the salt does by an IETF attendee yesterday. I support explaining this in the draft.
PR has some proposed text
Code change:
HTTP 401 (Unauthorized) status code.  The client MAY request a new access token and retry the protected resource request. <del> The request requires higher privileges than provided by the access token.  The resource server SHOULD respond with the HTTP 403 (Forbidden) status code and MAY include the "scope" attribute with the scope necessary to access the protected resource. </del> <ins> The request requires higher privileges (scopes) than provided by the scopes granted to the client and represented by the access token. The resource server SHOULD respond with the HTTP 403 (Forbidden) status code and MAY include the "scope" attribute with the scope necessary to access the protected resource. </ins> If the request lacks any authentication information (e.g., the client was unaware that authentication is necessary or attempted using an

Related discussion:
text: From Vittorio: The “insufficientscope” description here is problematic. The privileges the AT carries/points to are not necessarily (or exclusively) represented by the included scopes (eg the RO might have granted document:read to the client, but RO might have no privileges for the particular document being requested in this particular call). It might be useful to specify that “invalidscope” should be used for authorization errors that can be actually expressed in terms of delegated authorization, leaving to RS implementers the freedom to handle other authorization issues (eg user privileges, RBAC, etc) with a different error code. Or at least, we should be clear that authorization logic not expressed via scopes is out of scope (pun not intended) for this specification. Note, this isn’t an abstract problem: there are SDKs out there that use “invalid_scope” for every permission issues. Very confusing.
to me, insufficientscope => the client does not have scope required for the request invalidscope => when I see invalid_scope, I think that the RS does not understand what scope the client has
I'll get clarity for what Vittorio is asking for.
Here is my restatement from thread with Vittorio: "insufficientscopes" - is the correct error to return if the application has not been granted the scopes required for the request Vittorio: "to me the highest order but is ensuring that the reader doesn’t abuse insufficientscopes and realizes other error codes are possible." I've submitted a pull request with suggested language changes
Code change:
to wait before retrying the request.  In the absence of this header field, this document does not specify a minimum. <del> 2.1.1. </del> <ins> 2.2.1. </ins> <del> 2.1.1.1. </del> <ins> 2.2.1.1. </ins> Headers:

Related discussion:
text: Strawman proposal for: URL PoC implementation here URL
Definite start in the right direction - I would say it is enough to get in and build on
general thumbs upLGTM After a chat with Richard Barnes, I think there are a few things happening with and key binding, that we should probably consider independently for scitt: Registration Policies that require fresh signatures from issuers. Registration Policies that require issuer's to commit to a recent tree head. Registration Policies that require additional context binding and a fresh signature from the issuer bound to special context. 1 and 2 are basically both about "time". If the Transparency Service does not trust the issuer to be honest about time, the transparency service can force the issuer to include a time commitment from the transparency service in their registration with binding to their confirmation public key. In the case the "nonce" is a timestamp, the TS rejects key binding tokens that are outside some window. In the case the "nonce" is a recent tree head, the TS rejects key binding tokens that are not to a tree head inside some window. In the case the "nonce" is a "challenge token", the nonce is some special context, the TS rejects key binding tokens that lack this special context. There is an opportunity to make the registration none interactive and one shot, assuming the following is acceptable: The key binding token nonce is a "recent timestamp / tree head" The transparency service rejects key binding tokens with nonces that are not "recent" There is an opportunity to make the registration interactive and context binding, assuming the following is acceptable: The transparency service includes specific context the issuer must commit to in their "challenge token". The issuer uses the challenge token as the nonce in their key binding token. The transparency service rejects key binding tokens with nonces that omit required context In this second case, imagine a "dynamic registration policy" Holder (Issuer) asks Verifier (Transparency Service) for a challenge token for a Customs Entry for 16056100.
Code change:
to wait before retrying the request.  In the absence of this header field, this document does not specify a minimum. <del> 2.1.1. </del> <ins> 2.2.1. </ins> <del> 2.1.1.1. </del> <ins> 2.2.1.1. </ins> Headers:

Related discussion:
text: The transparency service knows that animal products require certificates to be imported, and issues a challenge token that looks like this: iss: "https://transparency.example" aud: "https://transparency.example" iat: ${now} exp: ${now + 7 day} currenttreehead: ... (not all TS are trees) currentpolicyhash: ... (not all policies are stored in trees) entrynumber: 42 htscodes: [ 16056100 ] The holder starts registering signed statements, each is bound to the same "challenge token". The first signed statement covers a phytosanitary certificate for the sea cucumber processing facility. The regulatory requirements change. The second signed statement covers the (now required) export certificate for sea cucumbers. The transparency service would normally have rejected the second signed statement, but because of the context in the challenge token, the transparency service knows that the second signed statement is now actually required. The holder did not need to request a "new challenge token" when the regulatory changes happened, and the holder still had to prove possession of the public key bound to both certificates ( and these public keys are different ). I chose to make this context scenario about sea cucumbers, but it could easily have been about network capable hardware devices that need to comply with regulations specific to Radio Antennas and GPUs... In those cases there would be firmware certifications required, and compliance requirements might change inside the transaction window. This also solves the problem of forcing the issuer to commit to the registration policies as they exist at the time the "challenge token" is issued. The TS can reject registrations that are committing to stale policies, or accept registrations that are commiting to stale policies, because the TS will know which policies the issuer is committing to by checking the challenge token. In the case that proof of possession is not required, and there is no need to commit to policies, the challenge token can be omitted, and the registration can proceed exactly as it is specified today. OS ORIE STEELE Chief Technology Officer www.transmute.industries
Code change:
2. <del> The document defines the following terms: </del> <ins> The document makes use of the following terms: Topology in this document refers to the network and service topology.  Network topology defines how physical or logical nodes, links and interfaces are related and arranged.  Service topology defines how service components (e.g., VPN instances, customer interfaces, and customer links) between customer sites are interrelated and arranged.  There are at least 8 types of topologies: point to point, bus, ring, star, tree, mesh, hybrid and daisy chain.  Topologies may be unidirectional or bidirectional (bus, some rings). </ins> <del> Network topology defines how physical or logical nodes, links and interfaces are related and arranged.  Service topology defines how service components (e.g., VPN instances, customer interfaces, and customer links) between customer sites are interrelated and arranged.  There are at least 8 types of topologies: point to point, bus, ring, star, tree, mesh, hybrid and daisy chain. Topologies may be unidirectional or bidirectional (bus, some rings). </del> <ins> A multi-layered topology models relationships between different layers of topology, where each layer represents a connectivity aspect of the network and services that needs to be configured, controlled and monitored.  Each layer of topology has a separate lifecycle. </ins> <del> Defines a layer in the multilayer topology.  A multilayer topology models relationships between different layers of connectivity, where each layer represents a connectivity aspect of the network and service that needs to be configured, controlled and monitored. </del> <ins> Represents topology at a single layer in the multi-layered topology. </ins> The topology layer can also represent what needs to be managed by a specific user, for example IGP layer can be of interest to the

Related discussion:
text: Addressed discussion on the nmop group for THREAD1, THREAD2 and THREAD3 as well as issues 1, 2, 3 (partial, just examples), 5, 6, 7
Code change:
to match an outgoing request from a client to the available dictionaries. <del> Dictionaries MUST have been served from the same {Origin} as the outgoing request to match. </del> <ins> Dictionaries MUST have been served from the same Origin RFC6454 as the outgoing request to match. </ins> To see if an outbound request matches a given dictionary, the following algorithm will return TRUE for a successful match and FALSE

Related discussion:
text: This addresses the reference issues, comments and nits from the AD review (see )
NAME would you mind taking a quick look before I publish a new draft?
(tried using ietf-comments but ran into issues so just tracking manually in one combined issue)... cc NAME Thank you for the work on this document. Almost all my comments are about references. I think a new version is necessary before starting IETF Last Call, to avoid process issues along the way. Francesca The boilerplate is duplicate, please remove the second occurrence. Can you please update the reference to 8941 to draft-ietf-httpbis-sfbis ? That doc is with the RFC Editor so should not be holding this document up. Also, I believe the reference to draft-ietf-httpbis-sfbis should be normative, not informative, since terminology from that doc is used. Alternatively, if you want to keep the ref informative, you can import the part of the terminology that is necessary for this doc. I think that's a uglier solution, so I highly prefer sfbis to be made normative, but won't block on it. [URLPattern] "URL Pattern Standard", March 2024, URL needs to be indicated as Living standard (see RFC 9110 or 9421 for eample of whatwg specs references). Please fix this so that the Fetch spec is properly referenced (normatively is needed, I believe). RFC 8792 should be (informatively) referenced. I agree with Mark's write up, 5861 should really be informative. There is several occurrences of {Origin}, please fix. Please add a reference. It would be good to have an informative reference to 6265 (or even 6265bis). This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [ tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: URL [ICT]: URL
Code change:
responds with a "Digest" field even though the client did not solicit one using "Want-Digest". <del> Some examples include JSON objects in the payload data.  For presentation purposes, objects that fit completely within the line- length limits are presented on a single line using compact notation with no leading space.  Objects that would exceed line-length limits are presented across multiple lines (one line per key-value pair) with 2 spaced of leading indentation. </del> <ins> Some examples include JSON objects in the content.  For presentation purposes, objects that fit completely within the line-length limits are presented on a single line using compact notation with no leading space.  Objects that would exceed line-length limits are presented across multiple lines (one line per key-value pair) with 2 spaced of leading indentation. </ins> "Digest" is media-type agnostic and does not provide canonicalization algorithms for specific formats.  Examples of "Digest" are calculated

Related discussion:
text: Use "content" instead of "payload data".
to reference semantics-14, including "payload data" --> "content".
Code change:
11. <ins> The Status List as defined in status-list only exists in cryptographically secured containers which allows checking the integrity and origin without relying on other aspects like transport security (e.g., the web PKI). </ins> 11.1. Implementers should be particularly careful for the correct parsing

Related discussion:
text: We would register: CWT Status Mechanisms registry in CWT JWT Status Mechanisms registry in JWT Status Types registry in OAuth parameters Any ideas how we could simplify this?
looks good to me in general. I would extend this to more than two weeks, if I look back how the current year went by. I think this is a good start for now, so we should merge this first and then evaluate afterwards if we can merge both status registries.
JWT/CWT registries use three week periods, the OAuth Parameter one uses two weeks. Should we just align with these registries for each one?
Section 4 of RFC 8126 -> supply registration procedures for the registries Define where these registries should be placed
Editors Call: we propose to put into OAuth Parameters: URL
Code change:
updating with the new information provided, and then do so. The initial set of stored responses to update are those that could <del> have been selected for that request -- i.e., those that meet the </del> <ins> have been chosen for that request -- i.e., those that meet the </ins> requirements in constructing.responses.from.caches, except the last requirement to be fresh, able to be served stale or just validated.

Related discussion:
text: Me confused. Which PR is relevant now? Both?
The other one is an evolution of this one.
We use the phrases 'selected representation' and 'selected response' in Semantics and Caching (respectively) to refer to two completely different concepts. Can we do better?
No
I think the two concepts match pretty well (and are used correctly in the four sentences). However, I also think that "chosen response" would be okay given it is only used in four places. I really don't think it needs a separate definition, since it means what the two words mean. So, maybe.
It was actually used in a few more places as the response selected. I think I found all of them.
See .