jiebi/CodeConvo huggingface dataset:
Change:
Authoritative servers are expected to return all available in-domain referral glue records in a referral response.  If message size constraints prevent the inclusion of all in-domain glue records over <del> UDP transport, the server MUST set the TC (Truncated) flag to inform the client that the response is incomplete, and that the client SHOULD use TCP to retrieve the full response.  This document clarifies that expectation. </del> <ins> the chosen transport, the server MUST set the TC (Truncated) flag to inform the client that the response is incomplete, and that the client SHOULD use another transport retrieve the full response.  This document clarifies that expectation. </ins> DNS responses sometimes contain optional data in the additional section.  In-domain referral glue records, however, are not optional.

Discussion:
and talk more generically about message size constraints regardless of transport. For
As currently written the document only talks about setting TC=1 over UDP. This sort of implies that UDP is the only possible transport where TC flag has meaning. We don't talk about setting TC over TCP because the assumption is that TCP always has enough room for all glue or whatever. But this doesn't account for two possibilities 1) a future transport that is limited in space 2) some kind of ridiculous zone configuration with so many NS and glue records that they won't even fit in a single DNS-over-TCP message. Would it be better to just say "set TC=1 if glue doesn't fit" and not bring UDP or TCP into the requirements language?
I like the idea of that, but I think simultaneous possession and ingestion of cake is also possible -- make the general, transport-agnostic point but also give the UDP/TCP fallback as an example that is known to be common at the time of writing. Joe
I prefer mentioning UDP and TCP and to say clearly never set it for TCP. I wouldn't consider "insanely weird" TCP that requires TC=1
would or wouldn't?
was merged so closing this for now
Change:
has already ended, the server MAY still abruptly terminate the stream or MAY take no action. <del> When a server sends CANCEL_PUSH, it is indicating that it will not be fulfilling a promise.  The client cannot expect the corresponding promise to be fulfilled, unless it has already received and processed the promised response.  A server SHOULD send a CANCEL_PUSH frame even if it has opened the corresponding stream. </del> <ins> A server sends CANCEL_PUSH to indicate that it will not be fulfilling a promise which was previously sent.  The client cannot expect the corresponding promise to be fulfilled, unless it has already received and processed the promised response.  Regardless of whether a push stream has been opened, a server SHOULD send a CANCEL_PUSH frame when it determines that promise will not be fulfilled.  If a stream has already been opened, the server can abort sending on the stream with an error code of H3_REQUEST_CANCELLED. </ins> Sending a CANCEL_PUSH frame has no direct effect on the state of existing push streams.  A client SHOULD NOT send a CANCEL_PUSH frame

Discussion:
In Section 7.2.3: URL A server SHOULD send a CANCELPUSH frame even if it has opened the corresponding stream. Is the intention that this sentence should have this meaning? "A server that has opened a stream for a PUSH and is unable to fulfill this promise SHOULD send a CANCEL_PUSH frame with the corresponding Push ID." I think as currently formulated it is missing the criteria as well when this may occur. Secondly the alternative is also not clear. I assume this is a SHOULD as the stream can be reset with an error code? Does that need to be added and which error will be used? Especially as the next paragraph only discusses that the client SHOULD abort reading. Can't the server terminate the stream from its side? If only the later is allowed, I think that should be made explicit but appears unnecessary.
To the second question, stating clearly that the server can abort the Push stream with H3REQUESTCANCELLED seems like a good improvement.
Looking at the larger paragraph, the point is that there are two possible states when a server decides not to fulfill a push: a. No stream has been created; CANCELPUSH is sufficient. b. A stream has been created. The server could simply reset the stream; this is valid, but risks the client processing the RESET before learning the Push ID, so it won't know which Push ID is no longer being fulfilled. Better if the server both resets the stream and sends a CANCELPUSH. You're right that this could be reworded to emphasize that you always send CANCEL_PUSH if you're not fulfilling a promise, and also close the stream if you've opened one.
This seems like the right framing. But everything seems to correspond.
Change:
specification QUIC-TLS.  This split is performed to enable light- weight versioning with different cryptographic handshakes. <del> 11. </del> <ins> 12. </ins> QUIC provides integrity protection for its version negotiation process.  This process assumes that the set of versions that a server

