Draft: draft-ietf-masque-connect-ip

Commentary: 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 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 do n'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 do n't 
 can you write up some text ? 
 Appear to look good .
Paragraph (version A):
Clients are configured to use IP proxying over HTTP via an URI
Template TEMPLATE.  The URI template MAY contain two variables:
"target" and "ipproto" (scope).  The optionality of the variables
needs to be considered when defining the template so that either the
variable is self-identifying or it is possible to exclude it in the
syntax.
Paragraph (version B):
Clients are configured to use IP proxying over HTTP via an URI
Template TEMPLATE.  The URI template MAY contain two variables:
"target" and "ipproto"; see scope.  The optionality of the variables
needs to be considered when defining the template so that either the
variable is self-identifying or it is possible to exclude it in the
syntax.
Paragraph (version A):
To initiate an IP tunnel associated with a single HTTP stream, a
client issues a request containing the "connect-ip" upgrade token.
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.
Paragraph (version A):
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.
Paragraph (version B):
To initiate an IP tunnel associated with a single HTTP stream, a
client issues a request containing the "connect-ip" upgrade token.
Paragraph (version B):
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).
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
A successful response (as defined in Sections resp1 and resp23)
indicates that the IP proxy has established an IP tunnel and is
willing to proxy IP payloads.  Any response other than a successful
response indicates that the request has failed; thus, the client MUST
abort the request.
Paragraph (version A):
An IP proxying request that does not conform to these restrictions is
malformed (see H2 and H3).
Paragraph (version B):
An IP proxying request that does not conform to these restrictions is
malformed; see H2 and H3.
Paragraph (version A):
If present, the IP prefix length in "target" SHALL be preceded by
a percent-encoded slash ("/"): "%2F".  The IP prefix length MUST
represent an integer between 0 and the length of the IP address in
bits, inclusive.
Paragraph (version A):
"ipproto" MUST represent an integer between 0 and 255 inclusive,
or the wildcard value "*".
Paragraph (version B):
If present, the IP prefix length in "target" SHALL be preceded by
a percent-encoded slash ("/"): "%2F".  The IP prefix length MUST
represent a decimal integer between 0 and the length of the IP
address in bits, inclusive.
Paragraph (version B):
"ipproto" MUST represent a decimal integer between 0 and 255
inclusive, or the wildcard value "*".