jiebi/CodeConvo huggingface dataset:
Code change:
Track Namespace: Identifies the track namespace in the ANNOUNCE message for which this response is provided. <del> 6.12. </del> <ins> 6.11. </ins> The receiver sends an ANNOUNCE_ERROR control message for tracks that failed authorization.

Related discussion:
text: A client connected to the relay and subscribed to a track, which fowarded the subscribe to a publisher. The track was published to the relay and ended with a FIN. Another client subscribes to this track from the beginning (Absolute/0,0) and no end. Does the relay need to resubscribe upstream? Now suppose that the connection from the publisher to the relay closed abruptly, or the track was terminated with SUBSCRIBE_RST. This is a signal to the relay that it's worth another subscribe to find out where the end of the track is. I can live if we consolidate the framing to a single message, and define a special error code to mean FIN, but I do think the transport needs to see the difference.
I like it. I would also like to merge ERROR with CLOSED, but we'll chat about that.
Code change:
Status Method Value: "status_list" Status Method Description: A status list containing up-to-date <del> status information on multiple other CWTs encoded as a bitarray. </del> <ins> status information on multiple tokens. </ins> Change Controller: IETF

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:
7.1.1. IANA will be requested to register the new COSE Header parameters <del> defined below in the "COSE Header Parameters" registry at some point </del> <ins> defined below in the "COSE Header Parameters" registry at some point. </ins> 7.2.

Related discussion:
text: and have been incorrectly merged. This PR brings the content to the state of 00 as in URL
NAME can you give me merge permissions?
Code change:
RFC7033, in a manner related to the description in Section 2 of OpenID.Discovery. <ins> PRMetadata defines metadata values that a protected resource can publish, which includes things like which scopes are supported, how a client can present an access token, and more.  These values may be used by other specifications, such as the "jwks_uri" used to publish public keys the resource server uses to sign resource responses, as described in Section 5.6.2 of FAPI.MessageSigning. </ins> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

Related discussion:
text: From BC's comments: URL FAPI Message Signing talks about the RS signing resource responses. This specification could be how the RS publishes the public key, as mentioned in 5.6.6.2 URL
I can see why this one was tricky. One more suggestion to approve, then merge.
Code change:
6.4. <ins> 6.4.1. The subscriber specifies a filter on the subscription to allow the publisher to identify which objects need to be delivered. There are 4 types of filters: Lastest Group (0x1) : Specifies an open-ended subscription with objects from the beginning of the current group. Latest Object (0x2): Specifies an open-ended subscription beginning from the current object of the current group. AbsoluteStart (0x3): Specifies an open-ended subscription with objects beginning from the object identified in the StartGroup and StartObject fields. AbsoluteRange (0x4): Specifies a closed subscription starting at StartObject in StartGroup and ending at EndObject in EndGroup.  The start and end of the range are inclusive. A filter type other than the above MUST be treated as error. 6.4.2. </ins> A receiver issues a SUBSCRIBE to a publisher to request a track. The format of SUBSCRIBE is as follows:

Related discussion:
text: I think we should eventually bring back Locations so the publisher can do this conversion too without an additional RTT, but the desire was to simplify start/end ranges.
FWIW, I thought/intended start_group=0 to correspond to b. Also +1 to removing case 2.
Thanks for summary. +1 to remove case 2 (abs/latest). I also thought we had b. today but we need case b so lets update to make it clear we have b (latest/0). I don't think we have a use case for a (latest/abs), +1 on remove. I originally was in favor of case c (next/0) but I have changed my mind for now. IF you need this, you just do case 1 (latest/latest) and toss out object until you get to the next group. If there was not enough bandwidth to do this, then there is probably not enough bandwidth for the next group when it arrives. If we get a bunch of code running and can show that (latest/latest) is not good enough and we really need (next/0), then I will change my mind but for now, I think we can live without (next/0). And +1 to point that TRACKSTATUSREQUEST solves most problems.
A +1 to all these points Regarding starting at the latest group at the beginning, this seems like the default starting use case for many players. Therefore per Luke's comment -
Fixed by
Code change:
The wire format of the SETUP message is as follows: <del> The Parameter Value Length field indicates the length of the Parameter Value. </del> <ins> The available versions and SETUP parameters are detailed in the next sections. 6.1.1. MoQ Transport versions are a 32-bit unsigned integer, encoded as a varint.  This version of the specification is identified by the number 0x00000001.  Versions with the most significant 16 bits of the version number cleared are reserved for use in future IETF consensus documents. </ins> The client offers the list of the protocol versions it supports; the server MUST reply with one of the versions offered by the client.  If

