jiebi/CodeConvo huggingface dataset:
Code change:
2.5.4. <del> The URI generic syntax for authority also includes a deprecated userinfo subcomponent (RFC3986) for including user authentication information in the URI.  Some implementations make use of the userinfo component for internal configuration of authentication information, such as within command invocation options, configuration files, or bookmark lists, even though such usage might expose a user identifier or password.  A sender MUST NOT generate the userinfo subcomponent (and its "@" delimiter) when an "http" URI reference is generated within a message as a request target or header field value. Before making use of an "http" URI reference received from an untrusted source, a recipient SHOULD parse for userinfo and treat its presence as an error; it is likely being used to obscure the </del> <ins> The URI generic syntax for authority also includes a userinfo subcomponent (RFC3986) for including user authentication information in the URI.  In that subcomponent, the use of the format "user:password" is deprecated. Some implementations make use of the userinfo component for internal configuration of authentication information, such as within command invocation options, configuration files, or bookmark lists, even though such usage might expose a user identifier or password. A sender MUST NOT generate the userinfo subcomponent (and its "@" delimiter) when an "http" or "https" URI reference is generated within a message as a request target or header field value. Before making use of an "http" or "https" URI reference received from an untrusted source, a recipient SHOULD parse for userinfo and treat its presence as an error; it is likely being used to obscure the </ins> authority for the sake of phishing attacks. 2.5.5.

Related discussion:
text: I believe that obscuring the authority for the purposes of phishing is not really mitigated by parsing the userinfo; subdomains in DNS offer similar notational flexibility. Parsing does help against misleading password popups, but these are probably easier to remedy when credential inquiries are only made in response to and headers.
Discussed in Basel. Correcting the reasoning of why it was deprecated can be addressed editorially. Changing what was deprecated needs to be a much larger discussion and pull in the security community.
Code change:
Browser fingerprinting is a set of techniques for identifying a specific user agent over time through its unique set of characteristics.  These characteristics might include information <del> related to its TCP behavior, feature capabilities, and scripting environment, though of particular interest here is the set of unique characteristics that might be communicated via HTTP.  Fingerprinting is considered a privacy concern because it enables tracking of a user agent's behavior over time (Bujlow) without the corresponding controls that the user might have over other forms of data collection (e.g., cookies).  Many general-purpose user agents (i.e., Web browsers) have taken steps to reduce their fingerprints. </del> <ins> related to how it uses the underlying transport protocol, feature capabilities, and scripting environment, though of particular interest here is the set of unique characteristics that might be communicated via HTTP.  Fingerprinting is considered a privacy concern because it enables tracking of a user agent's behavior over time (Bujlow) without the corresponding controls that the user might have over other forms of data collection (e.g., cookies).  Many general-purpose user agents (i.e., Web browsers) have taken steps to reduce their fingerprints. </ins> There are a number of request header fields that might reveal information to servers that is sufficiently unique to enable

