jiebi/CodeConvo huggingface dataset:
Code change:
10.2. <del> Requests without content can still send a "Digest" field applying the digest-algorithm to an empty representation. </del> <ins> In this example, a HEAD request is used to retrieve the checksum of a resource. </ins> The response "Digest" field-value is calculated over the JSON object "{"hello": "world"}", which is not shown because there is no payload data. <del> In this example there is no content coding applied, so the "sha-256" and the "id-sha-256" digest-values in the response would be the same. </del> Request: Response:

Related discussion:
text: Clarifies . 1- + HEAD is used to get a resource checksum 2- no Digest in request for clarity 3- only use sha-256 to focus on the actual example.
Digest can be sent in requests and response Nope, in the example Digest is both in the request and in the response. See the hidden 607 line URL When used in conjuction with signatures, the client that want to certify that no-payload was attached will: compute the Digest of an empty string sign that Digest header with some signature mechanism attach the signature and digest to the request send the request with no payload data The server will then: verify the signature according to the chosen mechanism if no payload is provided, the Digest is the one of an empty string eventually store the signature to prove that the request had no payload Clearly the signature mechanism should provide enough information to define the semantic of the request (eg. the method and all relevant headers). HTH, R.
Well. So the Digest is for the empty request payload. Maybe it would be good to state this in the spec? (That said, this is IMHO a very misleading example, as the HTTP spec is very clear that GET/HEAD request bodies ("A payload within a HEAD request message has no defined semantics; sending a payload body on a HEAD request might cause some existing implementations to reject the request."). It would probably better to have this example on a request that actually can take meaningful payload...
+1
NAME PTAL :)
I'll repeat what I said earlier: "That said, this is IMHO a very misleading example, as the HTTP spec is very clear that GET/HEAD request bodies ("A payload within a HEAD request message has no defined semantics; sending a payload body on a HEAD request might cause some existing implementations to reject the request."). It would probably better to have this example on a request that actually can take meaningful payload..."
In order to make progress here, I suggest we simplify the example to remove the Request digest. That keeps the example focused on it's name "Server Returns No Representation Data".
NAME removed Digest from the HEAD request.
NAME PTAL ;)
NAME PTAL :)
YAY :rocket:
In 10.2 Server Returns No Representation Data: what does the Digest request header field on the HEAD request refer to, and what is the recipient supposed to do with it?
Code change:
10.2. <del> Requests without content can still send a "Digest" field applying the digest-algorithm to an empty representation. </del> <ins> In this example, a HEAD request is used to retrieve the checksum of a resource. </ins> The response "Digest" field-value is calculated over the JSON object "{"hello": "world"}", which is not shown because there is no payload data. <del> In this example there is no content coding applied, so the "sha-256" and the "id-sha-256" digest-values in the response would be the same. </del> Request: Response:

Related discussion:
text: there's only one digest in the response, but the prose talks about two
Requests without payload data can still send a field applying the digest-algorithm to an empty representation. The recipient can validate that the digest-value matches the one of an empty representation or not. True. this is confusing, should reference the previous example.:
Code change:
415 Unsupported Media Type (status code) 416 Range Not Satisfiable (status code) 417 Expectation Failed (status code) <ins> 418 (Unused) (status code) </ins> 422 Unprocessable Entity (status code) 426 Upgrade Required (status code) 4xx Client Error (status code class)

Related discussion:
text: Looks good to me.
incorporate: URL
What do you want to incorporate exactly?
418 is reserved.
Well, not in the IANA registry right now. Wasn't the plan to do so without publishing something?
My recollection was that a publication is necessary; that's why it's here.
ok
Code change:
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: It seems like it would be better to transfer this in the STREAMHEADERTRACK and equivalent. Thoughts on that ? I also worry about how long a subscribe would wait to find out this information - that seems like it could be problematic for the client knowing when to give up on a subscribe. Hopefully we can discuss in Denver
Code change:
the verifiable data structure algorithm identifier for "ccf- ledger" (TBD_1). <del> "proof-type: int".  This header MUST be set to the value of the </del> <ins> "label: int".  This header MUST be set to the value of the </ins> "inclusion" proof type in the IANA registry of Verifiable Data <del> Structure Proof Type. </del> <ins> Structure Proof Type (-1). </ins> The unprotected header for a CCF inclusion proof signature MUST include the following:

