jiebi/CodeConvo huggingface dataset:
Code change:
3.2.4. <ins> An object holding a collection of Track Fields (objects with a location of TF or TFC in table 1) which are to be inherited by all tracks.  A field defined at the Track object level always supercedes any value inherited from the Common Track Fields object. 3.2.5. </ins> An array of track objects trackobject.  If the 'tracks' field is present then the 'catalog' field MUST NOT be present. <del> 3.2.5. </del> <ins> 3.2.6. </ins> An array of catalog objects catalogobject.  If the 'catalogs' field is present then the 'tracks' field MUST NOT be present.  A catalog MUST NOT list itself in the catalog array. <del> 3.2.6. </del> <ins> 3.2.7. </ins> A catalog object is a collection of fields whose location is <del> specified as 'RC', 'TC' or 'RTC' in Table 1. </del> <ins> specified as 'RC' or 'TFC' in Table 1. </ins> <del> 3.2.7. </del> <ins> 3.2.8. </ins> A track object is a collection of fields whose location is specified <del> as 'RT', 'TC' or 'RTC' in Table 1. </del> <ins> as 'TFC', 'TF' or 'T' in Table 1. </ins> <del> 3.2.8. </del> <ins> 3.2.9. </ins> The name space under which the track name is defined.  See section 2.3 of MoQTransport.  If the track namespace is declared in the root

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:
exporter is used to generate a 32-byte key which is then used as a nonce. <ins> Because the TLS keying material exporter is only secure for authentication when it is uniquely bound to the TLS session RFC7627, the Signature and HMAC authentication schemes require either one of the following properties: The TLS version in use is greater or equal to 1.3 TLS. The TLS version in use is greater or equal to 1.2 and the Extended Master Secret extension RFC7627 has been negotiated. Clients MUST NOT use the Signature and HMAC authentication schemes on connections that do not meet one of the two properties above.  If a server receives a request that uses these authentication schemes on a connection that meets neither of the above properties, the server MUST treat the request as malformed. </ins> 3. The "Unprompted-Authentication" header field allows a user agent to

Related discussion:
text: Add requirement for unprompted auth to use TLS 1.2 with extended master secret or later. Fixes httpwg/http-extensions
Please mark this PR as fixing the corresponding issue
From Ilari Liusvaara on the :
Code change:
verification key for the Issuer-signed JWT as defined in issuer- signed-jwt-verification-key-validation. <ins> If Schema Type Metadata is provided, a recipient MUST validate the JSON Schema as defined in schema-type-metadata. </ins> If there are no selectively disclosable claims, there is no need to process the

Related discussion:
text: This PR includes the following: [x] Add schema type metadata [x] Add full schema type metadata examples [x] Describe base document for schema validation [x] Minor editorial fixes [x] Moved type metadata retrieval section for readability purposes [x] ~IANA considerations for , and ~ See preview here: URL Fixes URL
NAME NAME Do you think it makes sense to describe the base document for schema type metadata validation? For example, a verifier receiving an SD-JWT VC with Disclosures won't be able to validate the JSON schema against it before transforming the entire SD-JWT VC with Disclosures to expanded JSON document first.
NAME NAME Should we restrict schema to specific JSON schema versions?
I'm honestly not familiar with the intricacies of JSON schema. Is/are there a stable standard version(s) that can be referenced from a prospective RFC? The current content of the PR seems to have some normative statements but no reference. I'd think that's kind of a prerequisite to discussing version restrictions/requirements. A few minutes of looking around and I found this https://json-URL which at least suggests it's a bit messy. Any idea if/how other actual standards documents utilize JSON schema?
Well, statements like "MUST validate the Verifiable Credential against the provided JSON Schema document." probably need some more clarity about what part of the VC and at what stage of transformation/processing.
I suggest that we proceed with merging this PR nonetheless and have a separate discussion on JSON Schema versions in an issue.
Update: We don't need IANA registration for schema, schemauri and schemauri#integrity since type metadata is not a JWT.
NAME NAME Can you please check the examples I added.
I believe we will need to distinguish between presentation and issuance schemas -> see
I don't really speak JSON schema but it looks ok
Thanks a lot. I updated the PR. Will merge later on the editor's call.
Merging this since all comments were addressed.
Define how schemas can be included in type metadata. Requirement is that it should allow JSON schema.
left a couple of editorial remarks, but generally this looks good to me, thank you!
Code change:
into the "reserved (local)" state for the server and the "reserved (remote)" state for the client. <del> 8.2.2. </del> <ins> 8.4.2. </ins> After sending the PUSH_PROMISE frame, the server can begin delivering the pushed response as a HttpResponse on a server-initiated stream

