jiebi/CodeConvo huggingface dataset:
Code change:
4.2. <del> TBD </del> <ins> This section defines the "StatusList" structure for a CBOR-encoded Status List. The "StatusList" structure is a map (Major Type 5) and defines the following entries: * "bits": REQUIRED.  Unsigned int (Major Type 0) that contains the number of bits in the per Referenced Token in the Status List.  The allowed values for "bits" are 1, 2, 4 and 8.  * "lst": REQUIRED.  Byte string (Major Type 2) that contains the Status List as specified in status-list-json. The following example illustrates the CBOR representation of the Status List: The following is the CBOR diagnostic output of the example above: </ins> 5.

Related discussion:
text: In fact COSE is already mentioned at all places, so the question is whether we should align things and say Referenced Token = JOSE/COSE-based
Use reference to RFC9052 instead of RFC8152
As described in the title, detail the CWT representation of the status list which is complementary to the JWT representation.
Maybe a naive question but what's the motivation for this draft having the two representations? When positioned as a companion of the SD-JWT VC draft and aiming for the OAuth WG, it seems like keeping the scope tighter and only having the JWT representation would be sufficient/okay/preferable.
NAME credential formats like mDocs do not have a status/revocation mechanism hence a CWT based representation is beneficial to these applications as they dont typically have JWT support.
I dunno, I'm not convinced that necessitates having multiple status list token representations. Especially in one draft. This draft, which again is being positioned as a companion to the SD-JWT VC. I suspect the work would be more palatable for adoption with a scope that's reflective of that. But maybe that's just me. Thanks for the context.
Code change:
The checksum is computed using one of the digest-algorithms listed in algorithms and then encoded in the associated format. <del> The example below shows the "sha-256" digest-algorithm that uses base64 encoding. </del> 3. The "Digest" field contains a comma-separated list of one or more

Related discussion:
text: [x] 3. It's probably worth mentioning that they're comma-separated in prose. [ ] 3. I'm uncomfortable with relying on examples to specify how this spec works normatively; by their nature, examples are not 'comprehensive.' While this spec shouldn't re-specify HTTP, the header's definition should be clear enough that a reader doesn't have to dig around in the examples and other specs to understand what's going on. [x] 3. Disagreeing plurals in 'an incremental digest-algorithms'. [x] 4. Is Want-Digest a request field, a response field, or both? In either or both cases, what's the scope of the assertion? [x] * 4. A reference to SEMANTICS 12.4.2 is necessary.
Code change:
Given an ASCII string as input_string, return a token. input_string is modified to remove the parsed value. <del> If the first character of input_string is not ALPHA, fail parsing. </del> <ins> If the first character of input_string is not ALPHA or "*", fail parsing. </ins> Let output_string be an empty string.

