jiebi/CodeConvo huggingface dataset:
Code change:
The "id" value is optional. <del> 2.1.5. </del> <ins> 2.1.4. </ins> The "type" value of the Use-As-Dictionary header is a sf-string value that describes the file format of the supplied dictionary.

Related discussion:
text: I'm not 100% sure it's just a workaround and origin-compressing against previous releases at build time may be preferable for some cases. The most extreme case that comes to mind is something like a huge WASM app (like Photoshop) where the files are upwards of 50MB (well, huge relative to the usual web page resources). Presumably the CDN could still do the work to do the compression (maybe as an offline job for future requests) so it doesn't require the origin to do it necessarily but it's a lot more reasonable in the extreme cases. That said, I think we can still get buy without a separate TTL and adding one later if it ends up being useful can be done as an enhancement without breaking the existing case.
I like red patches. Thanks.
Code change:
10.7. Padding within HTTP/2 is not intended as a replacement for general <del> purpose padding, such as might be provided by TLS12.  Redundant </del> <ins> purpose padding, such as might be provided by TLS13.  Redundant </ins> padding could even be counterproductive.  Correct application can depend on having specific knowledge of the data that is being padded.

Related discussion:
text: A lot has happened to TLS since we did RFC 7540. This tries to capture that succinctly. It rolls in changes from RFC 8740.It mentions early data and RFC 8470.It updates references, citing TLS 1.3 rather than 1.2 for a generic TLS reference.
A few small changes are included in , which could be integrated easily.
I won't create the pull request just yet, but here are some proposed changes: URL NAME do you think that you could review these? I've paraphrased some of RFC 8740 and I want to make sure I haven't missed anything.
(The GitHub link did something silly, but I'm assuming 837d46a5ff9e23a62cb719f69be7f1d10bf8da80 is the right commit and just looked at that.) s/the handshake// Though I wonder if this sentence can just be omitted. I needed to address it in RFC8740 because RFC7540 didn't have a TLS version dispatch. But now the TLS 1.2 features section is explicitly mentioned as being 1.2-only, so that exception already doesn't apply. Otherwise LGTM. (I think the default values in server settings is implicit from the fact that we haven't received anything from the server yet, but whatever.)
Thanks. I've updated my branch to remove the renegotiation piece. I've updated that link (which I should have checked).
Code change:
A sender MUST NOT generate a bare CR (a CR character not immediately followed by LF) within any protocol elements other than the payload <del> body.  A recipient of such a bare CR MUST consider that element to be </del> <ins> data.  A recipient of such a bare CR MUST consider that element to be </ins> invalid or replace each bare CR with SP before processing the element or forwarding the message.

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:
A sender MUST NOT generate a bare CR (a CR character not immediately followed by LF) within any protocol elements other than the payload <del> body.  A recipient of such a bare CR MUST consider that element to be </del> <ins> data.  A recipient of such a bare CR MUST consider that element to be </ins> invalid or replace each bare CR with SP before processing the element or forwarding the message.

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:
Although POSTs are inherently chunked, POST requests SHOULD also be accompanied by a Content-Length header field.  First, it informs the <del> server of how much data to expect, which the server can used to track </del> <ins> server of how much data to expect, which the server can use to track </ins> overall progress and provide appropriate user feedback.  More importantly, some HTTP server implementations fail to correctly process requests that omit the Content-Length header field.  Many <del> existing clients send a Content-Length header field, which caused server implementations have come to depend upon its presence. </del> <ins> existing clients send a Content-Length header field, and some server implementations have come to depend upon its presence. </ins> The user-agent is free to prioritize requests as it sees fit.  If the user-agent cannot make progress without receiving a resource, it

