Change:
Clients are configured to use IP Proxying over HTTP via an URI Template TEMPLATE.  The URI template MAY contain two variables: <del> "target" and "ip_proto".  Examples are shown below: </del> <ins> "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. Examples are shown below: The following requirements apply to the URI Template: The URI Template MUST be a level 3 template or lower. The URI Template MUST be in absolute form, and MUST include non- empty scheme, authority and path components. The path component of the URI Template MUST start with a slash "/". All template variables MUST be within the path or query components of the URI. The URI template MAY contain the two variables "target" and "ipproto" and MAY contain other variables. 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. 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. 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. </ins> 4.

Discussion:
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.
NAME 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 doesn'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 NAME is URL, 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 wouldn't use ipproto=0 to mean "any ipproto" because 0 means IPv6 Hop-by-Hop Options)
Yeah, using "" seems fine here
I didn'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 wasn'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 don'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 URL 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 doesn't have a concept of a "default URI template" the way CONNECT-UDP does. That concept was added 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 don't add anything we don't have a use for.
I don'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 doesn'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 added a default template to CONNECT-UDP because existing Web browsers have a proxy API that doesn't currently support encoding a path. An example of such an API that can'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: Masque Server (Proxy) hostname or IP address and port for the service. Client usage cases and necessary information. Request IP tunnel for single borrowed address Request IP tunnel for IP flow to specific target: Target address or host name a) Request specific IP protocol: Additional specify IP proto Request 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 can'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 don'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.
NAME 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 don'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 can'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 don'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. "URL{target}&p={ipproto}". If one attempts for example to specify no target but ipproto in the following template "URL{target}/{ipproto}/" it doesn't work as the path becomes invalid. Also URL{?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 wouldn't do ipproto=0 because that means IPv6 Hop-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 didn'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 doesn't support scoping.
I didn'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 don'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.