jiebi/TextFlow huggingface dataset:
Original text:
Note: "double-quoted" strings follow the JSON string syntax (RFC8259); "single-quoted" strings follow an analogous pattern <del> (syntax-index).  No attempt was made to improve on this syntax, so characters with scalar values above 0x10000, such as U+0026 U+0023 U+0031 U+0032 U+0039 U+0033 U+0030 U+0030 U+003B ("&#129300;", AMPERSAND, NUMBER SIGN, DIGIT ONE, DIGIT TWO, DIGIT NINE, DIGIT THREE, DIGIT ZERO, DIGIT ZERO, SEMICOLON), need to be represented by a pair of surrogate escapes (""uD83EuDD14"" in this case). </del>  2.5.1.2. <del> A "name-selector" string MUST be converted to a member name M by </del>  removing the surrounding quotes and replacing each escape sequence with its equivalent Unicode character, as in the table below: Applying the "name-selector" to an object node selects a member value <del> whose name equals the member name M, or selects nothing if there is </del>  no such member value.  Nothing is selected from a value that is not an object. Note that processing the name selector requires comparing the member <del> name string M with member name strings in the JSON to which the </del>  selector is being applied.  Two strings MUST be considered equal if and only if they are identical sequences of Unicode scalar values. In other words, normalization operations MUST NOT be applied to <del> either the member name string M from the JSONPath or to the member </del>  name strings in the JSON prior to comparison. 2.5.1.3.

Reviewer comments:
Wouldn't mind if we could get these editorials merged quickly so the bulk of the other PRs shrinks a bit.
LGTM, thanks.

Revised text:
Note: "double-quoted" strings follow the JSON string syntax (RFC8259); "single-quoted" strings follow an analogous pattern  <ins> (syntax-index).  No attempt was made to improve on this syntax, so if it is desired to escape characters with scalar values above 0x10000, such as U+0026 U+0023 U+0031 U+0032 U+0039 U+0033 U+0030 U+0030 U+003B ("&#129300;", AMPERSAND, NUMBER SIGN, DIGIT ONE, DIGIT TWO, DIGIT NINE, DIGIT THREE, DIGIT ZERO, DIGIT ZERO, SEMICOLON), they need to be represented by a pair of surrogate escapes (""uD83EuDD14"" in this case). </ins> 2.5.1.2.  <ins> A "name-selector" string MUST be converted to a member name "M" by </ins> removing the surrounding quotes and replacing each escape sequence with its equivalent Unicode character, as in the table below: Applying the "name-selector" to an object node selects a member value  <ins> whose name equals the member name "M", or selects nothing if there is </ins> no such member value.  Nothing is selected from a value that is not an object. Note that processing the name selector requires comparing the member  <ins> name string "M" with member name strings in the JSON to which the </ins> selector is being applied.  Two strings MUST be considered equal if and only if they are identical sequences of Unicode scalar values. In other words, normalization operations MUST NOT be applied to  <ins> either the member name string "M" from the JSONPath or to the member </ins> name strings in the JSON prior to comparison. 2.5.1.3.
Original text:
even if it is rough, as long as that does not jeopardize the objective of obtaining a usable, stable JSON query language.  1.3. The JSON value a JSONPath query is applied to is, by definition, a

Reviewer comments:
PR changed the spec to use "path" only for paths, and "query" for queries. The term "JSONPath" is then left in need of some motivation. This is provided in the History section so as not to interfere with the normative text.
... fine ...

Revised text:
even if it is rough, as long as that does not jeopardize the objective of obtaining a usable, stable JSON query language. <ins> The term was chosen because of the XPath inspiration and also because the outcome of a query consists of identifying nodes in the JSON argument. </ins> 1.3. The JSON value a JSONPath query is applied to is, by definition, a
Original text:
<del> JavaScript Object Notation (JSON) Path </del>  draft-ietf-jsonpath-base-latest Abstract

Reviewer comments:
(This was original raised in and now being split out) At IETF 110 we reached rough agreement for “JSONPath: Query expressions for JSON” to be the title of the document.
Created PR
Closed in

Revised text:
 <ins> JSONPath: Query expressions for JSON </ins> draft-ietf-jsonpath-base-latest Abstract
