jiebi/CodeConvo huggingface dataset:
Code change:
empty "valueString" are included with an empty string as the component value. <del> If a parameter name occurs multiple times in a request, all parameter values of that name MUST be included in separate signature input lines in the order in which the parameters occur in the target URI. </del> <ins> If a query parameter is named as a covered component but it does not occur in the query parameters, this MUST cause an error in the signature input string generation. </ins> For example for the following request: Indicating the "baz", "qux" and "param" named query parameters in would result in the following "@query-param" value: <ins> If a parameter name occurs multiple times in a request, all parameter values of that name MUST be included in separate signature input lines in the order in which the parameters occur in the target URI. Note that in some implementations, the order of parsed query parameters is not stable, and this situation could lead to unexpected results.  If multiple parameters are common within an application, it is RECOMMENDED to sign the entire query string using the "@query" component identifier defined in content-request-query. </ins> If used in a related-response, the "@query-params" component identifier refers to the associated component value of the request that triggered the response message being signed.

Related discussion:
text: I think to understand why that final private key works with the Java Web Crypto API but not the original one from which it was derived (which worked with Bouncy-Castle) we'd need the input of someone like NAME . With that public key replaced (in commit ) and a few others commits to get Continuous Integration to work, we have all the tests pass for Scala compiled to JavaScript Those running in the browser are a bit interleaved due to asynchronous execution, something that needs still to be fixed.
Looks good!
Code change:
The token-mediating backend pattern is more lightweight than the BFF pattern (See pattern-bff), since it does not require the proxying of <del> all requests to a resource server, which improves latency and significantly simplifies deployment.  From a security perspective, the token-mediating backend is less secure than a BFF, but still offers significant advantages over an OAuth client application running directly in the browser. </del> <ins> all requests and responses between the JavaScript application and the resource server.  From a security perspective, the token-mediating backend is less secure than a BFF, but still offers significant advantages over an OAuth client application running directly in the browser. </ins> If an attacker is able to execute malicious code within the JavaScript application, the application architecture is able to

Related discussion:
text: This PR offers an alternative to . Compared to PR it makes two changes: I removed the newly added text to avoid creating confusion between the responsibilities of a BFF. While it is technically possible to deploy a BFF as part of an API gateway, I believe this suggestion may create confusion for someone trying to grasp the pattern. An API Gateway is closely linked to an API, while a BFF is (in theory) closely linked to a frontend. Reworded the benefits of the Token Mediating Backend to more accurately represent the advantages/disadvantages of the pattern, as correctly suggested by this PR If this PR is merged, can be closed.
Code change:
encoding SHOULD be employed for the JSON object. Security considerations: See the Security Considerations section <del> of [[ this specification ]]. </del> <ins> of TBD. </ins> Interoperability considerations: n/a <del> Published specification: [[ this specification ]] </del> <ins> Published specification: TBD </ins> Applications that use this media type: TBD

Related discussion:
text: This PR addresses: URL Related issues: URL
Some additional details on the construction and use can be found here: URL I'm not including these in the PR, because I don't understand the security properties required by "SCITT Identifiers", but if the code I wrote covers the security properties, I am happy to do a follow up PR, after this one is merged.
LGTM for the consistency of CBOR structures
Code change:
accompany one another.  A common example would be tying together audio and video tracks. <del> 3.2.14. </del> <ins> 3.2.15. </ins> An integer specifying a group of tracks which are alternate versions of one-another.  Alternate tracks represent the same media content,

Related discussion:
text: We need the following Add Catalog Seq Number and explain how it is related to Parent Seq Num Make parent seq num independent of MoQT object number
Proposal is to add two fields: Catalog sequence number (CSN)- a required integer starting at 0 and monotonically increasing with each successive catalog update. Parent sequence number (PSN) - an optional reference pointing at a prior (not necessarily previous) catalog sequence number. If the PSN is absent, then the catalog is an independent catalog. If it is present, then the catalog represents a delta update. Having a sequence number independent of the transport sequencing allows catalogs to be distributed over moq-transport, or http or another transport and still be interpreted correctly.
Code change:
accompany one another.  A common example would be tying together audio and video tracks. <del> 3.2.14. </del> <ins> 3.2.15. </ins> An integer specifying a group of tracks which are alternate versions of one-another.  Alternate tracks represent the same media content,

