jiebi/CodeConvo huggingface dataset:
Code change:
3.1. <del> Lists are arrays of items (item) with one or more members.  Members </del> <ins> Lists are arrays of items (item) with zero or more members.  Members </ins> can also be an "inner list", itself an array of items. The ABNF for lists in HTTP/1 headers is:

Related discussion:
text: Overall, I don't see a lot of value in accommodating empty headers directly, and I don't think we should be promoting it as a practice.
Agree, I'm not convinced either. I see the potential, but Gettys rule applies: "The only thing worse than generalizing from one example is generalizing from no examples at all." (May actually be from Phil Karlton originally, sources differ.)
Hm, no. "A request without an Accept-Encoding header field implies that the user agent has no preferences regarding content-codings." vs. "An Accept-Encoding header field with a combined field-value that is empty implies that the user agent does not want any content-coding in response."
Yes, but in the real world, the outcome is always the same.
No. HTTP/1.1 introduced an IESG requirement that Host must always be sent and recipients must always reject with 400 if Host is not received. When I pointed out that not all URIs have a host, the response was that clients must send an empty Host field in that situation. It is a MUST requirement in Semantics section 5.4: This is ingrained in HTTP semantics and commonly used by non-browser HTTP implementations. There is only one example of an HTTP header field using "none" and that is Accept-Ranges. It isn't a good example for anything. To be clear, it would be a bug for an HTTP message processor to drop a received header field just because the value is empty. Nothing about SH will change that. What we are discussing is whether SH is capable of representing an empty list or an empty header field, both of which it is currently incapable of doing.
If that spec specifically says "empty field-value", a SH "empty" token will not be usable for Host: anyway, and we're back in the "generalizing from no example at all" again.
On Thu, Apr 11, 2019 at 03:53:15PM +0000, Poul-Henning Kamp wrote: After having thought a bit more about this, I now think that we don't need empty list elements in the end because lists are not strongly ordered, they're not arrays with a position so an empty element in a list brings no value.
Code change:
3.1. <del> Lists are arrays of items (item) with one or more members.  Members </del> <ins> Lists are arrays of items (item) with zero or more members.  Members </ins> can also be an "inner list", itself an array of items. The ABNF for lists in HTTP/1 headers is:

Related discussion:
text: I'd further say that removing an element from a list must result in removing the list once the last one was removed as it is a set. So I think I'm fine with not dealing with empty lists. This then leaves us only with the empty header field alone, likely where a string or a token are expected. I don't see a reason not to support an empty string just like any other string. A header field is not just a value, it's a name+value combination. With a void value the name still serves as a boolean (present or not) and this is exactly how it's used when the field is made mandatory to distinguish between agents generations or as a signal to detect support for something. We've all filled administrative forms where the requested information was irrelevant but mandatory in the form and just left it void so that the person in charge deals with the particular case (on paper) or filled with whatever was accepted (on web forms) hoping it would just be ignored since irrelevant. For me the Accept and Host fields are exactly in this category. My concern is to be certain that a valid HTTP request can be transmitted over SH. And ironically, the only mandatory HTTP header ("Host") is also the one requiring the support for an empty value due to its mandatory nature. Willy
I have lost count of the number of packages I have received from USA where part of the address is "Denmark does not have states" :-)
Again, the purpose of SH is not to allow all possible HTTP header to be represented in the data model -- it's to solidify the 80% case and promote best (and interoperable) practice. Representing a boolean as an empty header field is not good practice.
See PR above.
I've put in the changes for the list-based header fields. It's less clear to me that it's desirable to default a missing or empty item to an empty string (strings and tokens) 0 (integers and floats), False (boolean) or a 0-length binary array (binary data); to me, those are all going to be application-specific defaults that are better specified explicitly. I'm happy to adjust the spec to make that more clear, if folks feel it already isn't.
Code change:
client that the server is likely to send a final response with the header fields included in the informational response. <del> A server MUST NOT include Content-Length, Transfer-Encoding, or any hop-by-hop header fields (RFC7230, Section 6.1) in a 103 (Early Hints) response. </del> <ins> Typically, a server will include the header fields sent in a 103 (Early Hints) response in the final response as well.  However, there might be cases when this is not desirable, such as when the server learns that they are not correct before the final response is sent. </ins> A client can speculatively evaluate the header fields included in a 103 (Early Hints) response while waiting for the final response.  For example, a client might recognize a Link header field value containing the relation type "preload" and start fetching the target <del> resource. However, these header fields only provide hints to the client; they do not replace the header fields on the final response.  Aside from performance optimizations, such evaluation of the 103 (Early Hints) response's header fields MUST NOT affect how the final response is processed.  A client MUST NOT interpret the 103 (Early Hints) response header fields as if they applied to the informational </del> <ins> resource.  However, these header fields only provide hints to the client; they do not replace the header fields on the final response. Aside from performance optimizations, such evaluation of the 103 (Early Hints) response's header fields MUST NOT affect how the final response is processed.  A client MUST NOT interpret the 103 (Early Hints) response header fields as if they applied to the informational </ins> response itself (e.g., as metadata about the 103 (Early Hints) response). <del> An intermediary MAY drop the informational response.  It MAY send HTTP/2 (RFC7540) server pushes using the information found in the 103 (Early Hints) response. </del> The following example illustrates a typical message exchange that involves a 103 (Early Hints) response.

