jiebi/CodeConvo huggingface dataset:
Code change:
There are two ways using this specification increases the risk of phishing. <del> With this specification, the client interacts directly with the end user, collecting information provided by the user and sending it to the authorization server.  If an attacker impersonates the client and successfully tricks a user into using it, they may not realize they are giving their credentials to the malicious application. In a traditional OAuth deployment using the redirect-based authorization code flow, the user will only ever enter their credentials at the authorization server, and it is straightforward to explain to avoid entering credentials in other "fake" websites.  By introducing a new place the user is expected to enter their credentials using this specification, it is more complicated to teach users how to recognize other fake login prompts that might be attempting to steal their credentials. </del> <ins> Malicious application: With this specification, the client interacts directly with the end user, collecting information provided by the user and sending it to the authorization server. If an attacker impersonates the client and successfully tricks a user into using it, they may not realize they are giving their credentials to the malicious application. User education: In a traditional OAuth deployment using the redirect-based authorization code flow, the user will only ever enter their credentials at the authorization server, and it is straightforward to explain to avoid entering credentials in other "fake" websites.  By introducing a new place the user is expected to enter their credentials using this specification, it is more complicated to teach users how to recognize other fake login prompts that might be attempting to steal their credentials. </ins> Because of these risks, the authorization server MAY decide to require that the user go through a redirect-based flow at any stage

Related discussion:
text: Clarifying the text to make it clear that there are two ways in which phishing attacks may be facilitated by this specification. (see issue ) cc NAME
Maybe I misunderstand this section, but it sounds like only one way to do phishing is described, though the section starts by saying "there are two ways."
NAME Thank you for the new text.
Code change:
REQUIRED This claim, defined in RFC7519, identifies the trust domain in which the Txn-Token is valid.  This identifier MUST <del> uniquely identify the trust domain. </del> <ins> uniquely identify the trust domain to prevent the Txn-Token from being accepted outside it's current trust domain. </ins> REQUIRED Expiry time of the Txn-Token as defined in

