jiebi/CodeConvo huggingface dataset:
Change:
The Preconnection Object must be specified with both a Local Endpoint and a Remote Endpoint, and also the transport properties and security <del> parameters needed for Protocol Stack selection.  The Rendezvous() Action causes the Preconnection to listen on the Local Endpoint for an incoming Connection from the Remote Endpoint, while simultaneously trying to establish a Connection from the Local Endpoint to the Remote Endpoint.  This corresponds to a TCP simultaneous open, for example. </del> <ins> parameters needed for Protocol Stack selection. The Rendezvous() Action causes the Preconnection to listen on the Local Endpoint for an incoming Connection from the Remote Endpoint, while simultaneously trying to establish a Connection from the Local Endpoint to the Remote Endpoint.  This corresponds to a TCP simultaneous open, for example. </ins> The Rendezvous() Action consumes the Preconnection.  Once Rendezvous() has been called, no further properties may be added to

Discussion:
quickly adding this to fix NAME nits before -01 submission
Text: Internally, the transport system will first exclude all protocols and paths that match a Prohibit, then only keep candidates that match a Require, then sort candidates according to Preferred properties, and then use Avoided properties as a tiebreaker. does not read correct for me... I understand excluding prohibit, but the action on require seems wrong. I expected to remove candidates with prohibit and remove candidates that do NOT have require. What is written is different. —- I would prefer a para break before: The Rendezvous() Action causes the to show the change of topic. — Refs needed: SIP or WebRTC — maximum Message size should this be capitalised? What is maxlen? The same value? Of different? —- I could not finally understand what is intended by this text; The exact disposition of the Message when the Sent Event occurs is specific to the implementation and the constraints on the Protocol Stacks implied by the Connection's Transport Properties.
Change:
map to the same server.  It could then apply analytical techniques to try to obtain the server encoding. <del> The Stream and Block Cipher CID algorithms provide robust protection against any sort of linkage.  The Plaintext CID algorithm makes no attempt to protect this encoding. </del> <ins> The Encrypted CID algorithms provide robust protection against any sort of linkage.  The Plaintext CID algorithm makes no attempt to protect this encoding. </ins> Were this analysis to obtain the server encoding, then on-path observers might apply this analysis to correlating different client

Discussion:
Some have noted that "Stream Cipher" is now a misnomer. So this PR renames them.
Change:
The corresponding server configurations contain one or more unique server IDs. <del> A dynamically allocated configuration does not include any bespoke </del> <ins> A dynamically allocated configuration does not have a pre-defined </ins> assignment, reducing configuration complexity.  However, it places limits on the maximum server ID length and requires more state at the load balancer.  In certain edge cases, it can force parts of the

Discussion:
Here are some suggestions from my first pass, but overall I think the static vs dynamic server ID allocation idea works nicely. 2 Q's: Is the definition of non-compliant different at LB and server in some cases? Might non-routable be a better term than non-compliant?
Yes, they can be different because the perception of the configuration is different. In general, during configuration updates the LB will have a configs that some servers don't. Therefore, a DCID with those CR bits will be compliant at the LB and non-compliant at the server. With static allocation, servers don't do anything with non-compliant DCIDs, so this is irrelevant. With dynamic allocation, it means that the LB will allocate an SID that the server doesn't know anything about, until: 1) the allocation times out 2) the LB has the occasion to forward another packet with that SID to the server when the server has the configuration. I don't feel strongly about this, but it works for me. If you want to file a PR with this change I'd approve it.
In PR I suggested non-routable, though I realize non-conformant may also be an option. The sentence which caused me to suggest non-routable is: URL I'm happy to write a PR if others find non-compliant potentially confusing as well.
I like it. Let's go with it.
Change:
media stream is considered to be Running, and the state of ICE overall is Running. <del> Once roles are determined for a session, they persist unless ICE is restarted.  An ICE restart causes a new selection of roles and tie- breakers. </del> <ins> Once the roles are determined for a session, they persist througout the lifetime of the session.  The roles can be re-determined as part of an ICE restart (sec-restart), but an ICE agent MUST NOT re- determine the role as part of an ICE restart unless one or more of the following criteria is fulfilled: If the controlling agent is full, and switches to lite, the roles MUST be re-determined if the peer agent is also full. If the ICE restart causes a role conflict, the roles might be re- determined due to the role conflict procedures in sec-role- conflict. NOTE: There are certain 3PCC scenarios where an ICE restart might cause a role conflict. NOTE: The ICE agents needs to inform each other whether they are full or lite before the roles are determined.  The mechanism for that is signalling protocol specific, and outside the scope of the document. An ICE agent MUST be prepared that the peer might re-determine the roles as part of any ICE restart, even if the criteria for doing so are not fulfilled.  This can happen if the peer is compliant with an older version of this specification. </ins> 5.1.3.

