jiebi/CodeConvo huggingface dataset:
Code change:
the scalability and cost effectiveness associated with content delivery networks. <del> MOQT is a generic protocol is designed to work in concert with multiple MoQ Streaming Formats.  These MoQ Streaming Formats define how content is encoded, packaged, and mapped to MOQT objects, along with policies for discovery and subscription. </del> <ins> MOQT is a generic protocol designed to work in concert with multiple MoQ Streaming Formats.  These MoQ Streaming Formats define how content is encoded, packaged, and mapped to MOQT objects, along with policies for discovery and subscription. </ins> model describes the object model employed by MOQT.

Related discussion:
text: Line 179. “a join point” joint? Line 231. “The application is solely responsible for the content of the object payload.” What is the application? It is a bit confusing. It has not been defined. Line 269 .“within a single MOQT scope, subscribing to the same full track name would result in the subscriber receiving the data for the same track.” I am not sure to understand this sentence. Is a single MOQT scope a scope with only one server or do you mean “within a MOQT scope”? the two “same” adjectives are confusing too. Line 273. It would be better to stick to “servers” or to “connection URIs” to refer to the elements of the scope. Line 339. “The portion MUST NOT contain a non-empty portion.” Is it a double negation to say that the ‘authority’ MUST contain an empty ‘host’ portion? Line 357. This sentence may require a MUST. Line 359. “for exchanging …” and following sentences are not related to session initialization. They are rather remarks that would be a fit with the draft Section 4. +1 to the TODO remarks on line 381. This should be in Section 4. Line 654. “it allows the peers…” The term “peer” is used 7 times. It is supposed to be an “endpoint” (as defined Line 173), unless peer and endpoint have different meaning (in which case peer must be defined) Line 693. “A relay that reads from a stream and writes to stream in order will introduce head-of-line blocking.” I don’t understand this claim.
Thanks for the feedback. I'm going to mark this as Editorial, but there are a number of points here. If you believe any of them are not editorial (ie: "Line 357. This sentence may require a MUST."), please split into a separate issue.
Will assign to Mo.
NAME Please go through these and fix any that still apply.
Code change:
content coding defined in RFC8188. Since it is possible for there to be variation within content coding, <del> the checksum conveyed by the integrity field cannot be used to provide a proof of integrity "at rest" unless the whole (e.g., encoded) content is persisted. </del> <ins> the checksum conveyed by the integrity fields cannot be used to provide a proof of integrity "at rest" unless the whole content is persisted. </ins> 6.6.

Related discussion:
text: ballot position feedback
[x] §6.1 Recommend adding cautionary language about the capabilities of an adversary like those stated in Peter’s SECDIR review [x] Appendix A, typo[x] Section 6.5, e.g.
Code change:
Dictionaries are ordered maps of name-value pairs, where the names are short, textual strings and the values are items (item) or arrays of items, both of which can be parameterised (param).  There can be <del> zero or more members, and their names are required to be unique in the scope of the dictionary they occur within. </del> <ins> zero or more members, and their names are unique in the scope of the dictionary they occur within. </ins> Implementations MUST provide access to dictionaries both by index and by name.  Specifications MAY use either means of accessing the