Discussion:
(hopefully)
okay, next try. Moved some text to applicability and rewrote stuff in manageability... please review again...
Discussion in closed PR
Change:
This document describes the values of the qlog name ("category" + "event") and "data" fields and their semantics for the QUIC protocol. <del> This document is based on draft-34 of the QUIC I-Ds QUIC-RECOVERY QUIC-TLS.  HTTP/3 and QPACK events are defined in a separate document QLOG-H3. </del> <ins> This document is based on draft-34 of the QUIC I-Ds QUIC-TRANSPORT, QUIC-RECOVERY, and QUIC-TLS.  HTTP/3 and QPACK events are defined in a separate document QLOG-H3. </ins> Feedback and discussion are welcome at https://github.com/quicwg/qlog [1].  Readers are advised to refer to the "editor's draft" at that

Discussion:
quic: fix artwork line length quic: stick commas between refs to unfool xml2rfc Fixes part of URL The changes are tedious but also not too onerous. The main issue you have is that there's lots of comments here and there that break length limits. So I've just picked a line length that will appease xml2rfc. The changes you have in mind might have obviated the errors anyway. But if not, these changes will set a strong foundation to know how to shut xml2rfc up.
According to the official IETF draft guidelines, line length should not be longer than 72 ASCII characters (URL, and URL). For some reason, I had previously understood this to be 82 characters, and so the current texts are 10 characters too wide... Since this will be somewhat of a tedious process (which can be done largely automatically but with manual checks) which will impact allmost all parts of the documents, I propose we do this in a single burst somewhere down the line. cc NAME
Chatted a bit with rmarx offline. The errors that xml2rfc moans about are about artwork, not body text etc. Over the 3 PRs I created, there might look like a lot of churn but it is all constrained to the artwork pieces. In my opinion, it's better to fix these now (or nullify the json validation errors) so that we don't start ignoring things that exist or get newly introduced.
This should be fixed as of main-schema-02 and h3/quic-events-01. For future reference: hard limit of 72 is only needed inside "figures" (including code blocks!). Running text paragraphs/lists/etc. can be done by the tooling itself.
Change:
considerations of HTTP also apply to the handling of the content of these media types. <ins> 6.10. This document generally assumes that the same entity operates the and the .  However, as the performs generic HTTP processing, the use of forwarding cannot be completely precluded. The scheme specified in the determines the security requirements for any protocol that is used between the Oblivious Gateway and Target Resources.  Using HTTPS is RECOMMENDED; see server-responsibilities. A that is operated on a different server from the is an ordinary HTTP resource.  A can privilege requests that are forwarded by a given if it trusts the operator of the to only forward requests that meet the expectations of the .  Otherwise, the treats requests from an no differently than any other HTTP client. For instance, an might - possibly with the help of - be trusted not to forward an excessive volume of requests.  This might allow the to accept a greater volume of requests from that relative to other HTTP clients. An could implement policies that improve the ability of the to implement policy exemptions, such as only forwarding requests toward specific Target Resources according to an allowlist; see server- responsibilities. </ins> 7. One goal of this design is that independent requests are only