Related discussion:
text: For
[x] (7.6.3) Via "If a port is not provided, a recipient MAY interpret that as meaning it was received on the default TCP port, if any, for the received-protocol." So if received-protocol is "3", it's a UDP port. If received-protocol is "1" or "1.1", is the default port 80 or 443? IIUC the scheme isn't included to determine this. Editors: URL [x] (7.7) Message Transformations "A proxy that transforms the content of a 200 (OK) response can inform downstream recipients that a transformation has been applied by changing the response status code to 203 (Non-Authoritative Information)" Why not an normative word, instead of "can"? Editors: URL [x] (12.5.3) Is it correct that "identity" and having no field value for Accept-Encoding are synonymous? Editors: URL [x] "Servers that fail a request due to an unsupported content coding ought to respond with a 415 (Unsupported Media Type) status" Why not s/ought to/SHOULD ? Editors: URL [x] (14.3) Why can only origin servers send "Accept-Ranges: bytes"? Why not intermediaries? Editors: URL [x] (15.3.7) "A sender that generates a 206 response with an If-Range header field"... (13.1.5) leads me to believe that only clients can send If-Range. So how can there be a response with If-Range? Editors: URL [x] (15.3.7.2) The last instance of THISSTRINGSEPARATES has a trailing '--'. If this is intentional, it ought to be explained. Editors: URL [x] (16.3.1) says field names SHOULD begin with a letter, but (16.3.2.1) says they SHOULD begin with "an alphanumeric character". More broadly, the "Field name:" description in (16.3.1) should probably refer to (16.3.2.1) unless I'm misunderstanding the scope of these sections.
Code change:
Browser fingerprinting is a set of techniques for identifying a specific user agent over time through its unique set of characteristics.  These characteristics might include information <del> related to its TCP behavior, feature capabilities, and scripting environment, though of particular interest here is the set of unique characteristics that might be communicated via HTTP.  Fingerprinting is considered a privacy concern because it enables tracking of a user agent's behavior over time (Bujlow) without the corresponding controls that the user might have over other forms of data collection (e.g., cookies).  Many general-purpose user agents (i.e., Web browsers) have taken steps to reduce their fingerprints. </del> <ins> related to how it uses the underlying transport protocol, feature capabilities, and scripting environment, though of particular interest here is the set of unique characteristics that might be communicated via HTTP.  Fingerprinting is considered a privacy concern because it enables tracking of a user agent's behavior over time (Bujlow) without the corresponding controls that the user might have over other forms of data collection (e.g., cookies).  Many general-purpose user agents (i.e., Web browsers) have taken steps to reduce their fingerprints. </ins> There are a number of request header fields that might reveal information to servers that is sufficiently unique to enable

