jiebi/CodeConvo huggingface dataset:
Code change:
attribute-name of "Path", and the cookie's path is "/". If the cookie store contains a cookie with the same name, domain, <del> and path as the newly-created cookie: </del> <ins> host-only-flag, and path as the newly-created cookie: </ins> Let old-cookie be the existing cookie with the same name, <del> domain, and path as the newly-created cookie.  (Notice that this algorithm maintains the invariant that there is at most one such cookie.) </del> <ins> domain, host-only-flag, and path as the newly-created cookie. (Notice that this algorithm maintains the invariant that there is at most one such cookie.) </ins> If the newly-created cookie was received from a "non-HTTP" API and the old-cookie's http-only-flag is true, abort these steps

Related discussion:
text: Closes URL NAME mind taking a look?
(NAME would you mind adding NAME to the repo as a collaborator so I can ask him to review via the GitHub tool? :) )
Ping.
Invite was sent a while back. Still listed as "pending."
It is an internal flag, but I don't think the PR needs additional documentation. The change we're making is in the middle of an algorithm, and is basically a variable that was set earlier in the process. I think folks reading the document will understand that. :)
Thanks for the review! I'll merge this, and look forward to your PR adding yourself as an editor.
RFC 6265 section 5.3 defines a cookie by the name, domain, and path. However, given these two headers in a response from a request to URL Set-Cookie: mycookie=nothostonly; URL Set-Cookie: mycookie=hostonly Most browsers will have two cookies since they include host-only-flag in their definition of a unique cookie. I'd like to update section 4.1.2 and 5.3 to reflect the behavior of modern browsers with regards to host-only-flag.
Discussed in Berlin; seems reasonable.
I probably need to read more of the context but would it be useful to point out that this is an internal flag for the user agent? It is, right? Inferred from whether the setting of the cookie included the domain or not.
Code change:
Track Alias: A session specific identifier for the track. Messages that reference a track, such as OBJECT (message-object), reference this Track Alias instead of the Track Name and Track <del> Namespace to reduce overhead.  If the Track Alias is already in use, the publisher MUST close the session with a Duplicate Track Alias error (session-termination). </del> <ins> Namespace to reduce overhead.  If the Track Alias is already being used for a different track, the publisher MUST close the session with a Duplicate Track Alias error (session-termination). </ins> Track Namespace: Identifies the namespace of the track as defined in (track-name).

Related discussion:
text: Small editorial clarification on duplicate track alias for subscriptions that addresses aspects of
As I read the draft, is the distinguisher of a given subscription. is made unique for a subscription state by indicating "If the Track Alias is already in use, the publisher MUST close the session with a Duplicate Track Alias error." The is mentioned as "A session specific identifier for the track.". It is initially set by the subscriber, where the publisher MAY reject... likely not if it wants to avoid long subscribe times. The draft does not indicate that the track alias is a hash of track or not. If the client implementation uses a sequence ID for both subscribe ID and track alias, then it could result in duplicate subscribes that would result in the relay building state, propagating the subscribe toward the publisher to solicit a response of OK/ERROR. In some implementations that support headless publishers, the relay would send a subscribe OK immediately. The edge relay that has the connection to the publisher performs state compression of subscribes, but that's only at the level per the draft. In this case, the track alias is different, resulting in a new subscribe (duplicate when looking at the ) being created to the publisher. The publisher receives the subscribe with a new and and starts to publish data objects using the and that match internally the track . If one or more clients do this repeatedly, it would result in all relays and the actual publisher itself sending duplicate data that matches . Below diagram illustrates the above. I'm sure there are many reasonable fixes for this... below are a few. This would change the verbiage of duplicate track detection to perform duplication check on and instead of only on track alias. The state machine for subscribe SHOULD change to move from TO . This simplifies the state machine by reducing the complexity in: detection and elimination of duplicate subscribes eliminating the challenges with having to deal with trial and error responses A hash of namespace and name would allow for the duplicate track detection to work per draft, but... Track alias has a max value of 62 bits. Collisions are the largest pitfall for using a hash of two values. Registry/directory service could act as gatekeeper of track aliases. While this would work, it introduces another micro service for a simple pub/sub, which isn't great. It will also slow the subscribe process down. Many other issues will likely arise with this approach.
Code change:
Track Alias: A session specific identifier for the track. Messages that reference a track, such as OBJECT (message-object), reference this Track Alias instead of the Track Name and Track <del> Namespace to reduce overhead.  If the Track Alias is already in use, the publisher MUST close the session with a Duplicate Track Alias error (session-termination). </del> <ins> Namespace to reduce overhead.  If the Track Alias is already being used for a different track, the publisher MUST close the session with a Duplicate Track Alias error (session-termination). </ins> Track Namespace: Identifies the namespace of the track as defined in (track-name).

