Code change:
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.

Related discussion:
text: To initiate an IP tunnel associated with a single HTTP stream, a client issues a request containing the "connect-ip" upgrade token. <del> The target of the tunnel is indicated by the client to the IP proxy via the "target_host" and "target_port" variables of the URI Template; see client-config. </del> When sending its IP proxying request, the client SHALL perform URI template expansion to determine the path and query of its request, see client-config. <del> A successful response indicates that the IP proxy is willing to open an IP forwarding tunnel between it and the client.  Any response other than a successful response indicates that the tunnel has not been formed. </del> <ins> By virtue of the definition of the Capsule Protocol (see HTTP-DGRAM), IP proxying requests do not carry any message content.  Similarly, successful IP proxying responses also do not carry any message content. 4.1. Upon receiving an IP proxying request: if the recipient is configured to use another HTTP proxy, it will act as an intermediary by forwarding the request to another HTTP server.  Note that such intermediaries may need to re-encode the request if they forward it using a version of HTTP that is different from the one used to receive it, as the request encoding differs by version (see below). otherwise, the recipient will act as an IP proxy.  It extracts the optional "target" and "ipproto" variables from the URI it has reconstructed from the request headers, decodes their percent- encoding, and establishes an IP tunnel. IP proxies MUST validate whether the decoded "target" and "ipproto" variables meet the requirements in scope.  If they do not, the IP proxy MUST treat the request as malformed; see H2 and H3.  If the "target" variable is a DNS name, the IP proxy MUST perform DNS resolution before replying to the HTTP request.  If errors occur during this process, the IP proxy MUST reject the request and SHOULD send details using an appropriate Proxy-Status header field PROXY- STATUS.  For example, if DNS resolution returns an error, the proxy can use the "dns_error" Proxy Error Type from PROXY-STATUS. </ins> The lifetime of the IP forwarding tunnel is tied to the IP proxying request stream.  The IP proxy MUST maintain all IP address and route