Related discussion:
text: NAME thanks for the review, see latest commit. is talking about the abstract model for dictionaries, so they are required to be unique. I've removed "required to be" so that people don't misread this.
allows a sender to generate multiple header fields with the same name, if the field is defined as a comma-separated list [i.e., #(values)], and that such duplicates are semantically equivalent to them concatenated into a single header field. I think that this property has been useful for us, when annotating header fields. Can we allow such duplicates for Structured Headers too, when a list or a dictionary is being used? Note that we have merged based on the assumption that it is okay to require the consumer of SH header fields to have the knowledge on what the top type is.
That's always been the intent; are you saying that we should have text specifically enabling this for serialisation of dictionaries and lists?
Good to know that that has been the intent. Yes, I think we should clarify that explicitly for dictionaries and lists, because RFC 7230 can be interpreted to allow duplicates only for those using notation (which we do not use in SH). Also, it might be a good idea to revisit the rule for duplicate dictionary values, as I'd assume that people would try to append a header field without checking the values that already exist. IMO, the rule should be that the dictionary element that appears later overwrites the one that precedes.
PTAL
NAME Thank you! cb76bf1 looks good to me. Is your intention to retain the forbidding of duplicate dictionary values, even when the dictionary members are split into different header fields? For example, in the hypothetical world where cache-control is sent using SH, all the cache-control directives in the following example would be considered invalid and ignored. I am not strongly opposed to that, though my weak preference goes to requiring decoders to use the dictionary member that appears later when there is a collision.
NAME the problem is that ignoring duplicates can cause security issues for some headers (the headers that WebAppSec in the W3C are particularly sensitive about this). The only way to address it would be to add a flag to the API to control what to do with dups -- but that adds complexity (more to specifications than to implementations, but still). I'm not crazy about that; what do others think?
Code change:
Dictionaries are ordered maps of name-value pairs, where the names are short, textual strings and the values are items (item) or arrays of items, both of which can be parameterised (param).  There can be <del> zero or more members, and their names are required to be unique in the scope of the dictionary they occur within. </del> <ins> zero or more members, and their names are unique in the scope of the dictionary they occur within. </ins> Implementations MUST provide access to dictionaries both by index and by name.  Specifications MAY use either means of accessing the

Related discussion:
text: NAME Thank you for the explanation. But I wonder if it is actually the case that what those specifications forbid is having duplicate header fields, rather than forbidding duplicate dictionary members (or maybe both). By quickly searching on URL, I was able to find the prohibition on having duplicate header fields, but could not find a rule that forbids having duplicate policy tokens. Assuming that at least such specifications forbid having duplicate header fields, and based on the fact that SH draft does not forbid that (when a list or dictionary is used), I think there is no reason for the SH draft to forbid having duplicate dictionary members.
NAME NAME any comments re: the above? Specifically, if SH swallowed duplicate dictionary values rather than raising an error, would that be a concern from a security standpoint?
Given a header like , it seems like we have a few options: Fail parsing. Return . Return . Return . I think I can come up with arguments for any of these options, though I'd find 4 a bit surprising as a spec author, insofar as I'd have to deal with unexpected lists for all my dictionary values. of URL skips duplicate CSP directives. That is, it picks 2 out of the list above, choosing to retain only the first value for a given name. I do wonder whether that was the right decision, but it is consistent across browsers and provides developers with predictable behavior. We throw a warning into the console in Chrome for this case, and that's probably Good Enough.
This sounds like a bad API for working with structured header values. I'd hope that eventually we offer better APIs for operating on (what Fetch calls) header lists. I think historically there were some arguments for always using first or last based on likelihood of where header injection would happen. But I'm not sure how sound any of that rationale was. I don't think a client can reasonably protect against it. Therefore, what's most important is that the result is unambiguous and that it doesn't matter how you "spell" multiple values (commas or multiple fields or a combination) in the traditional header syntax.
Anyone have preferences between Mike's options 2 and 3?
NAME I think option 3 is preferable, because that would allow server administrators to override parameters by appending header fields.
Code change:
Dictionaries are ordered maps of name-value pairs, where the names are short, textual strings and the values are items (item) or arrays of items, both of which can be parameterised (param).  There can be <del> zero or more members, and their names are required to be unique in the scope of the dictionary they occur within. </del> <ins> zero or more members, and their names are unique in the scope of the dictionary they occur within. </ins> Implementations MUST provide access to dictionaries both by index and by name.  Specifications MAY use either means of accessing the

Related discussion:
text: I agree that NAME that it's a hack, though sadly, I do not think we can get rid of such practice through API design on the server side. People are so used to dealing with each line of header fields than working through a API that deals with a set of header fields as a whole.
There are CDNs that offer JS or Wasm APIs effectively using et al. Once structured header values are more baked and have dedicated on-the-wire support I'd definitely like to add first-class support to objects.
I weakly prefer "first one wins" (2). It's only an aesthetic preference, however: I don't have any principled reason to pick 2 over 3 or vice-versa. I can live with either for the reasons NAME spells out.
If I had pick, I probably agree with NAME reasoning.
PTAL
Thank you for the changes. Looks good to me now. FWIW, I was bit surprised to learn that we do not mention how a duplicate is processed alongside the type definitions in . I checked and now I understand that the formal definition is provided in section 4.
Code change:
sufficiently smaller so as to allow for the addition of certificate data. <ins> 3.3. Some TLS implementations do not retain client certificate information when resuming.  Providing inconsistent values of Client-Cert and Client-Cert-Chain when resuming might lead to errors, so implementations that are unable to provide these values SHOULD either disable resumption for connections with client certificates or initially omit a "Client-Cert" or "Client-Cert-Chain" field if it might not be available after resuming. </ins> 4. The header fields described herein enable a TTRP and backend or

Related discussion:
text: add a note about cert retention on TLS session resumption (to
Hi, given that I had the question today relayed from a customer by our support team, I had a second look at the draft to see what was planned for resumed connections, and I'm seeing this: The problem is, on resumed connections, the client does not present the certificate again, it will use a ticket or a session ID to match a cached entry or any other mechanism I'm not familiar with (please bear with me, I'm not SSL-fluent). In our case when this happens, the related fields are empty (since the info is missing from the TLS stack), and we encourage customers to log something else as a complement to match new connections against a previously verified session (e.g. session ID). I think it's important to explicitly state that such a certificate info is not necessarily available in such a case, and that either the proxy+application have to find other ways to persist the information between connections, or that the cases where the certificate is matched need to be narrowed down to the strict minimum. For example, I remember a decade ago when working for a bank that the security team absolutely wanted to distinguish really authenticated connections and resumed ones and that in particular they refused to consider as 2FA something that resulted from a resumed connection because they wouldn't be able to prove that the authentication happened at this precise instant if they had to defend this in court. After the different versions of TLS evolved, I'm not sure whether there is a stable session identifier that's available across multiple versions, but I do think that if we document a common method to pass this client-cert info to the server, we also need to provide "something" for all the resumed connections that do not convey that info anymore, otherwise users might fall back to poor solutions due to the difficulty of understanding all the details of the various versions (and it's very likely that I've been one of those giving such wrong advices, not knowing how to do better). It's particularly important in load-balanced environments because you cannot count on the front LB to keep a copy of the client-cert, as the resumed connection might very well end up on another node, and you cannot count on the server either since different requests will often reach different servers.
Code change:
sufficiently smaller so as to allow for the addition of certificate data. <ins> 3.3. Some TLS implementations do not retain client certificate information when resuming.  Providing inconsistent values of Client-Cert and Client-Cert-Chain when resuming might lead to errors, so implementations that are unable to provide these values SHOULD either disable resumption for connections with client certificates or initially omit a "Client-Cert" or "Client-Cert-Chain" field if it might not be available after resuming. </ins> 4. The header fields described herein enable a TTRP and backend or

Related discussion:
text: So the only thing that remains is that "thing" that the client uses to be recognized on resumption (sorry for the imprecise language, it seems for me that up to TLS1.2 it was a ticket but I'm not sure for 1.3).
Hi Willy, This is likely a limitation of your TLS implementation. A perfectly reasonable limitation, but not something that is consistent across all implementations. What happens with resumption is that any state from the initial connection can be carried across over into a resumed session. Obviously, things that happened on the first connection after a ticket was issued can't be assumed to be available, but generally anything that happened in the original handshake could be used. What the specification assumes is that the details of the handshake are remembered and can be used again. There's a bunch of other stuff like which TLS version and whatnot, some of which the specification requires endpoints to remember (see for example , which insists that the KDF remain the same). When it comes to authentication state, however, TLS is not very consistent and so implementations are not. Some implementations (like NSS and Boring SSL) remember the client certificate. The way they do this is they put the whole certificate chain in the session ticket. That makes the tickets pretty large, which can badly affect the resumption handshake: whatever you save on sending certificates is eaten up with a huge ticket in the first message. Worse, this first message is bad DoS mojo as you have to accept a whole lot of state before you are really sure that the client is OK (there are ways around this, but they are all pretty bad). Others might save the certificates server side, but that adds a whole different type of fragility. Others just "forget" that the client offered a certificate. That last one is probably what you are seeing here. This is a whole new sort of problem to solve. What you might need in this case is a way to recover an old certificate from a log based on some identifier. The problem here is that the identifier isn't stable either. TLS doesn't have a single consistent value you can use across all versions and all types of resumption.
Hi Martin, thanks for the detailed explanation.
Code change:
sufficiently smaller so as to allow for the addition of certificate data. <ins> 3.3. Some TLS implementations do not retain client certificate information when resuming.  Providing inconsistent values of Client-Cert and Client-Cert-Chain when resuming might lead to errors, so implementations that are unable to provide these values SHOULD either disable resumption for connections with client certificates or initially omit a "Client-Cert" or "Client-Cert-Chain" field if it might not be available after resuming. </ins> 4. The header fields described herein enable a TTRP and backend or

Related discussion:
text: The only viable way to convery the cert info is via the ticket anyway, because several consecutive connections may reach different LBs and there's no way to be faster than light to synchronize them on any external data. What you mention about BoringSSL is interesting given that it derives from OpenSSL. I'll suggest my coworkers to have a look there, in case we'd find that the behavior is configurable. Anyway, my point remains about the importance of mentioning this in the spec (not the details). Just putting a big warning about the fact that the presence of certificate information in resumed sessions is implementation-dependent, because that's an easy trap everyone falls into, and that's too bad when it serves to design an architecture and is discovered after deployment.
(BoringSSL's behavior was one of the things we changed from OpenSSL's. OpenSSL only retains the leaf certificate across resumption. We found that having different information available across resumptions led to bugs.) That, alas, does lead to a huge ticket as NAME mentioned. There's a third solution which avoids this and I think demonstrates an issue with this draft's kind of TLS/HTTP split. (We haven't implemented this in BoringSSL, as client certs aren't a huge priority for us, but I think it's clearly the right design.) At the end of the day, your server presumably uses client certificates as the proof for some sort of application-specific identity. That identity may be an email address, a username, or something else entirely. You can think of the VerifyCertificate process not as returning yes/no, but as returning the verified identity or an error. If you can capture your application-specific notion of identity, that's all you need to retain after the handshake and in the ticket. It's also all you need to pass down to the application. This will be much more compact than the input certificate chain. But it's incompatible with this and headers, which use a much larger intermediate representation. Of course, per the "don't make resumption behave differently" rule, any application which does this should make the full chain equally unavailable on initial and resumption handshakes. (As an analogy, when clients verify server certificates, the identity is the SAN list, perhaps with some metadata like expiry. We don't really need the original certificates.
Code change:
sufficiently smaller so as to allow for the addition of certificate data. <ins> 3.3. Some TLS implementations do not retain client certificate information when resuming.  Providing inconsistent values of Client-Cert and Client-Cert-Chain when resuming might lead to errors, so implementations that are unable to provide these values SHOULD either disable resumption for connections with client certificates or initially omit a "Client-Cert" or "Client-Cert-Chain" field if it might not be available after resuming. </ins> 4. The header fields described herein enable a TTRP and backend or

Related discussion:
text: Though browsers tend to provide these silly "view certificate" buttons, so we've got a bit of a hard time there.) Back to the original topic, I think we need to treat resumption behavior as a prerequisite to deploying a system around or . If you retain the EE certificate across resumption, you can use and enable resumption. If the full chain is only available on initial handshakes, you must either disable resumption or not implement . Trying to do something clever across TLS and HTTP session state will not work. I've seen far too many cases of bad server deployments breaking flakily because the system made assumptions about the relationship between HTTP requests, connections, and TLS sessions.
I did have a moment of hesitation when writing "... or the resumption of such a connection ..." as I didn't know the details but figured there might be implementation-dependent limitations or variations around what/how data is retained across resumption. I don't think this draft can do anything about it. Other than a mention? What else can be said? Please propose some text, if you can.
Is there a reasonable way to say that, in order to use / , the TLS implementation needs to retain the client cert info across resumption or not offer resumption to clients that established mutually authenticated connections?
For me it's not possible to "maintain" it as it's not necessarily the same physical machine. And one essential property of tickets is that they're usable across a fleet of reverse-proxies who share the same keys. I tend to think that it's not this draft's business to try to solve the TLS-level problems nor architectural shortcomings, however the draft needs to warn unsuspecting adopters about them. Something around this maybe ? "The ability to extract a client certificate and/or an issuer chain from a resumed TLS connection is entirely specific to the implementation and sometimes also to the TLS version in use. Implementers are strongly encouraged to verify if their implementation matches their expectations or to make sure the application has some way of retaining such information once already learned. One possibility to work around implementation limits is to completely disable resumption when client-cert is needed".
Thanks NAME I can work with that or similar. Probably/maybe in the Deployment Considerations somewhere like a new subsection. I'd love for NAME to take a look and tell us why it's wrong though and how it could be better.
Code change:
sufficiently smaller so as to allow for the addition of certificate data. <ins> 3.3. Some TLS implementations do not retain client certificate information when resuming.  Providing inconsistent values of Client-Cert and Client-Cert-Chain when resuming might lead to errors, so implementations that are unable to provide these values SHOULD either disable resumption for connections with client certificates or initially omit a "Client-Cert" or "Client-Cert-Chain" field if it might not be available after resuming. </ins> 4. The header fields described herein enable a TTRP and backend or

Related discussion:
text: I might add David's suggestion to recommend against providing a value that won't be consistent after resumption, so:
I guess I'm fine with Martin's proposal.
I'll borrow from both suggestions to piece something together.
Opened since it would be good to also have discussion in Security Considerations. There are some very sharp edges here (beyond the ones mentioned already) due to variations in how implementations do resumption and client certs in combination in ways that could be surprising to people who are not experts in TLS implementations.