Related discussion:
text: ... and allow token to start with "*".
I'm running my SH implementation against the HTTP Archive dumps (400,000,000+ HTTP requests) to see how the from BSH parse in something like the real world. It looks like some headers are failing because AcceptAccess-Control-Allow-Origin`. If we were to use a different character to delimit Byte Sequences, we could include in Token (necessarily as a first character, as well as in the rest, I assume). Worthwhile? If so, what should we use for Byte Sequences?
(via ) already allows , but not as a first character. '%' is short in HPACK and unlikely to trigger funny handling, but maybe it will conflict with pct-encoding to start. '=' has the virtue of being already allowed. It has the drawback of causing byte array parameters to look funny ( for instance). Interestingly, it makes removal of padding easier (base64 padding is silly).
How about ? I don't' think is a good idea; if an implementation enforces padding (which we caution against, but do not prohibit), it's confusing.
Checking with NAME NAME - any issues changing byte sequence delimiters from to ?
(the only conflicting use that comes to mind ATM for is that if someone wants to refer to H2 pseudo-headers like in a field that uses tokens, they'll be out of luck. I think that's OK, because existing fields that take header names as a list-of-tokens don't refer to pseudo-headers, and new fields can be defined as lists of tokens-or-strings.)
is free
Code change:
adaptable to these changes, and as the protocol diverges from HTTP, the benefit of mindshare will be lost. <del> Protocols that are based upon HTTP MUST NOT reuse HTTP's URL schemes, </del> <ins> Protocols that are based upon HTTP MUST NOT reuse HTTP's URI schemes, </ins> transport ports, ALPN protocol IDs or IANA registries; rather, they are encouraged to establish their own.

Related discussion:
text: This change switches from "URL" to "URI" specifically for two contexts: URI schemes URI syntax (It might be good to also add an explanation somewhere in the Introduction; I can make a proposal if needed)
It is a PR, no?
Weird, it didn't show the UX for PRs before, but does now. shrug
See URL
Code change:
has been superseded by "selected representation". This document replaces RFC3230.  The changes described in the <del> following paragraphs are intended to be semantically compatible with existing implementations where possible. </del> <ins> following paragraphs are intended to be syntactically and semantically compatible with existing implementations where possible. </ins> The "Digest" and "Want-Digest" field definitions are updated to align with the terms and notational conventions in SEMANTICS.

Related discussion:
text: Add syntactic compatibility.
From NAME WGLC review: This wording is awkward, we can editorialize this to be clearer what the scope and intent of changes are.
Code change:
5.6.2. <ins> Tokens are short textual identifiers that do not include whitespace or delimiters. </ins> Many HTTP field values are defined using common syntax components, separated by whitespace or specific delimiting characters. Delimiters are chosen from the set of US-ASCII visual characters not

Related discussion:
text: The first paragraph of the section 5.6.2 on Tokens, which describes delimiters, is misplaced. It should either be the last paragraph in that section or the first paragraph in the parent (Common Rules).
Moving it up would be a bit strange because to the reference to tokens. Moving to the end of the section seems good though.
Code change:
that have indeterminate length representations. Two steps are necessary because of limitations with the Range request <del> header and the Content-Range response header fields.  A server cannot know from a range request that a client wishes to receive a response that does not have a definite end.  More critically, the header fields do not allow the server to signal that a resource has </del> <ins> header fields and the Content-Range response header fields.  A server cannot know from a range request that a client wishes to receive a response that does not have a definite end.  More critically, the header fields do not allow the server to signal that a resource has </ins> indeterminate length without also providing a fixed portion of the resource.

Related discussion:
text: Note this was manually incorporated into draft-ietf-httpbis-rand-access-live-03
Code change:
clients MAY provide a configuration setting that disables this check, but MUST provide a setting which enables it. <ins> 4.3.5. A server that is identified using an IP address literal in the "host" field of an "https" URI has a reference identity of type IP-ID.  An IP version 4 address uses the "IPv4address" ABNF rule and an IP version 6 address uses the "IP-literal" production with the "IPv6address" option; see RFC3986.  A reference identity of IP-ID contains the decoded bytes of the IP address. An IP version 4 address is 4 octets and an IP version 6 address is 16 octets.  Use of IP-ID is not defined for any other IP version.  The iPAddress choice in the certificate subjectAltName extension does not explicitly include the IP version and so relies on the length of the address to distinguish versions; see RFC5280. A reference identity of type IP-ID matches if the address is identical to an iPAddress value of the subjectAltName extension of the certificate. </ins> 5. HTTP uses

Related discussion:
text: This is how it works in practice. RFC 6125 is due for an update, I guess. iPAddress subjectAltName has been supported for years and years, but it never managed to capture it properly. This is definitely a big change in that it now outlaws CN-ID. And the definition of IP-ID here is probably overreach, but I don't see how we can avoid that. I don't want to update RFC 6125 here (as much as it needs updating), so making the definition standalone seemed like the right way to handle it.
Discovered via a question NAME asked; it appears that 8aa1781d4fa7d25ab946f6cb1dd1b337435e0a17 made the change to require looking for URI-IDs in the certificate and I don't see any follow-up discussion on that in . However, I've never seen a certificate that offers a URI-ID for an HTTP endpoint. Shouldn't this be a DNS-ID to match current usage? Or perhaps either, with URI-ID preferred, if we believe that's the future?
Er, right, my mistake -- I was trying to describe it as verifying a URI as input, not as looking only at the certificate field for URI-ID. It should either be left unsaid, because it is defined by that RFC, or possibly specify DNS-ID with maybe URI-ID as a backup?
I am not entirely sure that there is need to mention URI-ID (I, for one, don't know of usage of it with HTTP; I barely know of usage of it at all). My understanding is that current practice prefers DNS-ID with a grudging tolerance for CN-ID as fallback (though there are efforts underway to fully deprecate use of CN-ID). Note also that when referencing the RFC 6125 procedures, the protocol document is expected not only to specify what name and type are to be used as input to verification, but also whether wildcard certificate are allowed. It is sometimes also useful to give instruction about what procedures are to be used for revocation checking, though 6125 does leave that explicitly out of its own scope. I am also trying to promote the definition and use of "IPADDR-ID" for the iPAddress SAN, but that's somewhat unrelated.
Do we want to state a position on adoption of URI-ID?
Code change:
clients MAY provide a configuration setting that disables this check, but MUST provide a setting which enables it. <ins> 4.3.5. A server that is identified using an IP address literal in the "host" field of an "https" URI has a reference identity of type IP-ID.  An IP version 4 address uses the "IPv4address" ABNF rule and an IP version 6 address uses the "IP-literal" production with the "IPv6address" option; see RFC3986.  A reference identity of IP-ID contains the decoded bytes of the IP address. An IP version 4 address is 4 octets and an IP version 6 address is 16 octets.  Use of IP-ID is not defined for any other IP version.  The iPAddress choice in the certificate subjectAltName extension does not explicitly include the IP version and so relies on the length of the address to distinguish versions; see RFC5280. A reference identity of type IP-ID matches if the address is identical to an iPAddress value of the subjectAltName extension of the certificate. </ins> 5. HTTP uses

Related discussion:
text: If not, then I think we say DNS-ID and MAY consider CN-ID, plus the wildcard language. I'm not aware of anything to reference for IPADDR-ID, and this doesn't seem like the place to define it.
Please don't use CN for anything. Nor rfc822Address nor domainComponent.
I'll be happy to accept any change here that folks generally agree to, preferably in the form of a PR. I already tried just writing it myself and that's what we have now, but it's wrong because I haven't implemented this myself.
Sorry for the late comment; apparently my github notifications aren't set to send me email when a new PR references an issue I'm watching.I'll trust NAME :-)
Code change:
Digest Algorithm: md5 <del> Description: The MD5 algorithm, as specified in RFC1321.  The output of this algorithm is encoded using the base64 encoding RFC4648.  This digest-algorithm is now vulnerable to collision attacks.  See NO-MD5 and CMU-836068. </del> <ins> Description: The MD5 algorithm RFC1321.  The output of this algorithm is encoded using base64 RFC4648.  This digest- algorithm is now vulnerable to collision attacks.  See NO-MD5 and CMU-836068. </ins> Reference: RFC1321, RFC4648, this document.

Related discussion:
text: There's not really any reason to describe anything other than the algorithm used and the format of encoding.
From NAME WGLC review This seems like cruft. The important things for the table are clear pointers to the algorithm definition and the encoding of values created by the algorithm.
If it's not broken, don't fix it :P I think we spent too much time wrt old algorithms. I'm in favor of anyone that wants to provide a PR that has consensus.
It is broken -- let's fix it. :)
LGTM
Code change:
Similarly, clients MUST NOT employ the "Client-Cert" or "Client-Cert- Chain" header field in requests. <del> A server that receives a request with a "Client-Cert" or "Client- Cert-Chain" header field value that it considers to be too large can respond with an HTTP 431 status code per RFC6585. </del> 3. <ins> 3.1. If the client certificate header field is generated by an intermediary on a connection that compresses fields (e.g., using HPACK RFC7541 or QPACK I-D.ietf-quic-qpack) and more than one client's requests are multiplexed into that connection, it can reduce compression efficiency significantly, due to the typical size of the field value and its variation between clients.  Recipients that anticipate connections with these characteristics can mitigate the efficiency loss by increasing the size of the dynamic table.  If a recipient does not do so, senders may find it beneficial to always send the field value as a literal, rather than entering it into the dynamic table. 3.2. A server in receipt of a larger header block than it is willing to handle can send an HTTP 431 (Request Header Fields Too Large) status code per RFC6585.  Due to the typical size of the field values containing certificate data, recipients may need to be configured to allow for a larger maximum header block size.  An intermediary generating client certificate header fields on connections that allow for advertising the maximum acceptable header block size (e.g. HTTP/2 RFC7540 or HTTP/3 I-D.ietf-quic-http) should account for the additional size of header block of the requests it sends vs. requests it receives by advertising a value to its clients that is sufficiently smaller so as to allow for the addition of certificate data. 4. </ins> The header fields described herein enable a TTRP and backend or origin server to function together as though, from the client's perspective, they are a single logical server side deployment of

Related discussion:
text: If an intermediary and a backend advertise the same value, but the intermediary is adding huge headers, it's possible that a request that the client sent was within the limit, but the request sent by the intermediary to the server will be too large.
There's also some background in that might help explain the issue.
There are two things here really. Alan is concerned about header block size. Mark about compression efficiency. Both are worth mentioning.
Code change:
The SETTINGS_NO_RFC7540_PRIORITIES setting is defined by this document in order to allow endpoints to explicitly opt out of using HTTP/2 priority signals (see Section 5.3.2 of HTTP2).  Endpoints are <del> expected to use an alternative, such as the scheme defined in this specification. </del> <ins> encouraged to use alternative priority signals (for example, header- field or h2-update-frame) but there is no requirement to use a specific signal type. </ins> The value of SETTINGS_NO_RFC7540_PRIORITIES MUST be 0 or 1.  Any value other than 0 or 1 MUST be treated as a connection error (see

Related discussion:
text: The context here is that the document defines independent elements a) the means to deprecate RFC 7540 stream priority using a setting b) the extensible priorities scheme. This text removes conflating those elements and making it appear that Extensible priorities is mandatory. Where someone chooses to use Extensible priorities (good choice!) there is some specific guidance about how to process settings and inform signal setting.
Above, you indicate any scheme can be used, with this being just one option. This does make guidance about PRIOUPDATE frames/header field more difficult later, so maybe some other textual adjustment is needed earlier: e.g., for the remainder of this text ,we assume the use of the scheme defined in this document as the alternate Or, move the following text from below up and adjust a bit send this scheme's priority signal Originally posted by NAME in URL
The text isn't amazingly clear if endpoints have to use Extensible priority when they explicitly disable H2 priority. I suggest we state they do. If anyone really wants to invent a new scheme, they will need to deal with negotiation.
Yeah I see two somewhat contradicting statements: Endpoints are expected to use an alternative, such as the scheme defined in this specification. Until the client receives the SETTINGS frame from the server, the client SHOULD send both the HTTP/2 priority signals and the signals of this prioritization scheme (see Section 5 and Section 7.1). I would argue that the former is precise, and that the latter is a bit misleading in recommending endpoints send Extensible Priorities rather than any alternative to H2 priorities. The rationale is as follows. In principle, negotiation is a hop-by-hop mechanism and therefore cannot be used for negotiating the use of an end-to-end signal, which includes the header-field variant of Extensible Priorities. To paraphrase, in a world where end-to-end signals are used for prioritization, multiple signals are expected to co-exist. IMO, SETTINGSDEPRECATERFC7540_PRIORITIES is no more than an optimization, that allows clients to conserve bandwidth (by omitting the PRIORITY frames), servers to reduce complexity (by ignoring PRIORITY frames being received). These benefits are stated correctly in the section.
Thanks Kazuho. I tend to agree. The thing I also wanted to avoid is endpoints disabling RFC 7550 stream priority and then not providing any suitable replacement by accident.
Code change:
The SETTINGS_NO_RFC7540_PRIORITIES setting is defined by this document in order to allow endpoints to explicitly opt out of using HTTP/2 priority signals (see Section 5.3.2 of HTTP2).  Endpoints are <del> expected to use an alternative, such as the scheme defined in this specification. </del> <ins> encouraged to use alternative priority signals (for example, header- field or h2-update-frame) but there is no requirement to use a specific signal type. </ins> The value of SETTINGS_NO_RFC7540_PRIORITIES MUST be 0 or 1.  Any value other than 0 or 1 MUST be treated as a connection error (see

Related discussion:
text: I think there is agreement that not doing scheduling is pretty bad. But we also highlight that other inputs, beyond this scheme and beyond anything that would be standardised are fine to use too. I'm getting an idea of how we could change the text to address the points made on this issue.
Reading again the current text send this scheme's priority signal. Handling of omitted signals is described in {{parameters}}. This is effectively a differently worded restatement of the guidance for implementers of Extensible Priorities receiving an HTTP request that does not carry these priority parameters, a server SHOULD act as if their default values were specified. That is, imagine both endpoints send SETTINGSDEPRECATERFC7540PRIORITIES and a client wants the default prioritization for a request (u=3,i). It can omit the Priority header field and have some expectation that a server implementing Extensible priorities will interpret that as a signal to apply the default. The simple action here is to make SETTINGSDEPRECATERFC7540PRIORITIES independent from any advice to use a specific alternative.
LGTM. I like how you've split the section.
Code change:
claim is treated as an object in the Disclosure. <del> The Issuer would create the following Disclosure: </del> <ins> The Issuer would create the following Disclosure referenced by the one hash in the SD-JWT: </ins> 7.2.

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:
claim is treated as an object in the Disclosure. <del> The Issuer would create the following Disclosure: </del> <ins> The Issuer would create the following Disclosure referenced by the one hash in the SD-JWT: </ins> 7.2.

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:
claim is treated as an object in the Disclosure. <del> The Issuer would create the following Disclosure: </del> <ins> The Issuer would create the following Disclosure referenced by the one hash in the SD-JWT: </ins> 7.2.

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