Related discussion:
text: I don't understand duplicate subscribes issue here ? can you please elaborate .
If a subscriber sends 2 subscriptions for the same track to a publisher ( ignoring relays for a bit here and also ignoring any form if Ids ), what should be the expected behavior of the publisher ? There are few options Publisher sends 2 copies of the objects (wherever they overlap) Publisher rejects the second subscribe since it is in the same connection Publisher sends only 1 copy of the overlapping objects What is in draft today allows for 1.
Clarification on relay vs publisher needs to be distinct here. When discussing this topic, we need to be distinct on is the request for a range of objects (aka fetch operation where there is a start and finish?) or subscribe to live stream where there is no known end? Some of the challenges here are introduced with the MOQT decision to overload to support both fetch operation and subscribe to live stream, possibility starting at X. In the case of fetch operation, subscribes do not get forwarded to original publisher or to other relays, they are instead immediately fulfilled by the first hop relay, which may pull the data from some distributed/localized cache. It is totally acceptable that fetch based subscribes (aka filter type 0x4), can be in duplicate... although I suspect that is a mistake/error on the client side to request at the same time overlapping/exact same data. Regardless, it's not a big deal for the relay to satisfy this repeated request over the same data at the exact same time, but there needs to be some level of rate limits established to mitigate DoS. While MOQT doesn't need to define the limits, it does need to support error responses that the limit has exceeded. In the case of live stream, IMO it's 100% mistake for any client to ask for the same live stream twice via the same QUIC connection. While talking with NAME , he mentioned a possible use-case where there are two or more displays that you want to display the same content to. If the display has IP connectivity, it should be reasonable that the display would have connected and subscribed to the content, hence moot. In the case where the display does not have IP connectivity, a HUB device could be used that does have IP to act as the MOQT client to receive the data content.
Code change:
Track Alias: A session specific identifier for the track. Messages that reference a track, such as OBJECT (message-object), reference this Track Alias instead of the Track Name and Track <del> Namespace to reduce overhead.  If the Track Alias is already in use, the publisher MUST close the session with a Duplicate Track Alias error (session-termination). </del> <ins> Namespace to reduce overhead.  If the Track Alias is already being used for a different track, the publisher MUST close the session with a Duplicate Track Alias error (session-termination). </ins> Track Namespace: Identifies the namespace of the track as defined in (track-name).

Related discussion:
text: IMO, it does not make sense that anyone would want duplicate live feeds of the same data via the same QUIC connection. Instead, if the HUB device has multiple displays that are not IP connected and cannot make MOQT connections themselves, they likely have some other method to mirror content, such as an HDMI splitter. I'm interest in hearing the use-cases that require MOQT to directly support and require relays to support duplication of live streams to the same QUIC connection. Per discussion with NAME , the relay peering would never duplicate the live feeds. It would de-dup all these requests using the track , regardless of how many track aliases were used by a client subscribe. The original publisher would realize this aggregation/de-duplication. In other words, each subscribe from the same QUIC connection or from multiple QUIC connections (in theory different clients) would be grouped together by the relay using the . Each of the and values together represent a feed. In this sense, only or is needed for this process, not both when considering live feeds. Again, fetch is different and is distinguished not only by , , but also by start and end ranges. I'm interesting in hearing the use-cases of why MOQT requires of the relay to support duplicate fetch requests for the exact same ranges at the same time when the other hasn't finished yet. Seems like it would make sense that if the same QUIC connection (aka client endpoint) request range X - Y and while still sending X - Y, it requests it again, that it would cancel the previous and start over. Add some text around that endpoint to relay can establish duplicate live streams by using different track aliases for the same namespace/name. The relay or original publisher MAY implement rate limits on the number of active subscribes for the same namespace+name. The relay and/or original publisher may implement different rate limits based on FITLER TYPE. For example, filter type 04 may allow a maximum of 10 active subscribes for the same namespace+name, while filter types less than 4 that involve live stream feeds is restricted to 1.
The status quo of having both needs to be fixed at some point, see
Does this mean we close the complete quic session? Can we just reject the subscribe?
Code change:
Track Alias: A session specific identifier for the track. Messages that reference a track, such as OBJECT (message-object), reference this Track Alias instead of the Track Name and Track <del> Namespace to reduce overhead.  If the Track Alias is already in use, the publisher MUST close the session with a Duplicate Track Alias error (session-termination). </del> <ins> Namespace to reduce overhead.  If the Track Alias is already being used for a different track, the publisher MUST close the session with a Duplicate Track Alias error (session-termination). </ins> Track Namespace: Identifies the namespace of the track as defined in (track-name).

