Draft: draft-age-masque-connect-ip

Commentary: This matches what CONNECT - UDP does . We can always revisit and switch to headers later , but for now this should be clear and consistent . 
 Is it legal to send a CONNECT - IP request where ? The more I think about this , the more I think that the target and ipproto would be better conveyed by two new HTTP headers instead of query parameters . Is there value in having these present in the URI ? 
 From reading I 'm even more inclined to use a header instead . 
 Yup , I 'm fine spelling this as headers too ! ( That 's more like the original  doc ) The reason I tried with the parameters is that it was a suggestion we had from   , etc , from one of the initial requests to use Extended Connect . This seems like something to ask the working group . 
 I think this would fall into the category of URI - template , like what 's done for DoH GET requests . So it should be allowed . 
 Using a URI template would be easier to reason about than the current text , so I 'd be in favor of that if we decided to go with path / query instead of a new header . 
 Yeah , I should have spelled it out as a template 
 Thinking about this some more , I feel like we should avoid specifying meaning to components of path , including the query - params . I think we should move target and ipproto to headers ( as  suggested ) , and allow path to be application defined . I was thinking of path to be more like /my - cool / proxy / with - auth , like an HTML , content to set " personality " , not a way to specify core operating parameters like these . 
 I think the question we should answer is : Do we want the target / ipproto in the URI ? The way I 'm visualizing this is that you could configure your client to use a given proxy by typing in a URI into the client software ( e.g. ) - whereas the target / ipproto are dynamic components that are picked by my proxy software in response to what networking the OS needs to do . All this to say that the more I think about it the more I think headers are preferable 
 I agree to  ’s last comment that target and ip_proto are rather parameters that are set by the proxy software and therefore I also tend to prefer headers . It also seems we would potential otherwise overload the URI scheme too much that still could be useful for other information ( as in  ’s example above ) 
 I frankly do n't understand the implications of either of choices to give an opinion here . I do n't know if hedaers will be easier or harder to get through intermediaries ? I think maybe the best way forward on this issue is to actually write it up and post to the mailing list . 
 Both headers and query params are equally easy to get through intermediaries in my experience . I would prefer we try to hash this out among ourselves before going to the mailing list . 
 I do n't want to reopen this issue or open another issue because I think this is fine ( for now ) . But I just want to quickly ask what we actually decided on this and why . The implicit question here was if we should use query parameters or headers . I assume the answer is that we use query parameters because we wanted to align with the UDP connect draft and can raise this issue again in the workgroup ( for both docs ) if needed ? Or what was the reason for having this as part of the query instead of headers ? 
 Yes when we met a few weeks ago we decided to go with an URI template to align with CONNECT - UDP for now . We can always revisit this later 
 ( This is related to , and here I 'm assuming that Section 3.1 meant query and not path . ) What does the URI path represent ? The examples use a path of and . Is the intention to let deployments decide what a path means ? That makes sense to me but we should mention it . 
 Perhaps all we need is a reference to : 
 The and examples were just arbitrary names that were examples of paths the proxies could run on . Adding a reference and explaining these are examples sounds good . 
 To my understanding we currently do n't specify multiple different functionalities based on the URI path component . Therefore we can work without any type of well - known URI suffix and the discovery procedure here is that the MASQUE client need to be configured / supplied with a base URI that gives the proxy as host component , and the path that is relevant on that proxy to invoke the MASQUE service . So unless we want to something more advance I think we can just make clear that the masque service resource is identified however the proxy want it to be . 
 I think that having MASQUE be able to work with any URI is a feature , and whether someone else down the line wants to make an auto - discovery for MASQUE - based proxies , either with .well - known or some other mechanism , should be a separate discussion ( and likely separate document ) . 
 Section 3.1 ( Limiting   ) uses the term but then it talks about variables which are part of the , not the path . Do we mean query here , or am I misunderstanding ? As a reminder , the " : path " pseudo - header and h3 contains both the path and the query separated by a question mark . 
 Yes , this should be the query part of the : path pseudo - header 
 Can I propose we close this issue out entirely in favor of switching to headers as per ? Then we avoid the confusion around what " path " is here . I 've left some thoughts on the philosophy of path in my comment there . 
 I 'd like the target hostname to be in the same place for CONNECT - UDP and CONNECT - IP ...
Paragraph (version A):
CONNECT-IP is defined as a protocol that can be used with the
Extended CONNECT method, where the value of the ":protocol" pseudo-
header is "connect-ip".
Paragraph (version A):
The ":method" pseudo-header field will be set to CONNECT and the
":scheme" pseudo-header field will be set to "https".
Paragraph (version A):
The ":authority" pseudo-header field contains the host and port of
the proxy, not an individual endpoint with which a connection is
desired.
Paragraph (version A):
Variables specified via the path query parameter (sent in the ":path"
pseudo-header field) are used to determine the scope of the request,
such as requesting full-tunnel IP packet forwarding, or a specific
proxied flow (scope).
Paragraph (version A):
Along with a request, the client can send a REGISTER_DATAGRAM_CONTEXT
capsule I-D.ietf-masque-h3-datagram to negotiate support for sending
IP packets in HTTP Datagrams (packet-handling).
Paragraph (version B):
This document defines the "connect-ip" HTTP Upgrade Token. "connect-
ip" uses the Capsule Protocol as defined in HTTP-DGRAM.
Paragraph (version B):
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.
Paragraph (version B):
The ":method" pseudo-header field SHALL be set to "CONNECT".
Paragraph (version B):
The ":protocol" pseudo-header field SHALL be set to "connect-ip".
Paragraph (version B):
The ":authority" pseudo-header field SHALL contain the host and
port of the proxy, not an individual endpoint with which a
connection is desired.
Paragraph (version B):
The contents of the ":path" pseudo-header SHALL be determined by
the URI template expansion, see client-config.  Variables in the
URI template can determine the scope of the request, such as
requesting full-tunnel IP packet forwarding, or a specific proxied
flow, see scope.
Paragraph (version B):
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).
Paragraph (version A):
CONNECT-IP uses variables in the URL path to determine the scope of
the request for packet proxying.  All variables defined here are
optional, and have default values if not included.
Paragraph (version B):
CONNECT-IP uses URI template variables (client-config) to determine
the scope of the request for packet proxying.  All variables defined
here are optional, and have default values if not included.