jiebi/CodeConvo huggingface dataset:
Code change:
received prior to the request-line. A sender MUST NOT send whitespace between the start-line and the <del> first header field.  A recipient that receives whitespace between the start-line and the first header field MUST either reject the message as invalid or consume each whitespace-preceded line without further processing of it (i.e., ignore the entire line, along with any subsequent lines preceded by whitespace, until a properly formed header field is received or the header section is terminated). The presence of such whitespace in a request might be an attempt to trick a server into ignoring that field line or processing the line after it as a new request, either of which might result in a security vulnerability if other implementations within the request chain interpret the same message differently.  Likewise, the presence of such whitespace in a response might be ignored by some clients or cause others to cease parsing. </del> <ins> first header field. A recipient that receives whitespace between the start-line and the first header field MUST either reject the message as invalid or consume each whitespace-preceded line without further processing of it (i.e., ignore the entire line, along with any subsequent lines preceded by whitespace, until a properly formed header field is received or the header section is terminated).  Rejection or removal of invalid whitespace-preceded lines is necessary to prevent their misinterpretation by downstream recipients that might be vulnerable to request smuggling (request.smuggling) or response splitting (response.splitting) attacks. </ins> When a server listening only for HTTP request messages, or processing what appears from the start-line to be an HTTP request message,

Related discussion:
text: "Highest ordered" implies some numerical rank-list of ordering, but we don't seem to clearly indicate whether older or newer requests receive higher numerical indices. It seems simples to just say "oldest" (or "newest", if that was the intent) rather than applying numerical ranking. Editors:
closure alert is received, an implementation can be assured that no further data will be received on that connection. TLS implementations MUST initiate an exchange of closure alerts before closing a connection. A TLS implementation MAY, after sending a closure alert, close the connection without waiting for the peer to send its closure alert, generating an "incomplete close". [...] TLS implementations (not placing restrictions on what TLS implementations are suitable for HTTPS). Fortunately, these "MUST initiate" and "MAY close without waiting" requirements seem to already be present in RFC 8446... I'm not a TLS expert. That said, if this is correct, would be lowercasing the two keywords be sufficient?
URL is for section 9.8
Change for 9.8 LGTM (as what might pass for a TLS expert).
Code change:
For example, given the following message: <del> ```http-message HTTP/1.1 200 OK Content-Type: text/plain Transfer- Encoding: chunked Trailer: Expires 4 HTTP 7 Message 10 Signatures 0 Expires: Wed, 9 Nov 2022 07:28:00 GMT ``` </del> The signer decides to add both the Trailer header field as well as <del> the Expires trailer to the signature base: ""@status": 200 "trailer": Expires "expires";tr: Wed, 9 Nov 2022 07:28:00 GMT " </del> <ins> the Expires trailer to the signature base, along with the status code derived component: </ins> <del> IF a field is available as both a header and trailer in a message, both values MAY be signed separately.  The values of header fields and trailer fields of the same name MUST NOT be combined. </del> <ins> If a field is available as both a header and trailer in a message, both values MAY be signed, but the values MUST be signed separately. The values of header fields and trailer fields of the same name MUST NOT be combined for purposes of the signature. </ins> Since trailer fields could be merged into the header fields or dropped entirely by intermediaries as per HTTP, it is NOT RECOMMENDED

Related discussion:
text: The HTTP message in Sec. 2.1.4 of draft -14 is not formatted correctly (both HTML and plain text).
NAME
Code change:
This document uses the Augmented Backus-Naur Form (ABNF) notation of RFC5234 with the list rule extension defined in RFC7230, Appendix B. <del> It includes by reference the DIGIT rule from RFC5234; the OWS, field- name and quoted-string rules from RFC7230; and the parameter rule from RFC7231. </del> <ins> It includes by reference the DIGIT rule from RFC5234 and the OWS and field-name rules from RFC7230. </ins> 2.

