jiebi/CodeConvo huggingface dataset:
Code change:
specified track, as well as associated metadata required to deliver, cache, and forward it.  There are two subtypes of this message.  When the message type is 0x00, the optional Object Payload Length field is <del> present.  When the message type ix 0x02, the field is not present. </del> <ins> present.  When the message type is 0x02, the field is not present. </ins> The format of the OBJECT message is as follows: <del> Track ID: The track identifier obtained as part of subscription and/or publish control message exchanges. </del> <ins> Track ID : The compressed full track name obtained as part of subscription and/or publish control message exchanges. </ins> Group Sequence : The object is a member of the indicated group model-group within the track.

Related discussion:
text: This PR is expected to be base PR to support multi-subscribe like flows that will follow up. It adds support for SubscribeID and also renames the trackId to to avoid the confusion and make the scope clear.
NAME NAME NAME wondering if the latest commits address the feedback. thanks
The normative bits look fine. PR needs some cleanup. Recommend splitting ID -> Alias to another PR, so this subscribe ID doesn't get caught up with bikeshedding the field name.LGTM but I would like Subscribe ID to be the first field in every message for consistency.Still looks fine after the split Having reviewed some code that does subscription matching with the current draft, I strongly endorse splitting those.
Code change:
or header field.  Request message framing is independent of method <del> semantics, even if the method does not define any use for a message body. </del> <ins> semantics. </ins> The presence of a message body in a response depends on both the request method to which it is responding and the response status code <del> (status.line), and corresponds to when a payload body is allowed; see payload.body. </del> <ins> (status.line), and corresponds to when payload data is allowed; see payload. </ins> 6.1. The Transfer-Encoding header field lists the transfer coding names corresponding to the sequence of transfer codings that have been (or <del> will be) applied to the payload body in order to form the message </del> <ins> will be) applied to the payload data in order to form the message </ins> body.  Transfer codings are defined in transfer.codings. Transfer-Encoding is analogous to the Content-Transfer-Encoding field

Related discussion:
text: I think we discussed this last week and Julian has pending changes to be made before review.
This just moves the ABNF, not the definition of the transfer codings.
This is the remaining ABNF production that Semantics imports from Messaging (for the definition of "TE"). Maybe we should move the production to messaging, reversing the dependency.
Discussed on call; worth a try.
URL out that there are a few more things to consider: Semantics currently claims there are regular parameters here, but transfer-parameter is special wrt BWS should we move the special case of "trailers" in the grammar into prose? In any case, what would it mean to have a ranking on "trailers"? Invalid, thus ignore? "t-ranking" seems to duplicate "weight"
Fine to merge, but shouldn't we also move the extensibility and IANA registry sections?
Code change:
or header field.  Request message framing is independent of method <del> semantics, even if the method does not define any use for a message body. </del> <ins> semantics. </ins> The presence of a message body in a response depends on both the request method to which it is responding and the response status code <del> (status.line), and corresponds to when a payload body is allowed; see payload.body. </del> <ins> (status.line), and corresponds to when payload data is allowed; see payload. </ins> 6.1. The Transfer-Encoding header field lists the transfer coding names corresponding to the sequence of transfer codings that have been (or <del> will be) applied to the payload body in order to form the message </del> <ins> will be) applied to the payload data in order to form the message </ins> body.  Transfer codings are defined in transfer.codings. Transfer-Encoding is analogous to the Content-Transfer-Encoding field

Related discussion:
text: This eliminates confusion with the message body protocol element of HTTP/1.1 and other usage of multipart body parts, and should make it easier to describe HTTP/2 and HTTP/3 data frames.
except for multipart body parts or when referring specifically to HTTP/1.1 message body.
See related comment: URL
I believe this is good; but more eyes are needed :-) If we go ahead with that, we may want to call out the new terminolody in one of the "changes from 723x" sections.
Code change:
(see RFC8610) for of the protected header and unprotected header of Signed Statements and Receipts. <del> Everything that is optional in the following CDDL definition can potentially be discovered out of band and Registration Policies are not assured on the presence of these optional fields.  A Registration Policy that requires an optional field to be present MUST reject any Signed Statements or Receipts that are invalid according to the Registration Policy. </del> <ins> This definition specifies the minimal mandatory labels. Implementation-specific Registration Policies may define additional mandatory labels.  A Transparency Service implementation MUST reject registering Signed Statements that do not meet their current Registration Policy requirements.  Each implementation SHOULD provide details for their registration policies through documentation or discovery APIs. </ins> fig-signed-statement-edn illustrates an instance of a Signed Statement in Extended Diagnostic Notation (EDN), with a payload that

