jiebi/TextFlow huggingface dataset:
Original text:
For example, the IP proxy could respond with: <del> 4.3. </del>  When using HTTP/2 H2 or HTTP/3 H3, IP proxying requests use HTTP Extended CONNECT.  This requires that servers send an HTTP Setting as

Reviewer comments:
I'll just use a single example here because I think it makes it easier to express my point but the problems might be wider The URI template may include a variable, which is later defined in URL as . The value can only be between 0 through 255, I presume this is a decimal value. What is expected to happen if I send some bad values like: I presume that the recipient would reject the request with a bad path, by virtue of applying the requirement in section 4 that :path SHALL NOT be empty and following the expansion requirements in Section 3 and following those requirements on to Section 4.5. That's a lot of hops to get things right. Is there any easier way to present these?
Agreed, we need better text to specify server handling. For example, we don't currently explicitly that the server has to percent-decode these variables (but we say they have to be percent-encoded). When we add new text about how to extract the variables and decode them, let's also say that the server has to validate that they match requirements and has treat the request as malformed if they don't
NAME can you write up some text?
Appear to look good.

Revised text:
For example, the IP proxy could respond with:  <ins> 4.4. </ins> When using HTTP/2 H2 or HTTP/3 H3, IP proxying requests use HTTP Extended CONNECT.  This requires that servers send an HTTP Setting as
Original text:
IP packet forwarding, or a specific proxied flow; see scope. An IP proxying request that does not conform to these restrictions is <del> malformed (see H2 and H3). </del>  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: <del> 4.4. </del>  The IP proxy indicates a successful response by replying with the following requirements:

Reviewer comments:
I'll just use a single example here because I think it makes it easier to express my point but the problems might be wider The URI template may include a variable, which is later defined in URL as . The value can only be between 0 through 255, I presume this is a decimal value. What is expected to happen if I send some bad values like: I presume that the recipient would reject the request with a bad path, by virtue of applying the requirement in section 4 that :path SHALL NOT be empty and following the expansion requirements in Section 3 and following those requirements on to Section 4.5. That's a lot of hops to get things right. Is there any easier way to present these?
Agreed, we need better text to specify server handling. For example, we don't currently explicitly that the server has to percent-decode these variables (but we say they have to be percent-encoded). When we add new text about how to extract the variables and decode them, let's also say that the server has to validate that they match requirements and has treat the request as malformed if they don't
NAME can you write up some text?
Appear to look good.

Revised text:
IP packet forwarding, or a specific proxied flow; see scope. An IP proxying request that does not conform to these restrictions is  <ins> 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.5. </ins> The IP proxy indicates a successful response by replying with the following requirements:
Original text:
For example, the IP proxy could respond with: <del> 4.5. </del>  Unlike UDP proxying requests, which require specifying a target host, IP proxying requests can allow endpoints to send arbitrary IP packets

Reviewer comments:
I'll just use a single example here because I think it makes it easier to express my point but the problems might be wider The URI template may include a variable, which is later defined in URL as . The value can only be between 0 through 255, I presume this is a decimal value. What is expected to happen if I send some bad values like: I presume that the recipient would reject the request with a bad path, by virtue of applying the requirement in section 4 that :path SHALL NOT be empty and following the expansion requirements in Section 3 and following those requirements on to Section 4.5. That's a lot of hops to get things right. Is there any easier way to present these?
Agreed, we need better text to specify server handling. For example, we don't currently explicitly that the server has to percent-decode these variables (but we say they have to be percent-encoded). When we add new text about how to extract the variables and decode them, let's also say that the server has to validate that they match requirements and has treat the request as malformed if they don't
NAME can you write up some text?
Appear to look good.

Revised text:
For example, the IP proxy could respond with:  <ins> 4.6. </ins> Unlike UDP proxying requests, which require specifying a target host, IP proxying requests can allow endpoints to send arbitrary IP packets
Original text:
If present, the IP prefix length in "target" SHALL be preceded by a percent-encoded slash ("/"): "%2F".  The IP prefix length MUST <del> represent an integer between 0 and the length of the IP address in bits, inclusive. </del>  <del> "ipproto" MUST represent an integer between 0 and 255 inclusive, or the wildcard value "*". </del>  IP proxies MAY perform access control using the scoping information provided by the client: if the client is not authorized to access any of the destinations included in the scope, then the IP proxy can immediately fail the request. <del> 4.6. </del>  This document defines multiple new capsule types that allow endpoints to exchange IP configuration information.  Both endpoints MAY send any number of these new capsules. <del> 4.6.1. </del>  The ADDRESS_ASSIGN capsule (see iana-types for the value of the capsule type) allows an endpoint to inform its peer of the list of IP

