jiebi/CodeConvo huggingface dataset:
Code change:
Recommended HTTP status code: 500 <del> 2.3.33. </del> <ins> 2.3.29. </ins> Name: proxy_configuration_error

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: 500 <del> 2.3.33. </del> <ins> 2.3.29. </ins> Name: proxy_configuration_error

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.
Code change:
Recommended HTTP status code: 500 <del> 2.3.33. </del> <ins> 2.3.29. </ins> Name: proxy_configuration_error

Related discussion:
text: While I can understand the appeal for providing 'informational' statuses, any suggestion beyond a level of is probably too normative, and unsupported by the underlying specifications and best practices.
NAME the context here is a CDN or other reverse proxy reporting back errors in HTTP response headers, for debugging. There are no requirements around sending them (and senders are cautioned against leaking information that could aid an attacker). So, at one end a Boolean doesn't really help, and at the other end, the full list of errors by any one library (or all of them) is impractical. The list of alerts from NAME seems promising, and I note that we already have , whose value can be any TLS Alert string. However, That's intended to convey alerts received (and perhaps we should communicate that more clearly). The desired semantics here are that the problem indicated by the alert is generated in the client itself, not received by it. That leads me to believe that there are two viable paths forward: Rearrange the errors so that they mirror the alerts above (leaving 's semantic as stated above); e.g., we'd have , , and so forth Reduce everything into two errors, and or similar. Both would carry the TLS Alert value as an additional payload item. I think the difference is mostly stylistic, so NAME and I can figure that out. The bigger question is whether this is the right set of errors to focus upon.
But I think this is missing an important detail: from the perspective of a client, the only stable output is the boolean. For example, OpenSSL's reporting of errors is symptomatic of deeper flaws within its certificate verification; fixing those errors necessarily means some existing errors can't effectively be reported. This is covered at some length in . Ultimately, the set of errors that are relevant are, to an extent, subject to local policy: it's rare for certificate validators to think of errors in the ontology laid out by the TLS layer. Typically, a client just does a "best guess" (or just maps straight to ) when trying to map to the TLS layer, in part so it doesn't disclose extra information. This is certainly true when you think about local policy, such as limits on validity or the requirement of associated metadata, potentially delivered over TLS, such as Certificate Transparency or OCSP Must-Staple.
Code change:
Recommended HTTP status code: 500 <del> 2.3.33. </del> <ins> 2.3.29. </ins> Name: proxy_configuration_error

Related discussion:
text: I think the core question is whether you expect the client and the proxy to be in the same management domain. If they aren't, and the ED seems to be oriented around this scenario (where server and proxy are likely same administrative domain, but proxy and client aren't), then it seems better served as an opaque diagnostic string. As RFC 4158 calls out, beyond the 'boolean' is really just an administrative/diagnostic capability, not something meant to be semantically rich, meaningful, or stable, and certainly not to allow next-hop policy decision making.
Just to be clear - the user agent isn't involved in this at all, beyond receiving the header so as to make it available to someone diagnosing a problem (Likely someone from the origin, from the CDN/reverse proxy operator, and/or a help desk talking to an end user). What I think I hear you saying is that we should define a generic error and allow implementations to convey textual detail in it. Does that make sense? I also still see some value in distinguishing a TLS alert received from the origin by the proxy (in its role as TLS client) from this case (a problem it encounters as a TLS client).
Yes. This matches with Criterion 2 of URL and the dual mode trade-off in URL , which perhaps more clearly highlights the local policy aspect ("Ultimately, the developer determines how to handle the trade-off between efficiency and provision of information"). 100% agreed here. I was only commenting to the extent at which the proxy validates the peer certificate independent of the TLS layer framing. Perhaps poorly stated, but my comment in URL was trying to capture that Option 2 from URL () would likely just reduce to a boolean anyways, in a well-behaved TLS client.
Code change:
3.2.2. The client makes a request to the token endpoint by sending the <del> following parameters using the "application/x-www-form-urlencoded" format per application-x-www-form-urlencoded with a character encoding of UTF-8 in the HTTP request content: </del> <ins> following parameters using the form-encoded serialization format per form-serialization with a character encoding of UTF-8 in the HTTP request content: </ins> REQUIRED.  Identifier of the grant type the client uses with the particular token request.  This specification defines the values