Related discussion:
text: WIP.
NAME NAME quick once over before I merge?
NAME thanks, updated, squashed.. merging.
:
: The and rules are not used in the document. The rule is not used in the document, unless you accept . The rule is not used in the document, but I think it can be useful to clarify the definition of , i.e.:
I agree that using "field-name" over there makes this a bit clearer.
Addressed in: URL
Code change:
Ranges are expressed in terms of a range unit paired with a set of range specifiers.  The range unit name determines what kinds of range-spec are applicable to its own specifiers.  Hence, the <del> following gramar is generic: each range unit is expected to specify </del> <ins> following grammar is generic: each range unit is expected to specify </ins> requirements on when ,

Related discussion:
text: The first is an incorrect change -- "advance configuration" means configured prior to the request, not "advanced". The second is indeed a typo.
Roman Danyliw has entered the following ballot position for draft-ietf-httpbis-semantics-16: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to URL for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: URL COMMENT: [x] ** Section 2.2. Per “Additional (social) requirements are placed on implementations …”, what’s a “social” requirement? Editors: removed in (URL)
[x] ** Section 4.2.2. http + https origins on the same host uniformly. Editors: added text in
[x] ** Section 5.1. Convention question. Per “Field names … ought to be registered within the …” HTTP field name registry, I have a question about the strength of the recommendation based on the use of the verb “ought” – is that RECOMMENDED? SHOULD? Section 8.3.1, 8.3.2, 8.4.1, 8.8.3, etc use a similar construct. Editors: we intentionally do not to use normative language for registration requirements.
[x] ** Section 7.2. Does this text allow for the possibility for both a Host and :authority be included? Editors: it's syntactically possible in H2 and H3. It's up to those specs to describe what that would mean.
[x] ** Section 9.2.1. In addition to example of the access logs files filling the disk, there could be significant CPU load if the target is a script. Editors: URL
[x] ** Section 17.1. The text provides helpful caution by stressing that “… the user's local name resolution service [is used] to determine where it can find authoritative responses. This means that any attack on a user's network host table, cached names, or name resolution libraries becomes an avenue for attack on establishing authority for "http" URIs.” The subsequent text highlights DNSSEC as improving authenticity.
Code change:
Ranges are expressed in terms of a range unit paired with a set of range specifiers.  The range unit name determines what kinds of range-spec are applicable to its own specifiers.  Hence, the <del> following gramar is generic: each range unit is expected to specify </del> <ins> following grammar is generic: each range unit is expected to specify </ins> requirements on when ,

Related discussion:
text: It seems that the integrity provided by DoT or DoH would also be relevant. Editors: added text in (see also URL)
[x] ** Section 17.2 people who run them; HTTP itself cannot solve this problem. No disagreement with the sentiment, but I would recommend not framing it in term of the trustworthiness of the people (i.e., intermediaries with poor security or privacy practices is not necessarily due to the lack of trustworthiness of the engineers operating the service; perhaps these services are also run in of jurisdictions where confidence in them should be reduced). NEW Users need to be aware that intermediaries are no more trustworthy that the entities that operate them and the policies governing them; HTTP itself cannot solve this problem. Editors: URL
[x] ** Section 17.5. More generically describe the attack OLD NEW Editors: d466398e
** Editorial
[x] -- Section 3.5. Should s/advance configuration choices/advanced configuration choices/? Editors: no, advance has the same meaning as "configuration choices made prior to request"
[x] -- Section 4.2.2. This text goes from referring to “secured” in the first sentence to “[acceptable] cryptographic mechanisms” in the second sentence. To link them, perhaps s/are secured/are cryptographically secured/ Editors: "secured" is a defined term for this spec.
[x] -- Section 6.5. Typo. s/section are are/section are/ Editors: URL
[x] -- Section 11.1. The text (at least when read as a .txt) isn’t showing RFC7617 or RFC7616 as references. Editors: it does in HTML: URL
[x] -- Section 14.1.1. Typo. s/gramar/grammar/ Editors: URL
disk, there could be significant CPU load if the target is a script. Yes. But this is the definition of "safe methods", not a discussion of all potential attack vectors of a server.
user's local name resolution service [is used] to determine where it can find authoritative responses. This means that any attack on a user's network host table, cached names, or name resolution libraries becomes an avenue for attack on establishing authority for "http" URIs.” The subsequent text highlights DNSSEC as improving authenticity.
Code change:
Ranges are expressed in terms of a range unit paired with a set of range specifiers.  The range unit name determines what kinds of range-spec are applicable to its own specifiers.  Hence, the <del> following gramar is generic: each range unit is expected to specify </del> <ins> following grammar is generic: each range unit is expected to specify </ins> requirements on when ,