Related discussion:
text: NAME NAME I have read through URL, and made some edits here as discussed to correct the leaf definition. This is deliberately quite light on details, but I am obviously very happy to expand wherever necessary.
NAME I had not seen the updates made in URL, I have attempted to merge them in here.
NAME if/when you have a chance, I would be grateful for a review and some feedback on how to take this forward :)
NAME I have tried to address your feedback, I hope I did not miss anything.
NAME may I ask you to check if the changes correctly addressed your feedback, and what the next steps are?
NAME thank you for the discussion yesterday, I have and added requested assignments for the labels. Please let me know if I need to do anything else before this can be merged.
:+1: let's pull this in and prepare for WG adoption call
Code change:
Upon receiving a Referenced Token, a Relying Party MUST first perform the validation of the Referenced Token - e.g., checking for expected <del> attributes, valid signature, expiration time.  As this is out of scope of this document, this validation is not be described here, but is expected to be done according to the format of the Referenced Token. </del> <ins> attributes, valid signature, expiration time.  The processing rules for JWT or CWT precede any evaluation of a Referenced Token's status. For example, if a token is evaluated as being expired through the "exp" (Expiration Time) but also has a status of 0x00 ("VALID"), the token is considered expired.  As this is out of scope of this document, this validation is not be described here, but is expected to be done according to the format of the Referenced Token. </ins> If this validation was not successful, the Referenced Token MUST be rejected.  If the validation was successful, the Relying Party MUST

Related discussion:
text: The first few entries are valid, revoked, suspended. There may be future well defined values that issuers and verifiers want global interoperability around. There may also be a need for private use of this space. This document should describe the "reserved for private use range", and leave room for enough globally interoperable and registered status values
We had similar ideas and totally agree
The section 7 explains how to setup the registry (URL) but we are missing a corresponding section in the IANA appendix
Code change:
have presented the SD-JWT with selected Disclosures directly, instead of encapsulating it in an SD-JWT+KB. <ins> After validation, the Verifier will have the following processed SD- JWT payload available for further handling: </ins> 7. Being JSON, an object in an SD-JWT payload MAY contain name/value

Related discussion:
text: Introduced the phrase in the end of the Section 8.1 on Verifying the SD-JWT for
Fair question. But I did add this one mention of the term in the location that NAME requested it in URL And it was already used in the text at the end of . And the just merged URL sprinkled in a few casual uses of it too. So I think it's sufficient enough. Also we have a fair number of kinda similar terms/phrases that are used in the doc but not formally introduced in the the terminology section. Which I think is fine. But putting this one there might be somewhat inconsistent and beg the question about other similar terms/phrases being there too.
We had the discussion in SD-JWT VC how to refer to the dehydrated (or maybe hydrated) result (Issuer-signed JWT payload) of the . It would help if we could give it a name to allow us to be more precise in other specs that are building on top of SD-JWT. The discussion occurred when adding the Schema for SD-JWT VCs that uses that result of the SD-JWT processing section to match the JSON schema against: URL We also have another issue that asks for an example of the result as well which would benefit from giving it a defined name: URL
Perhaps you can also confirm that this result in fact contains things like , , etc., and would only remove , , .
I was typing the following over in when it closed out from under me in favor of this issue.
why is not good enough? (in any case, would really like to avoid using hydrated/dehydrated since that term is kind of confusing and i used for something related but different in ISO I think)
I don't think that helps when referencing from another spec such as SD-JWT VC. The text you are referring to is from 8.3 Verification by the Verifier which is not general enough. I'd suggest to add one sentence to URL, e.g., "7. Let xzy be the processed result of the asdf algorithm ..." ... and make xzy a defined term, so it can be referenced. I don't think we can use from SD-JWT VC since it is not really defined in SD-JWT. If you don't define it in SD-JWT, we will define it in SD-JWT VC which I prefer not to.
Btw.
Code change:
have presented the SD-JWT with selected Disclosures directly, instead of encapsulating it in an SD-JWT+KB. <ins> After validation, the Verifier will have the following processed SD- JWT payload available for further handling: </ins> 7. Being JSON, an object in an SD-JWT payload MAY contain name/value

Related discussion:
text: if you call it processed payload, that is fine by me but it should be added to 8.1.
+ 1000000000% !
Defining terms is good. Dehydrated/hydrated would be bad. ;-)
PR URL has a small addition to sec 8.1 for this
agree to common law definition
Code change:
have presented the SD-JWT with selected Disclosures directly, instead of encapsulating it in an SD-JWT+KB. <ins> After validation, the Verifier will have the following processed SD- JWT payload available for further handling: </ins> 7. Being JSON, an object in an SD-JWT payload MAY contain name/value