Related discussion:
text: removes statements that are either redundant or contradicts with RFC 7230, 7231 clarifies how a server is expected to do when generating a response
While it is not required to specify how an intermediary might behave, doing so might be beneficial as suggested in URL We could possibly have something like the following below the example.
works for me.
NAME Thank you for the answer. Adopted the text (with nits) in d0903d6.
NAME Thank you for the review!
Looks good to me!
Code change:
to allow implementations to make the restrictions that make the most sense for their operational use cases. <del> At least one identifier for an identity document MUST be included in the protected header of the COSE envelope, as one of "x5t", "x5chain" or "kid". Support for "x5t" is mandatory to implement. Support for "kid" and "x5chain" is optional. When "x5t" or "x5chain" is present, "iss" MUST be a string with a value between 1 and 8192 characters in length that fits the regular expression of a distinguished name. The mechanisms for how Transparency Services obtain identity documents is out-of-scope of this document. The "kid" header parameter MUST be present when neither "x5t" nor "x5chain" are present.  Key discovery protocols are out-of-scope of this document. The protected header of a Signed Statement and a Receipt MUST include the "CWT Claims" header parameter as specified in CWT_CLAIMS_COSE. The "CWT Claims" value MUST include the "Issuer Claim" (Claim label 1) and the "Subject Claim" (Claim label 2) IANA.cwt. A Receipt is a Signed Statement, (cose-sign1), with addition claims in its protected header related to verifying the inclusion proof in its unprotected header.  See I-D.draft-ietf-cose-merkle-tree-proofs. fig-signed-statement-cddl illustrates a normative CDDL definition for of the protected header for Signed Statements and Receipts. Everything that is optional in the following CDDL 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 policy. fig-signed-statement-edn illustrates a payload that is detached. This is to support very large supply chain artifacts, and to ensure that Transparent Statements can integrate with existing file systems. </del> There are many types of Statements (such as SBOMs, malware scans, audit reports, policy definitions) that Issuers may want to turn into Signed Statements.  An Issuer must first decide on a suitable format

Related discussion:
text: Adjusts text around CDDL and EDN Adjusts text regarding Validation
LGTM, nice and clear changesLGTM
Code change:
4.3. <del> Holder Binding is an optional feature.  For example, when Cryptographic Holder Binding is required by the use-case, the SD-JWT must contain information about the key material controlled by the Holder. </del> <ins> Holder Binding is an optional feature.  When Cryptographic Holder Binding is required by the use-case, the SD-JWT MUST contain information about the key material controlled by the Holder. </ins> Note: How the public key is included in SD-JWT is out of scope of this document.  It can be passed by value or by reference. <del> The Holder can then create a signed document, the Holder Binding JWT, using its private key.  This document contains some data provided by the Verifier (out of scope of this document) to ensure the freshness of the signature, for example, a nonce and an indicator of the intended audience for the document. </del> <ins> The Holder can then create a signed document, the Holder Binding JWT as defined in hb-jwt, using its private key.  This document contains some data provided by the Verifier such as a nonce to ensure the freshness of the signature, and audience to indicate the intended audience for the document. </ins> The Holder Binding JWT can be included in the Combined Format for Presentation and sent to the Verifier along with the SD-JWT and the