Related discussion:
text: It seems that the integrity provided by DoT or DoH would also be relevant. Understood. Q: do we attempt an exhaustive list here, or just mention examples? If we did mention DoT and DoH, woulkd that be exhaustive?
By nature I don't think we can be exhaustive here. If anything, I'd replace DNSSEC with DoH, as it's getting more adoption (both in implementation and deployment) on the web.
http + https origins on the same host uniformly. We already say that in several places, and I don't think repeating ourselves helps the document become more readable or useful.
There are technical interop requirements for the protocol and social requirements to keep people safe on the Internet (or the Web safe from the people abusing it). This is just a short-hand version of old IETF lore, and probably isn't worth repeating in the spec.
Code change:
Digest can be used in requests too.  Returned value depends on the representation metadata header fields. <ins> 7.1.5. The response contains two digest values: one with no content coding applied, which in this case accidentally matches the unencoded digest-value sent in the request; one taking into account the "Content-Encoding". </ins> 7.2. 7.2.1.

Related discussion:
text: Adds id-sha-* algorithm examples throughout the document.
draft-ietf-httpbis-digest-headers includes examples of sha-256 in the Digest header value, but no examples of the two new algorithms it introduces: id-sha-256 and id-sha-512. Examples would be extremely useful to illustrate the difference between sha-256 and id-sha-256.
That sounds reasonable to me.
NAME WDYT?
Code change:
This field is optional and is only present if the PRIORITY flag is set. <del> Padding size high bits.  This field is only present if the PAD_HIGH flag is set. Padding size low bits.  This field is only present if the PAD_LOW flag is set. </del> A HeaderBlock. Padding octets.

Related discussion:
text: Padding is made to a frame and other frames (DATA and CONTINUATION) have these 2 bytes right after the frame header. It is easier for implementation to put the same constructs in the same position.
Code change:
of an underlying connection failure, as described in idempotent.methods. <ins> 2.5. HTTP's version number consists of two decimal digits separated by a "." (period or decimal point).  The first digit ("major version") indicates the messaging syntax, whereas the second digit ("minor version") indicates the highest minor version within that major version to which the sender is conformant (able to understand for future communication). While HTTP's core semantics don't change between protocol versions, the expression of them "on the wire" can change, and so the HTTP version number changes when incompatible changes are made to the wire format.  Additionally, HTTP allows incremental, backwards-compatible changes to be made to the protocol without changing its version through the use of defined extension points (extending). The protocol version as a whole indicates the sender's conformance with the set of requirements laid out in that version's corresponding specification of HTTP.  For example, the version "HTTP/1.1" is defined by the combined specifications of this document, "HTTP Caching" Caching, and "HTTP/1.1" Messaging. HTTP's major version number is incremented when an incompatible message syntax is introduced.  The minor number is incremented when changes made to the protocol have the effect of adding to the message semantics or implying additional capabilities of the sender. The minor version advertises the sender's communication capabilities even when the sender is only using a backwards-compatible subset of the protocol, thereby letting the recipient know that more advanced features can be used in response (by servers) or in future requests (by clients). When a major version of HTTP does not define any minor versions, the minor version "0" is implied and is used when referring to that protocol within a protocol element that requires sending a minor version. </ins> 3. HTTP was created for the World Wide Web (WWW) architecture and has

