Draft: draft-ietf-masque-connect-ip

Commentary: Proposal for update to client configuration section . Would address . I would note that I think this proposal have some short comings that should be resolved before accepting . With the exception to the well known proposal here there is overlap with the corresponding example in connect - up and likely some separation with connect - UDP is desired . Connect - UDP did register the suffix as noted in text . However , should the URI paths under masque be managed somehow by IANA too ? 
 I do not support defining a URI template for CONNECT - IP , especially if it requires port 443 endpoints to live in .well - known only . 
 there 's already a URI Template for where to put the target and protocol , I think the question is more about if there should be a well - known ( which it does n't currently ) . 
 Let 's keep the discussion on issue folks 
 Specific regarding templates in general . How does one express the optionality of the variable and still be able to correctly parse the template . As currently formulated the template allows for either variables or both . How should the template be created to handle that ? 
 As pointed by is , there is currently no non - empty way to convey " any ipproto " or " any IP address of any address family " . That can cause issues when using some path templates . It would be simple to define a non - empty way to convey " any " . I propose using for this purpose . ( I would n't use ipproto=0 to mean " any ipproto " because 0 means IPv6  - by - Hop Options ) 
 Yeah , using " " seems fine here 
 I did n't realise that the 0 for ipproto was actually broken . Will " " cause an type issue for ipproto ? For target that is either an IP address literal or a hostname string . So what meaning does " " have for those types ? As the target definition was n't clear on what type definition that was used we need to start with agreeing on those types to verify that the " " is fine . 
 So I have now attempted to address this is PR . Please review . 
 There is no normative specification for the target IP address formats that can be used . 
 Agreed , this text could be formalized a bit more . In particular it should mention percent - encoding of colons in IPv6 addresses , and the fact that IPv6 scoped addressing zone identifiers are not supported . We could pull in some of the text from CONNECT - UDP . 
 So I have tried to clarify in PR the target specification to actually reference the URI spec and relevant syntax elements . I would note that IPv4 Literals has not that stringently defined , and points to the IPv4address syntax so I did that explicitly . I have assumed that we do n't want the [ ] around the IPv6 address . I would note that Connect - UDP might be a bit louse on these aspects and could benefit from a similar change in Auth48 to include both a reference and the exact syntax element that are expected to be used . 
 Agreed . I filed to improve CONNECT - UDP , and once we have that there we can use that to inspire the text here 
 Align with CONNECT - UDP to use the well - known default template 
 CONNECT - IP currently does n't have a concept of a " default URI template " the way CONNECT - UDP does . That concept was to allow browsers to reuse their existing CONNECT configuration API when using HTTP/3 . I think this concept might be useful in CONNECT - IP , but I 'd rephrase this issue to say that we should investigate whether to add the concept of a default template or not . ( If we decide to add it , I agree it should live under .well - known / masque to be consistent with CONNECT - UDP ) 
 Are there any reasons to not add a default template ? 
 I 'm not opposed to adding it , I just want to make sure we do n't add anything we do n't have a use for . 
 I do n't think the use cases are uniform enough that a default template makes sense right now . I would avoid adding it just on that reason alone . I also think it does n't make sense in general because in CONNECT - IP you 're connecting to the URL of the service endpoint itself , not some other destination in many of the the use cases . 
 After having started with text , I think the well known URI makes sense . However , it is fairly clear that requesting without target is one of the more likely use cases and maybe with a specific IP version . So these relations needs to be made clearer . But , I think not having some text on client configuration would be confusing , even if we just develop the well known . 
 We a default template to CONNECT - UDP because existing Web browsers have a proxy API that does n't currently support encoding a path . An example of such an API that ca n't easily be fixed is PAC files . Do we have a similar use - case for CONNECT - IP ? 
 So my reason for thinking a well known also for connect IP is the following . We are considering using masque in mobile networks where we have first of all a multi - vendor situation for both MASQUE client and server , secondly the client will be thin one focused on establishing this connectivity and using it to provide network services . Although one could leave it up to 3GPP to define an HTTP API for its usage I think having one well defined one in the IETF specification have two advantages . First it reduces the barrier for using Connect - IP in a system , secondly it also ensures that we think through if there are aspects of its usage that impacts the part we absolutely need to specify for it to work at all . Looking at the client configuration and usage aspect here with the several types of usage we are considering for Connect - IP it is good to write consider the impact . Basic Client Configuration :   ( Proxy ) hostname or IP address and port for the service . Client usage cases and necessary information . IP tunnel for single borrowed address IP tunnel for IP flow to specific target : Target address or host name a ) Request specific IP protocol : Additional specify IP proto tunnelling of IP prefix I want to ensure that it exist at least one defined way of achieving 1 and 2 with alternatives . 
 Thanks for clarifying . If I understand you correctly , in that scenario you 'd still need a new mechanism to convey the hostname and port of the proxy right ? Why ca n't that new mechanism carry a URI template instead ? To get the use - cases 1,2,3 that you mentioned , you need a URI template , but you do n't need a default URI template . I 'm not proposing we remove the URI template , I 'm asking whether we need a default URI template for cases when the hostname and port are known but the path is not . 
 So for the use case of the mobile network a default URI template would clearly be the simplest as hostname and ports for the proxy are things that there are good existing mechanism to configure a client with . But , not defining a default one would be the same as requiring the service to define their own API or template that works . I see that is problematic unless we actually provide example templates that actually works across the use case sets . The current template examples are not covering the breath of use case , nor if co - deployed with connect - UDP . I would propose that we hold of the question of the default a bit and first try to improve the client configuration section so that it discusses the requirements and also gives example for how to solve it with a template that covers the different use cases . I would note that for the use case I have in mind we will like to support all three of the cases above . 
 can you elaborate on that ? Apart from co - deployment with CONNECT - UDP , what specific use cases are not served by one of the templates that are currently in the draft ? 
 I do n't feel too strongly either way here . I wonder if the stronger reason to have a CONNECT - IP default template is specifically if it is not co - deployed with CONNECT - UDP , such that a browser would need to use CONNECT - IP instead of CONNECT - UDP . The rationale for having the default template in CONNECT - UDP is that there are browser use cases where it 's not possible or convenient to add a full URI template . This assumes that general proxies would be supporting CONNECT - UDP , which is reasonable , but it 's possible that some proxies would actually only do CONNECT - IP . So it may be useful to have the template for those . One of the use cases I have for CONNECT - IP is the ability to open up a UDP listener over the proxy — like how WebRTC can open a UDP socket that can receive traffic from peer - to - peer connections . That is a case where we 'd use CONNECT - IP instead of CONNECT - UDP for browser traffic . In such a case , if the proxy was configured in the way that ca n't take a template , should CONNECT - IP indeed support a default template ? 
 I think we need to figure out as a WG how to do UDP listening sockets over HTTP . I think an extension to CONNECT - UDP would make more sense , as non - Apple browsers do n't have a UDP implementation nor an IP implementation . But maybe that 's a topic in and of itself for 114 ? If we decide that CONNECT - IP is the way forward for UDP listening sockets , then adding a default template makes sense . If we decide on an extension to CONNECT - UDP , then we 're back to not having a use - case for the default template . I 'm going to think about this some more . 
 So to my understanding the only URI template that can work when both target and ipproto are optional is the query based one where the parameter is identified by a variable name in the template , e.g. " { target}&p={ipproto } " . If one attempts for example to specify no target but ipproto in the following template " { target}/{ipproto}/ " it does n't work as the path becomes invalid . Also { ? target , ip_proto } is dependent on both parameter being present as there are no Null values specified for target , there is the " 0"=any for ipproto . So maybe let us start with having text for the template that actually makes it clear when they work and what limitations there are here . Because this is templates need more considerations than Connect - UDP . I think the question of a default is something we should discuss a bit more before making any decision on . I will see if I can update my PR to try to address the limitations on the template due to the optionality in the PR in the next few days and I can remove the well known part . 
 From my reading of RFC 9110 , is a valid URI and is a valid path . That 's a good point though , I think specifying something like " ipproto= means any " and " target= means any " would be a good idea . ( I would n't do ipproto=0 because that means IPv6  - by - Hop Options ) . I 've filed to track this . I agree . Thanks , that would be great ! 
 So PR has been updated to attempt to address the general need to consider this . I think this is a minimal general warning about the optionality . I do have one thing I am really uncertain about . I did n't discuss the " " usage for the value . If you construct a template are there any way to force the usage of rather than leaving it blank ? I would appreciate some help in thinking about that issue . Or will you be forced to ensure that either work when writing the template and the template interpreter will be implementation dependent on what it does ? 
 I think it 's simpler to just omit the variable from the template if the configuration does n't support scoping . 
 I did n't think about the case when the configuration does not support scoping . I was more thinking of the case when the client does not want to scope , is it omitting the variable freely , or can the template writer in some way force the client to inlace the " * " to indicate this . I do n't understand this URI template well enough to answer the later is possible ? And if not , then we can be clearer that as template writer you need to create a template where the variable can be omitted . 
 This is pretty straightforward : if the configuration wants to remove the ability to scope , all it needs to do is omit the variable . If the client wants to not scope even though the configuration supports it , the client can either omit the variable or send - so there 's no requirement on the template since the client has both options . 
 So the main question if there should be a default template is not yet resolved . 
 Discussed offline . I 'm OK with using a default template of where the two variables must be non - empty ( already means " any " ) 
 Oops , intended to make a PR .
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" (scope).  The optionality of the variables
needs to be considered when defining the template so that either the
variable is self-identifying or it works to exclude it in the syntax.
Paragraph (version B):
The URI Template MUST be a level 3 template or lower.
Paragraph (version B):
The URI Template MUST be in absolute form, and MUST include non-
empty scheme, authority and path components.
Paragraph (version B):
The path component of the URI Template MUST start with a slash
"/".
Paragraph (version B):
All template variables MUST be within the path or query components
of the URI.
Paragraph (version B):
The URI template MAY contain the two variables "target" and
"ipproto" and MAY contain other variables.
Paragraph (version B):
The URI Template MUST NOT contain any non-ASCII unicode characters
and MUST only contain ASCII characters in the range 0x21-0x7E
inclusive (note that percent-encoding is allowed; see Section 2.1
of URI.
Paragraph (version B):
The URI Template MUST NOT use Reserved Expansion ("+" operator),
Fragment Expansion ("#" operator), Label Expansion with Dot-
Prefix, Path Segment Expansion with Slash-Prefix, nor Path-Style
Parameter Expansion with Semicolon-Prefix.
Paragraph (version B):
Clients SHOULD validate the requirements above; however, clients MAY
use a general-purpose URI Template implementation that lacks this
specific validation.  If a client detects that any of the
requirements above are not met by a URI Template, the client MUST
reject its configuration and abort the request without sending it to
the IP proxy.