Related discussion:
text: Based on QUIC: URL
Based on call today, sounds like when running over QUIC we should also use an ALPN of "moq-13" for draft 13
When running over web transport, we need to talk to the web transport people to talk about what to do but the ALPN would be H3 (or whatever) so the answer is not ALPN
The conclusion was that we should move version negotiation out of the SETUP message and into an ALPN for native QUIC and an unspecified mechanism for WebTransport. However, I can't think of any replacement for WebTransport that would work today. Query parameters would work for passing the client supported versions but there's no mechanism for replying with the server selected version. The javascript API provides no information about connection establishment (ex. any returned headers), only that it completed. If we moved version negotiation out of SETUP, then it would not be possible to interop until new WebTransport functionality was deployed, assuming W3C agrees in the first place. Could we go ahead with this PR until there's an available alternative? I like the direction of utilizing more of the QUIC/WebTransport handshake, but I don't think we should block interop awaiting this marginally better design.
Can we add in the ALPN text as part of this PR and for now say something like "When QUIC is used, the negotiated alpn MUST match the value in the SETUP message."?
It's time to specify some version numbers so we can attempt interop. We should do something like QUIC, where draft versions are prefixed with 0xff (or something?).
+1 The QUIC guys way over engineered this so I would be fine with just doing the same thing so we don't need to bike shed on it.
For now, will go with lower bits are the draft number and upper bits are some fixed set of bits defined in the draft. Do roughly what QUIC did.
Here's what I propose we copy: URL We don't need semvar yet because each version WILL have breaking changes. I'd be totally fine with semvar for the final RFC, like one byte for the major/minor/revision. Although I also think that negotiating extensions is more flexible for a transport protocol, while semvar seems more useful for something intended for fanout like the catalog.
Code change:
The wire format of the SETUP message is as follows: <del> The Parameter Value Length field indicates the length of the Parameter Value. </del> <ins> The available versions and SETUP parameters are detailed in the next sections. 6.1.1. MoQ Transport versions are a 32-bit unsigned integer, encoded as a varint.  This version of the specification is identified by the number 0x00000001.  Versions with the most significant 16 bits of the version number cleared are reserved for use in future IETF consensus documents. </ins> The client offers the list of the protocol versions it supports; the server MUST reply with one of the versions offered by the client.  If

Related discussion:
text: Per conversation, we've decided to move forward with this and do ALPN as a separate PR.I would want to consider using alpn at some point in time. Want to keep it open for URL version at some point too. This PR is fine to continue the experimentation.Looks fine to me. Sure we might do more complicated stuff later but this seems like good enough for now.
Code change:
This example shows catalog for a media producer capable of sending 3 time-aligned video tracks for high definition, low definition and <del> medium definition video qualities, along with an audio track. </del> <ins> medium definition video qualities, along with an audio track.  In this example the namesapce is absent, which infers that each track must inherit the namespace of the catalog. </ins> 3.4.3.

Related discussion:
text: Consensus for merging at IETF meeting.
Per the discussion at URL, it would be useful that if the namespace were absent, that track names would inherit the namespace of the catalog track in which they were defined. This capability allows for relative naming, which aids in portability.
I know there has been lots of debate on this but it seems reasonable.
Code change:
Tree algorithm designers are encouraged to comment on this property of their leaf construction algorithm. <ins> 6.1.1. Implementers wishing to leverage multiple inclusion proofs to support selective disclosure, can prepend each payload with extra data before computing the inclusion proof, where extra data is a cryptographic nonce. </ins> 7. See the security considerations section of:

Related discussion:
text: This PR build on and attempts to clarify what is generic vc what is specific to RFC9162 encodings
Mostly improves on the earlier version, I like the generality it allows for. A couple of larger questions in here amongst the suggestions
Code change:
2.4. <del> Confidential and credentialed clients establish a client authentication method with the authorization server suitable for the security requirements of the authorization server.  The authorization </del> <ins> If the client is confidential or credentialed, the authorization </ins> server MAY accept any form of client authentication meeting its <del> security requirements. Confidential and credentialed clients are typically issued (or establish) a set of client credentials used for authenticating with the authorization server (e.g., password, public/private key pair). </del> <ins> security requirements (e.g., password, public/private key pair). </ins> The authorization server MUST authenticate the client whenever possible.  If the authorization server cannot authenticate the client

Related discussion:
text: rewords a circular definition in §2.3
Some editorial improvements [x] definition of user agent ( is an abnf syntax)
Code change:
Abstract This document describes a scheme for prioritizing HTTP responses. <del> This scheme expresses the priority of each HTTP response using absolute values, rather than as a relative relationship between a group of HTTP responses. </del> This document defines the Priority header field for communicating the initial priority in an HTTP version-independent manner, as well as HTTP/2 and HTTP/3 frames for reprioritizing the responses.  These

