Consider adding a default template

[tfpauly]

Align with CONNECT-UDP to use the well-known default template

[DavidSchinazi]

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)

[mirjak]

Are there any reasons to not add a default template?

[DavidSchinazi]

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.

[achernya]

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.

[gloinul]

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.

[DavidSchinazi]

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?

[gloinul]

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.

1. Request IP tunnel for single borrowed address
2. Request IP tunnel for IP flow to specific target: Target address or host name
   a) Request specific IP protocol: Additional specify IP proto
3. Request tunnelling of IP prefix

I want to ensure that it exist at least one defined way of achieving 1 and 2 with alternatives.

[DavidSchinazi]

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.

[gloinul]

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.

[DavidSchinazi]

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.

@gloinul 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?

[tfpauly]

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?

[DavidSchinazi]

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.

[gloinul]

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. "https://proxy.example.org:4443/masque?t={target}&p={ip_proto}". If one attempts for example to specify no target but ipproto in the following template "https://masque.example.org/{target}/{ip_proto}/" it doesn't work as the path becomes invalid. Also https://proxy.example.org:4443/masque{?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.

[DavidSchinazi]

If one attempts for example to specify no target but ipproto in the following template "https://masque.example.org/{target}/{ip_proto}/" it doesn't work as the path becomes invalid.

From my reading of RFC 9110, https://masque.example.org/// is a valid URI and /// is a valid path.

Also https://proxy.example.org:4443/masque{?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.

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 #55 to track this.

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 agree.

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.

Thanks, that would be great!

[gloinul]

So PR #48 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?

[DavidSchinazi]

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.

[gloinul]

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.

[DavidSchinazi]

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.

[gloinul]

So the main question if there should be a default template is not yet resolved.

[DavidSchinazi]

Discussed offline. I'm OK with using a default template of .well-known/masque/ip/{target}/{ipproto}/ where the two variables must be non-empty (* already means "any")

[tfpauly]

Oops, intended to make a PR.