Reviewer comments:
I'll just use a single example here because I think it makes it easier to express my point but the problems might be wider The URI template may include a variable, which is later defined in URL as . The value can only be between 0 through 255, I presume this is a decimal value. What is expected to happen if I send some bad values like: I presume that the recipient would reject the request with a bad path, by virtue of applying the requirement in section 4 that :path SHALL NOT be empty and following the expansion requirements in Section 3 and following those requirements on to Section 4.5. That's a lot of hops to get things right. Is there any easier way to present these?
Agreed, we need better text to specify server handling. For example, we don't currently explicitly that the server has to percent-decode these variables (but we say they have to be percent-encoded). When we add new text about how to extract the variables and decode them, let's also say that the server has to validate that they match requirements and has treat the request as malformed if they don't
NAME can you write up some text?
Appear to look good.

Revised text:
If present, the IP prefix length in "target" SHALL be preceded by a percent-encoded slash ("/"): "%2F".  The IP prefix length MUST  <ins> represent a decimal integer between 0 and the length of the IP address in bits, inclusive. </ins>  <ins> "ipproto" MUST represent a decimal integer between 0 and 255 inclusive, or the wildcard value "*". </ins> IP proxies MAY perform access control using the scoping information provided by the client: if the client is not authorized to access any of the destinations included in the scope, then the IP proxy can immediately fail the request.  <ins> 4.7. </ins> This document defines multiple new capsule types that allow endpoints to exchange IP configuration information.  Both endpoints MAY send any number of these new capsules.  <ins> 4.7.1. </ins> The ADDRESS_ASSIGN capsule (see iana-types for the value of the capsule type) allows an endpoint to inform its peer of the list of IP
Original text:
ADDRESS_REQUEST capsules, endpoints MAY send ADDRESS_ASSIGN capsules unprompted. <del> 4.6.2. </del>  The ADDRESS_REQUEST capsule (see iana-types for the value of the capsule type) allows an endpoint to request assignment of IP

Reviewer comments:
I'll just use a single example here because I think it makes it easier to express my point but the problems might be wider The URI template may include a variable, which is later defined in URL as . The value can only be between 0 through 255, I presume this is a decimal value. What is expected to happen if I send some bad values like: I presume that the recipient would reject the request with a bad path, by virtue of applying the requirement in section 4 that :path SHALL NOT be empty and following the expansion requirements in Section 3 and following those requirements on to Section 4.5. That's a lot of hops to get things right. Is there any easier way to present these?
Agreed, we need better text to specify server handling. For example, we don't currently explicitly that the server has to percent-decode these variables (but we say they have to be percent-encoded). When we add new text about how to extract the variables and decode them, let's also say that the server has to validate that they match requirements and has treat the request as malformed if they don't
NAME can you write up some text?
Appear to look good.

Revised text:
ADDRESS_REQUEST capsules, endpoints MAY send ADDRESS_ASSIGN capsules unprompted.  <ins> 4.7.2. </ins> The ADDRESS_REQUEST capsule (see iana-types for the value of the capsule type) allows an endpoint to request assignment of IP
Original text:
If an endpoint receives an ADDRESS_REQUEST capsule that contains zero Requested Addresses, it MUST abort the IP proxying request stream. <del> 4.6.3. </del>  The ROUTE_ADVERTISEMENT capsule (see iana-types for the value of the capsule type) allows an endpoint to communicate to its peer that it

Reviewer comments:
I'll just use a single example here because I think it makes it easier to express my point but the problems might be wider The URI template may include a variable, which is later defined in URL as . The value can only be between 0 through 255, I presume this is a decimal value. What is expected to happen if I send some bad values like: I presume that the recipient would reject the request with a bad path, by virtue of applying the requirement in section 4 that :path SHALL NOT be empty and following the expansion requirements in Section 3 and following those requirements on to Section 4.5. That's a lot of hops to get things right. Is there any easier way to present these?
Agreed, we need better text to specify server handling. For example, we don't currently explicitly that the server has to percent-decode these variables (but we say they have to be percent-encoded). When we add new text about how to extract the variables and decode them, let's also say that the server has to validate that they match requirements and has treat the request as malformed if they don't
NAME can you write up some text?
Appear to look good.

Revised text:
If an endpoint receives an ADDRESS_REQUEST capsule that contains zero Requested Addresses, it MUST abort the IP proxying request stream.  <ins> 4.7.3. </ins> The ROUTE_ADVERTISEMENT capsule (see iana-types for the value of the capsule type) allows an endpoint to communicate to its peer that it
Original text:
4.2.1. The ADDRESS_ASSIGN capsule allows an endpoint to inform its peer that <del> it has assigned an IP address to it.  It allows assigning a prefix which can contain multiple addresses.  This capsule uses a Capsule Type of 0xfff100.  Its value uses the following format: </del>  IP Version of this address assignment.  MUST be either 4 or 6.

