jiebi/CodeConvo huggingface dataset:
Change:
described in more detail in QUIC-TRANSPORT.  An endpoint MAY choose to treat a stream error as a connection error. <ins> Because new error codes can be defined without negotiation (see extensions), receipt of an unknown error code or use of an error code in an unexpected context MUST NOT be treated as an error.  However, closing a stream can constitute an error regardless of the error code (see request-response). </ins> This section describes HTTP/3-specific error codes which can be used to express the cause of a connection or stream error.

Discussion:
by saying that, since error codes are extensible, you can't treat the receipt of an error code you don't understand or don't think you should have gotten as an error itself. (Though it can still be an error that the stream closed, regardless of the error code.) (Which leads to the question, should we be greasing the error code space?)
Yes! I would create a grease stream and it could be closed (stop sending and/or reset) by peers.
That seems to have very narrow applicability. Would you only be permitted to send a greasing error code in that case? Or to put the question differently, what would happen if you decided to randomly turn a subset of the semantic-ful error codes you generate into greasing codes?
Per the language of this PR, I think that would be fine. Possibly with the exception of the errors that are supposed to inform behavior, like REJECTED and perhaps EARLYRESPONSE.
The HTTP/3 spec is a little light on detail about processing an error code that should have never been sent. At NAME suggestion, this issue is scoped to discussion of HTTP/3 stream errors: Example a) a client receives a STOPSENDING with HTTPREQUESTCANCELLED Example b) a server receives a RESETSTREAM with HTTPLIMITEXCEEDED
I'm mostly inclined to treat this with the same fatalism as an invalid code in an APPLICATIONCLOSE code that makes no sense. The stream is gone, regardless of the error code. If it was a critical stream, then CLOSEDCRITICALSTREAM; otherwise, perhaps a MAY GENERALPROTOCOL_ERROR?
I agree with NAME The error code doesn't matter. What matters is how you handle it. Error codes with no specific handling are fine; error codes with special handling can be ignored. The question of what to do with critical streams is separable. Don't make things worse by coupling the two concepts.
Oh, totally separable. But then you'd then have two competing permissions-to-blow up -- because the critical stream close (regardless of error code) and because a stream closed with an invalid error code (regardless of which stream). And I don't think it matters which reason you have to blow up or what the resulting error is.
Change:
is set to "application/json". The example in ex-restrict shows a restriction to the key used in ex- <del> push.  Extra whitespace is added to to meet formatting constraints. </del> <ins> push.  Extra whitespace is added to meet formatting constraints. </ins> An application might use the Web Push API API to provide the user agent with a public key.

Discussion:
These are some suggested fixes for some nits that came up from the Shepherd write-up review.
Change:
Connection Groups.  This is not a strict requirement.  The default is to have this option. <del> Notification of ICMP error message arrival: This boolean property specifies whether an application considers it useful to be informed when an ICMP error message arrives.  This property applies to Connections and Connection Groups.  This is not a strict requirement.  The default is to have this option. </del> <ins> Notification of ICMP soft error message arrival: This boolean property specifies whether an application considers it useful to be informed when an ICMP error message arrives that does not force termination of a connection.  This property applies to Connections and Connection Groups.  Received ICMP errors will be available as SoftErrors.  Note that even if a protocol supporting this property is selected, not all ICMP errors will necessarily be delivered, so applications cannot rely on receiving them.  This is not a strict requirement.  The default is not to have this option. </ins> Control checksum coverage on sending or receiving: This boolean property specifies whether the application considers it useful to

Discussion:
TEXT: informed when an ICMP error message arrives. I think this is OK. but is this intended to be for soft-errors, since hard-errors break the connection? I think I get this, although some transports obvioulsy "eat" the ICMP packets they receive, and many ICMP messages have no meaning to an app, but some can be important. Tell me more please...
this comes from minset - and so it’s based on the rfc “soft error” text. true, no guarantee that you get it.
So, maybe the next rev of text should just say this and it will be fine.
Change:
registration, update, lookup, and removal interfaces defined in this section. <ins> All operations on the contents of the Resource Directory MUST be atomic and idempotent. A Resource Directory MUST accept query filtering with multiple query parameters in the URI. </ins> 5.1. Resource Directory implementations using this specification MUST