Related discussion:
text: and only define the versioning there; leave message version requirements in control data. (no content changes)
Code change:
is used to express a type: <del> For example, a type </del> <ins> For example, a value of </ins> can be associated with rules that define that at least the registered JWT claims

Related discussion:
text: This PR renames the claim to , as per the discussion in
I oppose against this change. I suggest to use 'vct' instead.
I'm good with . For the record, I think it's important to move away from , because URL uses the claim name, but with a different syntax. Keeping the naming conflict will inevitably lead to grief.
Naming is hard. Regarding dct: isn't it obvious for an internet standard that we refer to digital credentials?
Neither dct nor vct are intuitive for me, so I am pretty unsure. But between dct and vct, I would prefer dct. A term Verifiable credentials got enough feedback that it has strong too strong of an association to W3C VC-DATA-MODEL. And Digital credentials seems to be a term that is acceptable to generalize.
Why is "Verifiable Credential Type" (vct) not intuitive to you? This would match the current definition of . Isn't this what this claim is about? That is why I'm actually in favor of over , .
I meant that abbreviations are not intuitive to me. And "type" is a pretty JSON-LD specific construct AFAIK so I was hoping we could have a deeper discussion on whether it should be called "claimset" or something. If we are to move away from "type" claim name. on dct and vct, as I explained, I prefer something that is not associated to W3C VCDM and digital credentials seems to be pretty well understood.
If the color of the bikeshed is still open for debate, how about just for credential type?
I like 3-letter-names more than 2-letter-names for some reason. Also, is more accurate since the spec is about SD-JWT VCs => Verifiable Credentials. I'd be still in favor of for that reason.
is fine for me. Updated the PR accordingly.
is fine for me too. was just an off-hand idea
Merging this PR since a lot of approvals. We will have a larger conversation on what is inferred by the value in a separate issue.
I suggest to use 'vct'.LGTM. We should address NAME concern in a separate issue.This is an improvement.
Code change:
response that they would have used for non-existent resources.  For example, this can mean using HTTP status code 404 (Not Found) instead of 401 (Unauthorized).  Such authentication failures can be caused <del> for example by: * absence of the Unprompted-Authentication field * failure to parse the Unprompted-Authentication field * use of Unprompted Authentication with an unknown key ID * failure to validate the signature or MAC. </del> <ins> for example by: * absence of the Authorization field * failure to parse the Authorization field * use of the Signature authentication scheme with an unknown key ID * failure to validate the signature. </ins> Such servers MUST also ensure that the timing of their request handling does not leak any information.  This can be accomplished by delaying responses to all non-existent resources such that the timing of the authentication verification is not observable. <del> 7. </del> <ins> 6. </ins> <del> Since the Signature and HMAC HTTP Authentication Schemes leverage TLS keying material exporters, their output cannot be transparently forwarded by HTTP intermediaries.  HTTP intermediaries that support this specification have two options: </del> <ins> Since the Signature HTTP authentication scheme leverages TLS keying material exporters, its output cannot be transparently forwarded by HTTP intermediaries.  HTTP intermediaries that support this specification have two options: </ins> The intermediary can validate the authentication received from the client, then inform the upstream HTTP server of the presence of