Reviewer comments:
This change adds text that addresses conveyed by ADDRESSASSIGN can be used in the "source address" field of an IP packet, while addresses conveyed by ROUTEADVERTISEMENT can be used in the "destination address" field. While we're here, also add a small clarification when a prefix is assigned/advertised that any of these addresses can be used in the source/destination field, respectively. A future extension could create semantics for these addreses, but that is not called out in the text at this time.
I'm know I'm late looking at this but thanks as this small clarification is really helpful
The current text in this draft needs to be updated to match the changes from URL I'll write up a PR once existing conflicting PRs are merged.
NAME is this unblocked now?
We need to clearly state that ADDRESSASSIGN defines a set of addresses the receiver of the capsule can use as a source IP address on packets it generates We need to clearly state that ROUTEADVERTISEMENT defines a set of addresses the receiver of the capsule can use as a destination IP address on packets it generates Should we rename the capsules to make this relationship more clear in all use cases?
Let's bike shed the name here NAME NAME NAME
(to clarify Tommy's comment - if anyone comes up with a new name they like, they should post it here. If not, we'll go with advertisement and withdraw)
Thanks!

Revised text:
4.2.1. The ADDRESS_ASSIGN capsule allows an endpoint to inform its peer that  <ins> it has assigned an IP address or prefix to it.  The ADDRESS_ASSIGN capsule allows assigning a prefix which can contain multiple addresses.  Any of these addresses can be used as the source address on IP packets originated by the receiver of this capsule.  This capsule uses a Capsule Type of 0xfff100.  Its value uses the following format: </ins> IP Version of this address assignment.  MUST be either 4 or 6.
Original text:
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 <del> 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. </del>  If an endpoint receives multiple ADDRESS_ASSIGN capsules, all of the assigned addresses or prefixes can be used.  For example, multiple

Reviewer comments:
This change adds text that addresses conveyed by ADDRESSASSIGN can be used in the "source address" field of an IP packet, while addresses conveyed by ROUTEADVERTISEMENT can be used in the "destination address" field. While we're here, also add a small clarification when a prefix is assigned/advertised that any of these addresses can be used in the source/destination field, respectively. A future extension could create semantics for these addreses, but that is not called out in the text at this time.
I'm know I'm late looking at this but thanks as this small clarification is really helpful
The current text in this draft needs to be updated to match the changes from URL I'll write up a PR once existing conflicting PRs are merged.
NAME is this unblocked now?
We need to clearly state that ADDRESSASSIGN defines a set of addresses the receiver of the capsule can use as a source IP address on packets it generates We need to clearly state that ROUTEADVERTISEMENT defines a set of addresses the receiver of the capsule can use as a destination IP address on packets it generates Should we rename the capsules to make this relationship more clear in all use cases?
Let's bike shed the name here NAME NAME NAME
(to clarify Tommy's comment - if anyone comes up with a new name they like, they should post it here. If not, we'll go with advertisement and withdraw)
Thanks!

Revised text:
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  <ins> is equal to the length of the IP Address, the receiver of this capsule 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 receiver of this capsule is allowed to send packets from any source address that falls within the prefix. </ins> If an endpoint receives multiple ADDRESS_ASSIGN capsules, all of the assigned addresses or prefixes can be used.  For example, multiple
Original text:
notifies its peer that if the receiver of the ROUTE_ADVERTISEMENT capsule sends IP packets for this prefix in HTTP Datagrams, the sender of the capsule will forward them along its preexisting route. <del> This capsule uses a Capsule Type of 0xfff102.  Its value uses the following format: </del>  IP Version of this route advertisement.  MUST be either 4 or 6.

Reviewer comments:
This change adds text that addresses conveyed by ADDRESSASSIGN can be used in the "source address" field of an IP packet, while addresses conveyed by ROUTEADVERTISEMENT can be used in the "destination address" field. While we're here, also add a small clarification when a prefix is assigned/advertised that any of these addresses can be used in the source/destination field, respectively. A future extension could create semantics for these addreses, but that is not called out in the text at this time.
I'm know I'm late looking at this but thanks as this small clarification is really helpful
The current text in this draft needs to be updated to match the changes from URL I'll write up a PR once existing conflicting PRs are merged.
NAME is this unblocked now?
We need to clearly state that ADDRESSASSIGN defines a set of addresses the receiver of the capsule can use as a source IP address on packets it generates We need to clearly state that ROUTEADVERTISEMENT defines a set of addresses the receiver of the capsule can use as a destination IP address on packets it generates Should we rename the capsules to make this relationship more clear in all use cases?
Let's bike shed the name here NAME NAME NAME
(to clarify Tommy's comment - if anyone comes up with a new name they like, they should post it here. If not, we'll go with advertisement and withdraw)
Thanks!

