jiebi/CodeConvo huggingface dataset:
Adds a citation in 1.4 for DIGEST and forward links to the security considerations sections for covered component selection and message body coverage.
Minor issue noted while reviewing. -13 does give a good overview of message content considerations, and mentions Content-Digest along with a citation to the digest headers draft. However, the earliest mention of Content-Digest is in section 1.4, and there are several examples through the text that use it. Simple fixup is to cite digest in section 1.4 too, and forward ref to 7.2.8 so anyone interested in this knows where to jump to.
Initial try at the definition of a workload.
Closes issue
I think we could be a bit more specific here. Every software is executed for a purpose... I believe the key practical difference between workload identity and user run software such as browsers and interactive applications in that there is no user to perform some interactive authentication flow. Maybe we could try and reflect that? For example, For the purpose of this document, workload is defined as a non-interactive instance of software interacting over network with other software and services. Certain workloads can be live for a very short durations of time (nanoseconds) and run for a specific purpose such as to provide a response to an API request. Other kinds of workloads might be executed for a very long durations such as months or years - examples include database services and machine learning training jobs.
I think I understand what your are saying, but I'm not sure I can express it yet. Also it seems there maybe some special workloads that do interact with user authentication mechanisms. Perhaps those are architecturally distinct pieces "Authenticaition Services"
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.
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.
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.
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.
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
by using a citation rather than a redundant and wrong statement. by removing the minimum length (zero is totally fine).
The Known-Length Messages section states that whereas the Header and Trailer Field Lines section allows empty field values. Which is it?
Editorial error on my part. Someone pointed out that fields can have empty values (yet another feature of the protocol that is weird and unnecessary). I fixed it one place, but not the other. Thanks for noticing.
The draft currently shows: This Length field isn't well defined. Is it the length of the Known-Length Field Section in bytes or in lines? If in bytes, does it include or exclude the length of the Length field itself? Either way, I don't understand why Length is at least 2. Either it's possible for there to not be any field lines, in which case maybe it should be zero. And if there needs to be at least one field line, then (we should say so, and) the minimum number should be 3, because a field line is two lengths and at least one byte of field name.
To pile on here, the spec also says in one place and in another It's a little ambiguous but f the value also can't be zero-length, then the minimum should be 4? (by David's second interpretation)
NAME see
Yeah saw that after hitting the button. Didn't intend to derail
Thanks!
Added a bunch of clarifying text about why to use the DHCPv6 PD prefix, and also clarified the bits about NAT64 with respect to when to use Infrastructure-provided versus stub-router-provided NAT64.
See URL in the working group meeting in London, and in both cases, it seemed that the argument that without NAT64 we can't deliver on "device must always be able to connect to the internet if it is available" overrode the objections that were raised. So despite some folks really not loving it, I think it's required. Michael (IIRC) also pointed out that we need DHCPv6 PD to get infrastructure-provided NAT64 to work, which I guess means that if we have IPv4 and infrastructure-provided NAT64, but no DHCPv6 PD, we have to do NAT64 in the stub router. If we have v6-only, infrastructure-provided NAT64, and no DHCPv6 PD, then in order to reach the internet, we'd need NAT66. I'm inclined to declare this situation out of scope, because (A) I really don't want to do NAT66, and (B) I think it's not a likely scenario at the moment, and the more devices out in the field that would break in this situation, the better.
See
I have trouble explaining why scanning a QR code is dangerous to initialize authentication flows to gain access because sometimes it is less dangerous. When using a device which is close proximity to the second device and forcing this through a protocol, the danger is reduced. I think introducing a new wording context would help (especially if this was used in the corresponding protocols, for example FIDO2 passkeys) Near device A device which is in close proximity to the second device and uses a protocol which forces a close proximity communication channel for the authentication steps. Cross device A device which communicates to a separate device and uses a protocol which does not force proximity to the second device. Then it would be easy to explain attacks and mitigations: Using a near device communication, the attack X is not possible etc. Not sure this is the right place to add this, but it would help I think.
That's and interesting idea. To me it is more about cross-device protocol properties. Some of them have strong proximity assurance properties, and some don't. Perhaps terminology like "proximity verified cross-device flows" or "proximity enforced cross device flows" vs "proximity-less cross device flows" works better? It is also somewhat protocol neutral.
I like these two: "proximity enforced cross device flows" vs "proximity-less cross device flows"
Let me think about how to work that terminology into the text at the right places.
As noted in , we don't need to redo these. A backward reference will do. This cuts quite a bit of XML out of the document, which I'm happy about.
NAME I disagree; IANA hold the registration data, not the document. My understanding is that templates need only appear in the originally registering documents; if there's doubt about that, we should check with the IESG and IANA.
That is true, but the registrations point to specs. The IANA Considerations need to take care of updating these references.
That's a good point; I will shelve that and change to adding a note that says "references to RFC 7540 for X, Y, and Z are updated to point to this document".
Absolutely. It just doesn't need to list them individually; a simple statements such as "update the references to RFCxxxx to this document in Registry Foo" will suffice.
If that's all which is necessary, yes. Hint: section numbers might change, and you don't want to handle that during AUTH48.
The current IANA Considerations for H2 bis has several requests to IANA that seem to be appropriate for the original document, but not a bis now that the registries are already filled out. Shouldn't these be reworded to say "this document updates..." or explain that the references for registries should point to this document, rather than the old RFC?
I don't think this is a good idea. At the end of the day, the IANA registry should point to the updated document.
to clients that attempt to guess (editorial)
I have no idea what this is trying to say and it is 1.1-specific. I suggest we delete it.
It was added as part of URL, adressing .
How about
May end up encouraging this kind of implementation, by providing an example here ... ? Maybe just leave this as "Some clients take a riskier approach and attempt to guess when an automatic retry is possible because the original request may not have been received by the server." ....
I don't see any problem with the original text, but NAME your replacement is fine too (although the second sentence is a fragment).
How about
We started this discussion in the comments of but it deserves its own issue. Now that has landed, capsule support is mandatory for servers but clients can decide whether or not to use it by sending the header. Another way forward would be to just say that connect-tcp always uses capsules. Some reasons why: it simplifies server implementations it simplifies client implementations that want capsules it would be consistent with every other that uses capsules it avoids reusing to mean something different from what was intended in RFC 9297 Since I don't see any real-world reason to use without capsules, this sounds like the best path forward to me cc NAME NAME NAME
I'm sympathetic to the argument that there may be cases where someone wants templates tcp without the overhead of capsules. So how about we move the capsule negotiation to the upgrade token? I.e. one token if you want capsules, another if you don't. Then it makes the use of capsule-protocol header more consistent with how it's already used in other connect-foo docs.
That's a good compromise. That allows me to only implement the upgrade token that enables capsules and not have to deal with the complexity of negotiation. Another option would be to say that if then the capsule extends to the end of the stream. That works because stream offsets only go to UINT64_MAX so that length cannot ever be valid. It's a shame we didn't do that in 9297 though
I think this approach works for the sender to indicate its disinterest to use capsules. But it does not allow the receiver to refuse use of capsules by the sender. By saying using connect-tcp without capsules, I think we are referring to endpoints that do not want to implement capsule support at neither send-side or receive-side. Assuming that is the case, I think using different upgrade token is the way to go, if somebody asks for connect-tcp without capsules.
OK, PR up: URL Please review.
WfmThanks!
I'll have to update extract-header-URL so that it can generate entries with status "obsoleted".
NAME Go ahead and merge after you update extract-header-URL
Isn't implemented, generated, used or surfaced to users; can we deprecate?
Proposal: Replace 5.5 Warning with a section noting that the Warning header is deprecated, and should be ignored. Remove all requirements to generate Remove Warning-specific requirements in 3.3 Combining Partial Content Remove Warning-specific requirements in 4.3.4 Freshening Stored Responses upon Validation Remove Warning-specific requirements in 4.3.5 Freshening Responses via HEAD
+1, with big notes in the Changes section.
Just curious if anyone has any background, what would be a good alternative to the Warning header for cache limit warnings?
This isn't a good place for general discussion. You might want to ask the mailing list, though I am not aware of any cache limit warnings within HTTP because they are only relevant to the cache admin (who typically has an email or phone number stored for such notifications).
I think this is the right thing to do; we added too much text here in 7234.
From : Both state that a (depending on context private, shared or both types of) "cache MAY store the response and reuse it for later requests, even if the response would normally be non-cacheable". To my understanding, this does not intend to override the requirements from the "Storing Responses in Caches" section (URL) altogether. Instead, I would assume that it only refers to the condition "has a status code that is defined as heuristically cacheable" in that section (or, as it was stated in RFC7234, "has a status code that is defined as cacheable by default")? Would it make sense to amend the list of conditions in that section, appending to the "the response either..." second-level list: "contains a private response directive if the cache is not shared"?
OP here
I'll trust you on the actual change :-)
The current draft allows tracks within a catalog to be updated. This causes a few problems: What happens if a track is changed (ex. new profile)? When does this update occur? What happens when the catalog update is delayed? If the publisher changes the codec/profile in the middle of a track, the decoder will blow up. There's no way to know when the change will take place.
I don't see how we could easily support tracks being updated. At the very least we would need a group ID when the change occurs, but that won't work in the face of packet loss, because the catalog update could arrive after the starting group. I think the only way to fix this is to put the init information at the start of each group (ex. SPS/PPS) which is not desirable. I would prohibit it for now. At the very least, some text to say that the init payload MUST NOT change on subsequent updates. We can only add or remove tracks.
IMO we start with no catalog updates for interop. Then we can build an ADD and REMOVE track message to avoid retransmitting the entire catalog on each update.
NAME By 'update', I agree that we shouldn't allow their media characteristics (anything described in the init segment or the init itself) to change. But we should allow them to be added and deleted . Agree I think that having no catalog updates in v1 is unnecessarily restrictive and would lead to missed use-cases, rather than better interop. We also don't need to invent ADD and REMOVE track messages if we allow the CATALOG (and its updates) to define the availability of tracks. The whole purpose of the CATALOG track is to do exactly that. This point is up to MOQ base protocl however and we need to resolve it there. And "avoiding retransmitting the entire catalog on each update" can be addressed by either ignoring (because catalog updates are small to begin even with their init payloads), or by allowing delta updates on the catalog, which wouldn't be complex and I can mock that up if you'd like to see what it might look like?
Yeah, the ADD and REMOVE messages would be delta updates. I think we need some timing information about when a track starts and ends, although I'm not sure.