jiebi/CodeConvo huggingface dataset:
Change:
Section 4.3 of RFC7231 defines the set of methods in HTTP; Section 5.8 of RFC7252 defines the set of methods in CoAP.  As part of the Uniform Interface constraint, each method can have certain <del> properties that give guarantees to clients: Safe methods do not cause any state change on the origin server when applied to a resource. </del> <ins> properties that give guarantees to clients. Safe methods do not cause any state change on the origin server when applied to a resource.  For example, the GET method only returns a representation of the resource state but does not change the resource.  Thus, it is always safe for a client to retrieve a representation without affecting server-side state. </ins> Idempotent methods can be applied multiple times to the same resource while causing the same visible resource state as a single such <del> request.  The following lists the most relevant methods and gives a short explanation of their semantics. </del> <ins> request.  For example, the PUT method replaces the state of a resource with a new state; replacing the state multiple times with the same new state still results in the same state for the resource. However, the response from the server can be different when the same idempotent method is used multiple times.  For example when DELETE is used twice on an existing resource, the first request would remove the association and return success acknowledgement whereas the second request would likely result in error response due to non-existing resource. The following lists the most relevant methods and gives a short explanation of their semantics. </ins> 3.5.1.

Discussion:
Note about client role and reference to architecture section for details.
+1 (if the newline in the definitions () still does render correctly...
How do you like your newlines cooked?
The definitions seem to render correctly. I'll merge this.
Change:
Each aggregator runs this procedure for a given input share with corresponding nonce as follows: <del> "vdaf_verify_param" is the public VDAF parameter, and "agg_param" is the opaque aggregation parameter.  If either step fails, the aggregator marks the report as invalid with error "vdaf-prep-error". </del> <ins> "vdaf_verify_key" is the VDAF verification key shared by the aggregators; "agg_id" is the aggregator ID ("0x00" for the Leader and "0x01" for the helper); and "agg_param" is the opaque aggregation parameter distributed to the aggregtors by the collector. </ins> <del> Otherwise, the value "out" is interpreted as follows.  If this is the last round of the VDAF, then "out" is the aggregator's output share. Otherwise, "out" is the pair "(prep_state, prep_msg)". </del> <ins> If either step fails, the aggregator marks the report as invalid with error "vdaf-prep-error".  Otherwise, the value "out" is interpreted as follows.  If this is the last round of the VDAF, then "out" is the aggregator's output share.  Otherwise, "out" is the pair "(prep_state, prep_msg)". </ins> 4.3.2.

Discussion:
The next VDAF draft is out. It includes some minor changes that we'll need to adopt here. URL
Change:
managed in GitHub, but any substantive change should be discussed on the MLS mailing list. <del> Groups of agents who want to send each other encrypted messages need a way to derive shared symmetric encryption keys.  For two parties, this problem has been studied thoroughly, with the Double Ratchet emerging as a common solution doubleratchet signal.  Channels </del> <ins> A group of agents who want to send each other encrypted messages needs a way to derive shared symmetric encryption keys.  For two parties, this problem has been studied thoroughly, with the Double Ratchet emerging as a common solution doubleratchet signal.  Channels </ins> implementing the Double Ratchet enjoy fine-grained forward secrecy as well as post-compromise security, but are nonetheless efficient enough for heavy use over low-bandwidth networks. <del> For groups of size greater than two, a common strategy is to </del> <ins> For a group of size greater than two, a common strategy is to </ins> unilaterally broadcast symmetric "sender" keys over existing shared symmetric channels, and then for each agent to send messages to the group encrypted with their own sender key.  Unfortunately, while this

Discussion:
It first reads as if MLS allows groups to communicate with each other, which I don't think is the intent.
Thanks Mark ;)
Change:
Export a secret "secret" from "context", using the string "message/bhttp response" as context.  The length of this secret is "max(Nn, Nk)", where "Nn" and "Nk" are the length of AEAD key and <del> nonce associated with "context". </del> <ins> nonce associated with "context".  Note: repurposing discusses how alternative message formats might use a different "context" value. </ins> Generate a random value of length "max(Nn, Nk)" bytes, called "response_nonce".