Related discussion:
text: Additionally, section 4.2.3 contains a lot of text that is similar to 4.2.2, but there may be a reason for that.
I'll try to remember to fix the content-length thing.
Code change:
Abstract <del> This document specifies Verifiable Credentials based on Selective Disclosure JSON Web Tokens (SD-JWT) with JSON payloads. </del> <ins> This specification describes data formats, validation and processing rules to express Verifiable Credentials based on the SD-JWT format (TBD: see oauth-selective-disclosure-jwt) using JSON payloads. </ins> 1. <del> TBD: why? - simplicity - JWTs are well-known, popular but doesn't work best with three-party-model - Also no selective disclosure, which impacts costs and security. This specification describes data formats, validation and processing rules for SD-JWT expresing Verifiable Credentials. </del> <ins> Todo: Discuss VCs, introduce terminology. Signed JSON Web Tokens (JWTs) RFC7519 can in principle be used to express Verifiable Credentials in a way that is easy to understand and process as it builds upon established web primitives.  However, JWTs do not support selective disclosure, i.e., the ability to disclose only a subset of the claims contained in the JWT.  This is a common problem in the so-called three-party model: An Issuer creates a Verifiable Credential for some End-User (Holder), who then presents this credential to multiple Verifiers.  A credential might contain a large number of claims, but the Holder typically only wants to disclose a subset of these claims to a Verifier.  In this case, the Holder would have to receive a new signed JWT from the Issuer, containing only the claims that should be disclosed, for each interaction with a new Verifier.  This is inefficient, costly, and the necessary interaction with the Issuer introduces additional privacy risks. SD-JWT is a specification that introduces conventions to support selective disclosure for JWTs: For an SD-JWT document, a Holder can decide which claims to release (within bounds defined by the Issuer). This format is therefore perfectly suitable for Verifiable Credentials. SD-JWT itself does not define the claims that must be used within the payload of the token or their semantics.  This specification therefore defines how Verifiable Credentials can be expressed using SD-JWT. Todo: Explain the 'plain JSON' part </ins> 1.1.

Related discussion:
text: NAME do you know how to fix the build errors?
let's fix references later and create a new issue for that
Code change:
re-issue Receipts for the Registry content, for instance after a transient fault during Signed Statement Registration. <del> 6.5. </del> <ins> 6.6. </ins> This section provides additional implementation considerations.  The high-level validation algorithm is described in validation; the <del> Registry-specific details of checking Receipts are covered in I- D.birkholz-scitt-receipts. </del> <ins> Registry-specific details of checking Receipts are covered in -COMTRE. </ins> Before checking a Transparent Statement, the Verifier must be configured with one or more identities of trusted Transparency

