jiebi/CodeConvo huggingface dataset:
Change:
release.  The sender shuts down the connection immediately after the abort (and may or may not wait for a Release or Abort message or connection shutdown in the inverse direction).  A diagnostic payload <del> SHOULD be included in the Abort message.  Messages may be in flight when the sender decides to send an Abort message.  The general expectation is that these will NOT be processed. </del> <ins> (see Section 5.5.2 of RFC7252) SHOULD be included in the Abort message.  Messages may be in flight when the sender decides to send an Abort message.  The general expectation is that these will NOT be processed. </ins> Abort messages are indicated by the 7.05 code (Abort).

Discussion:
One more 7.01 change to 7.00. Removed redundant requirement for references to abort: MAY immediately abort the connection (see Section 4.6) . since the Abort section already has the SHOULD.
URL Signaling s/Share/Relate/ (the nodes do not "share these characteristics") Shut down s/Ordered/Orderly/ Provide diagnostic information when terminating a connection in ... 4.3. Capability and Settings Messages (CSM) Hmm, should this be "Capabilities and Settings Messages"? (Need to change throughout.) s/A/One/ s/Capability and Settings message/CSM/ s/and/. Further CSM/ s/settings/setting/ 4.3.2. Max-Message-Size Capability Option (above 1152?)
URL Appendix B. Negotiating Protocol Versions s/Capability and Settings/Capabilities and Settings Messages (CSM)/
URL Cl.4.5/4.6: The text mentions a "diagnostic payload", is some standard envisaged for this or is it implementation dependent? This is implementation dependent, although it might be helpful to adapt or reference - URL
Reviewed in more detail. There is a reference to RFC7252 in an earlier section URL
Perhaps the RFC7252 references needs to be emphasized more. Options: Blockquote related RFC7252 Section 5.5.2 in section 4.1 to call more attention to it Include an xref with each related normative statement The simplest mitigation is the xref: A Release message indicates that the sender does not want to continue maintaining the connection and opts for an orderly shutdown. The details are in the options. A diagnostic payload (see Section 5.5.2 of [RFC7252]) MAY be included.
Change:
GET <del> {+type-lookup-location}{?d,res,ep,gp,et,rt,page,count,resource- param} </del> <ins> {+type-lookup-location}{?d,ep,gp,et,rt,page,count,resource-param} </ins>

Discussion:
This solves issue ("nobody really knows what the parameter is for") by removing the parameter altogether.
We are not clear on how to use "res"in a lookup query. For example, what does xx represent in this query? GET /example/rd-lookup-gp?res=xx I couldn't find text to explain. Is it expected to be the address of a resource, like href or anchor+href ?
Hi Michael, From version 04 to the current version the ?res has undergone a change In the -10 example the return is ;rt=sensor;ct=60 where I might have expected ;rt=sensor;ct=60 But I cannot check because we do not know the contents of the RD and hypothesizing now: ?res=xx would have returned nothing unless there was an entry like ;rt=sensor;ct=60 and even more confusing we have something called resource-param. In an earlier e-mail Christian already suggested to modify that to link-param if I remember correctly. So yes, I can concur with you and agreeing with the existence of confusion. Peter Michael Koster schreef op 2017-05-05 16:01:
The last I had in mind about the parameter a short mention in the phone call -- to me it looked like a relic whose role has been superseded by ins et al. It is now the first time I perceive it as a parameter that does anything with the path. What is the intended overall purpose of res=? And what do you mean by the contents of the RD?
Hi Chris, I assume this a sequel to my answer to Michael. May be not..... The contents of the RD are all the information about ep, resources, etc. stored into the RD by whatever means. My speculation about res=xx means that it indicates filtering on resource paths which start with /xx/...... Peter
For such filtering, there is already , which is covered by the query parameter referencing RFC 6690. NAME of the RD": I see. Going through all the references in the document, it seems to me that the examples you mentioned are not about the lookup parameter, but just the arbitrary resource names in the pagination example. I'd suggest removing the parameter altogether (PR ) unless its use resurfaces.