Related discussion:
text: This sentence in the abstract might be relevant for those who are caught up in the way that h2 originally signaled priorities, but for those who will read this document later, it adds nothing. It's a distraction. Stick to what the document does rather than what it doesn't do.
I agree, thanks for the PR
Code change:
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <ins> TODO: The terms defined here doesn't capture the ongoing discussions within the Working Group (either as part of requirements or architecture documents).  This section will be updated to reflect the discussions. </ins> Commonly used terms in this document are described below. 1.3.

Related discussion:
text: NAME does the updated text with OPEN ISSUE looks about right to you. I personally feel we should revisit all the terms and get to a common understaning across the documents. For -05 an OPEN ISSUE seems like OK. thoughts ?
LGTM
Code change:
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <ins> TODO: The terms defined here doesn't capture the ongoing discussions within the Working Group (either as part of requirements or architecture documents).  This section will be updated to reflect the discussions. </ins> Commonly used terms in this document are described below. 1.3.

Related discussion:
text: NAME please check the latest commit . thanks
Something is wrong, this PR appears blank
editorial nit if it can be addressed, otherwise LGTM
Code change:
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <ins> TODO: The terms defined here doesn't capture the ongoing discussions within the Working Group (either as part of requirements or architecture documents).  This section will be updated to reflect the discussions. </ins> Commonly used terms in this document are described below. 1.3.

Related discussion:
text: NAME I think you added this TODO but it got removed in the editorial pass, are you good with that?
Yes, we can remove this. We will certainly revisit the issue later, because this is a thorny subject. For example, we assume that "objects MUST not depend from objects in the group that have a higher priority code or a higher object ID" -- object at P2 does not depend on another object at P3, object number 1000 cannot depend on object number 2001. That much has consensus, but it is a negative statement.
Code change:
[2] #Unique Codes [3] #Content Filtering <ins> [4] #Example B5: Illicit Network Join [5] #Example B7: Illicit Session Transfer [6] ##Example A5: Add a device to a network [7] #Example A7: Transfer a session </ins>

Related discussion:
text: Added examples to illustrate cases when the authenticated flow is not an effective as a mitigation.
Code change:
Recommended HTTP status code: 400 <del> 3.32. </del> <ins> 3.31. </ins> Name: http_upgrade_failed

Related discussion:
text: Signed-off-by: Piotr Sikora
cc NAME
This field uses for a specific purpose, but that's already in the generic parameters. Suggest or similar. /cc NAME
Looks like has the same issue. Should we use for both? Note that the identifier is context-based, since if proxy configured SHA256-based validation, then would be , if it configured SPKI-based validation, then would be , etc. We could also use and instead of (and for ), but that doesn't seem very future-proof. What do you think?
Hmm, that's awkward. Maybe two fields? E.g., : [, ... ] : ... Is there a registry we can refer to, maybe?
I'm afraid that there isn't any registry that we can refer to, at least none that I know of. (opaque type) and (opaque value) seem a bit awkward. Wouldn't it be easier to just have and params? Also, in Envoy, we actually configure list of acceptable and values, and matching against any of them works, so we should probably emit both of them anyway. I could envision merging and into a single status type that lists all 3 params, e.g. See . What do you think?
Better than what we had :)
Code change:
dynamic table by setting a maximum size of 0, which can subsequently be restored. <del> The size of the dynamic table is the sum of the size of its entries. The size of an entry is the sum of its name's length in octets (as defined in string.literal.representation), its value's length in octets (see string.literal.representation), plus 32. The size of an entry is calculated using the length of the name and value without any Huffman encoding applied. NOTE: The additional 32 octets account for the overhead associated with an entry.  For example, an entry structure using two 64-bit pointers to reference the name and the value of the entry, and two 64-bit integers for counting the number of references to the name and value would have 32 octets of overhead. 4.2. </del> <ins> 4.3. </ins> Whenever the maximum size for the dynamic table is reduced, entries are evicted from the end of the dynamic table until the size of the dynamic table is less than or equal to the maximum size. <del> 4.3. </del> <ins> 4.4. </ins> Whenever a new entry is to be added to the dynamic table, entries are evicted from the end of the dynamic table until the size of the