Related discussion:
text: Discussions around defining SD-JWT-VC show that it would be very helpful for interoperability if HB JWT is normatively defined in SD-JWT specification itself. Using HB JWT is optional, but if used, it should be compliant to the definitions in SD-JWT. How to represent validity (iat, exp, nbf) will probably need the most discussion... also we should introduce an abbreviation .... cc NAME
need to re-generate example 4b, and 4a to update hb jwt header....
cc NAME please take a look (can't ask review from you...)
This change is sufficient to warrant an entry in the doc history like just, "Defined the structure of the Holder Binding JWT"
done, thank you, Brian
lgtm
Code change:
5.2.1.2. There are several reports in the public domain outlining how the <del> unauthenticated channel may be exploited to execute an illicit consent grant attack. </del> <ins> unauthenticated channel may be exploited to execute a Cross-Device Consent Phishing attack (Exploit1, Exploit2, Exploit3, Exploit4, Exploit5, Exploit6). </ins> 5.2.1.3.

Related discussion:
text: Introduce the Cross-Device Consent Grant label (see )
e.g. Malicious Context Change Authorization Request or something like that.
Ideas from Pieter's slides: Illicit Consent Grant Attack? Describes outcome, not the mechanism Attacker-in-the-Middle Attack? Describe attacker capability, but both too broad and too narrow Authorization Context Manipulation Attack? Describes the mechanism Authorization Context Manipulation Exploit Describe mechanism, hints that protocol functions as expected. What about "Phishing for Consent"? Describes the mechanim which depends to some extend on social engineering (phishing) Describes the outcome (consent) Other names shared via e-mail by George Fletcher: Zishing Azishing "Cross-Device Authorization Exploit" "Social Engineering Token Theft" "Authorization Flow Manipulation Exploit" FlowJack AuthJack TokenJack Context Manipulation Authorization Exploit Permitphishing, Authishing
"Cross-Device Consent Phishing"?
Some references on Consent Phishing: URL URL URL
CDCP - Cross Device Consent Phishing - the abbreviation works well.
Two editorial nits, the rest looks good to me! Thank you!
Code change:
Therefore, applications should not rely on specific labels being present, and applications should not put semantic meaning on the <del> labels themselves.  Instead, additional signature parmeters can be </del> <ins> labels themselves.  Instead, additional signature parameters can be </ins> used to convey whatever additional meaning is required to be attached to and covered by the signature.

Related discussion:
text: There are a few cases where the word is used. From the context, it appears that the intended word is .
Thanks! I have no idea why my spellcheck didn't catch those, and I appreciate it.
Code change:
Byte Sequence (binary) can be specified, along with a character encoding (preferably UTF-8 STD63). <del> When serialised in a textual HTTP field, Strings are delimited with </del> <ins> When serialized in a textual HTTP field, Strings are delimited with </ins> double quotes, using a backslash ("\") to escape double quotes and backslashes.  For example:

Related discussion:
text: There are currently some uses of "serialise" in place of the far more common "serialize", including one case that breaks the pattern of header names ("Serializing a List", "Serializing a Dictionary", "Serializing an Item", …, "Serialising a Date"). This PR also includes an analogous update of "summarises" to "summarizes" to increase the general pattern of American spellings.
Speaking Danglish myself, I am disqualified from having an opinion on this subject matter :-)
Despite my Australianised sensibilities, I see that 8941 was normalised to American spelling by the RFC Editor, and changing things now would introduce more diffs. Thanks for the PR.
Code change:
trusted locations or on trusted websites hosted on a specific domain, and never in e-mail or other media and locations). <del> It SHOULD be clear to the user how to decline the request.  To avoid accidental authorization grants, the "decline" option SHOULD be the default option or given similar prominence in the user experience as the "grant" option. </del> The user experience MAY include information to further educate the user on cross-device consent phishing attacks and reinforce the conditions under which authorization grants may be requested. <del> This information may be communicated graphically or in a simple message (e.g., "It looks like you are trying to access your files on a digital whiteboard in your city center office.  Click here to grant access to your files.  If you are not trying to access your files, you should decline this request and notify the security department"). </del> Improvements to user experience on their own is unlikely to be sufficient and SHOULD be used in conjunction with other controls described in this document.