Related discussion:
text: As proposed in at the WG meeting in Tokyo, we would like to move receipts as a generic primitive in COSE. (see issue ) This PR removes all explicit references to the SCITT receipt ID and instead defines Receipts based on . Note that I also incorporated 2 proposed changes to make SCITT statement and receipt signature more symmetrical: Receipts now include the DID of the transparency service. This can be optionally used to discover the receipt signing key. This change was originally proposed at the IETF WG meeting in London. It simplifies statement authorization, as verifiers can only trust the stable DID of the TS instead of worry about keys or certificate that may be rotated Transparency services can now indicate the registration policies that were actually applied. This is very helpful for verifier, for instance to check the freshness of claims. This was proposed in Tokyo
LGTM, see this implementation: URL and demo: URL
NAME can you help resolve the errors?
Hi, Does this change mean that implementations based on native merkle tries (eg will have to translate proofs to this format ? And if that is so, what is the basis for trusting the service that does that ? Or is there scope for registering trie algorithms based on native proofs like ERC 1186 ?
As we're working to complete for 116, I'm assigning to 116
See for a proposed implementation
Closing as has been merged
I'd like to more generally discuss additional information provided by the TS as it issues receipts: Some information "at the root" refers to its signing (timestamp, keying, ID, etc) but implicitly applies to every statement recorded so far. As discussed at the last hackathon, some information "at the leaf" is the outcome of applying the TS registration policy to each signed statement, including e.g. the configuration of the TS at that point (timestamp, authorized keys, DID resolution results, etc) LGTM
Code change:
2.3. This specification does not define authorization server discovery.  A <del> client MAY contact the resource and leverage the WWW-Authentication response (see section 3 of RFC6750), maintain a static mapping or use other means to identify the authorization server. </del> <ins> client MAY contact the resource server and leverage the WWW- Authentication response (see section 3 of RFC6750), maintain a static mapping or use other means to identify the authorization server. </ins> 2.4. The client performs token exchange as defined in RFC8693 with the <del> authorization server for its own domain (e.g.  Domain A), in order to </del> <ins> authorization server for its own domain (e.g., Domain A) in order to </ins> obtain an authorization grant that can be used with the authorization <del> server of a different domain (e.g.  Domain B) as specified in section </del> <ins> server of a different domain (e.g., Domain B) as specified in section </ins> 1.3 of RFC6749. 2.4.1.

Related discussion:
text: Includes updates based on
Original: URL Kelly's editorial changes: identity-chaining-draft-URL
Code change:
possibility would be to submit an internet-draft that documents the alternate congestion control mechanism for the benefit of the IETF and IRTF communities.  This is particularly encouraged in order to <del> get algorithm specifications widely disseminated to facilitate further research.  Such an internet-draft could be submitted to be considered as an Informational RFC, as a first step in the process towards standardization.  Such a document would also be expected to carry an explicit warning against using the scheme in the global Internet. </del> <ins> ensure algorithm specifications are widely disseminated to facilitate further research.  Such an internet-draft could also be considered as an Informational RFC, as a first step in the process towards standardization.  Such a document would be expected to carry an explicit warning against using the scheme in the global Internet. </ins> Note: we are not changing the RFC publication process for non-IETF produced documents (e.g., those from the IRTF or Independent

Related discussion:
text: Update the QS text and various editorial suggestions. if merged.
I'll propose a PR with some editorial updates to the first part of the ID.
Code change:
component identifiers and their associated values, along with any additional signature parameters discussed in signature-params. <del> Component identifiers are serialized using the production grammar defined by STRUCTURED-FIELDS.  The component identifier has a </del> <ins> Component identifiers are serialized using the strict serialization rules defined by STRUCTURED-FIELDS.  The component identifier has a </ins> component name, which is a String Item value serialized using the "sf-string" ABNF rule.  The component identifier MAY also include defined parameters which are serialized using the "parameters" ABNF

Related discussion:
text: Replaces
Thanks!
IMHO we need to be clear what the requirements of SF support are. The way the spec currently is written (referencing RFC 8941) means that SF-shaped field values using the new sf-date format are not supported. I don't think this is what we want, so unless we want to wait for sfbis to be ready, we'll need to add some consideration of how compat with SF extensions/revisions is supposed to work.
The intent of the current text is not to limit the use of the flag to only the currently defined formats. New formats are supported if the signer and verifier support the formats. The agreement of what format to use for a particular field is out of scope for this specification, and needs to be agreed upon by the signer and verifier outside of the signature process. This is true for all the current types and will remain true for any additional types defined in the future.
On a high level, this sounds right. As an implementer of a signature library, calling an SF library, what is your expectation what it'll do with sf-date once the spec is published? What if the sender want to sign an integer param in a dictionary, but the field instance contains another param using sf-date?
I would expect a library of that nature to publish its mapping between field names and SF types, and ideally allow that mapping to be edited by the caller of the library. Otherwise, how would a user of the library be able to provide a type mapping for a custom field that the library doesn't know about, let alone a new sf-type?
Understood. Different layers of libs. What I meant is a generic SF library, that just parses/serializes SF fields.
Then you need to know what you're parsing it in to. SF fields aren't entirely discoverable from the syntax alone, you need to know the type explicitly. I ran into this when implementing my own signature libraries. So the signature library needs to have that mapping, and if the underlying SF library doesn't support some new type, then you can't map to it. Once the dependencies are updated, you can provide that feature up the chain. It all seems pretty standard and simple to me, honestly.
How so? I still don't see the path to interop for any update of the structured field syntax, unless this spec at least provides some hints.
Code change:
component identifiers and their associated values, along with any additional signature parameters discussed in signature-params. <del> Component identifiers are serialized using the production grammar defined by STRUCTURED-FIELDS.  The component identifier has a </del> <ins> Component identifiers are serialized using the strict serialization rules defined by STRUCTURED-FIELDS.  The component identifier has a </ins> component name, which is a String Item value serialized using the "sf-string" ABNF rule.  The component identifier MAY also include defined parameters which are serialized using the "parameters" ABNF

Related discussion:
text: You need to know the top-level type (Dictionary, List, or Item) for each field. The consequence of that (AIUI) is that a recipient wishing to validate a signature that uses will need to understand the top-level type of each 'd field in the signature. It'll also need to support the permissable types in those fields -- e.g., if a field allows Date, the recipient needs to be able to handle that. As a result, it won't be possible to reliably verify a signature if your processor doesn't have knowledge of the top-level type, or if it doesn't have support for an extension type in use in one of those fields. However, there is a chance of verifying it still, if the SF-produced form is sent on the wire and not changed at all in transit, and the processor just ignores processing (and in some ways, this is worse than reliably failing). I think this all can be reasoned out by reading the specs appropriately. Documenting it as a tripping hazard would help users avoid interoperability issues, but this specification is already long and dense, and if we also make it a user guide, it will risk becoming unusable. So, speaking personally -- if the above summary is correct, I could see adding a sentence or two to section 2.1.1 at the most; I could also see leaving it to a separate profile/user guide.
[ chair hat on ] This issue is the last thing holding the Signature spec going to IETF LC. NAME NAME please respond to above, particularly: whether such text is necessary whether such text will address the issue when such text, if necesary, would need to be incorporated (before/after LC). Thanks,
I believe it would be good to have such text; and that it should be in the spec, not in a guide that is unlikely to materialize. It should be incorporated before LC (I hope you mean a new WGLC here...?). Given the amount of changes, we really should spend some time reviewing all that changed, and to verify that the open issues have been addressed properly.
NAME can you propose something? I don't see any reason to rerun WGLC, based upon the current PRs; there are some changes (especially in one or two), but they're based on AD review and can be discussed during IETF LC.
Code change:
component identifiers and their associated values, along with any additional signature parameters discussed in signature-params. <del> Component identifiers are serialized using the production grammar defined by STRUCTURED-FIELDS.  The component identifier has a </del> <ins> Component identifiers are serialized using the strict serialization rules defined by STRUCTURED-FIELDS.  The component identifier has a </ins> component name, which is a String Item value serialized using the "sf-string" ABNF rule.  The component identifier MAY also include defined parameters which are serialized using the "parameters" ABNF

Related discussion:
text: cc NAME
I would prefer to see your proposal :-). The RFC diff since the last WG version has 143 change blocks: URL We also currently have 17 open issues/PRs: URL IMHO we need to get these closed (can be rejecting or fixing), and also have a look at those that we raised since -13 and closed in the meantime. I don't think we do the community a service by sending this to IETF LC right now.
NAME you are grossly misrepresenting the state of the document. For one, the last WG version, and the one that went to the AD, is -15, not 13, so your diff above is misleading at best. The changes since then have largely not been substantive in nature, and all have been made publicly with the view and input of the WG. The open issues are nearly all addressed by open PRs, which I am waiting for AD feedback before merging (I'm not sure if the AD wants to review the PR text or the merged draft that results). What remains is this issue, as NAME pointed out above. To answer NAME 's question about how to resolve this: I think pointing out as a potential tripping hazard is not necessary but would not be harmful. The precondition to know the type is already in the text as the first sentence about the flag in section 2.1.1: Additionally, the lack of knowledge of the type of the field is already called out explicitly as a required error condition in section 2.5: I would propose we simply add a note to 2.1.1 of the form:
Well, it's hard to say what remains to be done until an issue is actually closed. We're all volunteers here, so it's good to make things as easy as possible to reviewers. So, trying to rephrase: let's get all open issues closed (one way or the other), and let the people who raised the issues give an opportunity to provide feedback before sending this back to the IESG. (I, for once, am not convinced that I agree with the proposed solutions, but due to the type of diffs (long lines) it's a bit tricky to understand what actually changed) works for the sending side; but what is a recipient supposed to do when the sf flag is present and the field value does not parse due to sender and receiver disagreeing about the SF version?
Code change:
component identifiers and their associated values, along with any additional signature parameters discussed in signature-params. <del> Component identifiers are serialized using the production grammar defined by STRUCTURED-FIELDS.  The component identifier has a </del> <ins> Component identifiers are serialized using the strict serialization rules defined by STRUCTURED-FIELDS.  The component identifier has a </ins> component name, which is a String Item value serialized using the "sf-string" ABNF rule.  The component identifier MAY also include defined parameters which are serialized using the "parameters" ABNF

Related discussion:
text: Also, that only affects the toplevel type of the structured field. It does not address the case where an extension parameter is added is an sf-date (or any future new type).
NAME until you propose text, it will be hard to say what kind of text you think would close this issue.
Except for this issue and two others recently raised by you (which will be considered as IETF LC issues), all of the issues and PRs you mention were generated by the AD review before IETF LC; this is a normal part of the process that does not require going back to WGLC unless the AD asks for WG review, which . NAME made a reasonable proposal. If you disagree with it, make your own.
If the proposal was: Then this isn't sufficient as it only applies to the toplevel type (see URL). NAME - I believe you are in the best position to make a proposal; but that said; I can try something later today.
So, we have in 2.1.1: This implies that the "sf" parameter can only be used on fields that conform to RFC 8941, no extensions allowed. I would suggest clarifying that, at the end of 2.1.1, with: "Note that the normative requirement to use the SF serialization algorithm precludes any use of future extensions of the structured field syntax. Support for future versions of SF will require an update to this specification." I believe this matches what NAME suggested.
Except that your proposed text is incorrect. The implication you are drawing is not true, nor what others have taken from that text. The use of the parameter does not preclude extensions to RFC 8941, as has been discussed at length here and on the mailing list. Extensions to sf types would not require changes to the signatures spec. I propose closing this issue without change to the signatures spec.
Sorry. Mark asked me to propose text, and that's what I did. The text has a normative requirement to use an RFC8941 serializer, so the proposed text is correct. That we disagree here is proof that a clarification is needed. If you feel that that p.o.v.