jiebi/CodeConvo huggingface dataset:
Change:
taken to fulfill the challenge, e.g., removing files that have been provisioned to a web server. <del> Presumably, the client's responses provide the server with enough information to validate one or more challenges.  The server is said to "finalize" the authorization when it has completed all the validations it is going to complete, and assigns the authorization a </del> <ins> The server is said to "finalize" the authorization when it has completed one of the validations, by assigning the authorization a </ins> status of "valid" or "invalid", corresponding to whether it considers the account authorized for the identifier.  If the final state is "valid", the server MUST add an "expires" field to the authorization.

Discussion:
With the combinations array now removed, this is no longer accurate.
If you could re-wrap that paragraph to get rid of the short line, LGTM.
I tend not to re-wrap Markdown on edits because it makes diffs & blames more meaningful. Do you feel strongly about the wrapping?
Change:
unique issuer public key for each value of metadata, such that N keys yields log2(N) bits of metadata.  The total amount of metadata bits included in a token is the sum of public and private metadata bits. <del> See parametrization for discussion about metadata limits. </del> Public metadata is that which clients can observe as part of the token issuance flow.  Public metadata can either be transparent or

Discussion:
After quickly skimming the parameterization section, it became clear that we already discuss these things in various consideration sections throughout the document, so this was just redundant. Moreover, it's very use-case and deployment specific that once had value in the joint deployment model, so it doesn't seem like particularly helpful now that we've generalized things a bit. Removing and avoiding confusion seems like the best path forward.
I'll take this one to the list before merging.
The privacy calculations should be updated to take into account metadata more explicitly, and take into account the cost of the number of redemptions, rather than the global issuer count. If used in a multiple disjoint architecture ecosystem, then the math should also be taken in terms of a specific 'context' rather than treating the whole PrivacyPass ecosystem as a single global system (allowing for more nuanced requirements/limitations on issuer counts).
On reflection, we may be better off deleting the text entirely and making sure the justification for the parameterization is adequately covered in the security and privacy considerations elsewhere in the document.
Change:
Message Framers are functions that define simple transformations between application Message data and raw transport protocol data.  A <del> Framer can encapsulate or encode outbound Messages, and decapsulate or decode inbound data into Messages. </del> <ins> Framer can encapsulate or encode outbound Messages, decapsulate or decode inbound data into Messages, and implement parts of protocols that do not directly map to application Messages (such as protocol handshakes or preludes before Message exchange). </ins> While many protocols can be represented as Message Framers, for the purposes of the Transport Services API, these are ways for