I think "res" (for resource) may be useful as a link target attribute for tagging resources, and in that context could also be used as a lookup parameter. If we don't plan to create "res" as a target attribute we should remove it from the document. If we do want to define a new target attribute, maybe we can come up with something more descriptive than "res"...
Change:
Rendezvous: The action of establishing a peer-to-peer connection with a Remote Endpoint.  It simultaneously attempts to initiate a <del> connection to a Remote Endpoint whilst listening for an incoming connection from that endpoint.  This corresponds, for example, to a TCP simultaneous open RFC0793.  The process of identifying options for the connection, such as resolution of the Remote Endpoint, occurs during the Rendezvous call.  As with Listeners, the set of local paths and endpoints is contrained by Selection Properties.  If successful, the Rendezvous call returns a Connection object to represent the established peer-to-peer connection. </del> <ins> connection to a Remote Endpoint while listening for an incoming connection from that endpoint.  The process of identifying options for the connection, such as resolution of the Remote Endpoint, occurs during the Rendezvous call.  As with Listeners, the set of local paths and endpoints is constrained by Selection Properties. If successful, the Rendezvous call returns a Connection object to represent the established peer-to-peer connection.  The processes by which connections are initiated during a Rendezvous action will depend on the set of Local and Remote Endpoints configured on the Preconnection.  For example, if the Local and Remote Endpoints are TCP host candidates, then a TCP simultaneous open RFC0793 will be performed.  However, if the set of Local Endpoints includes server reflexive candidates, such as those provided by STUN, a Rendezvous action will race candidates in the style of the ICE algorithm RFC8445 to perform NAT binding discovery and initiate a peer-to- peer connection. </ins> 4.1.4.

Discussion:
Generalise the discussion of Rendezvous in arch.
Rendezvous: TCP simultaneous open is one type of rendezvous, but only giving this as an example makes it seems more narrowly scoped that I envisaged. For example, I'd expect Rendezvous could perform an ICE exchange it STUN candidates were passed as Remote Endpoints. Should this description be generalised?
Change:
general, it cannot be simply assumed that the source of time a target endpoint uses is synchronized or trustworthy. <ins> Information pertaining to the existence of a flaw or flaws in software, hardware, and/or firmware, which could potentially have an adverse impact on enterprise IT functionality and/or security. Vulnerability description information should contain enough information to support vulnerability detection. A type of guidance extracted from vulnerability description information that describes the specific mechanisms of vulnerability detection that is used by an enterprise's vulnerability management capability to determine if a vulnerability is present on an endpoint. An enterprise IT capability managing endpoint vulnerabilities and associated metadata on an ongoing basis by ingesting vulnerability description information and vulnerability detection data, and performing a vulnerability assessment. The process of determining whether a set of endpoints is vulnerable according to the information contained in the vulnerability description information. </ins> 3. This memo includes no request to IANA.

Discussion:
added terms from the vulnerability assessment scenario
Hi Danny, I still want to highlight one last time that we will have 3-4 different kinds of capability in the terminology in -10 if we pull this in. I understand this to be a basis of discussion still :) I am not sure if that is the case, though! Let me elaborate. We have in SACM used by the architecture: Capability: : The extent of an SACM component's ability enabled by the functions it is composed of. Capabilities are propagated by a SACM component and can be discovered by or negotiated with other SACM components. For example, the capability of a SACM Provider may be to provide endpoint management data, or only a subset of that data. We have in i2nsf, referenced in the sacm terminology: We have the VA Terms: +Endpoint management capability: +: An enterprise IT capability managing endpoint identity, endpoint information, and associated metadata on an ongoing basis. +Vulnerability management capability: +: An enterprise IT capability managing endpoint vulnerabilities and associated metadata on an ongoing basis by ingesting vulnerability description information and vulnerability detection data, and performing a vulnerability assessment. "Managed" in i2nsf means "has interface on the management-plane". I still do not understand what managing actually means in the context of an VA capability :) What potential functions are propagated as capabilities? What is their input? What is their output? Is it possible that the two VA capabilities are actually tasks? Viele Grüße, Henk TL;DR I will pull these terms in, but we will have to align these terms better. On 07/08/2016 01:56 PM, Danny Haynes wrote:
Change:
comparing the aggregate result to the previous aggregate result may result in a privacy violation.  (Note that the helpers enforce this as well; see collect-flow.)  In addition, the leader SHOULD abort the <del> upload protocol and alert the client with error "staleReport". </del> <ins> upload protocol and alert the client with error "reportTooLate". </ins> The leader MUST buffer reports while waiting to aggregate them.  The leader SHOULD NOT accept reports whose timestamps are too far in the future.  Implementors MAY provide for some small leeway, usually no more than a few minutes, to account for clock skew.  If the leader rejects a report for this reason, it SHOULD abort the upload protocol <del> and alert the client with error "reportFromTheFuture". </del> <ins> and alert the client with error "reportTooEarly". </ins> 4.2.3.

