jiebi/CodeConvo huggingface dataset:
Code change:
Fields (fields) that are located within a <del> are are referred to as "trailer fields" (or just "trailers", </del> <ins> are referred to as "trailer fields" (or just "trailers", </ins> colloquially).  Trailer fields can be useful for supplying message integrity checks, digital signatures, delivery metrics, or post- processing status information.

Related discussion:
text: For instance, I can always GET a URI (such as for prefetch/preload/indexing) and if the server does do something stupid with that request (such as deleting a resource, or adding something to a shopping basked), it's their problem. Re idempotenty: this makes it possible to repeat a request.
The text states that intermediaries are allowed to collapse "an ordered subsequence of Via header field list members into a single member", and they can only do so "if the entries have identical received-protocol values." So I read 2 rules: the order matter, i.e. if (A,B) collapses to C, (B,A) does not map to C (A,B) must have identical recived-protocol values I was wondering about any additional rules that the intermediaries have to follow in order to collapse the list into one: for example, is it ever expected for the intermediary to remember that this single member was this collapsed ordered sequence? Are they ever requested to un-collapse?
Order matters for the purpose of collapsing. If you have "D, E, F", and E has a different protcol than D or F, you can't collapse. If "A, B" can be collapsed, so can "B, A" (because they have the same protocol) We are not saying that, so there is no expectation that the collapsing can be undone.
Ok, so yes I understand - the idea of this text is to say: "this is the intent, BUT be aware that implementations might do something stupid and not comply with this intent." I guess what I got stuck with was "the client can't be held accountable", as it wasn't clear to me what would it mean for a client to be held accountable, as clients in general are not aware of what's the action on the server their request will result in.
This might require a separate issue. A field value containing more than one list element and including "*" is invalid, and the spec really doesn't say what that means. The intent of saying "interoperable" is (IMHO) to prevent people from assuming the different servers will do the same thing with it. I believe we should clarify that a value like that is invalid, and thust MUST NOT be sent. NAME , NAME ?
That refers to URL - I guess we should cite that? NAME ?
Code change:
Fields (fields) that are located within a <del> are are referred to as "trailer fields" (or just "trailers", </del> <ins> are referred to as "trailer fields" (or just "trailers", </ins> colloquially).  Trailer fields can be useful for supplying message integrity checks, digital signatures, delivery metrics, or post- processing status information.

Related discussion:
text: Edit: opened URL
On the other hand, people complain about the spec being too long already. I don't think we should add examples unless they are needed to make things easier to understand.
Ok! (As I said, these are so minor that they are definitely up to you. Same with references and terminology comments)
I believe the simplest possible fix would be to remove "to be used in references", making this: NAME ? Edit: -> URL
I think that we should probably convert this one (and similar) to MUST NOT -- there isn't any situation where we recommend this behaviour, as it has interoperability and security implications.
Not convinced at all. The "SHOULD NOT" requirement is new and was controversial already. There is code out there using GET with body (in controlled environments) which just works.
That's not HTTP; that's a private protocol.
Tell that Google :-) Anyway. This is a normative requierement and we are past WG LC. If you want to change it, this absolutely needs to be confirmed explicitly by the WG (and would deserve a seaparate issue).
Maybe "The process for determining whether access is granted is defined..."? Edit: -> URL
You mean generally, for the fields we define? I don't think that's true; they're defined for the semantics they specify. If a use isn't specified, it might be extended in the future, so we rarely prohibit such a use. Saying that they can be used with any method or status code would imply that they have meaning in each circumstance, and that's often not true.
authentication. This isn't important for interoperability, it's just a bad idea. Maybe 'The From header field is not intended or suitable for use as a means of access control or authentication.'?
FWIW, the requirement is from RFC 7231, and widely accepted (I guess), so I don't think we should change it.
For 4, proposed rewrite:
WRT -- I don't think I'd use the word "widely" in conjunction with this header field. Again, if we use SHOULD NOT, we should explain the qualification.
In the sense that it's an interoperability requirement on a sender (not a recipient), I agree.
"MUST NOT be generated" maybe?
MUST NOT be generated, because recipient behaviour is not interoperable.
Code change:
Fields (fields) that are located within a <del> are are referred to as "trailer fields" (or just "trailers", </del> <ins> are referred to as "trailer fields" (or just "trailers", </ins> colloquially).  Trailer fields can be useful for supplying message integrity checks, digital signatures, delivery metrics, or post- processing status information.

Related discussion:
text: URL already say "MUST NOT generate ABNF-invalid messages" in general. So maybe we don't want to repeat BCP14 terms here... -> URL
I've reviewed the most recent commits, think this can be closed now.
Thanks for addressing my comments. I checked the commits and your answers: I can see everything was addressed, either by changes or by answers clarifying what I found confusing, except for: the one which is now issue point 14: giving context around the "SHOULD NOT" for the 'From' header field. Note that I am not asking you to make any change (such as removing the BCP 14 text), but following what BCP 14 defines: it seems important that the reader understands, or at least gets a hint of what these reasons and particular circumstances are, in order to be able to understand the full implications. This is why I think it's important to clarify the context around the SHOULD / SHOULD NOT, and was also my comment for the GET requirement, but I see that that comment has now transformed in a bigger issue the wg needs to find consensus on.
I disagree. You are presuming that we know those particular circumstances, and that is almost always false when SHOULD is being used. When we have a detailed list of conditions, we use "MUST NOT unless ...". The SHOULD is literally saying that the reader needs to take care and understand the risk/benefit for their own context, not that we need to explain to them based on our own imagination. It is fine to suggest additional text to address a specific concern, but I personally think that this one is self-explanatory. If we added a general description about why auth parameters shouldn't be sent in fields that are not expected to be treated as auth parameters by every recipient, such as within a security consideration, then we could reference it here.
I don't think we should know all possible circumstances, but I presume we do have an inkling that implementations going against the RECOMMENDations exist, for whatever reason, right? As a reader, putting myself in a new implementer shoes, I personally would have found it useful to get that hint of what to consider, but if you think that this one is self-explanatory, I won't insist.
Code change:
Fields (fields) that are located within a <del> are are referred to as "trailer fields" (or just "trailers", </del> <ins> are referred to as "trailer fields" (or just "trailers", </ins> colloquially).  Trailer fields can be useful for supplying message integrity checks, digital signatures, delivery metrics, or post- processing status information.

Related discussion:
text: The type of sentence I was thinking about would be something like: (Just trying to explain myself here, again, feel free not to take this suggestion if you and the wg don't think it helps the reader)
Okay, I have added URL because I think we should explain it if it isn't obvious to others.
Thank you NAME !
Code change:
These latency bands were appropriate for streaming media, which was the target for I-D.draft-ietf-mops-streaming-opcons, but some <del> realtime media may have requirements that are significantly less than "ultra-low latency".  Within this document, we are also using </del> <ins> interactive media may have requirements that are significantly less than "ultra-low latency".  Within this document, we are also using </ins> <del> ull500 (less than 500 ms) ull100 (less than 100 ms) </del> <ins> Ull-50 (less than 50 ms) Ull-200 (less than 200 ms) </ins> Obviously, these last two latency bands are the shortened form of <del> "ultra-low latency - 500 ms" and "ultra-low-latency - 100 ms".  Also obviously, bikeshedding on better names is welcomed. </del> <ins> "ultra-low latency - 50 ms" and "ultra-low-latency - 200 ms". Perhaps less obviously, bikeshedding on better names and more useful values is welcomed. </ins> 3.

Related discussion:
text: It's likely that only NAME and I will care about this, but I think it matters :grin:
Code change:
Label: TBD <del> Value Type: Receipt / [+ Receipt] </del> <ins> Value Type: [+ Receipt] </ins> <del> Description: A COSE_Sign1 Countersign Receipt to be embedded in the unprotected header of the countersigned COSE_Sign1 message. </del> <ins> Description: One or more COSE_Sign1 Countersign Receipts to be embedded in the unprotected header of the countersigned COSE_Sign1 message. </ins> 9.1.1.2.

Related discussion:
text: Allowing both a receipt and an array of receipts as type is ambiguous here since the receipt is an array itself and not wrapped, so distinguishing the two cases wouldn't work. Having a single type also simplifies client code.
Code change:
3.7.1. <del> Firmware is ubiquitous in IoT devices (e.g., appliances, televisions, smart LED bulbs, HVAC, automobiles), runs at the highest privilege level possible, and is often the bedrock on which the security story of the devices it powers. Firmware is powerful.  It runs in the highest privilege level possible and is often the bedrock on which the security story of the devices it powers. 3.7.2. </del> <ins> Firmware is a critical component for successful execution of any constrained IoT device.  It is often the bedrock on which the security story of the devices it powers. </ins> Personal health monitoring devices, i.e., eHealth devices, are generally battery driven and offer health telemetry monitoring, such

Related discussion:
text: NAME the revisions seem to place greater emphasis on package managers, removing the original intent. The original intent was much broader and could be applied to a wide swath of software distribution, i.e. GitHub, app stores, and package manager repos.
Sure, we can broaden the scope. Not a problem!
We had a detail discussion about this between me and Henk. Basically, I was all for the support of going to depict a real world example for each of the situation. However, this makes the document excessively long and verbose. We should make a judgment as a team as to: Where should the Use Case document reside ? Some members feel within Arch. Document, some feel as a separate RFC. Given the number of scenarios, should we abstract it to generic use case or we depict a specific example, next to each of them ? Is too long a document (when a separate RFC) acceptable to the group ?
NAME NAME NAME I have redone the PR post our meeting today. Please have a look..
This has been resolved now!
great improvements
Code change:
Signed Statement Issuers rely on being discoverable and represented as the responsible parties for their registered Signed Statements via <del> Transparency Services in a believable manner.  Analogously, </del> <ins> Transparency Services in a believable manner.  The issuer of a Signed Statement should be authenticated and authorized according to the registration policy of the transparency service.  Analogously, </ins> Transparent Statement Consumers rely on verifiable trustworthiness assertions associated with Transparent Statements and their processing provenance in a believable manner.  If trust can be put <del> into the operations that record Signed Statements (i.e., a believable notarization function) in a secure, append-only Registry via online operations, the same trust can be put into a corresponding Receipt that is the resulting documentation of these online operations issued by the Transparency Services and that can be validated in offline operations. </del> <ins> into the operations that record Signed Statements in a secure, append-only log via online operations, the same trust can be put into the resulting transparent statement, issued by the Transparency Services and that can be validated in offline operations. </ins> The Transparency Services specified in this architecture can be implemented by various different types of services in various types

Related discussion:
text: NAME Incorporated Review Comments!
Thanks NAME lets see if we can agree on append-only log|registry today so we can adapt and merge.
For the sake of clarity, suggesting "append only log"
LGTM
Code change:
7. <del> In some applications or transport protocols, it is desirable to put an SD-JWT into an outer JWT container.  For example, an implementation may envelope multiple credentials and presentations, independent of their format, in a JWT to enable application-layer encryption during transport. For such use cases, the SD-JWT SHOULD be transported as a single string.  Key Binding MAY be achieved by signing the envelope JWT instead of including a separate Key Binding JWT in the SD-JWT. The following non-normative example shows an SD-JWT Presentation enveloped in a JWT: Here, the SD-JWT is shown as the value of an claim where represents the Issuer-signed JWT and represents a Disclosure.  The SD-JWT does not contain a Key Binding JWT as the outer container can be signed instead. Other specifications or profiles of this specification may define alternative formats for transporting an SD-JWT that envelope multiple such objects into one object and provide Key Binding using means other than the Key Binding JWT. 8. </del> This section describes an optional alternate format for SD-JWT using the JWS JSON Serialization from RFC7515. For both the General and Flattened JSON Serialization, the SD-JWT is represented as a JSON object according to Section 7.2 of RFC7515. <del> The disclosures (both for issuance and presentation) are included in the serialized JWS using the key </del> <ins> The disclosures (both for issuance and presentation) SHOULD be included in the serialized JWS using the member name </ins> at the top-level of the JSON object (the same level as the

Related discussion:
text: -Update JSON Serialization to remove the kb_jwt member and allow for the disclosures to be conveyed elsewhere -Expand the Enveloping SD-JWTs section to also discuss enveloping JSON serialized SD-JWTs -Swap Enveloping SD-JWTs and JSON Serialization sections Editor's Copy from this PR: URL URL
I think this also addresses
Code change:
The "next-protocol" parameter's value indicates the ALPN protocol identifier RFC7301 of the protocol used by the intermediary to <del> connect to the next hop.  This is only applicable when that connection was actually established. </del> <ins> connect to the next hop when obtaining this response. </ins> The value MUST be either an sf-token or sf-binary, representing a TLS Application-Layer Protocol Negotiation (ALPN) Protocol ID (see

Related discussion:
text: I noticed that parameters are generally defined in terms of what happened to generate this response, whether or not the next hop was actually contacted. The exception is , which says: I think it's potentially valuable for a response to indicate what protocol it was fetched over even if it comes from cache. The remedy would be to remove that statement and align this with the other parameters by talking about 'this response'. Probably also making that more prominent in . Thoughts, NAME
Thanks!
Code change:
Furthermore the hash algorithms MD2, MD4, MD5, RIPEMD-160, and SHA-1 revealed fundamental weaknesses and they MUST NOT be used. <del> 7.5. </del> <ins> 7.6. </ins> TBD

Related discussion:
text: Would like to go with salted hashes based approach, since there has been a lot of feedback that "simplicity (of salted hases approach) is a feature". However, acknowledging , adding a text to the security considerations explaining mechanisms that should be adopted to ensure that verifiers validate the claim values received in SD-JWT-R by calculating the hashes of those values and comparing them with the hashes in the SD-JWT.
Code change:
4.4. Conceptually, the sequence number space of TIPS views satisfy the <del> following requirements: First, for a specific client, it may expect to see the same sequence number for the same version, to avoid occasional disconnections.  Second, the coupling of sequence numbers should be minimized for ALTO resources monitored by multiple clients. </del> <ins> following requirements: First, a specific client may expect to see the same sequence number for the same version to avoid occasional disconnections.  Second, the coupling of sequence numbers should be minimized for ALTO resources monitored by multiple clients. </ins> <del> Thus, the sequence number space is constant for each TIPS view per </del> <ins> Thus, the sequence number space is constant for each TIPS view per- </ins> client but is independent across TIPS views.  Note that For the same TIPS resource queried by different clients, multiple TIPS views will be created, one for each client, whose sequence number spaces are independent. <del> Independence implies that the clients must not assume there is a </del> <ins> Independence implies that ALTO clients must not assume there is a </ins> consensus of how different versions map to sequence numbers but does not force the sequence numbers to be different.  See shared- tips-view for cases where an ALTO server may desire to use the

Related discussion:
text: Please add captions to all figures and call them in the text rather than "below" thing :-) Thanks.
Code change:
security scans of running software provide valid annotations on build integrity to ensure conformance <ins> 3.10. Software producers often have multiple and concurrent supported versions of a product.  The versions may represent major feature or compatibility differentiating releases (1.0, 2.0), or implementations for different Operating System Platforms and Architectures (Linux, Mac, Windows, AMD, ARM, x86, x64). For each release, the software producer must be capable of providing statements, unique to that version.  Producers may provide free patching to a specific version the consumer has purchased, while requiring upgrades to newer major releases.  Consumers need to know which updates are compatible with their environment.  Third parties that provide statements of quality need to know how to differentiate supported version bands, avoiding the recommendation to upgrade to an incompatible version. As versions age, and vulnerabilities are discovered, consumers need to know the newer version of a particular product.  Software producers implement versioning updates, however there are no standards for consumers and third parties to apply across software producers. Consumers and Producers want: a standard means to associate vulnerability information, statements of quality, statements of support and end of life (EOL) with a specific version of a product a standard means to identify a patched version, specific to their Operating System and Platform a standard means to differentiate major and minor version upgrades a standard means to provide concurrent versioned updates </ins>

Related discussion:
text: Provides baseline discussion for clarifying . See
Minor nits and there is no paragraph/subsection included in the proposed use case
Code change:
The designated expert(s) should ensure that the proposed algorithm has a public specification and is suitable for use as [TBD]. <del> 7.2.2. IANA might be asked to establish a registry of signature algorithm identifiers, named "Signature Algorithms", with the following registration procedures: TBD The "Signature Algorithms" registry initially consists of: The designated expert(s) should ensure that the proposed algorithm has a public specification and is suitable for use as a cryptographic signature algorithm. </del> 8.  References 8.1.  URIs

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:
The popularity of cross-device flows attracted the attention of attackers that exploit the unauthenticated channel between the <del> Initiating Device and Authorizing Device using techniques commonly </del> <ins> Initiating Device and Authorization Device using techniques commonly </ins> used in phishing attacks.  These Cross-Device Consent Phishing (CDCP) attacks allow attackers to obtain access and refresh tokens, rather than authentication credentials, resulting in access to resources

Related discussion:
text: The "Authorization Device" was sometimes referred to as "Authorizing Device".
NAME Looks good to me, please merge if you approve as well.
Agreed.
Code change:
Track Namespace: Identifies the track namespace in the ANNOUNCE message for which this response is provided. <del> 6.11. </del> <ins> 6.9. </ins> The receiver sends an "ANNOUNCE ERROR" control message for tracks that failed authorization.

Related discussion:
text: This PR adds support for subscribers to issue unsubscribe requests to express its interest in not receiving media for a given track. This reflects discussions from The high level call flow is
Thinking about it some more, an error code doesn't seem necessary. publisher -> subscriber should have an error code. subscriber -> publisher doesn't need an error code. Even with an error code, it would get lost in the deduplication process.
Individual reviewIt might be useful to have an error code, but I'm not sure. LGTM.We'll need to revisit using track name vs track ID for unsubscribe once we have an answer to , but for now, this LGTM.