jiebi/CodeConvo huggingface dataset:
Code change:
Both QRT and the Engelbart draft attempt to use existing payloads of RTP, RTCP, and SDP, unlike RUSH and SRT, as well as using existing Datagram frames <del> RUSH introduces new frame types as its development pre-dates Datagram frames </del> All drafts take differing approaches to flow/stream identification and management; some address congestion control and others just omit the subject and leave it to QUIC to handle

Related discussion:
text: This should address
Although it's true that RUSH predates DATAGRAM, streams were an intentional choice as RUSH implementations can leverage standard QUIC library reassembly of messages longer than one MTU.
Absolutely. It's disingenuous to say that RUSH is using QUIC streams because QUIC datagrams didn't exist yet. QUIC streams provide fragmentation, reliability, flow control, and cancellation (error codes). In fact, you could (but shouldn't) use QUIC streams to deliver individual RTP packets without much downside.
The above commits should fix this, please let me know if I got it wrong.
Code change:
immutable context of a call chain. A special service within the Trust Domain, which issues Txn-Tokens <del> to requesting workloads.  Each Trust Domain has exactly one Txn- Token Service. </del> <ins> to requesting workloads.  Each Trust Domain that uses Txn-Tokens MUST have exactly one logical Txn-Token Service. </ins> 5.

Related discussion:
text: Changed MUST to MAY. Cardinality of the txn-token service is 0..1, not exactly one. MAY not be the appropriate framing, I'm open to alternative text here to describe this more correctly.
I've updated the PR with the language provided by NAME in two places where the previous language was found in the draft.
Code change:
The message/http media type can be used to enclose a single HTTP request or response message, provided that it obeys the MIME restrictions for all "message" types regarding line length and <del> encodings. </del> <ins> encodings.  Because of the line length limitations, field values within message/http are allowed to use line folding ( ), as described in line.folding, to convey the field value over multiple lines.  A recipient of message/http data MUST replace any obsolete line folding with one or more SP characters when the message is consumed. </ins> 10.2.

Related discussion:
text: … (now entirely handled by HTTP/1.1 messaging). Include LF in discussion of what characters are invalid in field values. Require obs-fold to be processed when consuming message/http data.
Citing Ben Kaduk (URL): (i.e., that has any field line value that contains a match to the obs-fold rule) unless [...] other production, and field-value excludes CRLF, it seems that any such field line value would already be in violation of the ABNF and thus forbidden. I don't really want to advocate for including obs-fold in the field-value production in -semantics, though, so maybe accepting this nit is the least bad choice here. In RFC723x, field-value allowed obs-fold. We need to: tune the prose above, and somehow properly allow it in message/http (maybe by modifying the field-value for that specific case???)
see also URL
This is a good change. A few things that might be worth considering, when comparing this to recent HTTP/2 changes. HTTP/2 prohibits additional things in field names: SP (0x20), COLON (0x3a), 0x01-0x1f, and 0x7f-0xff (inclusive), specifically. The other things in h2 are specific to that. That includes leading and trailing space in values (you just say "A field value does not include leading or trailing whitespace") and uppercase field characters are version-specific.
Code change:
This document defines a CBOR Signing And Encrypted (COSE) header parameter for incorporating RFC 3161-based timestamping into COSE <del> message structures (COSE_Sign and COSE_Sign1).  This enables the use of established RFC 3161 timestamping infrastructure to prove the </del> <ins> message structures ("COSE_Sign" and "COSE_Sign1").  This enables the use of established RFC 3161 timestamping infrastructure to prove the </ins> creation time of a message. 1.

Related discussion:
text: In , Orie commented that: "Some use cases for the 2 modes might improve the document."_ E.g., C2PA, SCITT, PDF timestamping.
Add a paragraph to the Introduction to explain the use cases.
given enough guidance you can pass as an artist ;) Authors might consider providing some guidance regarding validation of CTT where the COSE claims appear (iat, nbf) to have happened after the timestamp ( time travel ). IIRC cose counter signatures apply to the protected header, payload and signature, whereas CTT only applies to the signatures. This means that the TSA does not countersign any protected information in the header? Some use cases for the 2 modes might improve the document. Security considerations seem light. OS >
Code change:
Transparency Services MUST ensure that for any Signed Statement they register, enough information is made available to Auditors (either in the Append-only Log and retrievable through audit APIs, or included <del> in the Receipt) to authenticate and retrieve the Transparent Statements describing the registration policy and trust anchors that apply to this registration. </del> <ins> in the Receipt) to authenticate and retrieve the Signed Statements describing the registration policy and trust anchors that apply to this registration. </ins> 4.1.2.