Original text:
Range A precedes an IP address range B in the same ROUTE_ADVERTISEMENT capsule, they MUST follow these requirements: <del> IP Version of A MUST be lesser or equal than IP Version of B </del>  If the IP Version of A and B are equal, the IP Protocol of A MUST <del> be lesser or equal than IP Protocol of B. </del>  If the IP Version and IP Protocol of A and B are both equal, the End IP Address of A MUST be strictly less than the Start IP

Reviewer comments:
Where the word "lesser" is used, I think "less than" would read better. Especially in the construct "lesser or equal than"
SGTM

Revised text:
Range A precedes an IP address range B in the same ROUTE_ADVERTISEMENT capsule, they MUST follow these requirements:  <ins> IP Version of A MUST be less than or equal than IP Version of B </ins> If the IP Version of A and B are equal, the IP Protocol of A MUST  <ins> be less than or equal than IP Protocol of B. </ins> If the IP Version and IP Protocol of A and B are both equal, the End IP Address of A MUST be strictly less than the Start IP
Original text:
been formed. The lifetime of the IP forwarding tunnel is tied to the IP proxying <del> request stream.  Closing that stream (in HTTP/3 via the FIN bit on a QUIC STREAM frame, or a QUIC RESET_STREAM frame) closes the associated IP tunnel. </del>  Along with a successful response, the IP proxy can send capsules to assign addresses and advertise routes to the client (capsules).  The

Reviewer comments:
I think it would be helpful to review the lifetime text in URL more closely align with it where it makes sense. What stuck out to me first was speaking about HTTP/3 specifically sticks out because all versions are supported. Second, there's no text about if a proxy can timeout itself and close the stream.
This makes sense, we can be a bit more specific with this guidance

Revised text:
been formed. The lifetime of the IP forwarding tunnel is tied to the IP proxying  <ins> request stream.  The IP proxy MUST maintain all IP address and route assignments associated with the IP forwarding tunnel while the request stream is open.  IP proxies MAY choose to tear down the tunnel due to a period of inactivity, but they MUST close the request stream when doing so. </ins> Along with a successful response, the IP proxy can send capsules to assign addresses and advertise routes to the client (capsules).  The
Original text:
malformed.  The recipient of such a malformed request MUST respond with an error and SHOULD use the 400 (Bad Request) status code.  4.2. The IP proxy SHALL indicate a successful response by replying with If any of these requirements are not met, the client MUST treat this proxying attempt as failed and abort the connection.  4.3. When using HTTP/2 H2 or HTTP/3 H3, IP proxying requests use HTTP An IP proxying request that does not conform to these restrictions is malformed (see H2 and H3).  4.4. The IP proxy SHALL indicate a successful response by replying with If any of these requirements are not met, the client MUST treat this proxying attempt as failed and abort the request.  4.5. Unlike UDP proxying requests, which require specifying a target host,

Reviewer comments:
Our cousin, CONNECT-UDP, has simple examples about how the requests and responses look in HTTP/1.1, 2 and 3. I appreciate the appendix has complicated examples. Would it be worth providing simple examples in Section 4, or at least forward referencing to them so people can get a feel?
That would be nice, if someone's willing to volunteer to do the editorial work of writing that PR. In other words, I'll happily review and merge it, but I don't have time to write it personally.
there's 5 authors on the draft, maybe one of the other 4 can spare the 10 minutes it would take?
Simple enough to add =)
Thanks for writing this!

Revised text:
malformed.  The recipient of such a malformed request MUST respond with an error and SHOULD use the 400 (Bad Request) status code. <ins> For example, if the client is configured with URI Template "https://example.org/.well-known/masque/ip/{target}/{ipproto}/" and wishes to open an IP forwarding tunnel with no target or protocol limitations, it could send the following request: </ins> 4.2. The IP proxy SHALL indicate a successful response by replying with If any of these requirements are not met, the client MUST treat this proxying attempt as failed and abort the connection. <ins> For example, the IP proxy could respond with: </ins> 4.3. When using HTTP/2 H2 or HTTP/3 H3, IP proxying requests use HTTP An IP proxying request that does not conform to these restrictions is malformed (see H2 and H3). <ins> For example, if the client is configured with URI Template "https://example.org/.well-known/masque/ip/{target}/{ipproto}/" and wishes to open an IP forwarding tunnel with no target or protocol limitations, it could send the following request: </ins> 4.4. The IP proxy SHALL indicate a successful response by replying with If any of these requirements are not met, the client MUST treat this proxying attempt as failed and abort the request. <ins> For example, the IP proxy could respond with: </ins> 4.5. Unlike UDP proxying requests, which require specifying a target host,
Original text:
bytes of data to ascertain the link MTU and tear down the tunnel if they do not receive a response.  Unless endpoints have an out of band means of guaranteeing that the previous techniques is <del> sufficient, they MUST use this method. </del>  If an endpoint is using QUIC DATAGRAM frames to convey IPv6 packets, and it detects that the QUIC MTU is too low to allow sending 1280