Discussion:
Trying to avoid conflicts with txt files by creating a new pull request for the tie-breaker and role changes.
Change:
The payload of a CoAP message that is affected by a BERT Option in <del> descriptive usage (Section 2.1 of I-D.ietf-core-block). </del> <ins> descriptive usage (Section 2.1 of RFC7959). </ins> 2.

Discussion:
There's no longer an informative reference to this expired draft. Originally, it was included in the Introduction of draft-savolainen-core-coap-websockets-07.
Change:
The total number of affected messages affected by server key compromise can be limited by regular rotation of server keys. <ins> 7.7. Including a "Date" field in requests reveals some information about the client clock.  This might be used to fingerprint clients UWT or to identify clients that are vulnerable to attacks that depend on incorrect clocks. Clients can randomize the value that they provide for "Date" to obscure the true value of their clock and reduce the chance of linking of requests over time.  However, this increases the risk that their request is rejected as outside the acceptable window. </ins> 8. One goal of this design is that independent client requests are only

Discussion:
This includes the time correction piece. I'm interested in whether people think that it is OK to include that. The section could be removed along with the corresponding IANA piece, but given the prevalence of clock skew, I'm inclined to leave it in.
The picture might help, but it is also a lot of vertical real estate to dedicate to this. Let's see if I can't compress it a little.
Maybe an alternative style is to just list the happy path actions in a list? Client sends request, gets back response with 4xx and date header, retires request with new HPKE context, and then stops based on response, or something. These four simple steps are just spread across a lot of lines right now. But this is purely editorial, so I trust your judgement here.
There is a bunch of stuff that we normatively depend on regarding the use of Date. As it seems like request-date isn't going anywhere, we should pull in the relevant pieces instead.
That sounds reasonable like a reasonable way to unblock us and make forward progress.
Addressed by .
This LGTM. I wonder if it would be helpful to show the retry dance in a picture. Something like:
Change:
the latest state of the Attester, and that any Attestation Result was generated using the latest Appraisal Policy for Evidence. <ins> This section provides a number of details.  It does not however define any protocol formats, the interactions shown are abstract. This section is intended for those creating protocols and solutions to understand the options available to ensure freshness.  The way in which freshness is provisioned in a protocol is an architectural decision.  Provisioning of freshness has an impact on the number of needed round trips in a protocol, and therefore must be made very early in the design.  Different decisions will have significant impacts on resulting interoperability, which is why this section goes into sufficient detail such that choices in freshness will be compatible across interacting protocols, such as depicted in multievidence_diag. </ins> Freshness is assessed based on the Appraisal Policy for Evidence or Attestation Results that compares the estimated epoch against an "expiry" threshold defined locally to that policy.  There is,