Related discussion:
text: from :
MUST and "enough" does not seem suffiMay be we have to tighten up the you can retrieve the signed statement to something in the future that may only get the hashmore correct than before, still a MUST that is tad bit hard to follow. the change in this scope is okay
Code change:
Track Alias: Identifies the Track Namespace and Track Name as defined in message-subscribe-req. <del> The Track Namespace and Track Name identified by the Track Alias is different from the one specified in the subscription identified by </del> <ins> If the Track Namespace and Track Name identified by the Track Alias are different from those specified in the subscription identified by </ins> Subscribe ID, the receiver MUST close the session with a Protocol Violation. Other fields: As described in canonical-object-fields. <ins> An "OBJECT_PREFER_DATAGRAM" message carries a single object in a datagram or a stream.  There is no explicit length of the payload; it is determined by the length of the datagram or stream.  If this message appears on a stream, it MUST be the first message on a unidirectional stream. An Object received in an "OBJECT_PREFER_DATAGRAM" message has an "Object Forwarding Preference" = "Datagram". To send an Object with "Object Forwarding Preference" = "Datagram", determine the length of the fields and payload, and compare the length with the maximum datagram size of the session.  If the object size is less than or equal maximum datagram size, send the serialized data as a datagram.  Otherwise, open a stream, send the serialized data and terminate the stream.  An implementation SHOULD NOT send an Object with "Object Forwarding Preference" = "Datagram" on a stream if it is possible to send it as a datagram. </ins> 6.3.3. When multiple objects are sent on a stream, the stream begins with a

Related discussion:
text: This was previously part of . It allows an object to be sent in a datagram f it fits, and put on a stream if it doesn't.
Linking some feedback raised in the original PR that has not yet been addressed: URL URL
Looks like a great starting point to me.
Code change:
delimiters could be used to cause recipients to incorrectly interpret a message, which could be exploited by an attacker. <ins> HttpHeaders does not include specific rules for validation of pseudo- header fields.  If the values of these fields are used, additional validation is necessary.  This is particularly important where , , and are combined to form a single URI string (RFC3986).  Similar problems might occur when that URI or just are combined with to construct a request line (as in HTTP11).  Simple concatenation is not secure unless the input values are fully validated. </ins> An intermediary can reject fields that contain invalid field names or values for other reasons, in particular those that do not conform to the HTTP ABNF grammar from HTTP.  Intermediaries that do not perform

Related discussion:
text: It's going to happen anyway, but we can at least warn people. This doesn't specify what validation is necessary in any detail (that is somewhat involved), it only notes that simple concatenation is almost certainly not secure.
OK that's fine by me. At least they're warned, and those who want to know more will easily find info on the subject, including these conversations. Thank you Martin!
Before we definitely forget about it, could we please have a consideration for that one: URL There is nothing in H2 that prevents pseudo headers from being abused, and it's suggested that they have to be reassembled to make the whole request line, that is usually parsed later to extract the relevant parts, leading to the trouble reported in the portswigger article. And semantics only apply to the recomposed parts, which is too late. I would really like that we suggest controls there so that future implementations do not get caught by this uncovered area, and the comment above proposes the minimalist controls that protect against such attacks.
Willy, this document is now through IESG evaluation and is about to go to the RFC Editor. Adding substantial new text with requirements would require going back to the working group.
Sorry for letting that comment pass at the time NAME It's a reasonable request, but I don't think that we can go as far as specifying specific validation rules. URIs are just too complicated for that. I suggest that we add a special note to which already talks about how intermediaries might be forced to pass on bad stuff. See .
NAME I understand and your approach looks reasonable, many thanks! I've added a tiny comment so that we don't forget to mention ":method" that was also severely abused there, and it's OK for me. NAME I'm not trying to perform substantial changes but have been trying to reload that one over the last 6 months so that we don't miss it. It has been the main cause of generalized vulnerabilities coming from word-for-word implementation of the spec into code, the least we can do is warn implementers.
LGTM.
Code change:
6.9. <ins> The publisher sends the "UNANNOUNCE" control message to indicate its intent to stop serving new subscriptions for tracks within the provided Track Namespace. Track Namespace: Identifies a track's namespace as defined in (track-name). 6.10. </ins> The server sends a "GOAWAY" message to force the client to reconnect. This is useful for server maintenance or reassignments without severing the QUIC connection.  The server can be a producer or a