Reviewer comments:
Which IPv6 address is the Client pinging through the tunnel? The Client knows which source address(es) it can use (from the ADDRESSASSIGN(s) that it has received), but not necessarily a good destination address. When ROUTEADVERTISEMENT are networks, it is not clear which hosts if any on those networks are pingable. In the flow forwarding case, there is a clear target host, but do we want to require the target to respond to ICMPv6 echo request pings lest it be unreachable on any protocol over connect-ip? Perhaps the destination address for these pings should be a special address on which the IP Proxy itself is required to respond to ICMPv6 echo requests through the tunnel?
Good question! NAME thoughts?
This was intended to be the link-local address(es)
Good catch. I'll write a PR suggesting to use the link-local all-nodes multicast address if the peer's address is unknown

Revised text:
bytes of data to ascertain the link MTU and tear down the tunnel if they do not receive a response.  Unless endpoints have an out of band means of guaranteeing that the previous techniques is  <ins> sufficient, they MUST use this method.  If an endpoint does not know an IPv6 address of its peer, it can send the ICMPv6 echo request to the link local all nodes multicast address (ff02::1). </ins> If an endpoint is using QUIC DATAGRAM frames to convey IPv6 packets, and it detects that the QUIC MTU is too low to allow sending 1280
Original text:
11.4. <del> This document will request IANA to add the following values to the "HTTP Capsule Types" registry maintained at <<https://www.iana.org/assignments/http-capsule-protocol/http- capsule-protocol.xhtml>>. </del> 

Reviewer comments:
NAME as capsule type registry expert, are you OK with this text?
URL registers 3 capsules that use 0x1ECA6A00, 0x1ECA6A01, and 0x1ECA6A02. Its good practice to use the provisional registration space while developing a document, so you have my appreciation. But its not clear if you intend to change these into the permanent registration space prior to publication. CONNECT-UDP followed that approach and noted it with . Please clarify if you intend to change the values and, if so, when.
That's a good point, I was planning on changing them right after WGLC but I guess that's not written in the draft. Let's keep this issue open during the WGLC and close it once we move to the final values
Plan is to have: 0x01 for ADDRESSASSIGN 0x02 for ADDRESSREQUEST 0x03 for ROUTE_ADVERTISEMENT assuming NAME agrees since we're the two IANA experts on that registry
in principle that's fine by me. We should be wary of using them too early in case things have to change even after WGLC. So late binding once publication is impending is the least risky and works for me.
On one hand I agree with you that assigning them sooner avoids the risk of dealing with interop failures if IESG review leads to unavoidable wire-format changes. On the other, waiting until after IESG approval means that now we have interop issues between the folks that deployed before or after that - that's what we're seeing with QUIC version negotiation. So I would prefer to get provisional registrations for the low codepoints after WGLC personally
reasonable
LGTM. I was going to suggest ot would be nice to articulate the codepoint change in the changelog, but I guess you don't have one anyway...

Revised text:
11.4.  <ins> This document requests IANA to add the following values to the "HTTP Capsule Types" registry maintained at <<https://www.iana.org/assignments/http-capsule-protocol>>. All of these new entries use the following values for these fields: RFC Editor: please remove the rest of this subsection before publication. Since this document has not yet been published, it might still change before publication as RFC.  Any implementer that wishes to deploy IP proxying in production before publication MUST use the following temporary codepoints instead: 0x2575D601 for ADDRESS_ASSIGN, 0x2575D602 for ADDRESS_REQUEST, and 0x2575D603 for ROUTE_ADVERTISEMENT. </ins>
Original text:
protocol is similar to UDP proxying in HTTP, but allows transmitting arbitrary IP packets.  More specifically, this document defines a protocol that allows an HTTP client to create an IP tunnel through an <del> HTTP server that acts as a proxy.  This document updates RFC 9298. </del>  1. start the Capsule Protocol; see HTTP-DGRAM. If any of these requirements are not met, the client MUST treat this <del> proxying attempt as failed and abort the connection. </del>  For example, the IP proxy could respond with:

Reviewer comments:
In the abstract, the word 'proxy' is used without qualification. It would be better to use the term 'IP proxy'. In 4.3. HTTP/1.1 Response, 'abort the connection' is not typical usage (e.g., in RFC9112); suggest 'close the connection'.

Revised text:
protocol is similar to UDP proxying in HTTP, but allows transmitting arbitrary IP packets.  More specifically, this document defines a protocol that allows an HTTP client to create an IP tunnel through an  <ins> HTTP server that acts as an IP proxy.  This document updates RFC 9298. </ins> 1. start the Capsule Protocol; see HTTP-DGRAM. If any of these requirements are not met, the client MUST treat this  <ins> proxying attempt as failed and close the connection. </ins> For example, the IP proxy could respond with:
Original text:
field has value 6, the IP Address field SHALL have a length of 128 bits. <del> Length of the IP Prefix assigned, in bits.  MUST be lesser or equal to the length of the IP Address field, in bits. </del>  3.2.2. the IP Version field has value 6, the IP Address field SHALL have a length of 128 bits. <del> Length of the IP Prefix of the advertised route, in bits.  MUST be lesser or equal to the length of the IP Address field, in bits. </del>  The Internet Protocol Number for traffic that can be sent to this prefix.  If the value is 0, all protocols are allowed.

Reviewer comments:
NAME NAME Does this PR also ?
NAME not quite--it's a step, but there's more to do
I think the field description needs updates. The IP adress is after all an prefix that is masked by the specified number of bits. That is not quite clear yet. However, I think the question if this range should support excluding one or more sub-ranges needs to be sorted out also.
The specification of the field currently states . Is that unclear? If so, can you help provide text to help make it clearer? Agreed, that's discussed in
Editorial clarification that the prefix in the advertisement applies to the address in the advertisement, which is a remote prefix that the client is allowed to send to.

Revised text:
field has value 6, the IP Address field SHALL have a length of 128 bits.  <ins> The number of bits in the IP Address that are used to define the prefix that is being assigned.  This MUST be less than or equal to the length of the IP Address field, in bits.  If the prefix length is equal to the length of the IP Address, the endpoint is only allowed to send packets from a single source address.  If the prefix length is less than the length of the IP address, the endpoint is allowed to send packets from any source address that falls within the prefix. </ins> 3.2.2. the IP Version field has value 6, the IP Address field SHALL have a length of 128 bits.  <ins> The number of bits in the IP Address that are used to define the prefix of the advertised route.  This MUST be lesser or equal to the length of the IP Address field, in bits.  If the prefix length is equal to the length of the IP Address, this route only allows sending packets to a single destination address.  If the prefix length is less than the length of the IP address, this route allows sending packets to any destination address that falls within the prefix. </ins> The Internet Protocol Number for traffic that can be sent to this prefix.  If the value is 0, all protocols are allowed.
Original text:
address, the request will only support a single IP version.  If the target is a hostname, the server is expected to perform DNS resolution to determine which route(s) to advertise to the client.  The variable "ipproto" contains an IP protocol number, as defined in the "Assigned Internet Protocol Numbers" IANA registry.  If