Related discussion:
text: For . Here, I moved the text that covers the calculation of the dynamic header table size up into a new section. Then, I reworded the text to reduce the direct dependency on HTTP/2 and its settings. The emphasis is now on the using protocol setting a maximum, of which the HTTP/2 setting is just an example. Apologies for the diff, I'll try to split the move commit out to make it more readable.
OK, the first commit does the rewording, the second only moves text around.
Code change:
This eventually leads to a loss of reputation and company closure for Vendor OS-X. <ins> 5. Consumers want to understand and verify that an actual trust bond exists between the Supplier of a certain software component package and the Signing Authority of that software component package (4.1.1) Consumers want to obtain statements from producers and third- parties related to the software product in a timely and unambiguous fashion (4.2.1) Consumers want to attribute statements to an authoritative issuer (4.2.2) Consumers want to associate statements with other statements in a meaningful manner (4.2.3) Consumers want to consistently, efficiently, and homogeneously check the authenticity of statements (4.2.4) Consumers want to understand if a particular provider is actually the original provider or a promoter (4.3.1) Consumers want to know if and how the source, or resulting binary, of a promoted software component differs from the original software component (4.3.2) Consumers want to check the provenance and history of a software component's source back to its origin (4.3.3) Consumers want to assess whether to trust a promoter or not (4.3.4) To be continued... </ins>

Related discussion:
text: Added a placeholder section to aggregate problem statements across use cases. Refine and complete this section as use cases stabilize.
:ship: it
Code change:
header flags field RFC5175. This router advertisement MUST also include a Route Information <del> Option (RFC4191) for each routable prefix advertised on the stub </del> <ins> option (RFC4191) for each routable prefix advertised on the stub </ins> network.  If the stub router is also a normal router (e.g. a home WiFi router), it SHOULD include all other routes that it is advertising in the RA, if there is space.

Related discussion:
text: see URL in the working group meeting in London, and in both cases, it seemed that the argument that without NAT64 we can't deliver on "device must always be able to connect to the internet if it is available" overrode the objections that were raised. So despite some folks really not loving it, I think it's required. Michael (IIRC) also pointed out that we need DHCPv6 PD to get infrastructure-provided NAT64 to work, which I guess means that if we have IPv4 and infrastructure-provided NAT64, but no DHCPv6 PD, we have to do NAT64 in the stub router. If we have v6-only, infrastructure-provided NAT64, and no DHCPv6 PD, then in order to reach the internet, we'd need NAT66. I'm inclined to declare this situation out of scope, because (A) I really don't want to do NAT66, and (B) I think it's not a likely scenario at the moment, and the more devices out in the field that would break in this situation, the better.
Code change:
6. <del> See the privacy considerations section of: </del> <ins> See the security considerations section of: </ins>

Related discussion:
text: Feedback gathered from URL
Consider attempting better CDDL by applying URL We would like some time to discuss this draft at IETF 117: URL https://ietf-URL We've made several changes that were requested at 116. We provide a sample implementation demonstrating how to use RFC9162 tree algorithm with COSE Sign1 to create signed "inclusion" and "consistency" proofs. We updated the draft to support registration of other tree algorithms which can be specified in separate documents. If there are other changes folks would like to see, we are happy to try to get them in before the cut off date. Regards, OS ORIE STEELE Chief Technology Officer www.transmute.industries
Code change:
Once all the Envelope headers are set, an Issuer MUST use a standard COSE implementation to produce an appropriately serialized Signed <del> Statement (the SCITT tag of "COSE_Sign1_Tagged" is outside the scope of COSE, and used to indicate that a signed object is a Signed Statement). </del> <ins> Statement.  The SCITT tag "COSE_Sign1_Tagged" is outside the scope of COSE, and used to indicate that a signed object is a Signed Statement. </ins> Issuers may produce Signed Statements about different Artifacts under the same Identity.  Issuers and Relying Parties must be able to recognize the Artifact to which the statements pertain by looking at the Signed Statement.  The "iss" and "sub" claims, within the CWT_Claims protected header, are used to identify the Artifact the <del> statement pertains to. See Subject under terminology Terminology. </del> <ins> statement pertains to.  (See Subject under terminology Terminology.) </ins> Issuers MAY use different signing keys (identified by "kid" in the resolved key manifest) for different Artifacts, or sign all Signed

Related discussion:
text: Adjusts text around CDDL and EDN Adjusts text regarding Validation
LGTM, nice and clear changesLGTM
Code change:
the credentials are presented, the original session from the attackers device is authorized with the user's credentials. <del> 3.4.9. </del> <ins> 3.4.10. </ins> In all of the attack scenarios listed above, a user is misled or exploited.  For other attacks, where the user is willingly colluding

Related discussion:
text: See issue
There are two new attacks, the consent bombing and fake helpdesk attacks, that may be added as examples of attacks, or as extensions of existing attacks.
After discussing ith Daniel we agreeed: Add an example for the consent bombing attacks Add a sub-attack to example B.4 (split into two attacks).