Related discussion:
text: Following from discussions in , this PR allows a given publishers to un-announce a track namespace to indicate that it is not longer accepting new subscribe requests. The high-level call flow for happy path is as below
Individual Review
Code change:
If the DHCPv6-PD client determines that the prefix it provided to use as the OSNR prefix is no longer valid, and no replacement prefix is provided by the DHCPv6 server, then the SNAC router MUST switch to <del> the ULA link prefix that it has allocated for use on the SNAC </del> <ins> the ULA link prefix that it has allocated for use on the stub </ins> network.  In the case that the DHCPv6-PD client is unable to renew its lease on the current OSNR prefix, and time between the T2 interval for the prefix assignment I-D.ietf-dhc-rfc8415bis and the

Related discussion:
text: As Esko pointed out, the term "SNAC network" crept in during editing a few weeks ago, and doesn't add value. This pull request changes all instances of "SNAC network" to "stub network".
In -05, the term "SNAC network" is now used but not defined. Could we use the more generic term "stub network" instead? I.e. a SNAC router is able to automatically connect a stub network to an infrastructure network. So the stub network served by this SNAC router is still a "stub network". Or we could use the term "SNAC network" for any stub network that gets automatically connected via a SNAC router. But doing this adds an extra term throughout the document: it's not possible to mass-replace all occurrences of "stub network".
See also which overlaps with this issue, but targets a specific definition paragraph.
Right, this happened when we added a bunch of text in the last interim, and I think was a mistake. I think we just want to use the term "stub network" and not invent a new term. The thing that's new here is the "SNAC router", not the stub network.
I agree - "stub network" makes more sense here.
removed
Code change:
REQUIRED.  The type of the access token issued as described in access-tokens.  Value is case insensitive. <del> RECOMMENDED.  The lifetime in seconds of the access token.  For example, the value "3600" denotes that the access token will expire in one hour from the time the response was generated.  If omitted, the authorization server SHOULD provide the expiration time via other means or document the default value. </del> <ins> RECOMMENDED.  A JSON number that represents the lifetime in seconds of the access token.  For example, the value "3600" denotes that the access token will expire in one hour from the time the response was generated.  If omitted, the authorization server SHOULD provide the expiration time via other means or document the default value. </ins> RECOMMENDED, if identical to the scope requested by the client; otherwise, REQUIRED.  The scope of the access token as described

Related discussion:
text: This small PR attempts to clarify an unfortunately not that rare mistake of server implementations where they respond with a JSON string and not the expected JSON number. In between the client implementations I maintain I get a PRs/issues at least twice a year which ask that the clients attempt to normalize the Token Endpoint response expires_in value instead of expecting it to be a number.
Just curious, won't this necessities adding the type for all other parameters? Because a few sentences after the proposed edit, the specification states:
It might. In the past this awkward definition in a follow up paragraph might've been seen as necessary because the same response parameters and their descriptions were used for the implicit grant response which does not have any data types associated given it's part of the url fragment. With that portion of the spec gone we might as well put the JSON data type in the descriptions for all token response parameters.
Code change:
If the final character of input_number is ".", fail parsing. Parse input_number as a float and let output_number be the <del> result. </del> <ins> product of the result and sign. </ins> <del> Return the product of output_number and sign. </del> <ins> Return output_number. </ins> 4.2.7.