Discussion:
Defines more error types to represent various failure modes, updates protocol text to indicate when the new error types should be used, and affirms that the task ID should be encoded as base64url with no padding (since task ID has a fixed size).
NAME observes that we have an awkward MUST requirement on leaders buffering received reports: URL
We have some error codes like that aren't enumerated in the table in . We should bring that table up to date. While we're in there, I think and aren't the right types, since outdatedness or staleness aren't the only reasons that an HPKE config or report, respectively, could be rejected.
The error table was brought up to date by .
Looks great!
Change:
6.2.3. <del> This document assumes that all communication between different Oblivious Client, Oblivious Relay Resource, and Oblivious Gateway Resource is protected by HTTPS.  This protects information about which resources are the subject of request and prevents a network observer from being able to trivially correlate messages on either side of a relay.  However, it does not mitigate traffic analysis by such network observers. </del> <ins> Using HTTPS protects information about which resources are the subject of request and prevents a network observer from being able to trivially correlate messages on either side of a relay.  However, using HTTPS does not prevent traffic analysis by such network observers. </ins> The time at which Encapsulated Request or response messages are sent can reveal information to a network observer.  Though messages

Discussion:
The text noted in was correct, but we didn't have a single place where we outlined this as a direct requirement. The day where HTTP presupposes TLS has come for some, but not all of us. Until then, we can be more careful.
The document uses the term TLS connection(s) in four places: My understanding is that oHTTP is not restricted to versions of HTTP that use TLS. The obvious one being QUIC (arguably TLS-like) but presumably some future protocol that satisfies the security properties of HTTPS could be used and oHTTP wouldn't really care. Now, perhaps I'm mistaken and oHTTP does mandate TLS. If so, perhaps I'm overlooking it. URL states many requirements but not the use of HTTPS. That seems implicit via URL However, that seems in conflict with URL, which says In summary, there seems to be some opportunity to tighten up the consistency of expectations about the connections underpinning oHTTP interations.
Change:
7. <del> The ACK message is used by an endpoint to indicate handshake- containing the TLS records it has received from the other side.  ACK is not a handshake message but is rather a separate content type, with code point TBD (proposed, 25).  This avoids having ACK being added to the handshake transcript.  Note that ACKs can still be sent in the same UDP datagram as handshake records. </del> <ins> The ACK message is used by an endpoint to indicate which handshake records it has received and processed from the other side.  ACK is not a handshake message but is rather a separate content type, with code point TBD (proposed, 25).  This avoids having ACK being added to the handshake transcript.  Note that ACKs can still be sent in the same UDP datagram as handshake records. </ins> %%% ACKs struct { RecordNumber record_numbers<0..2^16-1>; } ACK;

Discussion:
In response to feedback on the mailing list (URL), this PR attempts to clarify (a) when to generate ACKs, and (b) which records to ACK.
This is much clearer to me. I see that you have removed the sentence I was having a problem with in the bullet: "Implementations MUST NOT send ACKs for handshake messages which they discard as out-of-order, because otherwise those messages will not be retransmitted"; logically, I believe you have captured this better by adding "and processed" above in "The ACK message is used by an endpoint to indicate which handshake records it has received and processed from the other side."
NAME Thank you for your feedback! I have removed the sentence because its content is already implied by what's stated in the previous section . See the commit description of URL
NAME thanks. This sensibly improves readability and clarity. Hi Hanno, Thank you for your clarifications. The example you gave helps a lot. I believe I now understand the text as written in this bullet (first bullet, not second--my bad). I no longer think it needs re-wording. Best regards, Jonathan Hanno Becker wrote:
Change:
credentials, which rely on a cryptographic binding between the entire certificate and the Delegated credential, cannot. <del> Delegated credentials allow signed messages to be bound to specific versions of TLS.  This prevents them from being used for other protocols if a service owner allows multiple versions of TLS. </del> <ins> Delegated credentials are bound to specific versions of TLS.  This prevents them from being used for other protocols if a service owner allows multiple versions of TLS. </ins> 2.2.

Discussion:
This suggests some minor changes to the draft, the goal being to clarify the text without changing any semantics. Most are minor, but one of the commits changes the way the client verification procedure is presented.
thanks a lot for the fixes, I like all of these changes
Change:
1.3" column with the following four values: "Client", indicating that the server shall not send them.  "Clear", indicating that they shall be in the ServerHello.  "Encrypted", indicating that <del> they shall be in the EncryptedExtensions block, and "No" </del> <ins> they shall be in the EncryptedExtensions block, "Certificate" indicating that they shall be in the Certificate block, and "No" </ins> indicating that they are not used in TLS 1.3.  This column [shall be/has been] initially populated with the values in this document.

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:
cryptographic standpoint. Note(3): The designated expert RFC5226 only ensures that the <del> specification is publically available. </del> <ins> specification is publicly available. </ins> 7.

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:
Since HTTP Datagrams require prior negotiation (for example, in HTTP/3 it is necessary to both send and receive the H3_DATAGRAM SETTINGS Parameter), clients MUST NOT send any HTTP Datagrams until <del> they have established support on a given connection.  If negotiation of HTTP Datagrams fails (for example if an HTTP/3 SETTINGS frame was received without the H3_DATAGRAM SETTINGS Parameter), the client MUST consider its CONNECT-UDP request as failed. </del> <ins> they have established support on a given connection. </ins> The proxy that is creating the UDP socket to the destination responds to the CONNECT-UDP request with a 2xx (Successful) response.

