jiebi/TextFlow huggingface dataset:
Original text:
That response has the media type "application/json", and That response's payload, when parsed as JSON RFC7159, contains an <del> object as the root, and The root object contains a member whose name is a case-insensitive character-for-character match for the origin in question, serialised into Unicode as per Section 6.1 of RFC6454, and whose value is an object (hereafter, the "origin object"), The origin object has a "lifetime" member, whose value is a number indicating the number of seconds which the origin object is valid for (hereafter, the "origin object lifetime"), and </del>  <del> The origin object lifetime is greater than the "current_age" (as per RFC7234, Section 4.2.3). </del>  <del> Note that origin object lifetime might differ from the freshness lifetime of the response. </del>  3.

Reviewer comments:
We've been circling an answer to this for a while. The entire gamut of possible solutions is broad, and we haven't had much luck in reaching clarity here. One the one end of the scale, it should be perfectly OK to send a request for an origin over an authenticated TLS connection. But we still have the (entirely legitimate) concern there is that some servers might get themselves confused by this. The other end of the scale is the bells and whistles JSON stuff. NAME seemed OK with this based on his implementation experience, but it is a little complicated. We found too many corner cases for me to be happy that it implementations wouldn't end up busted. And now that we insist on authentication for the server, many of the features didn't make sense. We've also considered an HTTP/2 setting. That's appealing, but it does limit the applicability a little. This change aims more to the conservative end of that scale. It keeps the resource, but simplifies it, reducing it to a flat list of origins. The client only needs to acquire this from the authenticated server. This doesn't defend against Alt-Svc attacks mounted by attackers with the ability to both send header fields and run an authenticated server, but we're in a very strange place if this is the sort of capabilities we ascribe to our attackers in our threat models. I've explicitly added here. I believe that's reflective of consensus, but that part is easy to revert. The text about client certificates is now clearer.

Revised text:
That response has the media type "application/json", and That response's payload, when parsed as JSON RFC7159, contains an  <ins> array as the root, and </ins>  <ins> The array contains a string that is a case-insensitive character- for-character match for the origin in question, serialised into Unicode as per Section 6.1 of RFC6454. </ins>  <ins> A client MAY treat an "http-opportunistic" resource as invalid if the contains values that are not strings. </ins> 3.
Original text:
The ORIGIN Extension in HTTP/3 <del> draft-ietf-httpbis-origin-h3-latest </del> Abstract <del> The ORIGIN frame for HTTP/2 is equally applicable to HTTP/3, but </del>  needs to be separately registered.  This document describes the ORIGIN frame for HTTP/3. 1. <del> Existing RFCs define extensions to HTTP/2 HTTP2 which remain useful in HTTP/3.  HTTP3 describes the required updates for HTTP/2 frames to be used with HTTP/3. </del>  ORIGIN defines the HTTP/2 ORIGIN frame, which indicates what origins are available on a given connection.  It defines a single HTTP/2

Reviewer comments:
This PR tracks changes under discussion with the RFC editor. (Note that I haven't renamed the file to the RFC number, because that hasn't been done in other drafts in this repo.) When AUTH48 completes, I will add the commit moving this draft to the archive and merge it.

Revised text:
The ORIGIN Extension in HTTP/3  Abstract  <ins> The ORIGIN frame for HTTP/2 is equally applicable to HTTP/3, but it </ins> needs to be separately registered.  This document describes the ORIGIN frame for HTTP/3. 1.  <ins> Existing RFCs define extensions to HTTP/2 RFC9113 that remain useful in HTTP/3.  RFC9114 describes the required updates for HTTP/2 frames to be used with HTTP/3. </ins> ORIGIN defines the HTTP/2 ORIGIN frame, which indicates what origins are available on a given connection.  It defines a single HTTP/2
Original text:
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <del> Frame diagrams in this document use the format defined in QUIC- </del>  TRANSPORT to illustrate the order and size of fields. 2. <del> The ORIGIN HTTP/3 frame allows a server to indicate what origin(s) (RFC6454) the server would like the client to consider as members of the Origin Set (ORIGIN) for the connection within which it occurs. </del>  The semantics of the frame payload are identical to those of the <del> HTTP/2 frame defined in ORIGIN.  Where HTTP/2 reserves Stream 0 for </del>  frames related to the state of the connection, HTTP/3 defines a pair of unidirectional streams called "control streams" for this purpose. <del> Where ORIGIN indicates that the ORIGIN frame should be sent on Stream 0, this should be interpreted to mean the HTTP/3 control stream.  The ORIGIN frame is sent from servers to clients on the server's control stream. </del>  HTTP/3 does not define a Flags field in the generic frame layout.  As no flags have been defined for the ORIGIN frame, this specification