Related discussion:
text: See issue
Good practice is to explain why something is a MUST. Suggestion: From: The value of the aud claim MUST remain unchanged in a replacement Txn-Token. To: The value of the aud claim MUST remain unchanged in a replacement Txn-Token to prevent the Txn-Token from being accepted outside it's current Trust Domain. Alternatively, we cann add security considerations for the draft as well.
I'm good with that text.
I think the current PR is making the change in the wrong place (unless I'm horribly mistaken)
Looks good
Code change:
The following is the CBOR Annotated Hex output of the example above: <del> 6.4. The Referenced Token MUST be encoded as a "COSE_Sign1" or "COSE_Sign" CBOR structure as defined in "CBOR Object Signing and Encryption (COSE)" RFC9052. It is required to encode the status mechanisms referred to in the Referenced Token using the "Status" CBOR structure defined in referenced-token-cwt. </del> <ins> ISO mdoc ISO.mdoc may utilize the Status List mechanism by introducing the "status" parameter in the Mobile Security Object (MSO) as specified in Section 9.1.2.  The "status" parameter uses the same encoding as a CWT as defined in referenced-token-cose. </ins> It is RECOMMENDED to use "status" for the label of the field that contains the "Status" CBOR structure.

Related discussion:
text: Rendered version: URL We need to fix width - otherwise the datatracker will refuse the document. I will make suggestions
NAME please approve
Editors Call: rename 6.2 -> Referenced Token in JOSE add SD-JWT example is it possible to merge 6.3 and 6.4 and make some specifics for CWT? include both cwt and mdoc example
Looks good imho
Code change:
The SEARCH method is used to initiate a server-side search.  Unlike the HTTP GET method, which requests that a server return a <ins> representation of the resource identified by the target URI (as defined by RFCHTTP), the SEARCH method is used to ask the server to perform a query operation (described by the request payload) over some set of data scoped to the effective request URI.  The payload returned in response to a SEARCH cannot be assumed to be a </ins> representation of the resource identified by the effective request <del> URI (as defined by RFC7230), the SEARCH method is used to ask the server to perform a query operation (described by the request payload) over some set of data scoped to the effective request URI. The payload returned in response to a SEARCH cannot be assumed to be a representation of the resource identified by the effective request </del> URI. The body payload of the request defines the query.  Implementations MAY use a request body of any content type with the SEARCH method; however, for backwards compatibility with existing WebDAV implementations, SEARCH requests that use the text/xml or <del> application/xml content types MUST be processed per the requirements </del> <ins> application/xml media types MUST be processed per the requirements </ins> established by RFC5323. SEARCH requests are both safe and idempotent with regards to the

Related discussion:
text: content-type / media type header / header field
This should include updating the core spec references; I will update this PR accordingly unless you get to that before me.
See
Code change:
4.3.1. <del> Proposed congestion control algorithms SHOULD include a clear </del> <ins> A proposed congestion control algorithm SHOULD include a clear </ins> explanation of any deviations from RFC2914 and RFC7141. 4.3.2.

Related discussion:
text: Please do not merge yet, I will tray to update to include a few sentences to address the issue related to in-network Circuit breakers.
From NAME review: I do wonder if this document needs to bring up the circuit breaker specifications (RFC 8083, RFC 8084) we do have and potential interaction with them. I would expect a congestion control algorithm to work well within the envelope which would trigger them. The question is if one needs to take them into account when dealing with them. I will note that traffic applying a circuit breaker can be dynamic in transmission pattern and rates and otherwise be very non-responsive in relation to congestion signals. Only if they exceed the circuit breaker threshold will something happen.
This looks good, but please don't mangle my name, or that of Lisong Xu, or ACM Queue reference. Minor edit suggestion on the wording of the last paragraph in "## Paths with Varying Delay {#delay}"
Code change:
Automatically Connecting Stub Networks to Unmanaged Infrastructure <del> draft-ietf-snac-simple-00 </del> <ins> draft-ietf-snac-simple-01 </ins> Abstract

Related discussion:
text: states: | If IPv6 prefix delegation is available, which implies that IPv6 | service is also available on the infrastructure link, then the stub | router MAY use IPv6 prefix delegation to acquire a prefix to | advertise on the stub network, rather than allocating one out of its | ULA prefix. and 5.2.3: | Therefore, when DHCPv6-PD is available, the stub router MUST use DHCPv6 | PD rather than its own prefix. That's contradictory, I suppose 5.2.2 should say: | If IPv6 prefix delegation is available, which implies that IPv6 | service is also available on the infrastructure link, then the stub | router MUST use IPv6 prefix delegation to acquire a prefix to | advertise on the stub network, rather than allocating one out of its | ULA prefix. Or maybe just drop the last paragraph from 5.2.2 entirely. URL
Esko adds: What about the case where DHCPv6-PD is available, but the stub router doesn’t get the desired prefix length or encounters some error in the process? In that exceptional case it still MAY allocate a prefix out of its ULA prefix. Depending on the reader, “is available” and “works for me” can be different things.
My suggestion: Right, MAY would be way too unspecific in that case. MAY basically says "we aren't saying you shouldn't do this, nor that you mustn't do this." :) So I think as you say that what we really need here is to be more specific about exactly what "is available" means. So, perhaps: If IPv6 prefix delegation and IPv6 service is both available on the infrastructure link, then the stub router MUST attempt to acquire a prefix using IPv6 prefix delegation. and Therefore, when the stub router is able to successfully acquire a prefix using DHCPv6-PD, it MUST use DHCPv6 PD rather than its own self-generated ULA prefix.
Explain what to do if prefix is to narrow, and also if it is too wide. states: | If IPv6 prefix delegation is available, which implies that IPv6 | service is also available on the infrastructure link, then the stub | router MAY use IPv6 prefix delegation to acquire a prefix to | advertise on the stub network, rather than allocating one out of its | ULA prefix.
Code change:
Automatically Connecting Stub Networks to Unmanaged Infrastructure <del> draft-ietf-snac-simple-00 </del> <ins> draft-ietf-snac-simple-01 </ins> Abstract