Related discussion:
text: resolves URL which is really based on URL
some of URL likely applies here too
Notes on section 6: URL say more about the input JWT Claims Set URL show the processed SD-JWT payload somewhere in this section
notes on appendix: URL say more about the input JWT Claims Set URL show the processed SD-JWT payload somewhere after URL say more about the input JWT Claims Set URL use the processed SD-JWT payload name URL say more about the input JWT Claims Set URL names URL input URL name
Code change:
2. <ins> The SCITT REST API is designed to support identifier systems that are currently relevant to supply chains, including DID, x509 and PGP. In order to support these systems, the API must be aware of specific header parameters, in particular, "kid", "x5u" and "x5c". The API enables implementers to deploy interoperable URIs for disclosing information feeds related to supply chain actors, and artifacts accessible via transparency services. </ins> 2.1. <ins> TBD (comments on OAuth / Client Attestation). 2.2. TBD (comments on GAIN / OIDC). 2.3. TBD (comments on URLs / QR Codes). 3. 3.1. </ins> All messages are sent as HTTP GET or POST requests. If the Transparency Service cannot process a client's request, it

Related discussion:
text: A few thoughts after IETF 117. Goals: Address identity up front (by not addressing it directly). Frame feeds in the context of the API Relate media types to feeds This PR is mostly placeholders for future work, but hopefully highlights some areas for follow up based on our in person discussions.
NAME I can't merge this, but we should unless there are changes requested.
fixed collaborator list
LGTM
Code change:
Reason Phrase: Provides the reason for announcement error and "Reason Phrase Length" field carries its length. <del> 6.9. </del> <ins> 6.10. The publisher sends the "UNANNOUNCE" control message to indicate its intent to stop serving new subscriptions for tracks within the provided Track Namespace. Track Namespace: Identifies a track's namespace as defined in (track-name). 6.11. </ins> The server sends a "GOAWAY" message to force the client to reconnect. This is useful for server maintenance or reassignments without

Related discussion:
text: Based on QUIC: URL
Based on call today, sounds like when running over QUIC we should also use an ALPN of "moq-13" for draft 13
When running over web transport, we need to talk to the web transport people to talk about what to do but the ALPN would be H3 (or whatever) so the answer is not ALPN
The conclusion was that we should move version negotiation out of the SETUP message and into an ALPN for native QUIC and an unspecified mechanism for WebTransport. However, I can't think of any replacement for WebTransport that would work today. Query parameters would work for passing the client supported versions but there's no mechanism for replying with the server selected version. The javascript API provides no information about connection establishment (ex. any returned headers), only that it completed. If we moved version negotiation out of SETUP, then it would not be possible to interop until new WebTransport functionality was deployed, assuming W3C agrees in the first place. Could we go ahead with this PR until there's an available alternative? I like the direction of utilizing more of the QUIC/WebTransport handshake, but I don't think we should block interop awaiting this marginally better design.
Can we add in the ALPN text as part of this PR and for now say something like "When QUIC is used, the negotiated alpn MUST match the value in the SETUP message."?
It's time to specify some version numbers so we can attempt interop. We should do something like QUIC, where draft versions are prefixed with 0xff (or something?).
+1 The QUIC guys way over engineered this so I would be fine with just doing the same thing so we don't need to bike shed on it.
For now, will go with lower bits are the draft number and upper bits are some fixed set of bits defined in the draft. Do roughly what QUIC did.
Here's what I propose we copy: URL We don't need semvar yet because each version WILL have breaking changes. I'd be totally fine with semvar for the final RFC, like one byte for the major/minor/revision. Although I also think that negotiating extensions is more flexible for a transport protocol, while semvar seems more useful for something intended for fanout like the catalog.
Code change:
Reason Phrase: Provides the reason for announcement error and "Reason Phrase Length" field carries its length. <del> 6.9. </del> <ins> 6.10. The publisher sends the "UNANNOUNCE" control message to indicate its intent to stop serving new subscriptions for tracks within the provided Track Namespace. Track Namespace: Identifies a track's namespace as defined in (track-name). 6.11. </ins> The server sends a "GOAWAY" message to force the client to reconnect. This is useful for server maintenance or reassignments without

Related discussion:
text: Per conversation, we've decided to move forward with this and do ALPN as a separate PR.I would want to consider using alpn at some point in time. Want to keep it open for URL version at some point too. This PR is fine to continue the experimentation.Looks fine to me. Sure we might do more complicated stuff later but this seems like good enough for now.
Code change:
Some examples of these kinds of transformations, and the effect they have on the message signature, are found in example-transform. <ins> Other transformations, such as parsing and re-serializing the field values of a covered component or changing the value of a derived component, can cause a signature to no longer validate against a target message.  Applications of this specification need to take care to ensure that the transformations expected by the application are adequately handled by the choice of covered components. </ins> 1.4. HTTP Message Signatures are designed to be a general-purpose security