Reviewer comments:
This PR tracks changes under discussion with the RFC editor. (Note that I haven't renamed the file to the RFC number, because that hasn't been done in other drafts in this repo.) When AUTH48 completes, I will add the commit moving this draft to the archive and merge it.

Revised text:
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here.  <ins> The frame diagram in this document uses the format defined in QUIC- </ins> TRANSPORT to illustrate the order and size of fields. 2.  <ins> The ORIGIN HTTP/3 frame allows a server to indicate what origin or origins RFC6454 the server would like the client to consider as one or more members of the Origin Set (ORIGIN) for the connection within which it occurs. </ins> The semantics of the frame payload are identical to those of the  <ins> HTTP/2 frame defined in ORIGIN.  Where HTTP/2 reserves stream 0 for </ins> frames related to the state of the connection, HTTP/3 defines a pair of unidirectional streams called "control streams" for this purpose.  <ins> Where ORIGIN indicates that the ORIGIN frame is sent on stream 0, this should be interpreted to mean the HTTP/3 control stream: that is, the ORIGIN frame is sent from servers to clients on the server's control stream. </ins> HTTP/3 does not define a Flags field in the generic frame layout.  As no flags have been defined for the ORIGIN frame, this specification
Original text:
2.1. <del> The ORIGIN frame has a nearly identical layout to that used in HTTP/2, restated here for clarity.  The ORIGIN frame type is 0xc (decimal 12) as in HTTP/2.  The payload contains zero or more instances of the Origin-Entry field. </del>  An Origin-Entry is a length-delimited string.  Specifically, it contains two fields:

Reviewer comments:
This PR tracks changes under discussion with the RFC editor. (Note that I haven't renamed the file to the RFC number, because that hasn't been done in other drafts in this repo.) When AUTH48 completes, I will add the commit moving this draft to the archive and merge it.

Revised text:
2.1.  <ins> The ORIGIN frame has a layout that is nearly identical to the layout used in HTTP/2; the information is restated here for clarity.  The ORIGIN frame type is 0x0c (decimal 12), as in HTTP/2.  The payload contains zero or more instances of the Origin-Entry field. </ins> An Origin-Entry is a length-delimited string.  Specifically, it contains two fields:
Original text:
3. This document introduces no new security considerations beyond those <del> discussed in ORIGIN and HTTP3. </del>  4. <del> This document registers a frame type in the "HTTP/3 Frame Type" registry (HTTP3). This allocation lists a change controller of the IETF and a contact of the HTTP working group (ietf-http-wg@w3.org). </del> 

Reviewer comments:
This PR tracks changes under discussion with the RFC editor. (Note that I haven't renamed the file to the RFC number, because that hasn't been done in other drafts in this repo.) When AUTH48 completes, I will add the commit moving this draft to the archive and merge it.

Revised text:
3. This document introduces no new security considerations beyond those  <ins> discussed in ORIGIN and RFC9114. </ins> 4.  <ins> This document registers a frame type in the "HTTP/3 Frame Types" registry defined by RFC9114, located at <https://www.iana.org/assignments/http3-parameters/>. </ins>
Original text:
Abstract <del> This document defines an HTTP Proxy-Status Parameter that contains a list of aliases and canonical names received over DNS when establishing a connection to the next hop. </del>  1.