Revised text:
notifies its peer that if the receiver of the ROUTE_ADVERTISEMENT capsule sends IP packets for this prefix in HTTP Datagrams, the sender of the capsule will forward them along its preexisting route.  <ins> Any of these addresses can be used as the destination address on IP packets originated by the receiver of this capsule.  This capsule uses a Capsule Type of 0xfff102.  Its value uses the following format: </ins> IP Version of this route advertisement.  MUST be either 4 or 6.
Original text:
requesting full-tunnel IP packet forwarding, or a specific proxied flow, see scope. <del> Along with a request, the client can send a REGISTER_DATAGRAM_CONTEXT capsule HTTP-DGRAM to negotiate support for sending IP packets in HTTP Datagrams (packet-handling). </del>  Any 2xx (Successful) response indicates that the proxy is willing to open an IP forwarding tunnel between it and the client.  Any response

Reviewer comments:
Aligning CONNECT-IP with the changes in HTTP datagrams and CONNECT-UDP.
NAME when do you plan to merge the other PRs?
NAME I plan on merging the other PRs as soon as we have WG consensus, which (assuming no objections) should happen at the end of the month (see ) Hi folks, During today's interim call, there was strong support to proceed with the output of the Design Team. This email begins a call to confirm that consensus. As a reminder, this consists of the following changes to draft-ietf-masque-h3-datagram and draft-ietf-masque-connect-udp: URL URL Please review these changes and send your comments to the list. This consensus call will conclude on February 28. Thanks, Chris and Eric

Revised text:
requesting full-tunnel IP packet forwarding, or a specific proxied flow, see scope.  <ins> The client SHOULD also include the "Capsule-Protocol" header with a value of "?1" to negotiate support for sending and receiving HTTP capsules (HTTP-DGRAM). </ins> Any 2xx (Successful) response indicates that the proxy is willing to open an IP forwarding tunnel between it and the client.  Any response
Original text:
request with a failure, or if the datagrams are received by the proxy before the request. <del> Extensions to this mechanism MAY define new HTTP Datagram Format Types in order to use different semantics or encodings for IP payloads.  For example, an extension could define a new HTTP Datagram Format Type which enables compression of IP header fields. </del> When a CONNECT-IP endpoint receives an HTTP Datagram containing an IP packet, it will parse the packet's IP header, perform any local policy checks (e.g., source address validation), check their routing

Reviewer comments:
Aligning CONNECT-IP with the changes in HTTP datagrams and CONNECT-UDP.
NAME when do you plan to merge the other PRs?
NAME I plan on merging the other PRs as soon as we have WG consensus, which (assuming no objections) should happen at the end of the month (see ) Hi folks, During today's interim call, there was strong support to proceed with the output of the Design Team. This email begins a call to confirm that consensus. As a reminder, this consists of the following changes to draft-ietf-masque-h3-datagram and draft-ietf-masque-connect-udp: URL URL Please review these changes and send your comments to the list. This consensus call will conclude on February 28. Thanks, Chris and Eric

Revised text:
request with a failure, or if the datagrams are received by the proxy before the request.  When a CONNECT-IP endpoint receives an HTTP Datagram containing an IP packet, it will parse the packet's IP header, perform any local policy checks (e.g., source address validation), check their routing
Original text:
Endpoints MAY implement additional filtering policies on the IP packets they forward. <del> 6. </del>  CONNECT-IP enables many different use cases that can benefit from IP packet proxying and tunnelling.  These examples are provided to help illustrate some of the ways in which CONNECT-IP can be used. <del> 6.1. </del>  The following example shows a point-to-network VPN setup, where a client receives a set of local addresses, and can send to any remote

Reviewer comments:
Aligning CONNECT-IP with the changes in HTTP datagrams and CONNECT-UDP.
NAME when do you plan to merge the other PRs?
NAME I plan on merging the other PRs as soon as we have WG consensus, which (assuming no objections) should happen at the end of the month (see ) Hi folks, During today's interim call, there was strong support to proceed with the output of the Design Team. This email begins a call to confirm that consensus. As a reminder, this consists of the following changes to draft-ietf-masque-h3-datagram and draft-ietf-masque-connect-udp: URL URL Please review these changes and send your comments to the list. This consensus call will conclude on February 28. Thanks, Chris and Eric

Revised text:
Endpoints MAY implement additional filtering policies on the IP packets they forward.  <ins> 7. </ins> CONNECT-IP enables many different use cases that can benefit from IP packet proxying and tunnelling.  These examples are provided to help illustrate some of the ways in which CONNECT-IP can be used.  <ins> 7.1. </ins> The following example shows a point-to-network VPN setup, where a client receives a set of local addresses, and can send to any remote