Related discussion:
text: Add a new root object to hold inheritable track fields. Update all examples.
I am not a big fan of this approach. This led to all sort of problems with SDP Session Level attributes. My main concerns How do we ensure the field that goes in this are not of type that represent aggregated values for all the tracks. Things like BW is easy to fall in this trap What problem is it solving other than moving these to per track level. May be I am missing something here . open to learn more, Thanks
There are no aggregated fields currently defined. All track selection properties, such as 'Bitate" apply only to that track. If multiple tracks have the same bitrate value, then that bitrate value can be placed inside a SelectionProperties object which is placed inside the Common Track Fields object. This is not moving anything to a per track level. Rather, it is providing a clear location to place track properties which are intended to be inherited by all tracks. IN the future, we may wish to add fields to the root which are not intended to be inherited, something for which the prior design left no mechanism for accomplishing.
makes sense and understand. We want to careful and not end up adding aggregates . How about we rename it "Inherirted Fields" instead and be explicit about it
In the current design, any track fields such as selectionParams, initTrack, renderGroup, packaging etc can be added at the root level. This design does not promote extensibility as it prohibits adding future fields to the root that should not be interpreted as inheritable track fields. Proposal is to add a new root object called "commonTrackFields" to explicitly hold fields intended to be inherited by all tracks. Example:
Code change:
documented here are applicable to any use of the "TLS" Upgrade Token, but no change is required in RFC2817. <del> 5.3. </del> <ins> 5.2. </ins> RFC6455 says:

Related discussion:
text: This avoids having to determine whether is an actual existing standard or not. This is an alternative to
Merging for draft cutoff.
The lists an entry for HTTP/.\, and specifically identifies "2.0" as a possible version value, as instructed by . However, this flow seems to have been superseded by "Upgrade: h2c", which was introduced in RFC 7540 and deprecated in RFC 9113. I am not aware of any implementations of "Upgrade: HTTP/2.0" in clients or servers. I think we have two main options: Status Quo: Regard "HTTP/.\" as a mechanism that is formally defined but not implemented anywhere. Provide formal analysis of its security for completeness. Deprecation: Update RFC 9110 in this draft to remove the definition of this upgrade token. Mark "HTTP" as "obsolete" in the Upgrade Tokens Registry.
Moving discussion over to the issue, perhaps. Upgrading to TLS is a defined thing that gets used; I'm not clear that we need to deprecate that. Upgrading to future HTTP versions is a little more interesting. Certainly it's illegal to upgrade to or because upgrade isn't defined by those specifications. RFC 7540 defines a distinct token, RFC 9113 deprecates it, and RFC 9114 does not define an Upgrade path for obvious reasons. It certainly looks like we've decided not to use this mechanism for changing HTTP versions. Does that mean we should eliminate it? I'm not opposed, but I'm also not certain we need to go there.
Moving to TLS with upgrade (i.e., RFC 2817) is now so much of a niche thing that I think that deprecation would be wise. We've heard that it is still in use, but it's certainly not inoperable in quite the same way as other parts of the protocol. Either way, I think it would be better to write a separate document deprecating Upgrade (either completely or more narrowly) than to sneak it in here. This document can point out that it is unsafe in the ways in which it is unsafe, but it doesn't need to make the deeper cut to achieve that.
It seems clear that we don't want to deprecate in this document, so I've removed that text from . I've kept open to discuss the fate of .
Code change:
documented here are applicable to any use of the "TLS" Upgrade Token, but no change is required in RFC2817. <del> 5.3. </del> <ins> 5.2. </ins> RFC6455 says:

Related discussion:
text: The WG seems to believe that this mechanism is already deprecated, if it was ever defined at all, and the IANA registry entry is just misleading or incorrect.
The trouble is that exists in a sort of quantum superposition of standardized and deprecated, but that will collapse if we mention it in this draft in any way. The options I see are: Don't claim (as the current text does) to present an exhaustive analysis of the defined Upgrade Tokens, and silently ignore the registration of . Treat it as a live standard. Declare that it was already deprecated. Deprecate it.
I'd say deprecating isn't particularly useful or interesting, since that doesn't impact implementations. If we can't agree on which quantum state we are in and want to be in at the same time, then I'd leave the cat in the box. The more interesting question is: should implementations do something to protect against a dangerous ? For h2, the preface should protect against smuggling. Where do we stand for other versions, is there a risk we should warn implementers about?
My expectation is that implementations of do not exist, and never will, so I don't think it's very useful to provide guidance to them. There's a question of whether one can even speak about a "downward Upgrade" from HTTP/1.1 to 0.9-1.1. Assuming that is allowed, I think 1.0 and 1.1 are safe, if we assume that the HTTP-Version line is sent/repeated at this point. (Does Upgrade: HTTP create a new HTTP connection or re-version the existing one???) They both start with "HTTP/1", which is not a valid method name due to the "/". HTTP/0.9 is possibly more interesting since it does not send an HTTP-Version line. I don't see a way for the server to figure out whether the client is speaking HTTP/1.1 (after the rejected upgrade) or HTTP/0.9 (optimistically). However, I don't think this poses a security threat, so long as the attacker-controlled data is the same in HTTP/1.1 as it is in HTTP/0.9.
Code change:
documented here are applicable to any use of the "TLS" Upgrade Token, but no change is required in RFC2817. <del> 5.3. </del> <ins> 5.2. </ins> RFC6455 says:

Related discussion:
text: There could possibly be a problem if the client, believing it is speaking HTTP/0.9, allows untrusted code to manipulate headers that were not special in HTTP/0.9 but are special in HTTP/1.1 (e.g. Content-Length, Transfer-Encoding). But as I said, this strikes me as counting angels on the head of a pin. "Upgrade: HTTP/0.9" is just not a thing, and we should all agree on that and move on.
I totally agree with you. I was more thinking about guidance for intermediaries that support other Upgrades (e.g., WebSocket) for what they should do if they encounter unknown/unexpected upgrade tokens like these. If there is no such guidance, than we can just go back to pretending that doesn't exist
HTTP intermediaries can't really do anything with unrecognized Upgrade tokens in HTTP/1.1. (Not even the useful thing, which would be to convert them to/from for Extended CONNECT.)
Code change:
Abstract <del> This document defines an HTTP Proxy-Status Parameter that contains a list of aliases and canonical names received over DNS when establishing a connection to the next hop. </del> <ins> This document defines the "next-hop-aliases" HTTP Proxy-Status Parameter.  This parameter carries the list of aliases and canonical names a proxy received during DNS resolution as part establishing a connection to the next hop. </ins> 1.

Related discussion:
text: think its a case of s/an/and
The abstract says is it really , is it some other phrasing a little more technically correct?
LGTM thanks
Code change:
6.4. <del> Trusted input for receipt verification: the identity and the public signature-verification key of the transparency service. These may be included in the verifier's trusted configuration, or determined by a trusted policy. Verification steps: Verify receipt (see I-D.birkholz-scitt-receipts). Verify issuer signature. Freshness/revocation? Validate format of the envelope contents. Once verified, the claims together with their authenticated issuer and transparent ledger identities can be used as input to an authorization policy. </del> <ins> This section provides additional implementation considerations, the high-level validation algorithm is described in validation, with the ledger-specific details of checking receipts are covered in I- D.birkholz-scitt-receipts. Before checking a claim, the verifier must be configured with one or more identities of trusted transparency services.  If more than one service is configured, the verifier MUST return which service the claim is registered on. In some scenarios, the verifier already expects a specific issuer and feed for the claim, while in other cases they are not known in advance and can be an output of validation.  Verifiers SHOULD offer a configuration to decide if the issuer's signature should be locally verified (which may require a DID resolution, and may fail if the manifest is not available or if the key is revoked), or if it should trust the validation done by the TS during registration. Some verifiers MAY decide to locally re-apply some or all of the registration policies if they have limited trust in the TS.  In addition, verifiers MAY apply arbitrary validation policies after the signature and receipt have been checked.  Such policies may use as input all information in the envelope, the receipt, and the payload, as well as any local state. Verifiers SHOULD offer options to store or share receipts in case they are needed to audit the TS in case of a dispute. </ins> 7.

Related discussion:
text: NAME added security considerations and architecture picture
Thanks for the diagram, the sec-sec and all the other additional polish! I thought about tinkering with the diagram, but am in doubt that I'll improve it significantly. LGTM!
Code change:
The "Width" request header field is a number that indicates the desired resource width in physical px (i.e. intrinsic size of an image).  The provided physical px value is a number rounded to the <del> largest smallest following integer (i.e. ceiling value). </del> <ins> smallest following integer (i.e. ceiling value). </ins> If the desired resource width is not known at the time of the request or the resource does not have a display width, the Width header field

Related discussion:
text: WIP.
NAME NAME quick once over before I merge?
NAME thanks, updated, squashed.. merging.
:
: The and rules are not used in the document. The rule is not used in the document, unless you accept . The rule is not used in the document, but I think it can be useful to clarify the definition of , i.e.:
I agree that using "field-name" over there makes this a bit clearer.
Addressed in: URL
Code change:
Track Alias: Identifies the Track Namespace and Track Name as defined in message-subscribe-req. <del> The Track Namespace and Track Name identified by the Track Alias is different from the one specified in the subscription identified by </del> <ins> If the Track Namespace and Track Name identified by the Track Alias are different from those specified in the subscription identified by </ins> Subscribe ID, the receiver MUST close the session with a Protocol Violation. Other fields: As described in canonical-object-fields. <ins> An "OBJECT_PREFER_DATAGRAM" message carries a single object in a datagram or a stream.  There is no explicit length of the payload; it is determined by the length of the datagram or stream.  If this message appears on a stream, it MUST be the only message on a unidirectional stream. An Object received in an "OBJECT_PREFER_DATAGRAM" message has an "Object Forwarding Preference" = "Datagram". To send an Object with "Object Forwarding Preference" = "Datagram", determine the length of the fields and payload, and compare the length with the maximum datagram size of the session.  If the object size is less than or equal maximum datagram size, send the serialized data as a datagram.  Otherwise, open a stream, send the serialized data and terminate the stream.  An implementation SHOULD NOT send an Object with "Object Forwarding Preference" = "Datagram" on a stream if it is possible to send it as a datagram. </ins> 6.3.3. When multiple objects are sent on a stream, the stream begins with a

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:
preference, the stub router SHOULD deprecate the prefix it is advertising. <del> 6.1. </del> <ins> 5.3.1. </ins> Stub networks are defined to be IPv6-only because it would be difficult to implement a stub network using IPv4 technology.