Discussion:
atomicity idempotency, Jim multiple query parameter, Fairhair deleted eps from group, Jim simple registration, hauke
Change:
local interfaces that are connected to different access networks. Internally, the transport system will first exclude all protocols and <del> 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.  In case of conflicts between Protocol and Path Selection Properties, Path Selection Properties take precedence.  For example, if an application indicates a preference for a specific path, but also a preference for a protocol not available on this path, the transport system will try the path first, so the Protocol Selection Property might not have an effect. </del> <ins> paths that match a Prohibit, then exclude all protocols and paths that do not match a Require, then sort candidates according to Preferred properties, and then use Avoided properties as a tiebreaker.  In case of conflicts between Protocol and Path Selection Properties, Path Selection Properties take precedence.  For example, if an application indicates a preference for a specific path, but also a preference for a protocol not available on this path, the transport system will try the path first, so the Protocol Selection Property might not have an effect. </ins> All Transport Properties used in the pre-establishment phase are collected in a TransportProperties Object that is passed to the

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:
QUIC uses a more nuanced loss recovery mechanism than the DTLS handshake, which has a basic packet loss retransmission timer. <del> This may allow loss recovery to occur more quickly for QUIC data. </del> <ins> This can allow loss recovery to occur more quickly for QUIC data. </ins> QUIC datagrams, while unreliable, can support acknowledgements, allowing applications to be aware of whether a datagram was

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:
Errors in the encapsulation of requests mean that responses cannot be encapsulated.  This includes cases where the is incorrect or <del> outdated.  The can generate and send a response with an error status to the .  This response MAY be forwarded to the or treated by the as a failure.  If a receives a response that is not an , this could indicate that the client configuration used to construct the request is incorrect or out of date. </del> <ins> outdated.  The can generate and send a response with a 4xx status code to the .  This response MAY be forwarded to the or treated by the as a failure.  If a receives a response that is not an , this could indicate that the client configuration used to construct the request is incorrect or out of date. </ins> 5.3.

Discussion:
Might as well say that.
From NAME Section 5.3: Should there be any indication that such errors in processing should be considered as bad requests (and hence return an appropriate error status code) or is this obvious?
Change:
Given an HPKE context "context", a request message "request", and a response "response", servers generate an "enc_response" as follows: <del> Export a secret "secret" from "context", using the string "message/bhttp response" as context.  The length of this secret is "max(Nn, Nk)", where "Nn" and "Nk" are the length of AEAD key and nonce associated with "context".  Note: repurposing discusses how </del> <ins> Export a secret, "secret", from "context", using the string "message/bhttp response" as the "exporter_context" parameter to "context.Export"; see HPKE.  The length of this secret is "max(Nn, Nk)", where "Nn" and "Nk" are the length of AEAD key and nonce associated with "context".  Note: repurposing discusses how </ins> alternative message formats might use a different "context" value. Generate a random value of length "max(Nn, Nk)" bytes, called

Discussion:
From NAME Please add a reference to section 5.3 of [HPKE]; it could be confusing at a first glance to have both the context from the exporter function in 5.3 of [HPKE] and the HPKE context here named "context".
Change:
and negotiations complete in order to gather metrics to influence future connections.  Similarly, an implementation may choose to hold onto fully established leaf nodes that were not the first to <del> establish for use in future connections, but this approach is not recommended since those attempts were slower to connect and may exhibit less desirable properties. </del> <ins> establish for use as part of a Pooled Connection, see pooled- connections, or in future connections.  In both cases, keeping additional connections is generally not recommended since those attempts were slower to connect and may exhibit less desirable properties. </ins> 4.5.1.

Discussion:
This is a follow-up issue for – As we have the ready to support connection coalescing and connection pooling, we have to describe it more closely in the Implementation.
Thanks for the fixes - I think this can be merged now.LGTM And: thanks for doing this! This can make the transport system a lot more powerful, and it's good to tell people about these interesting implementation options this draft, IMO.
Change:
being in the order of the client's preference, with most preferred first. <del> PskKeyExchangeModes have the following meanings: </del> <ins> PskKeyExchangeMode values have the following meanings: </ins> PSK-only key establishment.  In this mode, the server MUST not supply a "key_share" value.