Related discussion:
text: This moves the description of serializations to the appendix part of
Though i wonder whether the Authorization Response () section should account for the extension - URL with text like "unless specified otherwise by an extension".
yeah I can add that, sounds reasonable
added a lot of text around how clients form authorization requests, the language does not however account for the optional POST binding at the authorization endpoint. Sections and do not account for the optional POST binding which uses the request body to carry the encoded parameters. In OIDC there's the request parameters.
This has been resolved in , there is now a section that describes the serialization methods in an appendix, which is referenced elsewhere in the spec: URL
LGTM
Code change:
Note that the same component name MAY be included with and without the "req" parameter in a single signature base, indicating the same <del> named component from both the request and response message. </del> <ins> named component from both the request and response message, respectively. </ins> The "req" parameter MAY be combined with other parameters as appropriate for the component identifier, such as the "key" parameter for a dictionary field. <del> For example, when serving a response for this signed request: </del> <ins> For example, when serving a response for this request: </ins> This would result in the following unsigned response message: The server signs the response with its own key, including the "@status" code and several header fields in the covered components. <del> To cryptographically link the response to the request, the server includes the method, authority, and the signature and signature input labeled "sig1" from the request in the covered components of the response.  The signature base for this example is: </del> <ins> While this covers a reasonable amount of the response for this application, the server additionally includes several components derived from the original request message that triggered this response.  In this example, the server includes the method, authority, path, and content digest from the request in the covered components of the response.  The Content-Digest for both the request and the response are included under the response signature.  For the application in this example, the query is deemed not to be relevant to the response and is therefore not covered.  Other applications would make different decisions based on application needs as discussed in application. The signature base for this example is: </ins> The signed response message is:

Related discussion:
text: Reframe use cases that had previously signed signature values to avoid problems with this approach.
This looks good to me! Summary of the changes: Explicitly flagging that the application / implementer must specify how request-response binding is to be achieved (if desired). Removed all references to request-response binding in the main body. Removed all signatures of signatures from the examples Added guidance that applications SHOULD sign all signed components of a request when generating a signed response. Added guidance that generating signatures of signatures is NOT RECOMMENDED when generating responses. Added guidance that generating signatures of signatures is NOT RECOMMENDED when acting as a proxy between a request / response.
Code change:
in this document are to be interpreted as described in I-D.ietf- httpbis-semantics. <del> The definition "validator" in this document is to be interpreted as described in Section 10.2 of I-D.ietf-httpbis-semantics. </del> <ins> The definition "validator fields" in this document is to be interpreted as described in Section 10.2 of I-D.ietf-httpbis- semantics. </ins> 2.

Related discussion:
text: "validator" refers to validator fields used in preconditions. The term validator fields seems more faithful to the original cache-validators in RFC3230. URL and URL
Code change:
A receiver issues a SUBSCRIBE to a publisher to request a track. <del> 6.4.1. The receiver specifies a start and optional end "Location" for the subscription.  A location value may be an absolute group or object sequence, or it may be a delta relative to the largest group or the largest object in a group. There are 4 modes: None (0x0): The Location is unspecified, Value is not present Absolute (0x1): Value is an absolute sequence RelativePrevious (0x2): Value is a delta from the largest sequence. 0 is the largest sequence, 1 is the largest sequence - 1, and so on. RelativeNext (0x3): Value is a delta from the largest sequence.  0 is the largest sequence + 1, 1 is the largest sequence + 2, and so on. The following table shows an example of how the RelativePrevious and RelativeNext values are used to determine the absolute sequence. 6.4.2. </del> The format of SUBSCRIBE is as follows: Subscribe ID: The subscription identifier that is unique within

Related discussion:
text: Based on
Consider the following sequence of groups and objects, some already produced , some that will be produced in the future. The largest group ID is currently 23 and the largest object ID is 3 (it also happens to be the last object in the group). ! Our definitions for RelativePrevious and RelativeNext are shown here. Example 6.4.3.1 for 'now' shows In our example, largest group is 23, however Largest Object + 1 is 4, which does not exist. We need to adjust the definition of RelativeNext to allow for the fact that the next object may be in a different group. There may be some players who simply want the relay to send the next available Object, in this example Object 0 of group 24. There is no current way to reliably ask for this, because StartGroup mode cannot be 'none', and we don't know which group that object will belong to. It may be in the currently largest group, or it may be in the next group. A solution here would be to relax the constraint that StartGroup mode cannot be 'none'. If we then request it would instruct the relay "Send me your next object, no matter which group it belongs to". In 6.4.3 we have examples titled 'Now', 'Current', "previous" and 'Next". 'Now', 'Current' are synonymous to most readers. We need to better titles to illustrate what is actually being requested here. Additionally, "Previous' doesn't indicate whether we want the previous group, or previous object. Similarly for next.
Individual Comment: You are right that the example (and the text likely) don't show the full range of possibilities for what the next object will be. The intent was that Start = Prev/0, Next/0 will get you the next object, which could be any object in the current group greater than largest, or the first object in the next group. This is how my implementation handles it. I don't see a way to get only the next object in the current draft, however, because of the ambiguity you describe.
Code change:
A receiver issues a SUBSCRIBE to a publisher to request a track. <del> 6.4.1. The receiver specifies a start and optional end "Location" for the subscription.  A location value may be an absolute group or object sequence, or it may be a delta relative to the largest group or the largest object in a group. There are 4 modes: None (0x0): The Location is unspecified, Value is not present Absolute (0x1): Value is an absolute sequence RelativePrevious (0x2): Value is a delta from the largest sequence. 0 is the largest sequence, 1 is the largest sequence - 1, and so on. RelativeNext (0x3): Value is a delta from the largest sequence.  0 is the largest sequence + 1, 1 is the largest sequence + 2, and so on. The following table shows an example of how the RelativePrevious and RelativeNext values are used to determine the absolute sequence. 6.4.2. </del> The format of SUBSCRIBE is as follows: Subscribe ID: The subscription identifier that is unique within