Reviewer comments:
think its a case of s/an/and
The abstract says is it really , is it some other phrasing a little more technically correct?
LGTM thanks

Revised text:
Abstract  <ins> This document defines the "next-hop-aliases" HTTP Proxy-Status Parameter.  This parameter carries the list of aliases and canonical names a proxy received during DNS resolution as part establishing a connection to the next hop. </ins> 1.
Original text:
The "next-hop-aliases" parameter's value is a String STRUCTURED- FIELDS that contains one or more DNS names in a comma-separated list. <del> The items in the list include all alias names an canonical names </del>  received in CNAME records DNS during the course of resolving the next hop's hostname using DNS, not including the original requested hostname itself.  The names SHOULD appear in the order in which they

Reviewer comments:
think its a case of s/an/and
The abstract says is it really , is it some other phrasing a little more technically correct?
LGTM thanks

Revised text:
The "next-hop-aliases" parameter's value is a String STRUCTURED- FIELDS that contains one or more DNS names in a comma-separated list.  <ins> The items in the list include all alias names and canonical names </ins> received in CNAME records DNS during the course of resolving the next hop's hostname using DNS, not including the original requested hostname itself.  The names SHOULD appear in the order in which they
Original text:
fields, from certain kinds of corruption. Integrity fields are not intended to be a general protection against <del> malicious tampering with HTTP messages.  This can be achieved by combining it with other approaches such as transport-layer security or digital signatures (for example, HTTP Message Signatures SIGNATURES). </del>  6.2.

Reviewer comments:
ballot position feedback
[x] §6.1 Recommend adding cautionary language about the capabilities of an adversary like those stated in Peter’s SECDIR review [x] Appendix A, typo[x] Section 6.5, e.g.

Revised text:
fields, from certain kinds of corruption. Integrity fields are not intended to be a general protection against  <ins> malicious tampering with HTTP messages.  In the absence of additional security mechanisms, an on-path, malicious actor can remove or recalculate and substitute a digest value.  This attack can be mitigated by combining mechanisms described in this document with other approaches such as transport-layer security or digital signatures (for example, HTTP Message Signatures SIGNATURES). </ins> 6.2.
Original text:
content coding defined in RFC8188. Since it is possible for there to be variation within content coding, <del> the checksum conveyed by the integrity field cannot be used to provide a proof of integrity "at rest" unless the whole (e.g., encoded) content is persisted. </del>  6.6.

Reviewer comments:
ballot position feedback
[x] §6.1 Recommend adding cautionary language about the capabilities of an adversary like those stated in Peter’s SECDIR review [x] Appendix A, typo[x] Section 6.5, e.g.

Revised text:
content coding defined in RFC8188. Since it is possible for there to be variation within content coding,  <ins> the checksum conveyed by the integrity fields cannot be used to provide a proof of integrity "at rest" unless the whole content is persisted. </ins> 6.6.
Original text:
"insecure" - for insecure algorithms, <del> "reserved" - for algorithms that use a reserved token value that cannot be expressed in Structured Fields </del> Description: a short description of the algorithm Reference(s): pointer(s) to the primary document(s) defining the <del> technical details of the algorithm, and optionally the key </del>  When reviewing registration requests, the designated expert(s) should pay attention to the requested status.  The status value should