Discussion:
This talks about the odd case where target and gateway are separate. The primary insight here is that the target is just a regular HTTP resource and the requests from the gateway aren't special. Problems only occur if the gateway is privileged in some way. If abuse comes via the gateway, then the target would ordinary block the client, which tends to affect a bunch of bystanders in this model. So there is pressure to do something special for the gateway. In that case, the target is trusting the gateway in some way. Explain that. The heading here is the only case where we use the short names of the entities, but I can't stand short headings.
The changes are a big step forward in the right direction, but the flow seems a little weird as the text in the first part of the security section is about co-located gateway/target. Strongly suggest to move the added new text at the end of the whole section and add a forward reference in the text: (from the intro in the security section)
And, just to be clear, the PR text addresses my concern. My comment about the flow is just editorial.
I've taken the suggestion to move the text (with forward references) and made a few tweaks: Rebased. Moved and rewritten some text from the top of the security considerations that better fit the new section. Added a forward reference to this section. Moved and rewritten text added in to the applicability section. (Originally this was just to correct a misspelling, but I think this makes more sense in the new home.) NAME can you double-check my work. With this, I think we're ready to revise the draft and ask the IESG to finalize their ballot.
Change:
5.7. <del> When a SessionDescription of any type is supplied to setLocal/ RemoteDescription, the implementation must parse it and reject it if it is invalid.  The exact details of this process are explained below. </del> The SDP contained in the session description object consists of a sequence of text lines, each containing a key-value expression, as described in RFC4566, Section 5.  The SDP is read, line-by-line, and

Discussion:
Adam's concern here was that the local description could never be invalid, since it was generated by the implementation.
Correct. I think you need to either remove setLocal or do: parse and (if setRemote, choke one error).
Editor discussion: this paragraph seems redundant so just remove it? NAME to look.
NAME NAME - ready for re-review
Section 5.7, first paragraph: similar to above, change "setLocal/RemoteDescription" to "setRemoteDescription."
Section Parsing a Session Description Text is When a SessionDescription of any type is supplied to setLocal/ RemoteDescription, the implementation must parse it and reject it if it is invalid. The exact details of this process are explained below. Fix as adam sugested
Change:
4. <ins> RFC4949 has defined a number of terms that are also used in this document.  Some of the terms are close to, but not exactly the same. Where the terms are similar, they are noted below with references. As explained in RFC4949, Section 2.6 when this document says "Compare:", the terminology used in this document differs significantly from the definition in the reference. </ins> This document uses the following terms. 4.1.