Related discussion:
text: and 5.2.3: | Therefore, when DHCPv6-PD is available, the stub router MUST use DHCPv6 | PD rather than its own prefix. That's contradictory, I suppose 5.2.2 should say: | If IPv6 prefix delegation is available, which implies that IPv6 | service is also available on the infrastructure link, then the stub | router MUST use IPv6 prefix delegation to acquire a prefix to | advertise on the stub network, rather than allocating one out of its | ULA prefix. Or maybe just drop the last paragraph from 5.2.2 entirely. In my defence, I have been left unsupervised.
Code change:
comprise of multiple audio or video outputs with different codecs or bitrates.  This may also include other types of media essence such as subtitles or timing signalling information (e.g. markers to indicate <del> change of behaviour in client such as advertisement breaks) </del> <ins> change of behaviour in client such as advertisement breaks).  The use of "live rewind" where a window of media behind the live edge can be made available for clients to playback, either because the local player falls behind edge or because the viewer wishes to play back from a point in the past. </ins> 4.6.

Related discussion:
text: This is just a starting point, but brings the document closer to alignment with our spreadsheet. I've also added some additional details which should cover themes raised in the current BoF agenda.
Code change:
to distinguish them from decimal literals. This specification describes binary formats using the convention <del> described in QUIC. </del> <ins> described in QUIC.  Note that this format uses network byte order and high-valued bits are listed before low-valued bits. </ins> The following terms are used:

Related discussion:
text: URL is frame formats. I've chosen to put blank lines before and after both frames and the stream identifier part of the stream header. That should make this a lot clearer. NAME was right that this was a little hard to process without that. Hopefully this is a tiny bit better.
I think this helps. The only other clarification I can think of is to pull the flags out into a separate illustration, but let's see if this is sufficient first.
Bah I didn't respond at the right place. One day I'll understand github's interface. Or not :-) Both changes look good and possibly sufficient to me. Let's just wait a bit to see if anyone in the WG has any better proposal. Thanks for your quick reaction!
For the flags (and only the flags), what about trying this:
Should I add the octet values of flags? I would only do that for non-unused flags though.
I believe the prose text contains them, so there's at least a defensible reason for leaving them off.
They're indeed present but not trivially spottable. I have a dead-tree copy of 7540 here with them overlined in pink to spot them faster :-/ We could save a tree by noting them there :-). I agree with Martin that we can avoid the unused ones though, because what matters in tests is not to know the unused ones but rather to figure them as the complement of all known ones. I won't roll over the floor crying if that's rejected, but as an implementer I find that it significantly helps during debugging.
As I don't know how to comment in this format and I don't want to start inventing something (else), I think I'm going to take the coward's option.
What are the semantics of a blank line in this format? /me ducks
Code change:
new one and send the "STREAM_HEADER_TRACK" if needed, then serialize the the following object fields. <ins> A sender MUST NOT send an Object on a stream if its Group ID is less than a previously sent Group ID on that stream, or if its Object ID is less than or equal to a previously sent Object ID within a given group on that stream. </ins> When a stream begins with "STREAM_HEADER_GROUP", all objects on the stream belong to the track requested in the Subscribe message identified by "Subscribe ID" and the group indicated by "Group ID". <del> All objects on the stream have the same "Object Send Order". </del> <ins> All objects on the stream have the "Object Send Order" specified in the stream header. </ins> All Objects received on a stream opened with "STREAM_HEADER_GROUP" have an "Object Forwarding Preference" = "Group".