Related discussion:
text: Moved paragraphs to improve the flow of the section. Removed references to User Education (which is now a mitigation itself, so all the details are already in the ad hoc section). Fix case for keywords should and may.
Code change:
"content" in this document are to be interpreted as described in RFC9110. <ins> This document uses the line folding strategies described in FOLDING. </ins> Hashing algorithm names respect the casing used in their definition document (e.g.  SHA-1, CRC32c) whereas hashing algorithm keys are quoted (e.g. "sha", "crc32c").

Related discussion:
text: -
LGTM modulo nit
NAME 8972 Simple Two-Way Active Measurement Protocol Optional Extensions or URL line wrapping? Since 8792 is used in examples, dunno if that's normative but it's ok.
:-) Typo fixed. In any case, we need to reference it (IMHO). I would also suggest to avoid the escaping when not needed.
Code change:
5.2.2.1. The "must-revalidate" response directive indicates that once it has <del> become stale, a cache MUST NOT use the response to satisfy subsequent requests without successful validation on the origin server. </del> <ins> become stale, the response MUST NOT be used to satisfy any other request without forwarding it for validation and receiving a successful response; see validation.model. </ins> The must-revalidate directive is necessary to support reliable operation for certain protocol features.  In all circumstances a

Related discussion:
text: The specification of can be read to allow the response to be reused for another concurrent request, since it's specified in terms of non-volatile memory. Likewise, other cache directives are silent on such reuse. So-called "request collapsing" has become quite common in proxies, reverse proxies and CDNs. Clarification as to whether such reuse for temporally concurrent requests would be helpful (in the case of and otherwise).
This also seems related to and , which allow the response to be re-used after cache control would say not to re-use it: URL
Discussed in Montreal; introduce the concept of a single-use response, and carve out no-store.
Code change:
"urn:ietf:params:oauth:token-type:txn_token" "subject_token" REQUIRED.  The value MUST represent the subject of <del> the transaction.  This could be an inbound token received by an API Gateway, or a self-signed JWT constructed by a workload initiating a transaction, the type of which is identified by </del> <ins> the transaction.  This MAY be: An inbound token received by an API Gateway A self-signed JWT constructed by a workload initiating a transaction An unsigned JSON object constructed by a workload initiating a transaction Any other format that is understood by the Txn-Token Service The type of the "subject_token" field is identified by </ins> "subject_token_type". "subject_token_type" REQUIRED.  The value MUST indicate the type

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:
"urn:ietf:params:oauth:token-type:txn_token" "subject_token" REQUIRED.  The value MUST represent the subject of <del> the transaction.  This could be an inbound token received by an API Gateway, or a self-signed JWT constructed by a workload initiating a transaction, the type of which is identified by </del> <ins> the transaction.  This MAY be: An inbound token received by an API Gateway A self-signed JWT constructed by a workload initiating a transaction An unsigned JSON object constructed by a workload initiating a transaction Any other format that is understood by the Txn-Token Service The type of the "subject_token" field is identified by </ins> "subject_token_type". "subject_token_type" REQUIRED.  The value MUST indicate the type

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:
processing of invalid data. Not every hashing algorithm is suitable for use in the trailer <del> section, some may require to pre-process the whole payload before sending a message (e.g. see I-D.thomson-http-mice). </del> <ins> section, some may require to preprocess the whole payload before sending a message (e.g., see I-D.thomson-http-mice). </ins> 6.5. Content coding mechanisms can support different encoding parameters, meaning that the same input content can produce different outputs. <del> For example, GZIP supports mulitple compression levels.  Such </del> <ins> For example, GZIP supports multiple compression levels.  Such </ins> encoding parameters are generally not communicated as representation <del> metadata, for instance different compression levels would all use the same "Content-Encoding: gzip" field.  Other examples include where encoding relies on nonces or timestamps, such as the aes128gcm </del> <ins> metadata.  For instance, different compression levels would all use the same "Content-Encoding: gzip" field.  Other examples include where encoding relies on nonces or timestamps, such as the aes128gcm </ins> content coding defined in RFC8188. Since it is possible for there to be variation within content coding, the checksum conveyed by the integrity field cannot be used to <del> provide a proof of integrity "at rest" unless the whole (e.g. </del> <ins> provide a proof of integrity "at rest" unless the whole (e.g., </ins> encoded) content is persisted. 6.6.

Related discussion:
text: s/ise-case/use case e.g. -> e.g., nit pass