Related discussion:
text: Editors: URL [x] (17.13) s/TCP behavior/TCP or QUIC behavior Editors: URL [x] (B) It would be good to mention here that accept-ext has been removed in (12.5.1), and accept-charset is deprecated in (12.5.2), if that is new to this spec. Editors: see URL and URL
Because it isn't required, nor is it widely implemented (if at all). We try not to make requirements that we know won't be honoured.
Because the header is information about the capabilities of the origin server, not other members of the request chain. Intermediaries can change (e.g., with proxy configuration). Note that a gateway (e.g., a CDN) is effectively acting as an origin server, so it can do this. The language in this section needs to be tweaked, however; there are a few instances of 'server' that should be 'origin server'.
field"... (13.1.5) leads me to believe that only clients can send If-Range. So how can there be a response with If-Range? It looks like the phrase 'to a request' was dropped somewhere between and now.
this is intentional, it ought to be explained. This is how multipart works; see . I don't think there's value in re-specifying it here.
As per the spec: ...
Because we avoid making existing servers that predate this spec non-compliant (unless there's a very good reason, such as security)
Code change:
The SD-JWT and the Disclosures would then be serialized by the Issuer into the following format for issuance to the Holder: <ins> Examples of what presentations of SD-JWT VCs might look like are provided in presentation-examples. </ins> 3.4. The recipient (Holder or Verifier) of an SD-JWT VC MUST process and

Related discussion:
text: for and hopefully/maybe too URL URL URL
NAME this work and URL were largely undertaken as a result of your questions/feedback
Select parts of a conversation from an encrypted messaging service copied here. Editorial liberties have been taken to extract the most relevant parts of the discussion and protect the identities of the participants. >- the first example is just user claims that are being secured >- the second example is user claims + metadata that is necessary to be added when signing the sd-jwt IMHO it would be worthwhile to expand the example in URL with some additions to URL to also show the content of the thing that needs a name.
Seems related to
I think the understanding of the spec could be further facilitated by adding an example of a SD-JWT VC after the verifier has processed the SD-JWT VC and (basically) has constructed a JWT representation for further processing in the application.
The new PID example in draft -02/-03 shows the JSON data for "further processing" after validation: URL Does that seem sufficient? Or perhaps a similar addition to the example used in the main body of the draft ()? Or something different/more?
I personally don't understand why this applies to the verifier: "has constructed a JWT representation for further processing in the application". However, NAME has this issue been addressed by the examples NAME provided? Then we can close it.
Code change:
subscribers for each track.  Each new OBJECT belonging to the track within the subscription range is forwarded to each active subscriber, dependent on the congestion response.  A subscription remains active <del> until it expires, until the publisher of the track terminates the track with a SUBSCRIBE_DONE (see message-subscribe-done). </del> <ins> until the publisher of the track terminates the track with a SUBSCRIBE_DONE (see message-subscribe-done). </ins> Objects MUST NOT be sent for unsuccessful subscriptions, and if a subscriber receives a SUBSCRIBE_ERROR after receiving objects, it

Related discussion:
text: Note from call. Fixe subscribeDone at same time. Define a new bool type. p[ick new leatter other than b
Also make sure to fix SUBSCRIBE_DONE at the same time.
NAME - I updated, have another read and see if it looks OK. Thanks
and introduced a field to SUBSCRIBEOK, SUBSCRIBEFIN, and SUBSCRIBE_RESET. If I read the notation correctly, it has a size of 1 bit, which makes it hard to parse the rest of the message. Could we encode that information in the message type by using two types per message instead of a 1-bit field?
I think the intent is that it is one byte not one bit.
Maybe it should have been:
or just a byte field with only 2 possible values allowed (1) and (0) ..
I agree we need to keep this byte aligned however we do it.
IMO just make it a VarInt (or byte), with only values of 0 and 1 currently valid. This encoding is temporary until we nail down all of the fields/flags so we shouldn't be making life difficult or efficient.
Individual Comment: Even if it's temporary, my preference is for a one-bit field and unused/reserved bits to align, because there are no error conditions.
Have a look at PR
Code change:
subscribers for each track.  Each new OBJECT belonging to the track within the subscription range is forwarded to each active subscriber, dependent on the congestion response.  A subscription remains active <del> until it expires, until the publisher of the track terminates the track with a SUBSCRIBE_DONE (see message-subscribe-done). </del> <ins> until the publisher of the track terminates the track with a SUBSCRIBE_DONE (see message-subscribe-done). </ins> Objects MUST NOT be sent for unsuccessful subscriptions, and if a subscriber receives a SUBSCRIBE_ERROR after receiving objects, it

Related discussion:
text: And add a new SUBSCRIBE_DONE status code. Fixes part of , but it's still unclear how one might refresh a subscription without interruption.
Subscriptions always end with either SUBSCRIBEFIN or SUBSCRIBERESET, except when they Expire and then no control message is sent. This complicates the state machine and adds another case to handle. The subscriber needs to start a timer or something similar to know when the subscription will end, and it doesn't get to know the final group or object ID.
I'd like to get rid of , but my thought was that it's a signal to SUBSCRIBE again before the timeout to avoid interruption. Otherwise, there would be a SUBSCRIBE_RESET with an "expired" error code containing the final group/object.
I agree that a subscriber can deal with this field, but I don't know what purpose it serves for the publisher/relay? It's different from an idle connection timeout, because assuming there is data flowing for the subscription, it would never go idle. Unlike QUIC, I don't see value in having a 'silent close' for subscriptions, because typically we expect subscriptions to have data flowing at a somewhat regular interval. Also, there's no guarantee that the subscription will last until the expiry time, it can always end early with SUBSCRIBEFIN or SUBSCRIBERESET.
Based on last week's conversation, the Expires field doesn't change the state of the subscription by itself, a publisher would still have to send a FIN or RESET to close it. It's still unclear as to what a subscriber should do with it. There was a fair amount of discussion around refreshing one's authorization. It's unclear if that would be done with a SUBSCRIBE_UPDATE or something similar or via UNSUBSCRIBE/SUBSCRIBE?
Would the solution to this be when the relay expires a subscription, it sends a control message ? This might all become clearer once we figure out re authentication but at a high level, I want some way that the relays can clean up state on a time line that is under relay control particularly when poorly implemented clients make subscriptions.
I think this was resolved by -
LGTM
Code change:
6.1.1.1. <del> The GROUP SEQUENCE parameter (key 0x00) identifies the group within the track to start delivering objects in a SUBSCRIBE message.  The publisher MUST start delivering the objects from the most recent group, when this parameter is omitted.  The value is of type varint. 6.1.1.2. The OBJECT SEQUENCE parameter (key 0x01) identifies the object with the track to start delivering objects in a SUBSCRIBE message.  The "GROUP SEQUENCE" parameter MUST be set to identify the group under which to start delivery.  The publisher MUST start delivering from the beginning of the selected group when this parameter is omitted. The value is of type varint. 6.1.1.3. </del> AUTHORIZATION INFO parameter (key 0x02) identifies a track's authorization information in a SUBSCRIBE or ANNOUNCE message.  This parameter is populated for cases where the authorization is required

Related discussion:
text: This were replaced in Subscribe Locations (hints)
These parameters have been replaced with explicit fields in the SUBSCRIBE message. All that's left (outside of SETUP) is AUTHORIZATIONINFO in SUBSCRIBE and ANNOUNCE. I would just as soon get rid of non-setup parameters entirely and have an "authinfolength" field in the messages which can be zero. At a minimum, we need to eliminate GROUP and OBJECT_SEQUENCE.
+1 I would go even further and make a dedicated AUTH message.
Whoops, those were deleted but must have been re-added in a merge conflict.
Code change:
7.1. This memo registers the "encrypted" HTTP content-coding in the HTTP <del> Content Codings Registry, as detailed in aesgcm128. </del> <ins> Content Codings Registry, as detailed in aesgcm. </ins> <del> Name: aesgcm128 </del> <ins> Name: aesgcm </ins> Description: AES-GCM encryption with a 128-bit content encryption key

Related discussion:
text: In order to allow existing applications to update from one octet of padding per record to two (PR , Issue ), this PR renames "aesgcm128" to "aesgcm" as the value for the Content-Encoding header, as well as the parameter name in the Crypto-Key header. This also affects the context used for deriving the nonce and the content encryption key. Examples have been updated. What I did not update is the JWE mapping (currently "A128GCM"). Do we wish to change that to "AGCM", which may be less descriptive?
NAME - for your consideration I updated the hashes, but would like you to verify those when you've got a moment (they include the uint8 -> uint16 change). I wasn't able to reproduce the output of the explicit example using the current spec.
Awesome. I'm still awaiting the return of my implementation (I'm annoyed that I put it on a boat), but I will verify when able. It's entirely possible that one (or more) of the examples are in error.
I still need to double-check the examples, but I won't be able to do that for a while now. Stupid travel. Might as well make progress at least. Thanks for putting this all together NAME
Each record currently includes between 1 and 256 octets of padding, while the default record size is set to 4096 octets. This is in many cases not sufficient, for example in the pad-to-next-power-of-two case. Extending the padding length to two octets will allow up to 65537 octets (65KB) of padding. I raised this on the ietf-http-wg list here: URL Martin about an upgrade path for existing users. I'll reply on the mailing list to not split the discussion.
This was fixed in and .
Code change:
replacement Txn-Token.  The TTS MUST ensure there is not unintentional increase in authorization scope. <ins> 9.7. A Txn-token typically represents the call-chain of workloads necessary to complete a logical function initiated by an external or internal workload.  The "txn" claim in the Txn-token provides a unique identifier that when logged by the TTS and each subsequent workload can provide both discovery and auditability of successful and failed transactions.  It is therefore strongly RECOMMENDED to use an identifier, unique within the trust domain, for the "txn" value. </ins> 10. 10.1.

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:
Recommended HTTP status code: 400 <del> 2.3.30. </del> <ins> 2.3.26. </ins> Name: http_upgrade_failed

Related discussion:
text: PTAL NAME NAME NAME
Looks reasonable to me!
NAME PTAL; I'll merge tomorrow if I don't hear anything.
NAME how do you distinguish between a proxy certificate and the certificate used for the next hop?
By "proxy certificate" I mean the certificate sent by the CDN (when acting as a client) to the origin server for the purpose of mutual authentication. In contrast, would apply (at least in my mind) only to the certificate presented by the origin server.
So, I think the argument is that is either a (i.e., the server you're connecting to gave you an error to the effect that you need to present a client certificate), or a (i.e., you realised you need to present a certificate before connecting, but don't have one) depending on exactly how the error occurred. Is that sufficient?
As someone who spent countless hours debugging connection issues to various origin servers, my main concern is that alone doesn't provide enough information as to why the connection failed, it only narrows it down to a TLS certificate issue, but for anything definitive that you would want to share with the customer, you'd still need to go and dig further into logs, or try to replicate the issue. Yes, I know that you could put more information in the "details" field, but I'm not a big fan of implementation-specific free-form text. Having said that, I'm not going to oppose if you prefer to have only those 3 generic fields.
Thanks. As Ryan points out, the problem is that implementations have different terminology and granularity of error reporting, and it's not the place of this specification to impose that on them.
Looking at what to map x509 errors (as returned by into, the most obvious one is . However, there's also , which is one of these errors. It seems odd to have these two, but not any of the many other verification errors. At first glance, I suspect it may be better to have a single error, and let the convey the reason - whether it's expiration or something else.
Ultimately, there is a fine balance between providing a generic "catch-all" error, and enumerating all possible errors. The linked lists 69 possible reasons for success or failure, and including all of them clearly doesn't make sense, especially when only a few of them will happen in practice.
Code change:
Recommended HTTP status code: 400 <del> 2.3.30. </del> <ins> 2.3.26. </ins> Name: http_upgrade_failed

Related discussion:
text: However, having only a generic "catch-all" error with the real reason "hidden" in a free-form text in , that's going to vary from implementation to implementation, is going to make this less useful for any kind of automated processing and/or analysis. Ideally, I think, we should have specific enums that cover 95%+ of reasons happening in production, and only use the generic "catch-all" error for things not covered by them... So, playing the devil's advocate, perhaps we should add a few more? (Note that there is already raised on mismatched identity, SHA256, SPKI or other missed expectations.) Also, if you can get your hands on errors happening in production, that could help us make more informed decision here.
I agree we shouldn't do a 1:1 mapping (especially with a library), but the hierarchy needs to be clear, and mapped to terminology used in the standards. I.e., there should be a generic catch-all 'cert error' code, and then more specific ones for the major classes of problems.
TLS itself also contains a pile of certificate-verification-related alerts. Although I think the set is mostly just carried over from SSL. URL NAME may also have some thoughts on certificate verification error-reporting.
Despite what libraries may provide, for their developers, is fairly clear: the only defined result is a I think coupling any protocol-level expectation about diagnostics for errors is fundamentally misaligned. It should not matter, for example, whether a particular library checks the validity period of the certificate before the signature. We know, empirically, that different libraries do very different things there: macOS vs Mozilla NSS vs Microsoft CryptoAPI each verify something like validity at different points within their verification algorithms. We know it's deeply flawed to view there being "the" certificate chain for a server, because by definition, the chain is defined by the client's policy and set of trust anchors. As a consequence, we know that clients SHOULD implement certificate path building, to explore possible certificate chains, and we know that TLS 1.3 was explicitly updated to reflect those decades of running code and the emergent rough consensus that the message, beyond the first , is an attempt to aid/influence that. is a huge collection of different ways verifiers can process and examine errors, during forward path building and reverse verification, and notes that the trade-offs are heavily dependent upon client and use cases.