Related discussion:
text: … AIL change situations
Section 5.2.3 defines the mandatory DHCPv6-PD client role for the stub router. However, there are no details here what should trigger the stub router to renew/rebind the prefix lease. A reference to RFC 8415 should be added (as it contains some requirements on this topic). See section 18.2.12. Refreshing Configuration Information of RFC 8415. Do we define the SHOULD requirements of 18.2.12 about detecting a new network (new AIL) as mandatory for the stub router, or not? (If not: has consequences for wider IPv6 connectivity in such new-AIL cases) And what about the SHOULD requirement that involves "if the client detects a significant change regarding the prefixes available on the link (when new prefixes are added or existing prefixes are deprecated), as this may indicate a configuration change. " -> can we specify this better? What are the significant changes in our case? And how to do this detection? (e.g. monitor RAs?)
For this issue, we could reference the improved text in URL instead of RFC 8415. This text should be sufficient detail that stub router implementers know what to do. (Or at least, the DHC WG thinks it is enough for DHCPv6 client implementers to know what to do :-) ) PR with this pointer text is still needed.
Code change:
manipulation of the HTTP/2 priority tree.  Extensible priorities does not use stream dependencies, which mitigates this vulnerability. <del> TBD: depending on the outcome of reprioritization discussions, following paragraphs may change or be removed. </del> HTTP2, Section 5.3.4 describes a scenario where closure of streams in the priority tree could cause suboptimal prioritization.  To avoid this, HTTP2 states that "an endpoint SHOULD retain stream

Related discussion:
text: We're keeing reprioritization, no need for this TBD any longer.
Thank you for noticing it.
Code change:
12.3. <del> This memo updates the "MD5" digest algorithm in the HTTP Digest </del> <ins> This memo updates the "MD5" digest-algorithm in the HTTP Digest </ins> Algorithm Values [5] registry: Digest Algorithm: MD5

Related discussion:
text: is preliminary to Consistently use instead of . In case we need to further focus on the value, we can say or . Looking at "content-coding" vs "content coding" in URL I think that this choice makes the document more readable.
Code change:
7. <del> : This topic is still under discussion, see issue 79 [2] </del> <ins> : This topic is still under discussion, see issue 79 [1] </ins> Multiple, independently-operated Transparency Services can help secure distributed supply chains, without the need for a single,

Related discussion:
text: Adjustments regarding registration policies.
NAME I have made significant changes since your last review, including cutting out a lot of redundant text, and shuffling sections and section headers while eliminating the redundancy. I am dismissing your approval based on that, please give this another review.
Apologies for the scope creep of this PR ("massive"). This is all intended to be presentable on Monday.
NAME and NAME : i shall review it later today!
Subject to addressing the issues opened by this PR: This PR can be taken forward!The biggest issue now that x5t is required is that the issuer for x509-signed claims is not specified. This needs to be solved before we can merge this
Code change:
Specification document(s): accept-ch of this document Related information: for Client Hints <del> 4.2. </del> <ins> 5.2. </ins> Header field name: Accept-CH-Lifetime Applicable protocol: HTTP

Related discussion:
text: NAME - can you take a look and see if that clarifies things?
This seems helpful given what's currently in the spec. However, I think some of the material I was talking about when I filed is no longer there. But I suspect that material may now be in other specs, and could perhaps still gain from being clarified at its current location.
I've been reading Client Hints (both and the ), and I'm having a little trouble understanding how things fit together in terms of which header fields are sent when and lead to what. My confusion started when I looked at the section and noticed (to my surprise) that was being registered as both a request header field and a response header field (when, having read the spec quickly, I was expecting it to be only a response header field, and wasn't sure what it would mean as a request header field). Then I looked back over the spec, and noticed that section 2 of the spec is called but that the entirety of the section appears (I think) to be about response header fields. I think it would help the spec be easier to understand if it: more carefully distinguished between request header fields and response header fields, and more clearly explained what the request header field is.
lgtm, thank you!