Discussion:
Section 10. I found the level of detail on this section on freshness out of place and inconsistent with the level of abstraction found in the rest of the test. In most other section, generic interaction of roles, artifacts, their associated topologies, and high level security properties was noted. This section delves into specific implementation choices. In particular, Is the WG sure that it needs all of the details of Section 10.3. Even among all of the Section in 10., this stands out. It doesn't seem to provide enough detail to be create interoperability but goes beyond simply introducing the concept. Section 12.3
I agree with the observation, but don't believe it requires any changes.
This was carefully discussed and weighed over the entire editorial WG phase, actually. We found delicate consensus that might have also resulted in an unusual high level of attention to detail, but that detailed is most certainly warranted here especially. I think the text reflects the WG consensus building in an appropriately nuanced fashion today and am very hesitant with trying to refactor it again (even if it suddenly spikes to a maybe surprising level of detail) as I deem it unlikely that it will improve by that, tbh.
"This section is intended for those creating protocols or solutions to understand the options available to ensure freshness"
Change:
An application primarily interacts with this API through two Objects: Preconnections and Connections.  A Preconnection represents a set of properties and constraints on the selection and configuration of <del> paths and protocols to establish a Connection with a Endpoint.  A </del> <ins> paths and protocols to establish a Connection with an Endpoint.  A </ins> Connection represents an instance of a transport Protocol Stack on which data can be sent to and/or received from a Remote Endpoint (i.e., depending on the kind of transport, connections can be bi-

Discussion:
The use of “remote” on its own offends me: “Some types of remote might …” could we make this “Remote Endpoint” to ease my reading? or whatever else is intended? Similarly can we change “locals” and “remote” here to something that is defined: “This can expose some or all of the candidate locals to the remote”
Remote Endpoint
Change:
DNS documents, including the definitions here, often refer to the fields in the RDATA of an SOA resource record by field name. <del> Those fields are defined in Section 3.3.13 of RFC1035.  The names (in the order they appear in the SOA RDATA) are MNAME, RNAME, SERIAL, REFRESH, RETRY, EXPIRE, and MINIMUM.  Note that the meaning of MINIMUM field is updated in Section 4 of RFC2308; the new definition is that the MINIMUM field is only "the TTL to be used for negative responses".  This document tends to use field names instead of terms that describe the fields. </del> <ins> "SOA" stands for "start of a zone of authority".  Those fields are defined in Section 3.3.13 of RFC1035.  The names (in the order they appear in the SOA RDATA) are MNAME, RNAME, SERIAL, REFRESH, RETRY, EXPIRE, and MINIMUM.  Note that the meaning of MINIMUM field is updated in Section 4 of RFC2308; the new definition is that the MINIMUM field is only "the TTL to be used for negative responses".  This document tends to use field names instead of terms that describe the fields. </ins> The maximum "time to live" of a resource record.  "A TTL value is an unsigned number, with a minimum value of 0, and a maximum value

Discussion:
Agree with the first one, although I don't care which way it comes out from the RFC Editor. For the second one, I have changed the wording to 'An authoritative server is named in the NS ("name server") record in a zone.' We don't need to stray into which zone has authoritative data; the double use of "authoritative" will confuse the reader without helping with the terminology.
l 179, s/octets which/octets that. This has been changed to violate the that/which conventions of the RFC Editor. l844 (new) the authoritative name server is named in the parent zone but is not authoritative data there (NS is authoritative in the child). This is discussed elsewhere in the document, and I find this addition confusing. I won't hold up pver either of these. The rest looks ok.
Change:
length of the data. The AEAD output consists of the ciphertext output by the AEAD <del> encryption operation.  The length will generally be larger than TLSPlaintext.length, but by an amount that varies with the AEAD cipher.  Since the ciphers might incorporate padding, the amount of overhead could vary with different TLSPlaintext.length values. Symbolically, </del> <ins> encryption operation.  The length of the plaintext is one greater than TLSPlaintext.length due to the inclusion of TLSPlaintext.type. The length of aead_output will generally be larger than the plaintext, but by an amount that varies with the AEAD cipher.  Since the ciphers might incorporate padding, the amount of overhead could vary with different TLSPlaintext.length values.  Symbolically, </ins> In order to decrypt and verify, the cipher takes as input the key, nonce, the "additional_data", and the AEADEncrypted value.  The

Discussion:
This pull request has been updated to the current master
Consensus at meeting to merge this PR with updates and with the dummy type byte restored. NAME has action item to actually measure whether we can strip off the now fixed type, record.version bytes.
I've updated this with the expected changes: dummy external ContentType octet is restored, and URL is after fragment.content instead of the other way around (to make it easier to encrypt without having to shuffle buffers).
I agree with davegarrett's suggestion about field naming here, and have supplied a change implementing it.
TLSCiphertext.recordversion provides no useful information, encourages implementations to check it unnecessarily, and wastes two bytes per record. It should be removed entirely. This is effectively dependent on PR or similar changes. Filing this as a specific issue rather than just bringing it up in backwards compatibility discussion. Edited to add: Note that this value is called TLSCiphertext.version in TLS 1.2 and TLSCiphertext.recordversion as of TLS 1.3 draft 06. The TLSPlaintext equivalent of this version field cannot be removed as it is required for backwards compatibility, however it's only used with ClientHello at this point.
Defer pending measurements. Note that this fate shares with removing the cleartext content type
sgtm Amending issue title.
Mozilla is working on measurements.
Change:
parsing the Quarter Stream ID field MUST be treated as an HTTP/3 connection error of type H3_DATAGRAM_ERROR. <del> Endpoints MUST NOT send HTTP/3 datagrams unless the corresponding stream's send side is open.  On a given endpoint, once the receive side of a stream is closed, incoming datagrams for this stream are no longer expected so the endpoint can release related state.  Endpoints MAY keep state for a short time to account for reordering.  Once the state is released, the endpoint MUST silently drop received associated datagrams. </del> <ins> HTTP/3 Datagrams MUST NOT be sent unless the corresponding stream's send side is open.  Once the receive side of a stream is closed, incoming datagrams for this stream are no longer expected so related state can be released.  State MAY be kept for a short time to account for reordering.  Once the state is released, the received associated datagrams MUST be silently dropped. </ins> If an HTTP/3 datagram is received and its Quarter Stream ID maps to a stream that has not yet been created, the receiver SHALL either drop

Discussion:
NAME thank you for the suggestions over on URL David and I worked through your proposal from top to bottom and turned it into this PR, which accepts many suggestions but not all. Please review and let us know if you're happy with it. NAME we believe some of your comments are addressed here too (unless tracked on a separate ticket). Please take a look.
While the argument in Section 2 "requests are strictly serialised in the connection, therefore demultiplexing is not needed" is technically correct, Section 4. further restricts the use of HTTP/1.1 connections to a single stream of capsules/HTTP datagrams. I would prefer to see this restriction as an argument here.
The sentence "Additionally, this document defines the Capsule Protocol that can convey datagrams over prior versions of HTTP." seems a little misleading … During the IETF 113 discussions, I understood capsules as general mechanism reliable datagrams/wire encoding over HTTP In the draft however, Section 1 state "Additionally, this document defines the Capsule Protocol that can convey datagrams over prior versions of HTTP." contradicts this impression. Can we clarify this?
Why is the ebnf instead of ? Should this allow request/upgrade methods to append a list of additional parameters?
Yes, allows parameters but does not. We didn't see a good reason to ban future parameters
Maybe you should mention it and require intermediaries to pass and ignore them in case they don't understand them.
as per recent changes in HTTPland specs, the ABNF adds confusion. My suggestion is to remove the ABNF. That might still leave a question over the structured types, but that is answered by the Structured Field value specs and we are unlikely to need to state anything ourselves. I can take a pass at this.
LGTM, thanks!
Change:
The leaves of the tree are indexed separately, using a _leaf index_, since the protocol messages only need to refer to leaves in the tree. <del> Like nodes, leaves are numbered left to right.  Note that given the above numbering, a node is a leaf node if and only if it has an even node index, and a leaf node's leaf index is half its node index.  The leaf indices in the above tree are as follows: </del> <ins> Like nodes, leaves are numbered left to right.  The node with leaf index "k" is also called the "k-th" leaf.  Note that given the above numbering, a node is a leaf node if and only if it has an even node index, and a leaf node's leaf index is half its node index.  The leaf indices in the above tree are as follows: </ins> 0 = A

Discussion:
I've put a bunch of little fixes in here. If you disagree with any of these changes, I can back them out or change them. maximal is defined but never used k-th leaf/leaf index is defined in two places; merge definitions change KeyPackage struct definition to reflect that ~2~ 3 extensions are required is also a required extension grammar fix add missing semicolon
One minor thing, otherwise LGTM
Change:
the header field section, sent as a single HEADERS frame (see frame-headers), <del> optionally, the payload data, if present, sent as a series of DATA </del> <ins> optionally, the content, if present, sent as a series of DATA </ins> frames (see frame-data), and optionally, the trailer field section, if present, sent as a single HEADERS frame. Header and trailer field sections are described in Sections 6.3 and <del> 6.5 of SEMANTICS; the payload data is described in Section 6.4 of </del> <ins> 6.5 of SEMANTICS; the content is described in Section 6.4 of </ins> SEMANTICS. Receipt of an invalid sequence of frames MUST be treated as a

Discussion:
… avoiding confusion with individual frame payloads (editorial). This is related to the Semantics issue URL
NAME has created URL on http-core Semantics draft, which describes how the term "payload" is overloaded when considered with the H2 and H3 docs. Roy's has a proposal to change that term in Semantics, which impacts the HTTP/3 draft. But he was kind enought to submit PR URL, which demonstrates the impact of that change. This issue is mainly for visibility and tracking purposes.
With or without NAME suggestion. I need to do the same for h2, so it is good to see URL suggestion
Change:
2. <del> Messages from HTTP-based clients to HTTP-based servers are performed </del> <ins> Messages from HTTP-based Clients to HTTP-based Servers are performed </ins> as GET and POST requests.  The messages are sent via the "Sec- Privacy-Pass" header.

Discussion:
cc NAME for review. Mainly just removing the interfaces that were previously present and using the API functions from the protocol directly. I've also changed some of the wording around the key registry, and replaced client -> Client and server -> Server. Let me know if there is anything that you think I've missed.
We currently have interfaces in the architecture document that lay out how messages should be sent and received. I think the architecture document should be solely focused on the building of the ecosystem in a way that maintains the utility of the privacy and security guarantees made by the protocol. The interfaces are mainly used by the HTTP API doc, and so I think this will be a better home for them.
I've removed the interfaces from the architecture doc () and used the protocol API directly in the HTTP doc ()
Change:
GNAP allows for the negotiation of the grant process over time by multiple parties acting in distinct roles. <ins> The focus of this protocol is to provide interopability between the different parties acting in each role, and is not to specify implementation details of each.  Where appropriate, GNAP may make recommendations about internal implementation details, but these recommendations are to ensure the security of the overall deployment rather than to be prescriptive in the implementation. </ins> This protocol solves many of the same use cases as OAuth 2.0 RFC6749, OpenID Connect OIDC, and the family of protocols that have grown up around that ecosystem.  However, GNAP is not an extension of OAuth

Discussion:
adds a paragraph to the introduction adds specific examples under roles
Deploy preview for gnap-core-protocol-editors-draft ready! Built with commit aa65f1110cdcc11a60ca4d2d284e78f7909d0817 https://deploy-preview-254--gnap-core-protocol-editors-URL