Related discussion:
text: This is a rearrangement of the HTTP-related sections, in preparation for actually addressing 867.
This doesn't actually address the issue -- I came to a point where I realised this would add a bunch of new requirements and prose that would need heavy scrutiny, and if we want to finish soon, that may not be advisable (although maybe we can figure it out during WGLC). In the meantime, I think this rearrangement is much clearer than the original ordering -- see what you think.
The section talks about how to generate the various pseudo-header fields from a message, but not not how to create a message from the abstract constructs in HTTP semantics, such as the target URI. This includes security considerations around trusting the contents of . I'm happy to do a PR for this. Also, this is a weird paragraph: "HTTP/2 shares the same default port numbers" implies that it could choose to do otherwise; while that might have been an open question pre-core, I think this needs to be re-worded. Likewise, "requests for target resource URIs" is odd; is this meant to be "requests with target URIs"?
Yeah, most of this is just OLD. For instance, the "discovery" aspect really only relates to the need to use ALPN, but we have a better nomenclature now. If you are happy to do a PR, I'm more than happy to review rather than write.
Code change:
employ flow control to limit the amount of memory a peer can consume. Note, however, that this can lead to suboptimal use of available network resources if flow control is enabled without knowledge of the <del> bandwidth-delay product (see RFC7323). </del> <ins> bandwidth * delay product (see RFC7323). </ins> <del> Even with full awareness of the current bandwidth-delay product, </del> <ins> Even with full awareness of the current bandwidth * delay product, </ins> implementation of flow control can be difficult.  Endpoints MUST read and process HTTP/2 frames from the TCP receive buffer as soon as data is available.  Failure to read promptly could lead to a deadlock when

Related discussion:
text: This looks terrible, but it's the form that the RFC we cite uses (also, RFC 1323).
: We changed "Flow Control Performance" to "Flow-Control Performance" per the title of ("Flow-Control Principles"). Please let us know any concerns. Original: 5.2.3. Flow Control Performance Currently: 5.2.3. Flow-Control Performance
and 5.2.3: Should "bandwidth-delay product" be written as "bandwidth * delay product" per RFC 7323? Original: Note, however, that this can lead to suboptimal use of available network resources if flow control is enabled without knowledge of the bandwidth-delay product (see [RFC7323]). Even with full awareness of the current bandwidth-delay product, implementation of flow control can be difficult. ... If an endpoint cannot ensure that its peer always has available flow control window space that is greater than the peer's bandwidth-delay product on this connection, its receive throughput will be limited by HTTP/2 flow control.
I think "bandwidth-delay product" is the standard representation of the term. It's not a term specific to this document but a broader term of art. I recommend not taking this suggestion.
Thanks, I hate it.
Code change:
, which MAY be asynchronous from Registration.  The Transparency Service MUST be able to provide a Receipt for all registered <del> Statements.  A Receipt for a Signed Statement MAY be provided asynchronously.  Details about generating Receipts are described in Receipt. </del> <ins> Signed Statements.  Details about generating Receipts are described in Receipt. </ins> The last two steps may be shared between a batch of Signed Statements recorded in the Append-only Log.

Related discussion:
text: This is not correct if we also consider SCRAPI
SCRAPI says Auth is, may or isn’t required on specific endpoints, but doesn’t specify how it’s implemented. Is that inconsistent?
please check my suggested changeLGTMok with changes to 4.3 step 2LGTM
Code change:
Examples of the user-transferred authorization data pattern include flows in which the Consumption Device requests the Authorization Server to send authorization data (e.g., a 6 digit authorization code <del> in a text message or e-mail) to the Authorization Device.  Once the Authorization Device receives the authorization data, the user enters it on the Consumption Device.  The Consumption Device sends the authorization data back to the Authorization Server for validation before gaining access to the user's resources.  The figure below shows an example of this flow. </del> <ins> in a text message, e-mail or mobile application) to the Authorization Device.  Once the Authorization Device receives the authorization data, the user enters it on the Consumption Device.  The Consumption Device sends the authorization data back to the Authorization Server for validation before gaining access to the user's resources.  The figure below shows an example of this flow. </ins> The Authorization Server may choose to authenticate the user before <del> sending the authorization data.  The authorization data may be delivered as a text message or through a mobile application. </del> <ins> sending the authorization data. </ins> 3.2.

