jiebi/CodeConvo huggingface dataset:
Change:
4.3. Like HTTP/2, HTTP/3 employs a series of pseudo-header fields, where <del> the field name begins with the ':' character (ASCII 0x3a).  These </del> <ins> the field name begins with the ":" character (ASCII 0x3a).  These </ins> pseudo-header fields convey message control data; see HTTP. Pseudo-header fields are not HTTP fields.  Endpoints MUST NOT

Discussion:
The RFC Editor asks:
Along the way, there are two equivalent statements that need to be deduplicated that this change touches: I would suggest collapsing these two into the first statement, but using OPTIONS as an example and keeping the reference into http-core. Or perhaps that should be a question -- is there a difference between asterisk-form and OPTIONS-without-path?
Resolved in .
Change:
document RFC5226 is required to register an extension with the value "Yes". <ins> IANA is also to add the following note: </ins> 11. IANA is to add the following entry to the TLS Alert Registry (the

Discussion:
Added the guidelines from RFC 5705
Need to add designated expert instructions for exporters like we did for ExtensionType, Cipher Suite, and ClientCertificateType Identifiers registries.
Also addressed by .
Change:
Check that the inner JWS verifies using the key in its "jwk" field. <del> Check that the payload of the inner JWS is a well-formed key- change object (as described above). </del> <ins> Check that the payload of the inner JWS is a well-formed keyChange object (as described above). </ins> Check that the "url" parameters of the inner and outer JWSs are the same. <del> Check that the "account" field of the key-change object contains </del> <ins> Check that the "account" field of the keyChange object contains </ins> the URL for the account matching the old key (i.e., the "kid" field in the outer JWS). <del> Check that the "oldKey" field of the key-change object is the same </del> <ins> Check that the "oldKey" field of the keyChange object is the same </ins> as the account key for the account in question. Check that no account exists whose account key is the same as the

Discussion:
This PR is collecting changes to make sure we address during the editing window. Editorial clarifications only, please.
Both and are also TODO's for AUTH48.
Section 7.4 says: It should say , not . NAME Would you mind fixing this typo in this PR?
NAME Turns out the RFC editor caught that one (see ), so I don't have to fix it here :)
LGTM
Change:
On receiving key-change request, the server MUST perform the following steps in addition to the typical JWS validation: <del> Check that the JWS protected header container a "jwk" field </del> <ins> Check that the JWS protected header contains a "jwk" field </ins> containing a key that matches a currently active account. Check that there are exactly two signatures on the JWS.

Discussion:
Fixing two minor typos in Section 6.2.1 "Account Key Roll-over"
Change:
deemed invalid.  Clients that receive invalid delegated credentials MUST terminate the connection with an "illegal_parameter" alert.  If successful, the client uses the public key in the credential to <del> verify a signature provided in the handshake: in particular, the </del> <ins> verify the signature provided in the handshake: in particular, the </ins> CertificateVerify message in TLS 1.3 and the ServerKeyExchange in 1.2.

Discussion:
These came up when I implemented the extension in Go (URL) and I think would be useful to add to the standard.
looks good to me
Change:
4.3. In this model, the Origin and Issuer are operated by the same entity, <del> separate from the Attester, as shown in the figure below. </del> <ins> separate from the Attester, as shown in the figure below.  The Issuer accepts token requests that come from trusted Attesters.  Depending on the issuance protocol, the Attester may relay these requests between Client and Issuer over an authenticated channel, or trust may be established in some other manner. </ins> This model is useful for Origins that require Client-identifying attestation, e.g., through the use of application-layer account

Discussion:
cc NAME
[x] 1. The Reference PPEXT is not cited in the document. seems it could be sited in the into PR [x] 2. I think it would be good to explicitly say that the HTTP authentication protocol is targeted at redemption and the issuer protocol is targeted at issuance. PR [ ] 3. Last paragraph in section 3.2.1 mentions Origin Allow Lists. These allow lists are not specifically mentioned earlier in the document. Can you clarify this. [ ] 4. In section 4.3 and 4.4 is the attester involved in the TokeRequest and TokenResponse messages? Is the attester proxying the communication? It would be good to clarify this in the text. [ ] 5. Section 6 has an incomplete reference. [x] 6. It seems that the Reference to RFC 8446 is not needed. PR [ ] 7. The link - URL does not work perhaps this is the updated one? - URL
Change:
4.2.3. <del> The client uses the "signature_algorithms" extension to indicate to the server which signature algorithms may be used in digital signatures.  Clients which desire the server to authenticate itself via a certificate MUST send this extension.  If a server is authenticating via a certificate and the client has not sent a "signature_algorithms" extension, then the server MUST abort the handshake with a "missing_extension" alert (see mti-extensions). The "extension_data" field of this extension in a ClientHello contains a SignatureSchemeList value: </del> <ins> TLS 1.3 provides two extensions for indicating which signature algorithms may be used in digital signatures.  The "signature_algorithms_cert" extension applies to signatures in certificates and the "signature_algorithms" extension, which originally appeared in TLS 1.2, applies to signatures in CertificateVerify messages.  The keys found in certificates MUST also be of appropriate type for the signature algorithms they are used with.  This is a particular issue for RSA keys and PSS signatures, as described below.  If no "signature_algorithms_cert" extension is present, then the "signature_algorithms" extension also applies to signatures appearing in certificates.  Clients which desire the server to authenticate itself via a certificate MUST send "signature_algorithms".  If a server is authenticating via a certificate and the client has not sent a "signature_algorithms" extension, then the server MUST abort the handshake with a "missing_extension" alert (see mti-extensions). The "signature_algorithms_cert" extension was added to allow implementatations which supported different sets of algorithms for certificates and in TLS itself to clearly signal their capabilities. TLS 1.2 implementations SHOULD also process this extension. The "extension_data" field of these extension contains a SignatureSchemeList value: </ins> %%% Signature Algorithm Extension

Discussion:
The only thing that might need text (though I'm not certain) is that this doesn't describe what it means to have signaturealgorithmscert and not signaturealgorithms. I assume that it means that a signature isn't possible. However, in previous versions it would be interpreted to mean something else based on default values for signaturealgorithms.
Change:
addresses on a single link.  In such cases, identification could be performed by subnet, such as the /64 to which the IP belongs. <ins> 3.4.3. The URLs provided in the API SHOULD contain all the information necessary to render the resources requested: the resources should not depend on ambient information, such as remote address on the connection.  This is to ensure that the content served from these URLs is correct and meaningful to the User Equipment, even when accessed from a network other than the one that contains the captive portal.  One consequence of this is that URLs provided in the API are expected to be resolved using public DNS. Though a URL might still correctly resolve when the UE makes the request from a different network, it is possible that some functions could be limited to when the UE makes requests using the captive network.  For example, payment options could be absent or a warning could be displayed to indicate the payment is not for the current connection. URLs could include some means of identifying the User Equipment in the URLs.  However, including unauthenticated User Equipment identifiers in the URL may expose the service to spoofing or replay attacks. </ins> 4. This section aims to improve understanding by describing a possible

Discussion:
Thanks for doing this! I've left a few minor comments.
Just for transparency. Erik and I discussed this and made a few editorial changes.
thanks, was just trying to work on the changes here
Based on discussion in Singapore, the group decided to recommend (not require) that URLs use names that can be resolved from the public DNS (no split horizon, etc...). The content served from those URLs should also not be dependent on the network path, but instead the URL would include all information necessary to produce the resource.
i remember we were talking about primarily venue URL should be context free however, the architecture doc does not mention the venue URL (only portal URL) which section shall we add this context-free please? (maybe in section_pvd?) shall we also mention this in the api doc?
I think that NAME might want to think about what to include once we have text here. The text can be generic. I would suggest a new Section 3.5 as this relates to identification of UE. That is, you say that information presented in the API - and in particular URLs - need to include identification UE information. In particular, any information that is used from this context should not depend on ambient information, such as the remote address on a connection, as this information might be used by the UE on a different network interface. For example, a user might access venue information URLs from another network. You might also then mention that this might expose the service to spoofing or replay of that information in those cases. This might mean that though the URL might "work", it might not present all options. For instance, payment options might not be offered, or if they are, warnings might be shown that the payment is not for the current connection.
Thanks for doing this. This seems to accurately capture the outcome of the discussion we had.
Change:
issue the certificate (see identifier-authorization).  If the client fails to complete the required actions before the "expires" time, then the server SHOULD change the status of the order to "invalid" <del> and MAY delete the application resource. </del> <ins> and MAY delete the order resource. </ins> The server MUST issue the requested certificate and update the order <del> resource with a URL for the certificate as soon as the client has </del> <ins> resource with a URL for the certificate shortly after the client has </ins> fulfilled the server's requirements.  If the client has already satisfied the server's requirements at the time of this request (e.g., by obtaining authorization for all of the identifiers in the

Discussion:
Also fix an example date and fix an RFC reference to not be redundant.
Merging based on manual review, since CircleCI for PRs seems to be busted.
Change:
values MUST be used, as described in the initial answer section above. <del> If the m= section is not bundled into another m= section (i.e., it is either not bundled or it possesses the sender's BUNDLE-tag) each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless the ICE configuration has changed (either changes to the supported STUN/TURN servers, or the ICE candidate policy), or the "IceRestart" option (sec.icerestart was specified.  If the m= section is bundled into another m= section, it MUST NOT contain any ICE credentials. </del> <ins> Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless the m= section is restarting, in which case new ICE credentials must be created as specified in RFC5245, Section 9.2.1.1.  If the m= section is bundled into another m= section, it still MUST NOT contain any ICE credentials. </ins> If the m= section is not bundled into another m= section, for each candidate that has been gathered during the most recent gathering

Discussion:
Change position of initial paragraph on handling of bundled m= sections; simplify some text; remove discussion of ICE restart option in answers.
NAME FYI
Change:
1.1.4.1. <del> To illustrate properties of literals, a link example of RFC8288 is </del> <ins> To illustrate non-trivial literals, a link example of RFC8288 is </ins> converted. (Note that even the conversion scheme hinted at above for RFC6690

Discussion:
With direction on its way into a tag (discussion pending -- will it be a dedicated one or inside 38), the only use case we had for properties on literals is gone. I think the whole model is better if we remove them -- anything that can be expressed with properties can also be expressed with tags, but the latter are well defined and understood whereas the former are not. (What does it mean if two properties are on a literal and both are defined but their interaction is not? Tags are clearer there). PR is incomplete, needs a few more alterations.
Change:
(see issue#57).  For example, how does a leader respond to a collect request if the helper drops out?] <ins> The collector then decrypts each aggregate share "share" using the following procedure: where "sk" is the HPKE secret key, "task_id" is "AggregateReq.task_id" and "server_role" is the role of the server that send the aggregate share ("0x01" for the leader and "0x00" for the helper). "batch_interval" is the "Interval" from the "CollectReq".  The collector then unshards the aggregate shares into an aggregate result using the VDAF's "agg_shares_to_result" algorithm. </ins> 4.4.1. Before an aggregator responds to a collect request or aggregate-share

Discussion:
The info strings used in HPKE context construction used the prefix "pda", referring to the old "Private Data Aggregation" name of this protocol. This commit also adds text instructing the collector how to decrypt the aggregate shares it receives and to use the VDAF's unsharding algorithm to obtain aggregate results.
Question for the reviewers: VDAF defines labels like (). Should we include the draft version number in info strings like this? e.g. ?
Change:
In compatibility mode (see middlebox) this field MUST be non- empty, so a client not offering a pre-TLS 1.3 session MUST generate a new 32-byte value.  This value need not be random but <del> SHOULD be unpredictable to avoid but SHOULD be unpredictable to avoid intermediaries fixating on a specific value (also known as ossification).  Otherwise, it MUST be set as a zero length vector (i.e., a single zero byte length field). </del> <ins> SHOULD be unpredictable to avoid implementations fixating on a specific value (also known as ossification).  Otherwise, it MUST be set as a zero length vector (i.e., a single zero byte length field). </ins> This is a list of the symmetric cipher options supported by the client, specifically the record protection algorithm (including

Discussion:
There are many sorts of TLS middleboxes (CDN, decrypting proxy, local antivirus, actual attack, etc), with acceptabilities ranging from reasonable to extremely questionable to a terrible idea. (Categorization is left as an exercise to the reader.) They also have very different security considerations. Fundamentally, TLS secures a connection between two endpoints. As such, we have something to say about the endpoint-to-endpoint connections that make up such a system, but we shouldn't imply this section is sufficient, merely necessary. Adjust the text accordingly. I wrote "intermediary" in the original PR, predictively based on PR . Since the spec seems to have settled on "middlebox", align the terminology. (I don't really care what is used, just that it is consistent.)
Ah yeah. Fixed. I used "implementations" for this one because there is an "(also known as ossification)" parenthetical and, in the general case, endpoints can cause ossification too. Even here, I dunno, maybe a sufficiently confused endpoint will do something silly there. :-)
Should the legacysessionid description, which also mentions intermediaries, also be tweaked?Thanks!
Change:
Blank the intermediate nodes along the path from the removed leaf to the root <ins> Truncate the tree by reducing the size of tree until the rightmost non-blank leaf node </ins> 11.1.4. A PreSharedKey proposal can be used to request that a pre-shared key

Discussion:
This PR adds text to truncate the tree to perform garbage collection on removal. [ref: URL]
Over time we lost the rule that the ratchet tree should also be trimmed after members have been removed (where it really makes sense), not only when members are added.
NAME posted to address this issue
Fixed in - URL
Earlier, we had considered a "masking" approach for sender data, much like QUIC does for . This approach would save 28 bytes of overhead (nonce + tag), but was abandoned because of uncertainty around the security of the masking approach. Since then, Bellare et al. published , which includes what is effectively a proof of the security properties of the QUIC scheme. The QUIC scheme is essentially scheme HN1 of the paper, the main difference being that QUIC encrypt not the nonce directly, but a packet number which is used to compute the nonce. Our application would be similar, since we would encrypt metadata used to encrypt the key and the nonce. Given this new analysis, is it time to bring back masking?
Fixed by
Change:
The protocol must ensure interoperable media formats through a mandatory to implement format wherein a query must be able to <del> contain one or more EDNS extensions, including those not yet defined. </del> <ins> contain future modifications to the DNS protocol including the inclusion of one or more EDNS extensions (including those not yet defined). </ins> The protocol must use a secure transport that meets the requirements for HTTPS.

Discussion:
Right now the text only defines that future edns options must be supported, but (IMHO) we should support all future versions of changes to the DNS in general, not just future EDNS extensions. So I proposed text that rewords a bit to state this and uses EDNS as an example.
Good call. There might be other on-the-wire extension mechanisms in the future.
Change:
HTTP extensions sometimes need to access underlying transport protocol features such as unreliable delivery (as offered by DGRAM) <del> to enable desirable features like an unreliable version of the CONNECT method, and unreliable delivery in WebSockets RFC6455 (or its successors). </del> <ins> to enable desirable features.  For example, this could allow introducing an unreliable version of the CONNECT method, or adding unreliable delivery to WebSockets RFC6455. </ins> In datagrams, this document describes HTTP Datagrams, a convention that supports the bidirectional and possibly multiplexed exchange of

Discussion:
Section 1: To my understanding WebSockets have no partial reliability features per that specification. So I think the formulation is missleading. To enable this in WebSockets, would it not require an update to WebSockets. I thought WebTrans is basically that update. So why not reference WebTrans here instead, it will anyway be an informational reference.
These are examples of potential future extensions that serve to illustrate the motivation. The fact that we're not planning on building such examples does not diminish their usefulness. Readers might be more familiar with WebSocket than with WebTransport at this point.
Change:
4. <del> Define a registry that can contain both namespaces and keys. Namespaces can be recognized by ending with a hyphen/minus.  Actual keys do not.  See registered for the detailed information (to be edited). </del> <ins> IANA is requested to establish a registry called "Timestamp Suffix Tag Keys".  Each entry in the registry shall consist of the information described in registered.  Initial contents of the registry are specified in namespaced. </ins> The policy is "RFC required", "Specification Required", ??? RFC8126.

Discussion:
Replace "DST" and "daylight savings time" with "daylight saving time" Replace "timezone" with "time zone" Properly capitalize "Unicode Consortium" Improve phrasing
If you don't have time to work further on this very useful PR, I could merge it and fix these three nits.
Please don't add material to this one. We went the opposite direction in the last interim, so I'm about to remove some of this text.
OK, I pushed a commit just before your last comment but will withhold any further changes.
Sorry for the unsmooth handling of this PR. I now cherry-picked from this PR. Can I ask you to rebase to main and see what remaining parts you want to pursue?
My last message was too close to the holidays. Do you want to rebase this PR? Or do you think it is essentially covered by my cherry-picking?
Thanks for the ping, NAME Almost everything was covered by the cherry-picking, but a few things remain. I have rebased the PR to include only those.
Change:
Sent by endpoints receiving any hello message containing an extension known to be prohibited for inclusion in the given hello <del> message, including any extensions in a ServerHello not first offered in the corresponding ClientHello. </del> <ins> message, including any extensions in a ServerHello or Certificate not first offered in the corresponding ClientHello. </ins> Sent by servers when unable to obtain a certificate from a URL provided by the client via the "client_certificate_url" extension

Discussion:
This change adds a set of extensions to the Certificate message. This is intended to hold all extension messages that are certificate-specific as opposed to extensions that apply to the entire connection. This change facilitates future extensions to the protocol for post-handshake server authentication and resolves the anomaly of OCSP messages appearing before certificates in the handshake.
Changed SingleCertificate to CertificateEntry
NAME this seems ready to land from my side modulo the rename I propose. Do you have any changes to make?
Change:
Closed<> occurs when a Connection transitions to Closed state without error. <del> InitiateError<> occurs when a Connection created with Initiate() transitions from Establishing state to Closed state due to an error. </del> <ins> EstablishmentError<> occurs when a Connection created with Initiate() transitions from Establishing state to Closed state due to an error. </ins> ConnectionError<> occurs when a Connection transitions to Closed state due to an error in all other circumstances.

Discussion:
Interface, section 4.1.2: Why the limitation to aliases? Specifying a protocol might limit the utility of connection racing, so should perhaps be discouraged, but does it break anything to specify a protocol for a non-alias Endpoint?
Interim: suggest to remove the second sentence.
They are currently just called "Table"
In the interface draft, Section 1.1: Where is the event sent? Perhaps ?
Interim: add "to the application" (but double check, related to framers)
Could alternatively say the same another way around: "Applications can use these events..." (i.e. avoid saying only applications do this).
Section 6 in impl-draft has the parts where the framer objects receive events. There is no terminology section in implementation, so not sure if the terminology section in API should cover it as well.
We already say this in the intro text to this section, but I can tweak the structure and add some additional text to make this more clear.
The appendix text about convenience functions talks about "implementations should" provide various things. This reads strangely to me. I think these are not requirements and the text should be more in the form of it can be useful for implementations to provide various things.
How about: " implementations can provide special actions for adding each preference level i.e, TransportProperties.Set(someproperty, avoid) would be equivalent to TransportProperties.Avoid(someproperty):..."
EstablishmentError. Fixed in an upcoming PR.