Reviewer comments:
We should be clear that when a proxy resolves a hostname, it SHOULD give all results back as routes to the client (unless there is some policy to restrict it). Credit to NAME for proposing this
I agree
What is a client expected to do with this information? Say I ask for the proxy to connect to URL I get back a RA that includes the result of DNS lookups for URL (maybe multiple RAs that include all the answers from A/AAAA records?). Am I supposed to assume that this is the result of the DNS lookup? How do I distinguish that from other RAs that might just advertise where I might be able send packets via the tunnel? If the purpose of this is to provide name resolution, it is probably better to include an explicit signal. It's a bit of a rathole, but a new capsule type seems fairly obvious. That leads me to ask a whole bunch of questions about whether the proxy needs to supply a DNS service, ...
Nit: there is no port number. That's the status quo in this draft for hostname targets. The implicit signal here doesn't bother me, since it's unambiguous. I'm also fine with dropping support for DNS targets, although I think it might be useful in some scenarios.
Of course. I somehow got mislead by the first example: "URL{target}/{target_port}/"
Yeah, looks like that example had a copy paste error from CONNECT-UDP. I filed
The ability to specify a host to proxy to was important in our discussions for keeping parity with other proxying methods.
Indeed, that was bad copy-pasta from me, my apologies. It's been fixed in the editor's copy.
NAME thanks!
Thanks! ... wanted to raise the issue. URL". Section 4.1 says "route(s)", implying that the proxy might choose to advertise multiple routes to the target host, presumably because DNS resolution returned multiple A/AAAA records. I see the current text as an implicit "MAY return all the IP addresses", and I'm suggesting an upgrade to SHOULD.

Revised text:
address, the request will only support a single IP version.  If the target is a hostname, the server is expected to perform DNS resolution to determine which route(s) to advertise to the client. <ins> The server SHOULD send a ROUTE_ADVERTISEMENT capsule that includes routes for all usable resolved addresses for the requested hostname. </ins> The variable "ipproto" contains an IP protocol number, as defined in the "Assigned Internet Protocol Numbers" IANA registry.  If
Original text:
be lesser or equal than IP Protocol of B. If the IP Version and IP Protocol of A and B are both equal, the <del> End IP Address of A MUST be strictly lesser than the Start IP </del>  Address of B. If an endpoint received a ROUTE_ADVERTISEMENT capsule that does not or split-tunnel. In this case, the client does not specify any scope in its request. <del> The server assigns the client an IPv4 address to the client (192.0.2.11) and a full-tunnel route of all IPv4 addresses (0.0.0.0/0).  The client can then send to any IPv4 host using a source address in its assigned prefix. </del>  A setup for a split-tunnel VPN (the case where the client can only access a specific set of private subnets) is quite similar.  In this

Reviewer comments:
Edits collected while reading this draft. cc: NAME NAME
LGTM, thanks for this NAME !

Revised text:
be lesser or equal than IP Protocol of B. If the IP Version and IP Protocol of A and B are both equal, the  <ins> End IP Address of A MUST be strictly less than the Start IP </ins> Address of B. If an endpoint received a ROUTE_ADVERTISEMENT capsule that does not or split-tunnel. In this case, the client does not specify any scope in its request.  <ins> The server assigns the client an IPv4 address (192.0.2.11) and a full-tunnel route of all IPv4 addresses (0.0.0.0/0).  The client can then send to any IPv4 host using a source address in its assigned prefix. </ins> A setup for a split-tunnel VPN (the case where the client can only access a specific set of private subnets) is quite similar.  In this
Original text:
establish a tunnel to arbitrary servers, as that could allow bad actors to send traffic and have it attributed to the proxy.  Proxies that support CONNECT-IP SHOULD restrict its use to authenticated <del> users.  The HTTP Authorization header AUTH MAY be used to </del>  authenticate clients.  More complex authentication schemes are out of scope for this document but can be implemented using CONNECT-IP extensions.

Reviewer comments:
Fixing some ID nits validations errors include update references from drafts to RFCs for SEMANTICS and H3 Websockets draft.

Revised text:
establish a tunnel to arbitrary servers, as that could allow bad actors to send traffic and have it attributed to the proxy.  Proxies that support CONNECT-IP SHOULD restrict its use to authenticated  <ins> users.  The HTTP Authorization header SEMANTICS MAY be used to </ins> authenticate clients.  More complex authentication schemes are out of scope for this document but can be implemented using CONNECT-IP extensions.
Original text:
11.3. This document will request IANA to add the following values to the <del> "HTTP Capsule Types" registry created by HTTP-DGRAM: </del> 

Reviewer comments:
There should be a reference providing an URL for the Assigned Internet Protocol Number registry in this document, not just the name, even if this is formally sufficient. The URL is: URL

Revised text:
11.3. This document will request IANA to add the following values to the  <ins> "HTTP Capsule Types" registry maintained at <<https://www.iana.org/assignments/http-capsule-protocol/http- capsule-protocol.xhtml>>. </ins>