Discussion:
In Sec. 4 it says: If negotiation of HTTP Datagrams fails (for example if an HTTP/3 SETTINGS frame was received without the H3_DATAGRAM SETTINGS Parameter), the client MUST consider its CONNECT-UDP request as failed. IIUC it is entirely possible to do CONNECT-UDP entirely with CAPSULE frames, so I don't see why a client should fail the attempt because the first hop is H/2 only, or whatever.
Thanks for writing this up. I think this is the right solution. I'll leave this open for some time to see if anyone else would like to comment. To add context: this text predates the creation of capsules, and now CONNECT-UDP works even if QUIC datagram frames aren't available. We'll want to pick a solution for URL though. If the H3_DATAGRAM setting also covers capsules we might still need this text. But for now we can remove it.
Change:
All data channels MUST be secured via DTLS. All implementations MUST implement DTLS 1.0, with the cipher suite <del> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA and the DTLS-SRTP protection profile SRTP_AES128_CM_HMAC_SHA1_80.  Implementations SHOULD implement DTLS 1.2 with the TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite.  Implementations MUST favor cipher suites which support PFS over non-PFS cipher suites and SHOULD favor AEAD over non-AEAD cipher suites.  [[OPEN ISSUE: Should we require ECDSA?  Waiting for WG Consensus.]] The API MUST provide a mechanism to indicate that a fresh DTLS key pair is to be generated for a specific call.  This is intended to allow for unlinkability.  Note that there are also settings where it is attractive to use the same keying material repeatedly, especially those with key continuity-based authentication.  Unless the user specifically configures an external key pair, different key pairs MUST be used for each origin.  (This avoids creating a super-cookie.) </del> <ins> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA with the the FIPS186.  The DTLS- SRTP protection profile SRTP_AES128_CM_HMAC_SHA1_80 MUST be supported for SRTP.  Implementations SHOULD implement DTLS 1.2 with the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite. Implementations MUST favor cipher suites which support PFS over non- PFS cipher suites and SHOULD favor AEAD over non-AEAD cipher suites. The API MUST generate a new authentication key pair for every new call by default.  This is intended to allow for unlinkability. The API MUST provide a means to reuse a key pair for calls.  This can be used to enable key continuity-based authentication, and could be used to amortize key generation costs. Unless the user specifically configures an external key pair, different key pairs MUST be used for each origin.  (This avoids creating a super-cookie.) </ins> When DTLS-SRTP is used, the API MUST NOT permit the JS to obtain the negotiated keying material.  This requirement preserves the

Discussion:
I also cleaned up the requirements that follow on from this. I think that those changes are editorial only.
Tickling this issue. Not clear to me if it is resolved or not. Current text (-12): All implementations MUST implement DTLS 1.0, with the cipher suite TLSECDHEECDSAWITHAES128CBCSHA with the the P-256 curve [FIPS186]. The DTLS-SRTP protection profile SRTPAES128CMHMACSHA180 MUST be supported for SRTP. Implementations SHOULD implement DTLS 1.2 with the TLSECDHEECDSAWITHAES128GCM_SHA256 cipher suite. Implementations MUST favor cipher suites which support PFS over non- PFS cipher suites and SHOULD favor AEAD over non-AEAD cipher suites. (Original text of this comment turned out to be a misunderstanding. The draft linked as "editor's draft" from the project's master page is older than the published -12 version.)
I think that the actual editors draft is OK, ekr merged a while ago.
Change:
7.2.5. The PUSH_PROMISE frame (type=0x5) is used to carry a promised request <del> header field section from server to client on a request stream, as in </del> <ins> header section from server to client on a request stream, as in </ins> HTTP/2. The payload consists of:

Discussion:
HTTP Semantics refers to the field sections used at particular locations using terms "header section" and "trailer section." However, the HTTP/3 draft sometimes calls them "header field section" and "trailer field section." This PR addresses the inconsistency. It also fixes one instance "fields section."
NAME Of course I did (not). Done in 18c0242.
Have you checked to make sure QPACK matches as well?