Related discussion:
text: But I don't feel strongly about this one so I'm happy to not include it if it's the WG's preference.
Just saying here's a registry that you might could co-opt: URL Defined by URL
This is an existing registry of hash algorithms with string identifiers: URL Defined by URL
Discussed at IETF 116, sense of the room appeared to be that removing the HMAC feature entirely and switching to the TLS SignatureScheme registry for signatures was the simplest solution here.
OK wrote up to address this
Is there a technical reason why the header was not chosen for this draft? That can be sent without a corresponding challenge (in an unprompted way), as we note in the . It seems like that would work in this context, too.
Is this rather about using the Authorization header?
Yep!
NAME can you elaborate on "as we note in the "? I skimmed through that draft and it seems to clearly require a TokenChallenge before sending a Token.
I thought we had text that described it, but I can't find it. In any case, I think one can send the Authorization header unsolicited, so I think this draft ought to do that instead of rolling a new auth header.
Fair enough, let's discuss this at 116.
FWIW, I agree that unprompted "Authorization" is permissible in this context, but I think "Unprompted-Authorization" could be useful for clarity when reading logs, etc.
Discussed at IETF 116, sense of the room appeared to be that switching to Authorization made sense.
OK wrote up to address this
Code change:
The goals do not include: <del> The digest mechanism described here does not cover the full HTTP message nor its semantic, as representation metadata are not included in the checksum. </del> <ins> Digest mechanisms do not cover the full HTTP message nor its semantic, as representation metadata is not included in the checksum. </ins> <del> The digest mechanisms described here cover only representation and selected representation data, and do not protect the integrity of </del> <ins> Digest mechanisms cover only representation and selected representation data, and do not protect the integrity of </ins> associated representation metadata or other message fields. <del> The digest mechanisms described here are not meant to support authentication of the source of a digest or of a message or anything else.  These mechanisms, therefore, are not a sufficient defense against many kinds of malicious attacks. </del> <ins> Digest mechanisms do not support authentication of the source of a digest, message or anything else.  These mechanisms, therefore, are not a sufficient defense against many kinds of malicious attacks. </ins> Digest mechanisms do not provide message privacy. <del> The digest mechanisms described here are not meant to support authorization or other kinds of access controls. </del> <ins> Digest mechanisms do not support authorization or other kinds of access controls. </ins> 1.4. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <del> "OPTIONAL" in this document are to be interpreted as described in BCP 14 (RFC2119 and RFC8174) when, and only when, they appear in all </del> <ins> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all </ins> capitals, as shown here. This document uses the Augmented BNF defined in RFC5234 and updated

Related discussion:
text: This ended up being more changes than I first intended but I think most of them are uncontroversial and simply improve consistency through the document.
LGTM. Thanks NAME and Happy New Year!
Code change:
Section 6.5.1 of SEMANTICS. When an incremental digest-algorithm is used, the sender and the <del> receiver can dynamically compute the digest value while streaming the </del> <ins> receiver can dynamically compute the checksum while streaming the </ins> content. 5.

Related discussion:
text: Consistent use of "checksum".
From NAME WGLC review: Personally, I think the use of both terms is ok. Mainly because digest is overloaded in the document. But it wouldn't hurt us to review the document for usages and perhaps add a note in notational conventions about the use of terms.
is a generic checksum computation, should be the actual digest algoritm computation. We need to clarify this and probably introduce new terminology.
Code change:
Object Sequence: An integer always starts at 0 with in a Group and increases sequentially.  Object Sequences are scoped to a Group. <del> Object Delivery Order: An integer indicating the object delivery order (delivery-order). </del> <ins> Object Send Order: An integer indicating the object send order (send-order). </ins> Object Payload: The format depends on the track container (containers).  This is a media bitstream intended for the decoder

Related discussion:
text: Matches the terminology used by W3C is generally much better. This is the order at which objects are sent, but does not guarantee delivery in this order. Doesn't preclude further conversations about prioritization.
This is just a rename so maybe merge it after fixing conflicts (you'll need another approval), or abandon? Based on the discussion today we'll be updating the priority section to indicate other possibilities for expressing priority.
Looks good to me. I would like to see this merged soon, so we can make the proper references to "send order" in the additional PRs.I do think that send order make more sense than delivery order but the parts of this that have to do with the prioritization scheme should probably be moved to a new section of the draft where we talk about the algorithms to decide what to send next.