Related discussion:
text: These proposed changes, if accepted,
potentially be discovered out of band and Registration Policies are not assured on the presence of these optional fields. I do not understand what you want to say with the second part of the sentence. Even the first part of the sentence do not convey any real meaning.
LGTM of URL
Code change:
client and the server; it allows the peers to establish the mutually supported version and agree on the initial configuration before any objects are exchanged.  It is a sequence of key-value pairs called <del> ; the semantics and format of which can vary based on whether the client or server is sending.  To ensure future extensibility of MOQT, the peers MUST ignore unknown setup parameters.  TODO: describe GREASE for those. </del> <ins> SETUP parameters; the semantics and format of which can vary based on whether the client or server is sending.  To ensure future extensibility of MOQT, the peers MUST ignore unknown setup parameters.  TODO: describe GREASE for those. </ins> The wire format of the SETUP message is as follows:

Related discussion:
text: The stuff we had to italicize the stuff in html is inserting underscores in the .txt file so I just want to remove this until for now until we figure this out. Did not change anything other than making the words not italicized
Thanks for catching this , the rendered TXT file looks different for these things. Merging it for now and we can work on figuring out the right markdown syntax.
Code change:
WIMSE certificate may contain SubjectAltName extensions of other types such as DNSName. <del> WIMSE identities may be used to validate server and client connections.  When validating a WIMSE identity the relying party MUST validate that the CA issuer for the WIMSE identity is authorized to issue certificates for the trust domain of the WIMSE identity in the certificate.  Other PKIX path validation rules apply. Servers wishing to use the WIMSE identity for authorizing the client MUST require client certificate authentication in the TLS handshake. Other methods of post handshake authentication are not specified by this document. </del> <ins> WIMSE certificates may be used to secure both server and client connections.  When validating a WIMSE certificate, the relying party MUST validate that the CA issuer for the WIMSE certificate is authorized to issue certificates for the trust domain of the WIMSE workload identified by the certificate.  Other PKIX path validation rules apply. Servers wishing to use the WIMSE certificate for authorizing the client MUST require client certificate authentication in the TLS handshake.  Other methods of post handshake authentication are not specified by this document. </ins> WIMSE clients and servers MUST validate that the trust domain portion of the WIMSE certificate matches the expected trust domain for the

Related discussion:
text: Editorial.
Commenting as identity enthusiast as opposed to WIMSE co-chair. Consider replacing WIMSE Identities with WIMSE Credentials since it is the credential that is being verified, which may include a Workload identifier and possibly other claims.
WIT stays though.
Code change:
Remove any leading or trailing WSP characters from the attribute- name string and the attribute-value string. <del> If the attribute-value is longer than 1024 bytes, ignore the </del> <ins> If the attribute-value is longer than 1024 octets, ignore the </ins> cookie-av string and return to Step 1 of this algorithm. Process the attribute-name and attribute-value according to the

Related discussion:
text: Addresses
NAME NAME PTAL
RFC6265bis mentions the cookie length constraints in relation to parsing the Set-Cookie headers but doesn't in the more general Storage Model section. From chatting with NAME about this, it'd be desirable to have these constraints be listed in that section as well. Since there are other ways cookies can come in to the cookie store (Ex: Cookie Store API), having these constraints be enforced when adding cookies from any source to the cookie store would better ensure cookie format consistency.
Code change:
Reference: Where this algorithm is defined Initial contents: Provided in <del> 8.  References 8.1.  URIs [1] https://www.iana.org/assignments/ </del>

Related discussion:
text: These changes focus this draft on the minimal definitions required to secure the data structures defined in RFC9162 using CBOR and COSE. Extraneous information has been removed. There is a wip implementation available here: URL There is a demo here: URL
LGTM!sry 4 the l8 approvalI recommend merging now
Code change:
case-sensitive strings where the value(s) MUST represent the specific purpose or intent of the transaction.  * "requested_token_type" REQUIRED.  The value MUST be "urn:ietf:params:oauth:token-type:txn- <del> token" * "subject_token" REQUIRED.  The value MUST be a token representing the subject of the transaction.  This could be an OAuth access_token received by an API Gateway or a JWT assertion constructed by a workload initiating a transaction or another form of token as identified by "subject_token_type".  * "subject_token_type" REQUIRED.  The value MUST indicate the type of the token present in the "subject_token" parameter </del> <ins> token" * "subject_token" REQUIRED.  The value MUST represent the subject of the transaction.  This could be an OAuth access_token received by an API Gateway, a JWT assertion constructed by a workload initiating a transaction or a simple string value all identified by "subject_token_type".  * "subject_token_type" REQUIRED.  The value MUST indicate the type of the token or value present in the "subject_token" parameter </ins> The following additional parameters MAY be present in a Txn-Token Request:

Related discussion:
text: I updated the text to require the claim remain unchanged when requesting a replacement transaction token. I also added a mechanism to allow for tracking the workloads that have requested replacement transaction tokens. This was necessary as the current text required the to remain unchanged in the replacement transaction token and the object contains the requesting workload identifier. I used a mechanisms similar to x-forwarded-for. This needs lots of review.
It would be good to show how, in a replacement txn-token, the identity of the previous subid is preserved. The replacement token may have a new subid that represent the workload that requested the replacement token. Originally posted by NAME in URL
Can we close this since it was addressed in PR ?
Code change:
request.  The "actor_token" MUST authenticate the identity of the requesting workload. <del> 9.4. </del> <ins> 9.5. </ins> Validation of a replacement Txn-Token, as well as any Txn-Token, is critical to the security of the entire transaction invocation

Related discussion:
text: The notes copy-pasted from the WG notes do say "when", but based on our recollection of the events during that session, the real ask was to clarify that one could use unsigned JSON objects. That is indicated in the action item (i.e. the last line in that issue description)
the following came up in the IETF 120 session about TraTs: "Add an outline on when self-signed may be useful Yaron thought self-signed wil be a footgun Suggest a simple JSON object as replacement." The description of in section 7.1 is too rigid as it only allows an inbound token or a self-signed token. It should make it clear that an implementation may choose to have any different format for the subjecttoken.
Just a few very minor comments
Code change:
request.  The "actor_token" MUST authenticate the identity of the requesting workload. <del> 9.4. </del> <ins> 9.5. </ins> Validation of a replacement Txn-Token, as well as any Txn-Token, is critical to the security of the entire transaction invocation

Related discussion:
text: The following issue came up during the IETF 120 session on TraTs: There was a comment about some of the processing rules that was the equivalent of NULL with extra processing steps (N_A)
George and Atul recommend that we should drop the sentences after "REQUIRED A unique transaction identifier as defined in Section 2.2 of ]." Since this is a normative section, it need not have any usage guidance in there. If required we can add non-normative usage guidance such as "The txn value MAY be used to identify the call chain"
Code change:
configuration, it will appear as if Proxy-Authentication-Info is being forwarded because each proxy will send the same field value. <ins> Proxy-Authentication-Info can be sent as a trailer field (trailer.fields) when the authentication scheme explicitly allows this. </ins> 12. When responses convey content, whether indicating a success or an

Related discussion:
text: This goes back to URL
Simplest possible fix would be to mark it as allowed in trailers as well.
Code change:
Workloads MAY request replacement Txn-Tokens in order to change (add to, remove or modify) the asserted values within a Txn-Token. <ins> The value of the "aud" claim MUST remain unchanged in a replacement Txn-Token.  If the claim "req_ctx" is present in the original Txn- Token, then it MUST be present unchanged in the replacement Txn- Token. </ins> 7.3.1. A Txn-Token Service replacing a Txn-Token must consider that

Related discussion:
text: Looks good to me. Left a comment, but nothing major.
Left a comment, but looks good to me.
Code change:
Additional section.  The resolver should also include an ipv4only.arpa record in the Additional section. <del> 7. </del> <ins> 6.3. Some network media may provide their own mechanisms for advertising NAT64 service to the stub network.  If such a mechanism is available, stub routers MUST use the mechanism provided by the network medium used on the stub network to advertise NAT64 service.  Otherwise, NAT64 service MUST be advertised using the PREF64 Router Advertisement option RFC8781. 6.4. </ins> If a stub network is constructed using mesh technology, it may become partitioned.  In such a situation, it may be one stub router is

Related discussion:
text: Added a bunch of clarifying text about why to use the DHCPv6 PD prefix, and also clarified the bits about NAT64 with respect to when to use Infrastructure-provided versus stub-router-provided NAT64.
See URL in the working group meeting in London, and in both cases, it seemed that the argument that without NAT64 we can't deliver on "device must always be able to connect to the internet if it is available" overrode the objections that were raised. So despite some folks really not loving it, I think it's required. Michael (IIRC) also pointed out that we need DHCPv6 PD to get infrastructure-provided NAT64 to work, which I guess means that if we have IPv4 and infrastructure-provided NAT64, but no DHCPv6 PD, we have to do NAT64 in the stub router. If we have v6-only, infrastructure-provided NAT64, and no DHCPv6 PD, then in order to reach the internet, we'd need NAT66. I'm inclined to declare this situation out of scope, because (A) I really don't want to do NAT66, and (B) I think it's not a likely scenario at the moment, and the more devices out in the field that would break in this situation, the better.
Code change:
explicit expiration time F <ins> Fields Age Cache-Control Expires Pragma Warning </ins> fresh freshness lifetime