Reviewer comments:
SGTM. Feel free to merge if you are sure we won't need this. Kind regards, R
John Scudder raised during IESG review: algorithms that use a reserved token value that cannot be expressed in Structured Fields". This is a well-formed sentence but I have no idea what it means. I made a desultory attempt to suss it out by searching the document for "token" and this was the only occurrence. If people who will actually be making use of the registry can be expected to make sense of it, then feel free to disregard my comment, of course. This reminded me at some point, I'd sketched out a design for the "Hash Algorithms for HTTP Digest Fields" registry that worked differently with what we ended up with now. In that design, it would have been possible to register an algorithm in the table under some friendly name and then separately register some Structured-Fields identifier that it related to. This would have made it possible to register an algorithm but reserve it from being used, in order to (for example) try and maintain some parity with old digest. Needless to say, the original sketch design had flaws and we didn't go that way. Instead, the registry requires entries to be identified using a Structured Fields key, which makes the idea of a reserved status due to a key that can't be used rather strange. TL;DR lets remove the "reserved" status because it isn't used by anything already and doesn't have much logic behind how it would be used in future.
We need to evaluate and possibly pare down / adjust the flags in the frame, based upon real-world use cases. See Kazuho's evaluation: URL
I agree the need for evaluation. OTOH, I do not think we should pare down / adjust flags, since real-world use cases could change as time evolves. The way it is defined now represents the cache state as-is and I believe that it would be most resilient in the long term.
OK.

Revised text:
"insecure" - for insecure algorithms,  Description: a short description of the algorithm Reference(s): pointer(s) to the primary document(s) defining the  <ins> Algorithm Key and technical details of the algorithm </ins> When reviewing registration requests, the designated expert(s) should pay attention to the requested status.  The status value should
Original text:
capabilities.  Such an approach could support transitions away from weaker algorithms (see sec-agility). <del> A recipient MAY ignore any or all digests.  This allows the recipient to choose which hashing algorithm(s) to use for validation instead of verifying every digest. </del>  A sender MAY send a digest without knowing whether the recipient supports a given hashing algorithm, or even knowing that the

Reviewer comments:
Roman Danyliw made some comments during IESG review related to receiver validation behaviour. RFC 3230 was quite relaxed about stating receiver requirements and we've followed suit by carrying over that normative langauge almost verbatim for Content-Digest and Repr-Digest. The intention has always been that applications are responsible for deciding what integrity checks are important and what validation failure means to them. Roman suggests that we make this intention more concrete by adding explicit statements. This seems like a good idea and I'll prepare a PR to this effect. Its a restatement of intent but it is new normative language, so I'll cross post to the HTTP WG list for any additional input.

Revised text:
capabilities.  Such an approach could support transitions away from weaker algorithms (see sec-agility).  <ins> A recipient MAY ignore any or all digests.  Application-specific behavior or local policy MAY set additional constraints on the processing and validation practices of the conveyed digests.  For example, validation of a subset of received digests is one approach to protection against resource exhaustion; see resource-exhaustion. </ins> A sender MAY send a digest without knowing whether the recipient supports a given hashing algorithm, or even knowing that the
Original text:
unsupported-algorithm.  It is not a protocol error if preferences are ignored.  Applications that use Integrity fields and Integrity preferences can define expectations or constraints that operate in <del> addition to this specification.  How to deal with ignored preferences is a scenario that should be considered. </del>  "Want-Content-Digest" and "Want-Repr-Digest" are of type "Dictionary" where each:

Reviewer comments:
Apologies in advance.
No apology needed. I stuttered over this same sentence yesterday when fixing an unrelated nit. I almost changed it then but didn't want to mix concerns. Given that somebody else has raised a comment and provided an alternative I agree with, leads me to believe its worth fixing. Thanks.
Much cleaner, +1

Revised text:
unsupported-algorithm.  It is not a protocol error if preferences are ignored.  Applications that use Integrity fields and Integrity preferences can define expectations or constraints that operate in  <ins> addition to this specification.  Ignored preferences are an application-specific concern. </ins> "Want-Content-Digest" and "Want-Repr-Digest" are of type "Dictionary" where each:
Original text:
This indicates that proxy.example.net, which used the IP address "2001:db8::1" as the next hop for this request, encountered the names <del> "tracker.example.com" and "service1.example-cdn.com" in the DNS </del>  resolution chain.  Note that while this example includes both the "next-hop" and "next-hop-aliases" parameters, "next-hop-aliases" can be included without including "next-hop".

Reviewer comments:
Update example domain names to avoid "example-URL" and too-long lines
Some examples use ; IDNITS dings you for not using . Should probably use something like .
The examples in 2.1 have lines that are too long. Because it's caused by , which is a String, I think your options are: Shorten the strings Use RFC 8792 line wrapping