Discussion:
This is a lot more disruptive, but I think it is a clearer description of how you might repurpose this design. I'm still a little unsure about using application/dns-message, but I can live with it.
If this is acceptable, I might cherry-pick some of the other changes from rather than take it wholesale.
OK, I think that I understand what you are looking for and I agree, we can say more about that. But we probably don't need to say heaps more. Is the latest commit what you are looking for?
NAME I think it's closer, but I genuinely don't see why noting precisely where things need to change in the spec is harmful. I prefer Tommy's original change here.
Yeah, this still doesn't solve the problem of letting implementers know which parts of the encapsulated request processing are the bits that can become generic to handle other media types. Another way to look at this is, for another spec to define how to use another media type, it should be easy to simply say "the OHTTP spec explains the couple places where the media type can be changed from BHTTP to something else — and this use of OHTTP tells you to use a different media type in those spots". We should avoid having new specs like this need to wholesale copy the sections of the OHTTP document that define how to use HPKE, etc, and just have one subtle difference.
I'm not seeing that. I realize that I missed the padding piece (though I don't consider that particularly important, it's worth mentioning). For a generic format, the only adaptation required is replacing the constant strings. This describes how that might work. That we don't burden the reader of the algorithm piece with this detail at the time is a feature, not a bug, as far as I'm concerned.
I don't consider it a burden. I think it's an important piece for someone who's implementing OHTTP since it has API implications. For example, one could implement the main encap and decap algorithms using the fixed "message/bhttp" content type and then find they have to either duplicate code later on adjust their encap and decap APIs (or something else) to accommodate another type of application encoding.

The inline hints from the original suggestion in suggest that implementers might want to allow for changes to the content type string so they don't run into this situation down the road, and they're minimally invasive hints at that.
I've added the pointers, as requested. (I only skipped one on the decapsulation process as that seemed redundant.)
Thanks, latest changes look good to me
Change:
Export a secret "secret" from "context", using the string "message/bhttp response" as context.  The length of this secret is "max(Nn, Nk)", where "Nn" and "Nk" are the length of AEAD key and <del> nonce associated with "context". </del> <ins> nonce associated with "context".  Note: repurposing discusses how alternative message formats might use a different "context" value. </ins> Generate a random value of length "max(Nn, Nk)" bytes, called "response_nonce".

Discussion:
This adds a little structure to the section on encapsulation and tries to make the relationship between different media types more distinct. This builds on top of (which we are going to merge soon) because that hits all the same text and we have already effectively agreed to those changes. You can review to see what the substance of these changes are. Alternatively, just look at the top of the "HPKE Encapsulation" section (the other changes are unrelated).
I spent some time being confused because (content type) and (the hpke info tag) are so similar. Is it possible to align these two? Section 9, Repurposing the Encapsulation Format, mentions changing the hpke info for other protocols, so I suppose is re-using the content-type from the binary http draft at this layer, while the outer Content-Type is specific to this draft's application? I can see the logic there, but some clarifying text about the two being different would have been helpful.
We kept them separate because they refer to different things. The "message/ohttp-req" content type refers to the type of HTTP request sent from client to gateway, whereas the "message/bhttp request" content type refers to the type of content that's encapsulated to the gateway. We can probably improve this distinction in the text. Thanks for flagging this.
I did a little rewriting of some of the key framing text for another issue, does the following help at all? URL
The new references to the repurposing section in that commit are helpful. The extra wording you linked doesn't help much I think. It's confusing that the both encapsulates a and is called an 'encapsulated request/response'. So when you say, the word 'contains' is ambiguous: is it that the directly contains the binary HTTP message, or is that the HPKE AEAD contains the binary HTTP message? I understand it's the second one, but on first reading this kind of layer confusion was hard to keep track of. Maybe something about the media type containing the encrypted message along with the necessary parameters to convey the encapsulation would help?
I took a swing at this in . Am I getting closer?
Change:
Unless otherwise specified, this document encodes protocol messages in TLS notation from TLS13, Section 3. <del> This document uses the following terms to refer to various roles and functions in the Privacy Pass architecture: Client: A client is a application or device, generally operated by a user, that can be issued tokens via an issuance protocol, and can redeem these tokens with an origin. Origin: An HTTP server that acts as the relying party and can redeem tokens presented by a client.  When used in a web context, this represents the origin the client is accessing. Token: A signed message that can be issued to a client and redeemed without allowing token redemption to be linked to issuance. Interactive / non-interactive token: An interactive token signs a nonce generated by an origin as part of a challenge for tokens. This means that the client needs to fetch a new token for this challenge in order to redeem it and cannot use a pre-fetched token.  A non-interactive token is one that can be pre-fetched. Issuance protocol: A protocol by which the client fetches tokens. Every issuance protocol includes two functions: validating or authenticating the client, and issuing a token to the client. Issuer: An entity that generates tokens for clients using one or more issuance protocols.  An Issuer is identified by an Issuer name. </del> <ins> This document uses the terms "Client", "Origin", "Issuer", "Issuance Protocol", and "Token" as defined in I-D.ietf-privacypass- architecture.  It additionally uses the following terms in more specific ways: </ins> Issuer key: Keying material that can be used with an issuance protocol to create a signed token. Token challenge: A requirement for tokens sent from an origin to a <del> client, using the "WWW-Authenticate" HTTP header.  This may be a challenge for an interactive token or a non-interactive token.  A challenge defines the issuance protocol and issuer name to use for a token. </del> <ins> client, using the "WWW-Authenticate" HTTP header.  This challenge is bound to a specific token issuer and issuance protocol, and may be additionally bound to a specific context or origin name. </ins> Token redemption: An action by which a client presents a token to an origin, using the "Authorization" HTTP header.