Related discussion:
text: If I wanted to receive all objects in group N, I would issue: However the draft sneaks this restriction in, and it would actually be a protocol violation: It wasn't clear to me until chatting with Alan how you're supposed to do it: It's clarified in example 5, but I don't think this is obvious and it feels like an off-by-one. For example, if N was the last group in the broadcast, I can imagine some implementations incorrectly throwing an error or somehow mishandling it.
Individual Comment: This was discussed on the PR here: URL Given how subscribe locations work (end is exclusive), end=N+1/0 means "including through the end of group N". The question is whether we should have more than one way to do things, and defaults when values are not present.
Sorry, bad choice of word there. I meant that it's not immediately obvious why the restriction exists, and what it impacts.
Individual Review: I like removing relative options from subscribe. I don't love the group ID + 1 spelling, but I guess I can live with it. An alternative is to add 4 code points for SUBSCRIBE to indicate the presence/absence of start/end (SUBSCRIBE, SUBSCRIBEFROM, SUBSCRIBETO, SUBSCRIBE_RANGE).
Code change:
2.3. <ins> HTTP caching has a single, end-to-end freshness model defined in Section 4.2 of I-D.ietf-httpbis-cache.  When additional freshness mechanisms are only available to some caches along a request path (for example, using targeted fields), their interactions need to be carefully considered.  In particular, a targeted cache might have longer freshness lifetimes available to it than other caches, causing it to serve responses that appear to be prematurely (or even immediately) stale to them, negatively impacting cache efficiency. For example, a response stored by a CDN cache might be served with the following headers: From the CDN's perspective, this response is still fresh after being cached for 30 minutes, while from other caches' standpoint, this response is already stale.  See AGE-PENALTY for more discussion. When the targeted cache has a strong coherence mechanism (e.g., the origin server has the ability to proactively invalidate cached responses), it is often desirable to mitigate these effects.  Some techniques seen in deployments include: Removing the Age header field Updating the Date header field value to the current time Updating the Expires header field value to the current time, plus any Cache-Control: max-age value This specification does not place any specific requirements on implementations to mitigate these effects, but definitions of targeted fields can do so. 2.4. </ins> A targeted field for a particular class of cache can be defined by requesting registration in the Hypertext Transfer Protocol (HTTP) Field Name Registry https://www.iana.org/assignments/http-fields/

Related discussion:
text: wouldn't the "Proxy-Status" header field require an action in the IANA considerations section to register the header field itself? currently, the only things in this section are the creation of new registries required for the header field.
a la rewriting, invalidation controls, etc. See
Code change:
The HTTP/3 stream closure is also analogous to the TCP connection closure of RFC6455.  Orderly TCP-level closures are represented as a <del> FIN bit on the stream (HTTP3).  RST exceptions are represented with a stream error (HTTP3) of type H3_REQUEST_CANCELLED (HTTP3). </del> <ins> FIN bit on the stream (HTTP/3).  RST exceptions are represented with a stream error (HTTP/3) of type H3_REQUEST_CANCELLED (HTTP/3). </ins> 4.

Related discussion:
text: NAME - that does not seem to work as expected. See the output at URL
Understood. I personally inline everything always, so outages, bugs, and not-yet-published states simply do not affect me :-)
Please note that, per the rest of this cluster of documents, the reference citation strings "[HTTP2]" and "[HTTP3]" have been changed to "[HTTP/2]" and "[HTTP/3]", respectively. Please let us know any objections.
That does not seem to work as expected, see output at URL
See URL for how to do this in Markdown
I struggled with this in my own draft, the instructions in the style guide didn't seem to work, guessing they will once the RFCs are actually published. I copied Mikes approach, but H3 dgram solved it with what looks like a simpler approach URL
They key part is that "/" can not be in the reference name (because it's not legal in an XML ID), thus needs to go into "title". That may not have worked locally unless you have a recent version of kramdown-rfc2629.
If I do and ref RFC91113. Then make causes kramdown to blurt out and the HTML output is Versions:
Oh, that's because the XML reference file will not exist until that RFC is published. You need to inline all the information.
yeah, that's what I meant by my unclear statement "Mike's approach" - see URL But that's like a million miles off what the style guide suggests, and is annoying while we are stuck in this temporary purgatory :D
So there are two issues here combined: citing something as RFC which is not published overwriting the reference name The latter thing is what the style guide describes; for the first issue only inlining everything helps. (I personally inline everything anyway, so it didn't occur to me that that's the problem you encountered :-)
AH! Thanks for the info and pointers. I've sent out to fix.
I didn't even know what David did was possible. Magic!