Related discussion:
text: When parsing a number, multiply back in to before testing against the range defined in Section 3.5.
Thanks!
Code change:
The example belows shows the message invoked by the client in trust domain A to perform token exchange with the authorization server in <del> domain A (https://a.org/auth) to receive an authorization grant for the authorization server in trust domain B (https://b.org/auth). </del> <ins> domain A (https://as.a.org/auth) to receive an authorization grant for the authorization server in trust domain B (https://as.b.org/ auth). </ins> 2.5.

Related discussion:
text: Replaces examples and add response examples
Feedback from Brian Campbell Seeing curl commands in the examples is sort of unexpected. Typically these kinds of drafts try to show the "on the wire" HTTP message -something like this [URL] for example or this [URL] or [URL] etc
Code change:
Digest Algorithm: crc32c <del> Description: The CRC32c algorithm is a 32-bit cyclic redundancy check.  It achieves a better hamming distance (for better error-detection performance) than many other 32-bit CRC functions.  Other places it is used include iSCSI and SCTP. The 32-bit output is encoded in hexadecimal (using between 1 and 8 ASCII characters from 0-9, A-F, and a-f; leading 0's are allowed).  For example, crc32c=0a72a4df and crc32c=A72A4DF are both valid checksums for the 3-byte message "dog". </del> <ins> Description: The CRC32c algorithm RFC4960.  The 32-bit output is encoded in hexadecimal (using between 1 and 8 ASCII characters from 0-9, A-F, and a-f; leading 0's are allowed). For example, crc32c=0a72a4df and crc32c=A72A4DF are both valid checksums for the 3-byte message "dog". </ins> Reference: RFC4960 appendix B, this document.

Related discussion:
text: There's not really any reason to describe anything other than the algorithm used and the format of encoding.
From NAME WGLC review This seems like cruft. The important things for the table are clear pointers to the algorithm definition and the encoding of values created by the algorithm.
If it's not broken, don't fix it :P I think we spent too much time wrt old algorithms. I'm in favor of anyone that wants to provide a PR that has consensus.
It is broken -- let's fix it. :)
LGTM
Code change:
<del> Client-Cert HTTP Header Field: Conveying Client Certificate Information from TLS Terminating Reverse Proxies to Origin Server Applications </del> <ins> Client-Cert HTTP Header Field </ins> draft-ietf-httpbis-client-cert-field-latest Abstract

Related discussion:
text: "Client-Cert HTTP Header Field: Conveying Client Certificate Information from TLS Terminating Reverse Proxies to Origin Server Applications" is kind of ridiculous looking. Change it to just "Client-Cert HTTP Header Field" and move the rest to the abstract, if it doesn't already say as much.
shorter is better
Code change:
.  This " " is used to provide the data and metadata for evaluating conditional <del> requests preconditions and constructing the payload for </del> <ins> requests (preconditions) and constructing the payload for </ins> and

Related discussion:
text: See ; the issue is not just about moving the text.
I understand that, I just thought it would be good if we could split this into two changes; that makes it easier later on...
See - I'm on it.
I think I'm ok with the actual changes, but we need a summary for the "Changes from RFC 723" section. Proposal:
NAME I think this is ready to go.
We still need to document this as a normative change from RFC 723.
Done.
LGTM.
As discussed quite a bit, retries in HTTP need to be better defined. In particular, HTTP does not offer a guarantee that any particular request will not be automatically retried.
Messaging - 9.4.1. Retrying Requests contains some things that probably belong in Semantics, probably somewhere up in the architecture section. Beyond that, I think the action here is to clarify a bit more that POST etc. requests are actively retried by many UAs (e.g., most Web browsers) because of H1's connection management issues. NAME can you confirm that that's H1-specific?
generally goaway would determine this in h2
Semantics - 7.2.2 Idempotent Methods talks about retries some. I'm inclined to add a very short reference to it in architecture -- e.g., "Some requests can be retried in the event of failure; see ref" -- around the sentence starting "A client sends an HTTP request..." in 2.1 Client Server Messaging. In h1-messaging, I'd like to add the behaviour that UAs actually implement to the list of examples of how they'd know it's OK to retry. AIUI, that would be something like: NAME is that accurate?
Well, the server could have had an opportunity to process a request, because they routinely start processing based on only a small amount of the header. The fact is that some clients retry based on very weak signals, risking duplicate processing in favour of greater robustness. The retry logic as I understand it is "have I seen any hint of a response? no? retry."
It seems like either clients or the spec should change, then.
Code change:
.  This " " is used to provide the data and metadata for evaluating conditional <del> requests preconditions and constructing the payload for </del> <ins> requests (preconditions) and constructing the payload for </ins> and

Related discussion:
text: I suspect clients will not...
There's two things you might consider here: noting that clients might do some things to retry based on their own determination of when that is appropriate (for example, in the extreme, retrying if the connection breaks before any byte of a response is seen).recommendations about good practice, which probably doesn't want to point at what the most aggressive clients (i.e., browsers) might choose to do Trying to walk the line without making that distinction is probably too hard.
That seems like a good direction, except that the spec currently contains a MUST NOT; "good practice" isn't that strong... MUST NOT (BUT WE KNOW YOU WILL)?
Yep. Part of this work is in aligning the spec with reality. A SHOULD NOT is probably appropriate. No need to resort to RFC 6919 language.
Proposal:
LGTM. s/; f/. F/
While I'm fine with this, I'm stil having a big problem with retries. Some of our (haproxy) users are pressuring us to implement the so-called "L7 retries" by which if the intermediary faces a problem with the server after the request was delivered, it happily retries it, even for a POST! Not only it's a technical problem (requires all requests to be buffered for the time it takes a server to respond) but it's in total violation of all rules. The problem here is that there's an ongoing trend for doing this and users find it normal since it allows them to hide their constantly crashing servers... And usually they consider that the application deals with replay protection by itself so obviously the infrastructure must retry. Thus my big concern here is to figure till what extent an intermediary could reasonably retry, or how we could have signals between UA and server to indicate if the request is retry-safe.
A protocol extension seems reasonable for that case; I think it could be interesting to clients -- both intermediary and otherwise.
Just leaving a note to remember to go through to make sure we got everything.
I had a bunch of editorial suggestions to make and decided to just make them directly to the pull request to save you the time and annoyance. I hope that is okay, since my changes just reduce the prior diffs.