Discussion:
We should consider renaming to . This value doesn't need to be a nonce, it's just some origin-selected context that it is binding to. We can also rename the in the Token struct to to make it clear what role it has.
Change:
If the Destination Connection ID is zero length and the packet matches the address/port tuple of a connection where the host did not require connection IDs, QUIC processes the packet as part of that <del> connection.  Endpoints MUST drop packets with zero-length Destination Connection ID fields if they do not correspond to a single connection. </del> <ins> connection.  Endpoints SHOULD either reject connection attempts that use the same addresses as existing connections, or use a non-zero- length Destination Connection ID so that packets can be correctly attributed to connections. </ins> Endpoints can send a Stateless Reset (stateless-reset) for any packets that cannot be attributed to an existing connection.  A

Discussion:
How could this happen? The recipient knows if a given tuple is unique, so it shouldn't issue zero-length DCIDs for that tuple.
Yeah, it is more like recipients MUST not issue 0-length CID's in that case. And MUST drop non-issued CID's.
I remember why was added. If you had one connection on those addresses, time passes and a NAT rebinding moves another connection to that same path, then you get problems. That a nonsensical situation and better addressed as suggested.
Change:
The certificate MUST allow the key to be used for signing (i.e., the digitalSignature bit MUST be set if the Key Usage extension is present) with a signature scheme indicated in the client's <del> "signature_algorithms" extension. </del> <ins> "signature_algorithms"/"signature_algorithms_cert" extensions (see signature-algorithms). </ins> The "server_name" RFC6066 and "certificate_authorities" extensions are used to guide certificate selection.  As servers MAY require

Discussion:
In your answer to my question on list you say: and chain validation. I don't see that covered by this PR. Shouldn't this be explicit?
then the "signature_algorithms" extension also applies to signatures appearing in certificates. is unaffected by this change
As NAME says, there is already text that implies that you need not send "signature_algorithms" cert, so I don't think new text is really needed here.
That sentence says nothing about under what circumstances it is ok to omit "signaturealgorithmscert". It only implies that you may not always get it. I think it would not hurt to be more explicit.
Change:
Evidence and Attestation Results are expected to be integrity protected (i.e., either via signing or a secure channel) and optionally might be confidentiality protected via encryption.  If <del> confidentiality protection of the conceptual messages is omitted or unavailable, the protecting protocols that convey Evidence or Attestation Results are responsible for detailing what kinds of information are disclosed, and to whom they are exposed. </del> <ins> there isn't confidentiality protection of Evidence and Attestation Results, the underlying conveyance protocol should provide these protections. </ins> As Evidence might contain sensitive or confidential information, Attesters are responsible for only sending such Evidence to trusted