Related discussion:
text: This was previously part of . It allows an object to be sent in a datagram f it fits, and put on a stream if it doesn't.
Linking some feedback raised in the original PR that has not yet been addressed: URL URL
Looks like a great starting point to me.
Code change:
new one and send the "STREAM_HEADER_TRACK" if needed, then serialize the the following object fields. <ins> A sender MUST NOT send an Object on a stream if its Group ID is less than a previously sent Group ID on that stream, or if its Object ID is less than or equal to a previously sent Object ID within a given group on that stream. </ins> When a stream begins with "STREAM_HEADER_GROUP", all objects on the stream belong to the track requested in the Subscribe message identified by "Subscribe ID" and the group indicated by "Group ID". <del> All objects on the stream have the same "Object Send Order". </del> <ins> All objects on the stream have the "Object Send Order" specified in the stream header. </ins> All Objects received on a stream opened with "STREAM_HEADER_GROUP" have an "Object Forwarding Preference" = "Group".

Related discussion:
text: Update main to reflect the tx-mode branch after was merged.
Agreed, but I'm not sure there's any normative language there. Is this a case of writing a paragraph cautioning that such limits could cause issues?
Whoa, I've missed some PRs, but LGTMIndividual Review: There was some feedback on previous iterations about this PR lacking guidance when encountering flow control limits (eg: send as datagram, relay converts to stream, but is out of streams or flow control)
Code change:
Many of these same restrictions are shared by HTTP/2 H2 and HTTP/3 H3. <ins> Note that while some messages - CONNECT or upgrade requests in particular - can be represented using this format, doing so serves no purpose as these requests are used to affect protocol behavior, which this format cannot do without additional mechanisms. </ins> 7. The "message/bhttp" media type can be used to enclose a single HTTP

Related discussion:
text: What does it mean for a client to send, for example, a CONNECT request in the binary message. Is that permitted or prohibited?
I don't think that it needs to be prohibited. It's just not going to do anything that makes any sense. Worth a note perhaps.
I guess it could work if the thing you're delivering the binary message to actually actions the CONNECT, exchanging tunneled bytes would just look like content.
You would need somewhere for those bytes to go. A valid CONNECT request doesn't include a body. It's nonsensical basically.
Code change:
1. <del> Most if not all of the web pages processed by a web browser contain links to external resources that need to be fetched prior to rendering the documents.  Therefore, it is beneficial to send such links as early as possible in order to minimize the time spent until the browser becomes possible to render the document.  Link header of type "preload" (Preload) can be used to indicate such links within the response headers of an HTTP response. However, it is not always possible for an origin server to send a response immediately after receiving a request.  In fact, it is often the contrary.  There are many deployments in which an origin server needs to query a database before generating a response.  It is also not unusual for an origin server to delegate a request to an upstream HTTP server running at a distant location. </del> <ins> It is common for HTTP responses to contain links to external resources that need to be fetched prior to their use; for example, rendering HTML by a Web browser.  Having such links available to the client as early as possible helps to minimize perceived latency. The "preload" (Preload) link relation can be used to convey such links in the Link header field of an HTTP response.  However, it is not always possible for an origin server to generate a response header block immediately after receiving a request.  For example, the origin server might need to query a database before generating a response, or it might delegate a request to an upstream HTTP server running at a distant location. </ins> The dilemma here is that even though it is preferable for an origin server to send some headers as soon as it receives a request, it <del> cannot do so until the status code and the headers of the final HTTP response is determined. HTTP/2 (RFC7540) push can be used as a solution to the issue, but has its own limitations.  The resources that can be pushed using HTTP/2 are limited to those belonging to the same origin.  Also, it is impossible to send only the links of the resources using HTTP/2 push. Sending HTTP responses for every resource is an inefficient way of </del> <ins> cannot do so until the status code and the full headers of the final HTTP response are determined. HTTP/2 (RFC7540) server push can be used as a solution to this issue, but has its own limitations.  The responses that can be pushed using HTTP/2 are limited to those belonging to the same origin.  Also, it is impossible to send only the links using server push.  Finally, sending HTTP responses for every resource is an inefficient way of </ins> using bandwidth, especially when a caching server exists as an intermediary.