Related discussion:
text: This is related to issue On the flight back from Switzerland, I spent time looking at the cache directives and how they differ from the descriptions in RFC2616. I worked out these problems and drafted a pull request, but I haven't checked whether we changed these deliberately for RFC7234, or if the distinctions just got lost in the rewrite. In any case, I think this is an improvement, but definitely needs reviews.
This ended up being an editorial change between drafts because the only normative changes were already noted for and , and this is just rewording what we had for .
From : Both state that a (depending on context private, shared or both types of) "cache MAY store the response and reuse it for later requests, even if the response would normally be non-cacheable". To my understanding, this does not intend to override the requirements from the "Storing Responses in Caches" section (URL) altogether. Instead, I would assume that it only refers to the condition "has a status code that is defined as heuristically cacheable" in that section (or, as it was stated in RFC7234, "has a status code that is defined as cacheable by default")? Would it make sense to amend the list of conditions in that section, appending to the "the response either..." second-level list: "contains a private response directive if the cache is not shared"?
OP here
lists some directives that allow responses with Authentication to be stored, but some of those directives' definitions do not mention this.
I think this should also be added for ; see .
I think this issue needs to be reopened and the specification text reverted to something more like what was in RFC2616. That spec specifically requires public be present to allow responses to a request with Authorization to be stored by a shared cache, regardless of must-revalidate or proxy-revalidate. This is not implied by those other directives.
Code change:
For more advanced use-cases, the "Repr-Digest" request and response header and trailer field (representation-digest) is defined.  It contains a digest value computed by applying a hashing algorithm to <del> "selected representation data" (SEMANTICS).  Basing "Repr-Digest" on </del> <ins> selected representation data (SEMANTICS).  Basing "Repr-Digest" on </ins> the selected representation makes it straightforward to apply it to use-cases where the transferred data requires some sort of manipulation to be considered a representation or conveys a partial

Related discussion:
text: Right now, it's inconsistent in the document. HTTP core just uses an unquoted version so I'm inclined to just use that
Code change:
7.2.4. <ins> The "Content-Length" header field indicates the associated representation's data length as a decimal non-negative integer number of octets.  When transferring a representation in a message, Content- Length refers specifically to the amount of data enclosed so that it can be used to delimit framing of the message body (e.g., body.content-length).  In other cases, Content-Length indicates the selected representation's current length, which can be used by recipients to estimate transfer time or compare to previously stored representations. </ins> An example is A sender MUST NOT send a Content-Length header field in any message

Related discussion:
text: We decided to move the version-independent parts of the definition of Content-Length to Semantics, but that calls for some new text to explain its semantics in general. For now, we have added (in crefs) the following text to the section on "Content-Length" in Semantics:
s/representation/representation data/?
Code change:
For example, an ETag field in a response communicates the entity-tag of the newly created resource's <del> representation, so that it can be used in later conditional requests to prevent the "lost update" problem (preconditions). </del> <ins> representation, so that the entity-tag can be used as a validator in later conditional requests to prevent the "lost update" problem. </ins> This specification defines two forms of metadata that are commonly used to observe resource state and test for preconditions:

Related discussion:
text: … (now entirely handled by HTTP/1.1 messaging). Include LF in discussion of what characters are invalid in field values. Require obs-fold to be processed when consuming message/http data.
Citing Ben Kaduk (URL): (i.e., that has any field line value that contains a match to the obs-fold rule) unless [...] other production, and field-value excludes CRLF, it seems that any such field line value would already be in violation of the ABNF and thus forbidden. I don't really want to advocate for including obs-fold in the field-value production in -semantics, though, so maybe accepting this nit is the least bad choice here. In RFC723x, field-value allowed obs-fold. We need to: tune the prose above, and somehow properly allow it in message/http (maybe by modifying the field-value for that specific case???)
see also URL
This is a good change. A few things that might be worth considering, when comparing this to recent HTTP/2 changes. HTTP/2 prohibits additional things in field names: SP (0x20), COLON (0x3a), 0x01-0x1f, and 0x7f-0xff (inclusive), specifically. The other things in h2 are specific to that. That includes leading and trailing space in values (you just say "A field value does not include leading or trailing whitespace") and uppercase field characters are version-specific.