Related discussion:
text: Add reference for obs-fold, add note about transforms,
The spec several times refers to the term obs-fold, but doesn't say where it's defined (-> URL). Furthermore, in 1.3 it claims that addition of obs-fold could be permitted under certain circumstances. That IMHO is incorrect.
Adding the reference makes sense. The signatures spec doesn't change how the messages are created, nor does it make more allowed than it is now, it just tells people what to do with the messages that they have even if they have in them.
: This is misleading. No HTTP permits addition of leading/trailing whitespace. Leading/trailing whitespace in field values by definition is invalid.
While technically true, many (including implementers) won't understand the nuance Here. Given the impact, it's better to be over-inclusive, I think.
If invalid changes are included, then it might be best to either say that some of these changes might be invalid or point specifically to those that are.
Yes, my proposal would be to split the list into two; the second just listing the transformatios that might happen in reality despite bing forbidden.
NAME I agree that we need to prepare developers for the messy reality of HTTP in addition to what's strictly allowed. What else would appear in this second list?
The only other thing that I can see right now is addition of obs-fold.
Speaking of which: there are other transformations like parsing and re-serializing field values, which are certainly allowed. Shouldn't these be mentioned here as well?
NAME Re-serialization of a field value by an intermediary would likely break things in an expected way. It was my impression that this was not allowed by intermediaries in general. A structured field does help this, and the flag protects against that kind of transformation, as mentioned in the section.
I don't think we have a rule anywhere that would keep an intermediary from parsing and re-serializing fields. And even if that was the case, the same would be true for the original point (addition of leading/trailing WS), so I'm trying to understand where we draw the line.
Code change:
13.4. <del> Please update the "Message Headers" registry of "Permanent Message Header Field Names" at <https://www.iana.org/assignments/message- headers> with the header field names listed in the table of field.names. </del> <ins> Please create a new registry as outlined in field.name.registry. After creating the registry, all entries in the Permanent and Provisional Message Header Registries with the protocol 'http' are to be moved to it, with the following changes applied: Please annotate the Permanent and Provisional Message Header registries to indicate that HTTP header field registrations have moved, with an appropriate link. After that is complete, please update the registry with the header field names listed in the table of field.names. </ins> 13.5.

Related discussion:
text: For
I believe the registry URI should actually say "http-header-fields". Can I change that?
The text might be confusing to IANA as the registry does not exist yet.
Code change:
interval since that time.  A typical setting of this fraction might be 10%. <del> When a heuristic is used to calculate freshness lifetime, a cache SHOULD generate a header field with a 113 warn-code (see warn.113) in the response if its current_age is more than 24 hours and such a warning is not already present. </del> 4.2.3. The

Related discussion:
text: I'll have to update extract-header-URL so that it can generate entries with status "obsoleted".
NAME Go ahead and merge after you update extract-header-URL
Isn't implemented, generated, used or surfaced to users; can we deprecate?
Proposal: Replace 5.5 Warning with a section noting that the Warning header is deprecated, and should be ignored. Remove all requirements to generate Remove Warning-specific requirements in 3.3 Combining Partial Content Remove Warning-specific requirements in 4.3.4 Freshening Stored Responses upon Validation Remove Warning-specific requirements in 4.3.5 Freshening Responses via HEAD
+1, with big notes in the Changes section.
Just curious if anyone has any background, what would be a good alternative to the Warning header for cache limit warnings?
This isn't a good place for general discussion. You might want to ask the mailing list, though I am not aware of any cache limit warnings within HTTP because they are only relevant to the cache admin (who typically has an email or phone number stored for such notifications).
Code change:
HttpHeaders does not include specific rules for validation of pseudo- header fields.  If the values of these fields are used, additional <del> validation is necessary.  This is particularly important where </del> <ins> validation is necessary.  This is particularly important where " </ins> <del> , </del> <ins> ", " </ins> <del> , and </del> <ins> ", and " </ins> <del> are combined to form a single URI string (RFC3986).  Similar problems might occur when that URI or just </del> <ins> " are combined to form a single URI string (RFC3986).  Similar problems might occur when that URI or just " </ins> <del> are combined with </del> <ins> " are combined with " </ins> <del> to construct a request line (as in HTTP11).  Simple concatenation is not secure unless the input values are fully validated. </del> <ins> " to construct a request line (as in HTTP11).  Simple concatenation is not secure unless the input values are fully validated. </ins> An intermediary can reject fields that contain invalid field names or values for other reasons, in particular those that do not conform to

Related discussion:
text: I had to add to one use of :authority.
and subsequent: Please note that, per the rest of this cluster of documents, we have placed the terms beginning with a colon (":method", ":scheme", etc.) in double quotes where they appear in running text. Please review, and let us know any objections.