Related discussion:
text: Thanks, -dhs Dean H. Saxe, CIDPRO (he/him) Senior Security Engineer, AWS Identity Security Team | Amazon Web Services (AWS) E: EMAIL | M: 206-659-7293 From: OAuth on behalf of Rifaat Shekh-Yusef Date: Monday, April 22, 2024 at 7:57 AM To: oauth Subject: RE: [EXTERNAL] [OAUTH-WG] WGLC for Cross-Device Flows BCP CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. We have not received any feedback on this document so far. This is a reminder to review and provide feedback on this document. If you reviewed the document, and you do not have any comments or concerns, it would be great if you can send an email to the list indicating that. Regards, Rifaat All, This is a WG Last Call for the Cross-Device Flows BCP document. URL Please, review this document and reply on the mailing list if you have any comments or concerns, by April 29th. Regards, Rifaat & Hannes
Code change:
A server can limit the amount of early data with the "max_early_data_size" field of the "early_data" TLS extension.  This can be used to avoid committing an arbitrary amount of memory for <del> deferred requests.  A server SHOULD ensure that when it accepts early data, it can defer processing of requests until after the TLS handshake completes. </del> <ins> requests that it might defer until the handshake completes. </ins> 4.

Related discussion:
text: Just editorial suggestions here, but all good ones.
Nice wording, I really like this new version. Thanks!
Code change:
The Object Status field is only sent if the Object Payload Length is zero. <ins> The Subgroup ID field of an object with a Forwarding Preference of "Datagram" (see object-fields) is set to the Object ID. </ins> 7.4. Sending a track on one stream:

Related discussion:
text: Oh that makes more sense. Let's add this to the issue and see if others agree there.
NAME NAME you both approved when this PR set the value to 0 but I changed it. Please take another look.
if a Datagram object is delivered via FETCH (which doesn't really make sense, see and ), what Subgroup ID do I put in the FETCH object header? The only answers that make sense are zero, or the object ID.
I think the answer is getting datagrams via FETCH doesn't make much sense?
Agreed! The point of this issue is that there is an ambiguity in the spec unless we choose to close it via 588 or 599
I think we need to be able to fetch object that were originally delivered over datagram. Common use case is audio is over datagram and client got disconnected from the meeting for 10 seconds, rejoined, wants to get the missing 10 seconds and replay and 1.5x speed till it catches up then joins live meeting. I was sort of assuming subgroup would be zero for datagrams but I had not thought about using object ID. I would be concerned when doing that that object id can be large but size sub groups are limited to be pretty small so we could make them work with priorities. My question would be, does it every matter in anyway what the subgroup is for fetch ? If not, then zero seems fine.
Individual Comment: +1 for using zero It does if data that is FETCHed can later be subscribed to. Today it's possible because SUBSCRIBE allows Current Group (). If adding JOIN removes that (I think it should) then the protocol wouldn't have a direct use for subgroup. I wonder if there's a case of FETCHing a static asset to a re-broadcast publisher that would recreated the broadcast and want the subgroups though. I'm inclined to keep them in the FETCH stream wire format, at least for now.
The easiest way to think about this probably is, datagrams for a track have just on subgroup and thus its value is 0. I feel subgroup concept is important since it allows a publisher to control granularity of HOL blocking (based on subgroup size) support different priorities within a group I am not too sure of the requirement of fetched data to serve subscription. Even in JOIN flows, it is internally fetch + subscribe.
Code change:
The Object Status field is only sent if the Object Payload Length is zero. <ins> The Subgroup ID field of an object with a Forwarding Preference of "Datagram" (see object-fields) is set to the Object ID. </ins> 7.4. Sending a track on one stream:

Related discussion:
text: We have following cases: Case 1: Objects are sent as datagrams and cached with subgroup of 0 On Join, fetch will return all the objects until live edge on a single stream and then subscribe will get all the new objects as datagrams. Basically fetch flattens the priorities, original stream mapping (datagram here) and just returns objects from the cache. Case2: Objects are sent over streams and can have one or more subgroups. So when cached, objects can have different subgroupIds. On Join, fetch will return all the objects until live edge on a single stream and then subscribe will get all the new objects based on the subgroup mapping in one or more streams. Even here, fetch flattened the subgroups and priorities and just returns objects from the cache. What am i missing here ?
Maybe you want this comment on ? I think for now a PR with subgroup=0 should resolve this.
I don't have that strong a preference, but I would think having all Datagrams in a Group have the same subgroup ID would indicate I should be sending them over a single stream? Making the subgroup ID the same as the Object ID is more in keeping with the SubGroup == Stream transmission model.
Individual Comment: I previously +1 using zero but I'm convinced by Ian's argument to set it to the object ID. That may result in ever-so-slightly larger FETCH responses when there are more than 64 objects in a group, but I think that's in the noise.
I'm fine with this, since it resolves the issue, but I would think having all Datagrams in a Group have the same subgroup ID would indicate I should be sending them over a single stream? Making the subgroup ID the same as the Object ID is more in keeping with the SubGroup == Stream transmission model.
Code change:
of interaction between two workloads.  This is the core component of the WIMSE architecture I-D.ietf-wimse-arch.  Assume that Service A needs to call Service B.  For simplicity, this document focuses on <del> REST services, and the service-to-service call consists of a single HTTP request and its response.  We define the credentials that both services should possess and how they are used to protect the HTTP exchange. </del> <ins> HTTP-based services, and the service-to-service call consists of a single HTTP request and its response.  We define the credentials that both services should possess and how they are used to protect the HTTP exchange. </ins> There are multiple deployment styles in use today, and they result in different security properties.  We propose to address them

Related discussion:
text: There's nothing necessarily RESTful about this nor should it be limited to REST. Let's just not use the term. URL is a fun semi-related read, if you have or can find the time.
Quoting the article: I am not as young but I agree with this sentiment. Having said that, I guess a standard needs to be reasonably precise in its usage of terminology, and so I accept the PR.
Code change:
HTTP header fields are registered within the "Message Headers" registry maintained at <https://www.iana.org/assignments/message- <del> headers>.  This document defines and registers the Tunnel-Protocol header field, according to RFC3864 as follows: </del> <ins> headers>.  This document defines and registers the ALPN header field, according to RFC3864 as follows: </ins> <del> Tunnel-Protocol </del> <ins> ALPN </ins> http

Related discussion:
text: Last call discussion identified this as a solution to the confusion that exists around the intent of the header field.
Apparently, this is confusing. Picking a new name might help.
Code change:
triggered the push, plus resource identification information provided by the server.  Request header fields are necessary for HTTP cache control validations (such as the Vary header field) to work.  For <del> this reason, caches MUST inherit request header fields from the associated stream for the push.  This includes the Cookie header field. </del> <ins> this reason, caches MUST associate the request header fields from the PUSH_PROMISE frame with the response headers and content delivered on the pushed stream.  This includes the Cookie header field. </ins> Caching resources that are pushed is possible, based on the guidance provided by the origin server in the Cache-Control header field.

Related discussion:
text: We've long since agreed that full request headers are sent in the PUSHPROMISE frame; found a lingering reference to pushed resources "inheriting" headers from the original request. Revised it to reference the request headers in the PUSHPROMISE frame like everywhere else.
Code change:
Once TLS negotiation is complete, both the client and the server MUST send a ConnectionHeader. <del> 3.4. </del> <ins> 3.3. </ins> A client can learn that a particular server supports HTTP/2 by other means.  For example, ALT-SVC describes a mechanism for advertising

Related discussion:
text: HTTP/1.1 to HTTP/2 Upgrade was never widely deployed and has no particular defenders. This change removes the text explaining and defining the mechanism. This change still requires discussion on the mailing list.
NAME I've returned the two IANA registry entries and pointed them backwards at RFC 7540, as the sections that define those fields were removed from this document. I'm not actually sure that's the right IETF process there. Happy to take guidance as to what I should be doing instead (e.g. putting in a pair of dummy sections saying that the field and token don't have semantics any longer and referring to those instead).
Ok, I've replaced the registrations with tombstones, this is ready for another go around.
It would be good to more explicitly say that the upgrade mechanism is NOT RECOMMENDED, both because we're encrypting everything and because of the it enables (even if they're mostly shoddy implementation, it's more surface area).
Sounds like a reasonable addition, but it might be better to track that with a separate change.
Happy to add that here or make a separate change, either way.
Looking into this a little more, I think that Section 10.3 () is probably where some extra warnings might be worthwhile. The reason I might prefer a separate change is that we can hit Upgrade, Transfer-Encoding, Content-Length, and other Connection fields at the same time if we do it right.
This has not been implemented, so can likely go. See the discussion on URL for more context.
I’m in favour of removing this. It’s clear that the ecosystem has not found a use for it.
As a co-author of this one, I agree as well. This resulted from a misunderstanding of the use of the preface that everyone happily uses in clear to distinguish between H1 and H2 (and hence serve as a much easier upgrade).
Seems to have support; does anyone have an issue with this?
As stated in today's meeting, this sounds good to me, but it's worth posting on the list.