Discussion:
That change would have helped me understand what framers can do. It seems a bit out of sync with " A Framer can encapsulate or encode outbound Messages, and decapsulate or decode inbound data into Messages." which sounds like it'd preclude operations like processing received data (or whole messages) into connection object state without emitting a message again -- maybe that sentence could be extended along with it (if even just to include "for example" or "or modify the connection object").
NAME we've added some clarifying text in the message framer definition
Impl draft Section 4.5: Handling racing with "unconnected" protocols "In the case that the application signals that the initial Protocol Stack is failing for some reason and that another option should be attempted, the Connection can be updated to point to the next candidate Protocol Stack. This can be viewed as an application-driven form of Protocol Stack racing." How does the application indicate that? I don't think this is covered by the API draft? Also I would recommend to move this section as a subsection within 4.5. (Completing Establishment) or at least switch the order with the previous section (Establishing multiplexed connections) to get a better reading flow.
This may affect the API draft so we should conclude if the API draft needs to be updated. We do have the functionality in NEAT for racing with unconnected protocols so i think the text is based on that.
Change this to text about how a framer can be used to drive racing over UDP. We shouldn't have a special API for marking the current connection failed.
Action is to propose initial text and follow up at next interim.
Change:
oauth-signed-http-request section 4, with the following additional requirements: <del> The at (access token) field MUST be omitted unless this method is being used in conjunction with an access token as in use-access- token.  [[ See issue #112 [86] ]] </del> <ins> The "at" (access token) field MUST be omitted unless this method is being used in conjunction with an access token as in use- access-token.  [[ See issue #112 [86] ]] </ins> <del> The b (body hash) field MUST be calculated and supplied, unless </del> <ins> The "b" (body hash) field MUST be calculated and supplied, unless </ins> there is no entity body (such as a GET, OPTIONS, or DELETE request).

Discussion:
iss-sub was renamed to iss_sub in draft -06 of secevent identifiers drop unnecessary hyphenation the initial introduction sentence still might need some more significant rewording
Change:
setRemoteDescription, meaning the PeerConnection is in the "remote- pranswer" or "stable" states, an offer is generated based on the negotiated session descriptions by following the steps mentioned for <del> the "local-offer" state above, along with these exceptions: [OPEN ISSUE: should this be permitted in the remote-pranswer state? https://github.com/rtcweb-wg/jsep/issues/143] </del> <ins> the "local-offer" state above, along with these exceptions: </ins> If a m= section exists in the current local description, but does not have an associated local MediaStreamTrack (possibly because

Discussion:
Discusses multiple imageattr; use of different codecs; no aspect ratio handling; preserve aspect ratio when scaling
LGTM
LGTM
Change:
Verify that the resulting URI is well-formed. <del> Dereference the URI using an HTTP GET request. </del> <ins> If the client has supplied an address to use, verify that the address is included in the A or AAAA records to which the domain name resolves.  If the address is not included in the result, the validation fails. Dereference the URI using an HTTP GET request.  If an address was supplied by the client, use that address to establish the HTTP connection. </ins> Verify that the body of the response is well-formed key authorization.  The server SHOULD ignore whitespace characters at

Discussion:
This looks fine to me, and consistent with the list discussions. (I have a couple of minor issues, which I filed as .) I am merging this in preference to , which got negative feedback on the list.
The format should be specified more clearly, by reference to a couple of RFCs The "peer" provision seems kind of awkward. For server implementations where the validation is done by a separate entity than the ACME interactions (like ), this means that the challenge no longer has all the information that the validation agent needs to do the validation. I'm inclined to drop it and put the burden on the client.
Change:
3.3.5. CurveCP CurveCP is a UDP-based transport security protocol from <del> Daniel J.  Bernstein.  Unlike other security protocols, it is based entirely upon highly efficient public key algorithms.  This removes many pitfalls associated with nonce reuse and key synchronization. CurveCP provides its own reliability for application data as part of its protocol. </del> <ins> Daniel J.  Bernstein.  Unlike many other security protocols, it is based entirely upon public key algorithms.  CurveCP provides its own reliability for application data as part of its protocol. </ins> 3.4.

Discussion:
Addresses
Comment from Ekr'r review of -10: S 3.3.5. CurveCP [CurveCP] is a UDP-based transport security protocol from Daniel J. Bernstein. Unlike other security protocols, it is based entirely upon highly efficient public key algorithms. This removes many pitfalls associated with nonce reuse and key synchronization. This text is going to be confusing to people. Not to say that CurveCP is bad, and the primitives it uses are fast, but they're not any faster than those used by TLS, QUIC, or tcpcrypt. I think the consensus here is that it's not currently practical to have a general purpose transport protocol that doesn't do key establishment and then use symmetric keys. (This is the same reason why we weren't able to use public key encryption for QUIC CID encryption). Reply from Kyle: Good point. We could discuss the tradeoff between performance and security that DJB was trying to achieve, but that is probably out-of-scope for this document, so we should stick to a value-free description (e.g., "based entirely on public key algorithms") and let it go with that.
LGTM!
Change:
TLS ExtensionType Registry: Values with the first byte in the range 0-254 (decimal) are assigned via Specification Required <del> RFC2434.  Values with the first byte 255 (decimal) are reserved for Private Use RFC2434.  IANA [SHALL update/has updated] this </del> <ins> RFC5226.  Values with the first byte 255 (decimal) are reserved for Private Use RFC5226.  IANA [SHALL update/has updated] this </ins> registry to include the "key_share", "pre_shared_key", and "early_data" extensions as defined in this document.

Discussion:
RFC 5226 obsoleted RFC 2434 so we should refer to that to avoid a GENART review comment.
Change:
*Note:* This registry will not exist until SEMANTICS is approved. *RFC Editor*, please remove this note prior to publication. <del> As in previous versions of HTTP, field names are strings containing a subset of ASCII characters that are compared in a case-insensitive fashion.  Properties of HTTP field names and values are discussed in more detail in Section 5.1 of SEMANTICS.  As in HTTP/2, characters in </del> <ins> Field names are strings containing a subset of ASCII characters. Properties of HTTP field names and values are discussed in more detail in Section 5.1 of SEMANTICS.  As in HTTP/2, characters in </ins> field names MUST be converted to lowercase prior to their encoding. A request or response containing uppercase characters in field names MUST be treated as malformed (malformed).

Discussion:
NAME said
NAME said
Honestly, this whole sentence is a bit awkward. I'll improve that.
NAME said
I have to say, this is a little odd. HTTP requires case insensitive comparison, but by calling it out here, the juxtaposition is weird. As we force lowercase, we could just strike: "that are compared in a case-insensitive fashion"
The first is a statement of fact about what SEMANTICS requires. However, I agree that we reduce confusion and lose nothing by making the statement less explicit. Interested parties can read SEMANTICS.
Yes, the proposed text addresses my comments. Thanks for the updates.
Change:
of type "urn:ietf:params:push". The push service MUST provide a URI for a receipt subscribe resource <del> in a link relation of type "urn:ietf:params:push:receipt". </del> <ins> in a link relation of type "urn:ietf:params:push:receipts". </ins> An application-specific method is used to distribute the push and receipt subscribe URIs to the application server.  Confidentiality

Discussion:
Is there any value in using a link relation type for the receipt subscription rather than a new header field? We already have to define the link relation type, so maybe it can save on a bit of protocol machinery.
While considering this, I noticed an editorial error in Section 10.2 where the link relation is referenced as urn:ietf:push:receipts instead of urn:ietf:push:receipt which is used throughout the rest of the draft. Using a link relation might be more consistent - not sure that it saves on protocol machinery? Are you proposing to replace the Push-Receipt header with a new link relation - potentially there would be: push:receipts - to create new receipt subscriptions push:receipt - a specific receipt subscription
Yes, there are the same number of moving parts. My mistake. Just remembered the actual reason for opening the issue. The HTTP working group often state that header fields need to have wide applicability for them to be defined, otherwise the data they carry is best carried in payload bodies. The same restriction does not apply to link relations.
Change:
A relative href value denotes the path to the registration resource of the Endpoint.  When pointing to a registration resource on a <del> different RD, the href value is an absolute URI. </del> <ins> different RD, the href value is a URI. </ins> 6.2.

Discussion:
The previous text did not match my intentions, back when I thought of "absolute URIs" as "URI references that are already in URI form", where actually they are a construct intended for protocols to express that the fragment part does not take part in the dereferencing process. Closes: URL Will merge soon unless it conflicts with someone's private branches or draws other negative comments.
+1 for awareness of the difference between a URI and a reference to a URI
Oh, I see. But then I've been using the term wrong. In ABNF terminology for RFC3986, there's a "URI" (thing-with-scheme), a "relative-ref" and a "URI-reference" (which can be relative or not). I had thought it wise to talk of absolute URIs when I mean thing-with-scheme to disambiguate "URI" from "URI-reference", unaware that "absolute-URI" is even stricter. As we are not designing a communication protocol, we should not use the term "absolute URI", but talk of "URI" or (if ambiguous) a "complete URI". I'll need to patch that in the draft, sorry for the mess and thanks for pointing it out.
Change:
stop and an error MUST be returned. Next, the SessionDescription is parsed into a data structure, as <del> described in the sec.parsing-a-desc section below.  If parsing fails for any reason, processing MUST stop and an error MUST be returned. </del> <ins> described in sec.parsing-a-desc below.  If parsing fails for any reason, processing MUST stop and an error MUST be returned. </ins> Finally, the parsed SessionDescription is applied as described in <del> the sec.applying-a-remote-desc section below. </del> <ins> sec.applying-a-remote-desc below. </ins> 5.7.

Discussion:
This addresses Adam's actual comment - and adds the first references to rollback in the processing section - but leaves the details to be filled in by a future PR.
LGTM
Change:
an optional authenticator request or certificate_request_context (from 0 to 255 bytes) <del> It returns the exported authenticator as a sequence of octets.  It is RECOMMENDED that the logic for selecting the certificates and extensions to include in the exporter is implemented in the TLS library.  Implementing this in the TLS library lets the implementer take advantage of existing extension and certificate selection logic. </del> <ins> It returns the exported authenticator as a sequence of octets. Ideally, the logic for selecting the certificates and extensions to include in the exporter is implemented in the TLS library. Implementing this in the TLS library lets the implementer take advantage of existing extension and certificate selection logic. </ins> It is also possible to implement this API outside of the TLS library using TLS exporters.  This may be preferable in cases where the

Discussion:
It's also the only use of 2119 language in this section, which is otherwise nicely informative.
Change:
session not be resumed.  This is a change from TLS 1.0 to conform with widespread implementation practice. <del> Either party may initiate a close by sending a close_notify alert. </del> <ins> Either party MAY initiate a close by sending a close_notify alert. </ins> Any data received after a closure alert is ignored. Unless some other fatal alert has been transmitted, each party is

Discussion:
It refers to potentially sending a message so I would say its caps, though I am not sure about this one ...
Change:
This section defines Extract, Expand and other key derivation functions based on these: Expand is used to define EDHOC-KDF and in turn EDHOC-Exporter, whereas Extract is used to define EDHOC- <del> KeyUpdate. </del> <ins> KeyUpdate.  In EDHOC a specific message always use the same key, but how the key is derived depends on the method.  A diagram of the EDHOC key schedule can be found in Figure 2 of Vucinic22. </ins> 4.1.

Discussion:
From Sean's review: s5.1 (question): Is a state diagram needed? One thing people clamored for from TLS was a state machine. Maybe a diagram isn’t needed because there are so few states?
Not sure it is needed in EDHOC. TLS has three distict states (early data, handshake, post handshake) and the key to use depend on the state irrespective of message type. EDHOC has none of that. A key derivation figure would maybe make more sense if we are to add anything.
Suggestion by Goran to add a reference to an academic paper that has a figure with the key derivation
Perhaps sufficient to refer to figure 2?
I don't have a strong preference, but fig 3 is used for message_4.
But message_4 will likely not be used in most deployments, so maybe Fig 2 is enough.
I think this can be closed after interim today, unless there are any more comments.
Change:
RFC6347.  It merely provides a more robust mechanism for associating an incoming packet with a stored security context. <del> 8. </del> <ins> 7. </ins> IANA is requested to allocate an entry to the existing TLS "ExtensionType Values" registry, defined in RFC5246, for

Discussion:
Trying to address URL but also trying to expand the description a bit for clarity.
According URL all records seems to use a . Does this include the ?
Does this PR provide an improvement help? URL
Yes, it clarifies it for me.
Change:
hardness assumptions of the underlying cryptographic protocol(s). The issuance protocol can reveal the Issuer public key for the purposes of determining which private key to use in producing the <del> token.  A result of this property is that the redemption flow is unlinkable from the issuance flow. </del> <ins> token. </ins> One-more forgery security.  The issuance protocol MUST NOT allow malicious Clients or Attesters (acting as Clients) to forge tokens

Discussion:
cc NAME
E.g., consider a protocol where the Issuer signs a commitment to the token challenge. This fails as an unlinkable anonymous credentials because the signature is not randomized, but is has input secrecy because of the commitment.
In this hypothetical example, is the commitment not revealed during redemption? If so, I think we could address this by saying that input secrecy is necessary but insufficient for unlinkability. Thoughts?
Change:
"init_secret" for the current epoch and the path secret (if present). <del> Construct a Welcome message from the encrypted GroupInfo object, the encrypted key packages, and any PSKs for which a proposal was included in the Commit.  The order of the "psks" MUST be the same as the order of PreSharedKey proposals in the "proposals" vector. </del> <ins> Construct one or more Welcome messages from the encrypted GroupInfo object, the encrypted key packages, and any PSKs for which a proposal was included in the Commit.  The order of the "psks" MUST be the same as the order of PreSharedKey proposals in the "proposals" vector.  As discussed on joining-via-welcome- message, the committer is free to choose how many Welcome messages to construct.  However, the set of Welcome messages produced in this step MUST cover every new member added in the Commit. </ins> If a ReInit proposal was part of the Commit, the committer MUST create a new group with the parameters specified in the ReInit

Discussion:
This initial effort tweaks the sections that talk about generating and processing Welcome messages. There might be other references to a single Welcome per Commit that should be amended for clarity. Someone should audit for those before we merge this PR.
From my reading, it looks like the creator of an epoch must send the exact same message to each new user. However, in some systems, it is more efficient to send a different message to each user, only containing the intended for them, rather than the for all new members. As far as I can tell, no changes are required on the recipient side. I'm running some performance testing, trying to add thousands of members at a time, and the messages are hundreds of kilobytes large. In a federated environment, this could be copied to multiple servers, with the vast majority of that being unnecessary data.
Good point NAME I filed . In the case, you would do something like send a Welcome per home server?
Thanks. With the way that Matrix currently works, it would probably be best to send a separate message per user, since the current endpoint for sending messages directly to devices requires specifying the message separately for each recipient, and implementations (AFAIK) currently don't do deduplication. In the future, it might be possible to do it differently.
NAME shouldn't ResumptionPSKUsage include (255)? enum { reserved(0), application(1), reinit(2), branch(3), (255) } ResumptionPSKUsage;
Fixed in
Change:
complete Message, the implementation should wait until an entire Message (datagram, stream, or frame) is read before delivering any Message content to the application.  This requires the implementation <del> to understand where messages end, either via a supplied deframer or because the top-level protocol in the established Protocol Stack preserves message boundaries.  If the top-level protocol only supports a byte-stream and no framers were supported, the application can control the flow of received data by specifying the minimum number of bytes of Message content it wants to receive at one time. </del> <ins> to understand where messages end, either via a supplied or because the top-level protocol in the established Protocol Stack preserves message boundaries.  If the top-level protocol only supports a byte- stream and no framers were supported, the application can control the flow of received data by specifying the minimum number of bytes of Message content it wants to receive at one time. </ins> If a Connection finishes before a requested Receive action can be satisfied, the Transport Services API should deliver any partial

Discussion:
replace DG by CL. Changed one oddity: /as to/ to /about/
"Connection establishment is only a local operation for a Datagram transport (e.g., UDP(-Lite))": I think the criterion is not Datagram transports but "transports without a handshake" or "connectionless protocols" as it is used later in the document.
I wrote, and I suggest we use "connectionless protocols" explicitly mentioning examples of UDP and UDP-Lite when used as a transport without a handshake.
To whoever plans to address this: I checked occurrences of the word "datagram" in the architecture and API drafts, and I found (only) one sentence that needs fixing on similar grounds, I think, in the API draft: in Section 8.1.4 "Timeout for keep alive packets". Surely the guidance regarding this matter in the UDP usage RFC is related to the fact that UDP(-Lite) is connectionless, not that it's datagram based.
Starting to fix this.
This LGTM