Related discussion:
text: ... for your consideration; feel free to take, discard, or do whatever else you like :)
Thank you so much for the improvements. This PR is a tremendous opportunity for me to improve my skills (both in terms of writing a specification and in terms of English).
Code change:
9.6.1. If the client and authorization server are using DPoP binding of <del> access tokens and/or authorization codes, then they SHOULD also require DPoP binding of the "auth_session" value as well. </del> <ins> access tokens and/or authorization codes, then the "auth_session" value SHOULD be protected by the DPoP binding as well.  The authorization server SHOULD bind the "auth_session" value to the DPoP public key.  If the authorization server is binding the "auth_session" value to the DPoP public key, it MUST check that the same DPoP public key is being used and MUST verify the DPoP proof to ensure the client controls the corresponding private key whenever the client includes the "auth_session" in an Authorization Challenge Request as described in challenge-request. </ins> DPoP binding of the "auth_session" value ensures that the context referenced by the "auth_session" cannot be stolen and reused by another device. <del> This specification defines an additional claim in the DPoP Proof JWT Syntax defined in Section 4.2 of RFC9449: </del> 9.6.2. This specification makes no requirements or assumptions on the

Related discussion:
text: Removed the need for the new ash claim by inverting the way in which binding works by putting responsibility for maintaining the binding on the authorization server (see issue ).
I do love "ash" as a claim name but (as DPoP co-author and a DE on the JWT Claims registry) I'd strongly suggest that the binding be done the other way around. Basically just say that the AS binds the authsession value to the the public key from the DPoP proof and checks the binding whenever the client sends the authsession. Binding that way is simpler (from the spec perspective anyway) and provides more protections. It's also how most of the binding in DPoP works ("ath" is kind of an outlier and provides somewhat questionable value). URL URL
Suggestion: also require a unique DPoP key per session to avoid risks around session binding.
Completed in
Looks good
Code change:
9.6.1. If the client and authorization server are using DPoP binding of <del> access tokens and/or authorization codes, then they SHOULD also require DPoP binding of the "auth_session" value as well. </del> <ins> access tokens and/or authorization codes, then the "auth_session" value SHOULD be protected by the DPoP binding as well.  The authorization server SHOULD bind the "auth_session" value to the DPoP public key.  If the authorization server is binding the "auth_session" value to the DPoP public key, it MUST check that the same DPoP public key is being used and MUST verify the DPoP proof to ensure the client controls the corresponding private key whenever the client includes the "auth_session" in an Authorization Challenge Request as described in challenge-request. </ins> DPoP binding of the "auth_session" value ensures that the context referenced by the "auth_session" cannot be stolen and reused by another device. <del> This specification defines an additional claim in the DPoP Proof JWT Syntax defined in Section 4.2 of RFC9449: </del> 9.6.2. This specification makes no requirements or assumptions on the

Related discussion:
text: Also, doing DPoP key binding of the needs the DPoP proof - so a client doing DPoP in this context really just should be sending the DPoP proof header.
Closing this as it was resolved in
looks okay to me (pending conflicts that need to be resolved)
Code change:
operations use cases, but it is also a requirement for the Digital Twin. <del> The following sections shows some example use case descriptions to initiate the discussion what type of info is needed to describe the use cases in the context of Digital Map.  The next version of the draft will include more info on these use cases, from the perspective of what is the value of the digital map for each use case and how the Digital Map API can be used.  This will also clarify if only read and if/when write interface is needed per use case. </del> <ins> The following sections includes some initial use case descriptions to initiate the discussion about what type of info is needed to describe the use cases in the context of Digital Map.  The next version of the draft will include more info on these use cases and more input from the operaotors, from the perspective of what the value of the digital map for each use case is and how the Digital Map API can be used. This will also clarify if only read and if/when write interface is needed per use case. </ins> 3.1.

Related discussion:
text: Addressed discussion on the nmop group for THREAD1, THREAD2 and THREAD3 as well as issues 1, 2, 3, 5, 6, 7 + some minor changes. 3 commits