Discussion:
The PskKeMode and PskAuthMode types were not defined, substitute them by the defined enums. Use non-plural enum names for consistency with other enumeration types. Remove the old opaque psk_identity type in favor of PskIdentity which was otherwise unused. Increase minimum length from 2 to 4 to account for the PskIdentity.identity field length.
Change:
An ECHConfigList structure containing one or more ECHConfig structures, in decreasing order of preference, to be used by the <del> client in subsequent connection attempts.  These are known as the </del> <ins> client as described in rejected-ech.  These are known as the </ins> server's "retry configurations". Finally, when the client offers the "encrypted_client_hello", if the

Discussion:
…with reference to Section 6.1.6 See also the discussion on tlswg/draft-ietf-tls-esni.
Change:
that protocol constrain the serialization format of the Attestation Result.  The format of the Evidence on the other hand is only constrained by the Attester-Verifier remote attestation protocol. <ins> This implies that interoperability and standardization is more relevant for Attestation Results than it is for Evidence. </ins> 5.2.

Discussion:
` Yes but for real passports, the Relying Party must separately evaluate the trustworthiness of 192 different Verifiers, i.e., nation states, no? This seems to imply that relying parties had better get ready to validate a limitless variety of Attestation Results? [mcr: yes, in fact, in real passports, Relying Parties do not treat all 192 nation states equally, which is why, I'm told, Israeli Mossad agents apprently like Canadian passports...]
The detail of how the Relying Party should trust the Verifiers is described in the "Trust Model" Section. Besides, there may be Appraisal Policies for Attestation Results, which will guide the Relying Party on validating the Attestation Results. I don't think an update is needed here.
The passport analogy shows that there is a cardinality of: Individual (1)(1) Passport Agency Individual (1)(N) Immigration Desk The text currently does not state that this implies that interoperability and standardization is more relevant for Attestation Results than it is for Evidence (in this model). The question I want to raise is, do we want to make that more explicit to the reader?
Change:
This document provides an architecture for doing remote attestation. No specific wire protocol is documented here.  Without a specific proposal to compare against, it is impossible to know if the security <del> threats listed below have been mitigated well.  The security considerations below should be read as being essentially requirements against realizations of the RATS Architecture.  Some threats apply to protocols, some are against implementations (code), and some threats are against physical infrastructure (such as factories). </del> <ins> threats listed below have been mitigated well. The security considerations below should be read as being essentially requirements against realizations of the RATS Architecture.  Some threats apply to protocols, some are against implementations (code), and some threats are against physical infrastructure (such as factories). The fundamental purpose of the RATS architecture is to allow a Relying Party to establish a basis for trusting the Attester. </ins> 12.1.

Discussion:
purpose statement into beginning of Security Considerations. I moved the statement to the beginning of section 12, but maybe some wanted it moved to the beginning of 12.1.
** Section 12.1.1 An essential value-add provided by RATS is for the Relying Party to be able to trust the Attester even if the user or owner is not trusted. Is it more accurate to say that an "A foundational security assumption of a RATS architecture is that a Relying Party is able to trust the Attester even if the user or owner is not trusted"
Section 12.1.1 Is it more accurate to say that an "A foundational security assumption of a RATS architecture is that a Relying Party is able to trust the Attester even if the user or owner is not trusted" I think the statement is closer to "A foundational security assumption of a RATS architecture it that a Relying Party is able to establish the basis for trusting the Attester functions, or Attester users.
Remove word "assumption", as this is an input, and we are talking about the output. move this sentence to the beginning of that section. "The fundamental purpose of the RATS architecture is to allow a Relying Party to establish a basis for trusting the Attester."
Change:
but does not include an equals sign.  This special case is only available for time zone tags. <del> 3.2. </del> <ins> 4.2. </ins> Here are some examples of Internet Extended Date/Time Format (IXDTF).

Discussion:
Section 3.3 is not yet updated (but will clearly change a lot) (As discussed at IETF 114)
cc NAME
Hi NAME NAME - what are the next steps on this PR?
NAME NAME - Is there any update on this PR?
There isn't yet, but vacation time has officially ended in Europe... RSN.
Looks great! Thanks for bringing all these edits together. I left one minor comment in case you'd want to make that change, but also OK to merge if you don't think it's needed.
Change:
However, in practice denial of service attacks target open TCP ports so the TCP SYN-ACK does not offer much protection in real scenarios. <ins> The security considerations described in HTTP-DGRAM also apply here. </ins> 8. 8.1.

Discussion:
All of these should apply here, doesn't hurt to remind people. Especially the bit in the other spec that says Tokens, it is not accessible from Web Platform APIs (such as those commonly accessed via JavaScript in web browsers).
Change:
known name of the resolver.  This query can be issued to the named Encrypted DNS Resolver itself or to any other resolver.  Unlike the case of bootstrapping from an Unencrypted DNS Resolver <del> (bootstrapping), these records SHOULD be available in the public DNS. </del> <ins> (bootstrapping), these records SHOULD be available in the public DNS if the same domain name's A or AAAA records are available in the public DNS to allow using any resolver to discover another resolver's Designated Resolvers.  When the name can only be resolved in private namespaces, these records SHOULD be available to the same audience as the A and AAAA records. </ins> For example, if the client already knows about a DoT server "resolver.example.com", it can issue an SVCB query for

Discussion:
NAME please check!
I think there are way too many bald SHOULDs in this document. Since SHOULD presents an implementer with a choice, it's usually a good idea to describe that choice rather than presenting something that looks like "you really should do this, but it's probably fine if you don't" and moves on. To wit: An example of one that could use improvement is the first one in Section 4, as I've no idea why you would not always do what it says. An example of one that does provide such guidance is the second one in Section 4, where I understand the consequences of not doing what it says.
LGTM!
Change:
Session descriptions generated by createAnswer must be immediately usable by setLocalDescription; like createOffer, the returned <del> description should reflect the current state of the system.  Because this method may need to inspect the system state to determine the currently available resources, it may need to be implemented as an async operation. </del> <ins> description should reflect the current state of the system. </ins> Calling this method may do things such as generate new ICE credentials, but does not trigger candidate gathering or change media

Discussion:
Section 4.1.5 createOffer: The statement about this being async is either a requirement or out of scope. I'd suggest out of scope (it is purely an API property); the alternative is saying "it is an async operation".
Change:
The "type" member is a JSON string containing a URI reference URI that identifies the problem type.  Consumers MUST use the "type" URI <del> (after resolution, if necessary) as the problem's primary identifier. </del> <ins> (after resolution, if necessary) as the problem type's primary identifier. </ins> When this member is not present, its value is assumed to be "about:blank".

Discussion:
It seems that saying could be read as identifying the problem instance rather than identifying the problem type. Here's a minor edit to make this more explicit: It's not quite clear to me what other identifiers could be (patterns of extension members, maybe?), but that's a different question.
Change:
SHOULD be able to read longer connection IDs from other QUIC versions in order to properly form a version negotiation packet. <del> The Destination Connection ID field follows the DCID Len and is between 0 and 20 bytes in length. negotiating-connection-ids describes the use of this field in more detail. </del> <ins> The Destination Connection ID field follows the DCID Length field and is between 0 and 20 bytes in length. negotiating-connection- ids describes the use of this field in more detail. </ins> The byte following the Destination Connection ID contains the length in bytes of the Source Connection ID field that follows it.

Discussion:
This is not an editorial decision, this is a request for feedback on whether this form of presentation makes more sense. So far we have mixed feedback.
Did you consider TLS presentation language? It would be nice to not have n+1 formats.
NAME TLS presentation language implies length prefixes in a lot of places. Plus we already ripped out TLS presentation language for definition of the transport parameters. Bringing it back for definition of packet layouts would be... a bit weird.
As long as it was considered and found to be unsuitable, that's fine with me.
I definitely like this general structure better. As far as the question of whether we should import the TLS language, you would need some extensions, but I suspect that you could get pretty far with the following three: uintX == unsigned integer of size X uintv == varint opaque x[URL] == opaque vector without a header (TLS uses <> to mean that it has a header) and opaque x[y..] means "to end of the container and minimum size y] I believe we've already done uintv for MLS and NAME has been thinking about a generalized an a "TLS spec language"
Orthogonal to this PR, but perhaps we should align the "Maximum Data" and "Data Limit" terms which reference the same limit in different frames? Originally posted by NAME in URL
SGTM. Maximum Data(or Max Data) seems like the preferable option to me.
NAME The link to NAME post seems to be broken.
Odd, that was automatically generated by GitHub. That comment was on a review of .
But...! But...! Muh ASCII art! More seriously, this is probably a net improvement for readability. There's value in conforming to existing paradigms where possible, but we'd already had to define custom extensions to the notation from RFC2360 and from RFC7540, so this is probably no worse. What are your thoughts on applying this to QPACK as well? I'm really not a fan of the trailing comma in the lists, but that's neither here nor there.I really like this format.