Discussion:
Fixes line in privacy section that was unclear about using encryption as a privacy protection approach.
In we now explicitly say that "confidentiality protection of Evidence and Attestation Results" is required in some form. In we now explicitly say that "Many Claims in Evidence, many Claims in Attestation Results, and Appraisal Policies potentially contain Personally Identifying Information (PII)". See my point already? Maybe protection of Appraisal Policies is "technically out-of-scope", but expressing this side by side makes a curious impression to me.
`
I suggest sticking to defined terminology such as 'conveyance protocol' instead of 'protecting protocols'. The 'kinds of information disclosed' is terminology for 'Claims'. It might make sense to include the line "If there isn't confidentiality protection of Evidence and Attestation Results in the conceptual messages, the underlying conveyance protocol should provide these protections."
"for example, if there isn't object-level confidentiality protection of messages, then the transport protocol should provide it" "If there isn't confidentiality protection of Evidence and Attestation Results in the conceptual messages, the underlying conveyance protocol should provide these protections."
Change:
may be to fix bugs in software, to add new functionality, or to re- configure the device. <del> The firmware update process has to ensure that </del> <ins> The firmware update process, among other goals, has to ensure that </ins> The firmware image is authenticated and attempts to flash a malicious firmware image are prevented.

Discussion:
Added David Brown as co-author Added further terms Updated text about permissions Re-wrote text about operating modes Editorial changes (including formatting) Revised section about claims Added new architecture figure Reworked security description Included device firmware update examples provided by David. Updated example flow (and included bootloader)
Change:
To enforce forward secrecy and post-compromise security of messages, each participant periodically updates its leaf secret which represents its contribution to the group secret.  Any member of the <del> group can send an Update at any time by generating fresh leaf secret and keys and send an Update message that describes how to update the </del> <ins> group can send an Update at any time by generating a fresh leaf secret and sending an Update message that describes how to update the </ins> group secret with that new information.  Once all participants have processed this message, the group's secrets will be unknown to an attacker that had compromised the sender's prior leaf secret.

Discussion:
NAME Hi Brendan ! Would you mind please revert the last of the 3 changes. Even though the sentence is not amazing and your change correct, I find it better to keep explicit the fact that the root should not be included, instead of having to infer it from the fact it has no siblings :) Thanks !
You don't have to infer it -- direct paths are defined to never include the root node in the sentence just before.
Change:
The IANA policy for future additions to this sub-registry is based on number ranges for the option numbers, analogous to the policy defined <del> in Section 12.2 of RFC7252. </del> <ins> in Section 12.2 of RFC7252.  (The policy is analogous rather than identical because the structure of the subregistry includes an additional column; however, the value of this column has no influence on the policy.) </ins> The documentation for a Signaling Option Number should specify the semantics of an option with that number, including the following

Discussion:
Partially addresses
It is analogous, because the structure of the subregistry is slightly different (additional column). We can add a sentence that the value of the additional column does not influence the choice of the policy. Good point. OK, “update” is not the right word them. Good point. It was smeared all over the document, and then we collected it in an appendix. I don’t think anyone would have a strong opposition against making it a mainline section. Should we?
In general, I prefer to separate out unrelated issues (editorial or not) to simplify tracking/closing: Regarding: There are at least three similar cases of "both endpoints" which would need to be corrected together.
NAME - Regarding Ben's comment (which you seem to concur with ...): 7.6: The "updates" in this section are confusing. I understand this to mean that the procedures for TCP and WS are identical to those for UDP except for the mentioned steps. But the language of the form of "This step from [RFC7252] is updated to:" makes it sound like this intends to actually change the language in 7252 to this new language. If the latter, then that effectively removes UDP support from 7252 as updated. This could easily be fixed by changing that to something to the effect of "When using TCP, this step changes to ..." The text actually updates RFC7252 to address all cases. I don't see how it effectively removes UDP support since the text is additive. For example: This step from [RFC7252]: If does not equal the request’s destination UDP port, include a Uri-Port Option and let that option’s value be . is updated to: If does not equal the request’s destination UDP port or TCP port, include a Uri-Port Option and let that option’s value be .
NAME - I do not feel strongly about moving Appendix A - but I'm open to suggestions. It's hard to find the right place in the flow - perhaps before/after Section 6?
This issue is partially addressed by - which I'm merging now since I'm on leave for the next two weeks. The other potential editorial changes are pending responses from NAME
Change:
11.1. <del> IANA is requested to create an entry, encrypted_client_hello(0xffce), in the existing registry for ExtensionType (defined in RFC8446), with "TLS 1.3" column values being set to "CH, EE", and "Recommended" column being set to "Yes". </del> <ins> IANA is requested to create the following two entries in the existing registry for ExtensionType (defined in RFC8446): encrypted_client_hello(57), with "TLS 1.3" column values being set to "CH, EE", and "Recommended" column being set to "Yes". outer_extension(58), with the "TLS 1.3" column values being set to "CH", and "Recommended" column being set to "Yes". </ins> 11.2.

Discussion:
Once we have some implementations that interop, we'll go ahead with early codepoint allocation. The new version matches -07, which will be the next draft version we submit. cc NAME NAME
We need to pick some values for the "encryptedclienthello(TBD)" and for the HTTPSSVC RR type before we can do interop. Allocating some values from the private ranges for those before draft-07 is pushed out would be good so we can do some interop testing. (Or for whatever is the next draft for which we want to do interop.)
Change:
Message Framer, all bytes received on the Connection will be represented as one large Message of indeterminate length. <ins> In the following example, an application only wants to receive up to 1000 bytes at a time from a Connection.  If a 1500-byte message arrives, it would receive the message in two separate ReceivedPartial events. </ins> 9.3.2.3. A ReceiveError occurs when data is received by the underlying

Discussion:
Reading 7.3.2 I found the concepts there quite abstract. I think it would really help to be a bit more specific and e.g. take UDP and TCP as examples basically saying some like: as UDP is consider a message based protocol, each received datagram will trigger receive() of a complete message. As TCP is stream-based all TCP segments will be delivered by ReceivedPartial().
My impression here is that we could use some examples for different protocols for sending and receiving (for messages, datagrams, and raw streams). This could be a 7.4 Examples section.
Do we need to do this - can we just close this?
I think it's still valuable to have an example of ReceivedPartial somewhere.
The ReceivedPartial example is good. I think we may need clarification that Received can support object-based rather than just byte-array-based responses.
LGMT