Related discussion:
text: Pulls in some text from and attempts to convey the conclusions of the Seattle interim. Adds Subscribe Parameters to SUBSCRIBEOK to allow this parameter to be optional in SUBSCRIBEOK.
LGTM
Code change:
4.3. For transporting the SVC together with the SD-JWT from the issuer to <del> the holder, the SVC is base64ur-encoded and appended to the SD-JWT using </del> <ins> the holder, the SVC is base64url-encoded and appended to the SD-JWT using a period character </ins> as the separator.  For Example 1, the combined format looks as follows:

Related discussion:
text: Some minor edits: consistency of hyphenation in base64url-encode(d) use transaction instead of use case in one place because selective might be needed or not within one use case, depending on the interaction with RP explicitly called out period character to avoid misinterpreting as missing word some typos
changed six . separated to four per Christian's separate comment
What did I miss? The presentation should be six dot separated elements. Three for the SD-JWT, three for the SD-JWT-R.
Why would you need to merge both? I don't understand the proposed flow between issuer, holder, and verifier; perhaps a data flow section would help. I would think the holder gets a 3+1 part JWS with SVC (which can be -concatenated). Then all you need to present to a verifier is the same data, along with some user proof key signature if the JWT is bound to a user key (for which a property is added in the SD-JWT-R, if I understood correctly; more details would be helpful here).
creating a separate issue on six vs four period separated elements to merge this editorial PR
LGTM
Code change:
WWW-Authenticate describes the use of "WWW-Authenticate" by protected resources to dynamically inform clients of the URL of their protected resource metadata.  This use of "WWW-Authenticate" can indicate that <del> the protected resource metadata MAY have changed. </del> <ins> the protected resource metadata may have changed. </ins> 1.1.

Related discussion:
text: from review comments from John Scudder
Please also add John Scudder to the acknowledgements.
Code change:
10.1. <del> A client sends request header fields to provide more information about the request context, make the request conditional based on the target resource state, suggest preferred formats for the response, supply authentication credentials, or modify the expected request processing.  These fields act as request modifiers, similar to the parameters on a programming language method invocation. </del> The request header fields below provide additional information about the request context, including information about the user, user agent, and resource behind the request.

Related discussion:
text: to be removed ... it was just leftover from the old org. Also, we should call it Request Context Fields.
Code change:
The interoperability guaranteed by the Transparency Services is enabled via core components (architectural constituents).  Many of the data elements processed by the core components are based on the <del> Concise Signing and Encryption (COSE) standard specified in RFC9052, </del> <ins> CBOR Signing and Encryption (COSE) standard specified in RFC9052, </ins> which is used to produce Signed Statements about Artifacts and to build and maintain a Merkle tree that functions as an Append-only Log for corresponding Signed Statements.