Revised text:
This indicates that proxy.example.net, which used the IP address "2001:db8::1" as the next hop for this request, encountered the names  <ins> "tracker.example.com" and "service1.example.com" in the DNS </ins> resolution chain.  Note that while this example includes both the "next-hop" and "next-hop-aliases" parameters, "next-hop-aliases" can be included without including "next-hop".
Original text:
Unreserved Characters (RFC3986, Section 2.3) MUST be percent-encoded as defined in RFC3986, Section 2.1. <del> For example, consider the DNS name "name,with,commas.example.com". This name would be encoded within a "next-hop-aliases" parameter as </del>  follows: It is also possible for a DNS name to include a period character

Reviewer comments:
Update example domain names to avoid "example-URL" and too-long lines
Some examples use ; IDNITS dings you for not using . Should probably use something like .
The examples in 2.1 have lines that are too long. Because it's caused by , which is a String, I think your options are: Shorten the strings Use RFC 8792 line wrapping

Revised text:
Unreserved Characters (RFC3986, Section 2.3) MUST be percent-encoded as defined in RFC3986, Section 2.1.  <ins> For example, consider the DNS name "comma,name.example.com".  This name would be encoded within a "next-hop-aliases" parameter as </ins> follows: It is also possible for a DNS name to include a period character
Original text:
the context is set to the structure described in <del> the exporter output length is set to 32 bytes (see output) </del>  3.1.

Reviewer comments:
In the current draft, the header is composed as: The server computes the nonce from the TLS key material exporter and verifies the signature. This doesn't actually guarantee freshness, because its possible for parties to construct signatures which are valid for any message/nonce. This means that a party which does not have access to the TLS Export material can still inject a valid Auth header. I don't think that's a major problem, but it is a bit unintuitive and its hard to predict how drafts like this will eventually get deployed. A simple fix would be in to add an additional parameter, say which is or similar and have servers check its been correctly computed. This ensures that only parties that can access TLS key material can inject valid headers. Behind the scenes, this attack / fix works because hash functions have to be collision resistant for all inputs, whereas signatures don't have to satisfy any properties if the associated public key was generated maliciously. has a longer discussion.
Thanks! This sounds like an easy fix. Instead of a hash, we could also generate more bytes from the key exporter and use some for the nonce and some for the parameter
Wrote up to fix this

Revised text:
the context is set to the structure described in  <ins> the exporter output length is set to 48 bytes (see output) </ins> 3.1.
Original text:
3.2. <del> The output of the exporter is a 32-byte symmetric key.  That symmetric key is then used as nonce which can be signed using the client's chosen asymmetric private key.  The resulting signature is then transmitted to the server using the Authorization field. </del>  4.

Reviewer comments:
In the current draft, the header is composed as: The server computes the nonce from the TLS key material exporter and verifies the signature. This doesn't actually guarantee freshness, because its possible for parties to construct signatures which are valid for any message/nonce. This means that a party which does not have access to the TLS Export material can still inject a valid Auth header. I don't think that's a major problem, but it is a bit unintuitive and its hard to predict how drafts like this will eventually get deployed. A simple fix would be in to add an additional parameter, say which is or similar and have servers check its been correctly computed. This ensures that only parties that can access TLS key material can inject valid headers. Behind the scenes, this attack / fix works because hash functions have to be collision resistant for all inputs, whereas signatures don't have to satisfy any properties if the associated public key was generated maliciously. has a longer discussion.
Thanks! This sounds like an easy fix. Instead of a hash, we could also generate more bytes from the key exporter and use some for the nonce and some for the parameter
Wrote up to fix this

Revised text:
3.2.  <ins> The key exporter output is 48 bytes long.  Of those, the first 32 bytes are input to the signature and the next 16 bytes are sent alongside the signature.  This allows the recipient to confirm that the exporter produces the right values.  This is described in fig- output: The key exporter context contains the following fields: </ins> 4.