Discussion:
Despite fixes in , Roman asks: [Roman's comments on -13] -- Section 4.1. In the definition of relying party, what does the sentence fragment "Compare /relying party/ in [RFC4949]" mean? -- Section 4.2. Per the definition of "Claim", what does "Compare /claim/ in [RFC7519]" mean? -- Section 4.2. Per the definition of "Appraisal Policy for Attestation Results", what does "Compare /security policy/ in [RFC4949]" mean? I continue to hold the position that this language "Compare /xxx/ in RFC####" is not clear. In the natural language sense, that phrase doesn't parse. If the semantics are being taken from Section 2.6 of RFC4949, please explain that. However, it seems confusing to explicitly be listing antonyms (which RF4949 suggests is the meaning of the "Compare" notation). In the case of a claim, is it an antonym -- isn't a claim here in fact similar to the one in Section 2 of RFC7519?
`
Change:
Path Identifier (Path ID): An identifier that is used to identify a path in a QUIC connection at an endpoint.  Path Identifier is <del> used in multi-path control frames (etc.  PATH_ABANDON frame) to </del> <ins> used in multipath control frames (etc.  PATH_ABANDON frame) to </ins> identify a path.  By default, it is defined as the sequence number of the destination Connection ID used for sending packets on that particular path, but alternative definitions can be used if the

Discussion:
Be consistent with title.
NAME flagged in his PRs that there are many places using hyphenated "multi-path" and many using "multipath". We need to fix that.
This is due to the merge of the different drafts. I thought I fixed most of them, but I guess I could have done a search :-) Will do
Change:
receive one or more extension frame types with the one transport parameter. <ins> Extensions that modify or replace core protocol functionality (including frame types) will be difficult to combine with other extensions which modify or replace the same functionality unless the behavior of the combination is explicitly defined.  Such extensions SHOULD define their interaction with previously-defined extensions modifying the same protocol components. </ins> Extension frames MUST be congestion controlled and MUST cause an ACK frame to be sent.  The exception is extension frames that replace or supplement the ACK frame.  Extension frames are not included in flow

Discussion:
The SHOULD is guidance for future extensions; if we'd like to downgrade that to non-normative, that's also fine.
I'm going to merge this.
Resolution of was to have no design change, but consider a "here be dragons" warning in the extension section paralleling what was added to HTTP/3 in . (The reasons, and therefore the guidance, are different at the transport layer -- we can't directly steal the text.)
Change:
Filter expressions "?<boolean expr>" select certain children of an object or array as in <ins> 1.3.4. </ins> tbl-overview provides a quick overview of the JSONPath syntax elements. <del> This document treats the bracket notations as canonical and defines the above shorthands in terms of the canonical bracket notation. </del> 2. This section provides examples of JSONPath expressions.  The examples

Discussion:
This is a stab at addressing one NAME review comments in PR .
NAME If you don't think this PR is going in the right direction, please close it and we'll circle back to the matter later.
The term "current node" is traditionally used with iterating over children of structured nodes in filter selectors. Now it also appears in 3.3 Semantics chapter in a different context: To avoid confusion of readers, we might use a different term there. A good alternative would be "context node", which is also used by XPath in a similar context.
Perhaps a simple solution would be to avoid the use of the term in 3.3 as this term doesn't appear to be used elsewhere.
Please see the simplification in URL
Change:
Application protocols using datagrams are responsible for defining the semantics of the Datagram Data field, and how it is parsed.  If the application protocol supports the coexistence of multiple <del> entities using datagrams inside a single QUIC connection, it may need </del> <ins> entities using datagrams inside a single QUIC connection, it can use </ins> a mechanism to allow demultiplexing between them.  For example, using datagrams with HTTP/3 involves prepending a flow identifier to all datagrams, see I-D.schinazi-quic-h3-datagram.

Discussion:
There are several instances of lowercase "may" in this document. It is ambiguous if these are normative requirements or not.
Could you elaborate on why it's ambiguous? We have a reference to RFC 8174.
I sometimes assume typos :) If you're happy the present document is correct, I will close this issue
I'm not aware of errors like this, do you have any specific ones in mind?
Gah, fat fingered accidental close. The example that triggered opening this issue is below, I had to read this several times. Perhaps that's just a sign that editorial tweaks would help, regardless of the exact words in use
I can fix this
Thanks!
Change:
valid authenticators. The set of extensions allowed in the CertificateRequest structure <del> are those defined in the TLS ExtensionType Values IANA registry containing CR in the TLS 1.3 column.  The extensions allowed in the ClientCertificateRequest are those containing CR in the TLS 1.3 column, along with the server_name RFC6066 extension. </del> <ins> and the ClientCertificateRequest structure are those defined in the TLS ExtensionType Values IANA registry RFC8447 containing CR in the TLS 1.3 column.  In addition, the set of extensions in the ClientCertificateRequest structure MAY include the server_name RFC6066 extension. </ins> The uniqueness requirements of the certificate_request_context apply only to CertificateRequest and ClientCertificateRequest messages that

Discussion:
Section 4: I find this confusing: extensions: The set of extensions allowed in the CertificateRequest structure are those defined in the TLS ExtensionType Values IANA registry containing CR in the TLS 1.3 column. The extensions allowed in the ClientCertificateRequest are those containing CR in the TLS 1.3 column, along with the servername [RFC6066] extension. I think it means: extensions: The set of extensions allowed in the CertificateRequest structure and the ClientCertificateRequest structure are those defined in the TLS ExtensionType Values IANA registry [cite] containing CR in the TLS 1.3 column. In addition, the set of extensions in the ClientCertificateRequest structure MAY include the servername [RFC6066] extension.
fixed in
Change:
1. This protocol allows a piece of software, the resource client, to <del> request delegated authorization to resource servers and direct information.  This delegation is facilitated by an authorization server usually on behalf of a resource owner.  The requesting party operating the software may interact with the authorization server to authenticate, provide consent, and authorize the request. </del> <ins> request delegated authorization to resource servers and to request direct information.  This delegation is facilitated by an authorization server usually on behalf of a resource owner.  The requesting party operating the software may interact with the authorization server to authenticate, provide consent, and authorize the request. </ins> The process by which the delegation happens is known as a grant, and the GNAP protocol allows for the negotiation of the grant process

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:
and no trailing newline character. The party then hashes this string with the appropriate algorithm <del> based on the "hash_method" parameter of the "callback".  If the </del> <ins> based on the "hash_method" parameter under the "finish" key.  If the </ins> "hash_method" value is not present in the client instance's request, the algorithm defaults to "sha3".

Discussion:
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 681a99c7e9be294002d224d914dbb452a5d278bf Inspect the deploy log: Browse the preview:
Change:
As above, mitigation of this threat is beyond the scope of this proposal. <ins> 7.4. As noted in Section 4.2 of RTCWebSecurity, an attacker may use ICE as a way to send unsolicited network traffic to specific endpoints. While this is not specific to mDNS hostname candidates, this technique makes it easier to target devices with well-known mDNS names. As noted in processing, ICE agents may decide to not resolve mDNS names, for example, if these names are not in the format defined by gathering. </ins> 8. This document requires no actions from IANA.

Discussion:
As pointed by NAME one can stuff ICE candidates with mDNS names that are not UUID. This may ease exposing some devices (URL) to some unsolicited mDNS/STUN traffic.
To be noted that a web application can currently synthesize candidates with well-known IP addresses/address ranges. Allowing non UUID mDNS resolution might ease such attacks. We should evaluate whether this is fine as is or not. One possibility would be to mandate mDNS resolution for UUID-based names only.
I am inclining towards mandating mDNS resolution for UUID-base names only. My rationale is the technique proposed is essentially intended to expose no handle to applications to tweak. A general name + .local could fall back to the path of FQDN ICE supported by unicast DNS currently, with better security scrutiny.
Implementations might use the same code path for mDNS and unicast DNS, so I am not sure this will be easy to do this distinction in practice. I would do the distinction between applications that trust the source of ICE candidates (in which case any mDNS is fine) from cases where there is no trust (web browsers typically). In the latter case, I would go with a SHOULD statement.
Started PR URL
Fixed via
Approved with a few editorial comments
Change:
header field therefore has exactly one value, which is "aesgcm128". Multiple "aesgcm128" values are not permitted. <del> An application server MUST include exactly one entry in each of the Encryption and Crypto-Key header fields.  This allows the "keyid" parameter to be omitted from both header fields. </del> <ins> An application server MUST include exactly one entry in the Encryption field, and at most one entry having a "dh" parameter in the Crypto-Key field.  This allows the "keyid" parameter to be omitted from both header fields. </ins> An application server MUST NOT include an "aesgcm128" parameter in the Encryption header field.

Discussion:
defines: This removes a number of edge-cases and simplifies implementations. However, defines: Which is a violation of the former. Semantically it makes most sense for these to be distinct values since they're intended for different audiences. I'll propose a PR limiting webpush-encryption to one Crypto-Key entry having a value instead.
Because life is complicated, there are some libraries that are using ";" and creating a single parameter set containing both ECE and VAPID parameters, e.g. Because of "quirks" in both the mozilla and FCM handlers, this works. It may be beneficial if legacy push servers continue to support this behavior while libraries and applications that depend on them transition to any new division format.
Change:
timing of these acknowledgements is not used for loss recovery. As with any ack-eliciting frame, when a sender suspects that a packet <del> containing only DATAGRAM frames has been lost, it MAY send probe packets to elicit a faster acknowledgement as described in Section 6.2.4 of RFC9002. </del> <ins> containing only DATAGRAM frames has been lost, it sends probe packets to elicit a faster acknowledgement as described in Section 6.2.4 of RFC9002. </ins> If a sender detects that a packet containing a specific DATAGRAM frame might have been lost, the implementation MAY notify the

Discussion:
RFC 9002 doesn't equivocate regarding whether probes are sent: ack-eliciting packet in the packet number space as a probe. This text uses "MAY", which strongly suggests that probes are discretionary. That's not true.