Related discussion:
text: LGTM, Thanks, NAME the stakeholders to consumers looks like a great change. I don't know if we'd keep both, or replace. I'll merge this to keep moving forward. Also, thanks for the catch on CBOR
Code change:
Because refresh tokens are typically long-lasting credentials used to request additional access tokens, the refresh token is bound to the <del> client to which it was issued.  Confidential or credentialed clients MUST authenticate with the authorization server as described in token-endpoint-client-authentication. </del> <ins> client to which it was issued.  Confidential clients MUST authenticate with the authorization server as described in token- endpoint-client-authentication. </ins> For example, the client makes the following HTTP request using transport-layer security (with extra line breaks for display purposes

Related discussion:
text: OAuth 2 gives a clear definition of public clients, which is where OAuth 2.1 says isn't one of the forms / attributes that could be referred to as credentials? Public clients do have them, they didn't go away, right? ... while they don't have clientsecret of course.
A is not a credential, it is an identifier, and it is always public.
Code change:
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. <del> 1.2. </del> <ins> 2. </ins> The ORIGIN HTTP/2 frame (RFC7540, Section 4) indicates what origin(s) RFC6454 the sender considers this connection authoritative for (in

Related discussion:
text: Putting the meat of the document in Section 1.2 was a bit odd. Also, the fields descriptions were glommed together.
Weird; didn't happen on local copies.
Code change:
Abstract <del> This document defines HTTP extension header fields that allow a TLS </del> <ins> This document describes HTTP extension header fields that allow a TLS </ins> terminating reverse proxy to convey the client certificate information of a mutually-authenticated TLS connection to the origin server in a common and predictable manner.

Related discussion:
text: and use "describes" rather than "standardize" to better align w/ the Informational intended status
As Yoda might say, do or do not. We can lose the aspiration here and be assertive about the document consensus progress.
I have a tendency towards that kind of demure writing. But you and Yoda are right. Will change.
LGTM, too.LGTM
Code change:
frame toward the flow control window, if the receiver does not, the flow control window at sender and receiver can become different. <ins> A WINDOW_UPDATE frame with a length other than 4 octets MUST be treated as a ConnectionErrorHandler of type . </ins> 6.9.1. Flow control in HTTP/2 is implemented using a window kept by each

Related discussion:
text: If an http2 implementation receives a frame with an unexpectedly large size, what should it do? As one example, a WINDOW_UPDATE should be 4 bytes. Or should it be at least 4 bytes? The Extending HTTP/2 notes at URL aren't clear about whether an unexpectedly long frame is okay. The closest I can find is: "Implementations MUST ignore unknown or unsupported values in all extensible protocol elements. " But I can't find a definition of an "extensible protocol element". It seems that the spirit of Section 5.5 would be to permit overly long frames.
I forgot to mention: there is FRAMESIZEERROR, but it only says: "If a frame size exceeds any defined limit, or is too small to contain mandatory frame data, the endpoint MUST send a FRAMESIZEERROR error." But only PING and SETTINGS mention it or a limit. What is the intended behavior for PRIORITY, RSTSTREAM and WINDOWUPDATE?
Code change:
phishing resistant authentication mechanism, which may in itself negate the need for a cross-device flow. <del> Starting with an authenticated flow does not prevent the attacks described in Example B5: Illicit Network Join [6] and Example B7: Illicit Session Transfer [7] and it is RECOMMENDED that additional mitigations described in this document is used if the cross-device flows are used in scenarios such as Example A5: Add a device to a network [8] and Example A7: Transfer a session [9]. </del> <ins> Authenticating on the Consumption Device before starting a cross- device flow does not prevent the attacks described in Example B5: Illicit Network Join [6] and Example B7: Illicit Session Transfer [7] and it is RECOMMENDED that additional mitigations described in this document is used if the cross-device flows are used in scenarios such as Example A5: Add a device to a network [8] and Example A7: Transfer a session [9]. </ins> 5.1.16.

Related discussion:
text: Alternative name for authenticated flow (see )
Can we find a better name for the "Authenticated Flow" mitigation?
Additional authentication on consumption device Initial authentication on consumption device Authenticate before initiating cross-device flow. Authenticate on consumption device before initiating cross-device flow. Cross-Device Flow with previous authentication Authenticate before initiating cross-device flow.
Thanks, approved with minor editorial changes
Code change:
credentials are displayed. This section defines Type Metadata that can be associated with a type <del> of a SD-JWT VC, as well as a method for retrieving the Type Metadata </del> <ins> of an SD-JWT VC, as well as a method for retrieving the Type Metadata </ins> and processing rules.  This Type Metadata is intended to be used, among other things, for the following purposes:

Related discussion:
text: Remove the requirement to insert a .well-known part for vct URLs , ,
Dr. Fett, PhD: >Gentlemen, Some feedback I received (on top of the comments we already got in the issuers) makes me second-guess the choice to use a .well-known URL for the type metadata documents. In fact, RFC 5785 tells us that .well-known is mainly to be used for site-wide information or information about a specific host. that it will be used to make site-wide policy information and other metadata available directly (if sufficiently concise), or provide references to other URIs that provide such metadata. Brian Campbell, B.A.: >That feedback seems not wrong to me. We've got probably a lot of somewhat questionable uses of .well-known but type metadata is maybe less well suited than most. And less needed. >It could just point to the json document. Or we make up some convention. Or something with uri templates.
Relevant related issues: , ,
I believe that lifting the restriction is not preventing the use of .well-known; IMO there are two approaches provide the full link signal that the metadata is under the well-known However, metadata owner must be aware of the responsibility to take care of the versioning. As mentioned in , should there be a requirement to either use hash links or protect the remote content via vct#digest? Dr. Horvat, PhD
Maybe I'm missing something, but the change in PR should mostly solve this, I think. It now requires to provide the full URL to the metadata. (If someone wants to provide it under .well-known, that is their choice, but doesn't influence the requester at all). For versioning I filed a . Not sure about making #digest mandatory, but we should also discuss this separately.
digest mandatory, but we should also discuss this separately. -> if it's an external resource, it should be defined how it is protected
URL Is defining that if vct is an https:// it should check the metadata under the well known (at least the 2nd part of the text reads like this: Many registries are, and will be accessible via URLs, hence the metadata type is expressed via an URL; Adding or maintaining a .well-known might not fit in the existing API designs.