Original text:
there exist proxy configuration interfaces that only allow the user to configure the proxy host and the proxy port.  Client implementations of this specification that are constrained by such <del> limitations MUST use the default template which is defined as: </del>  "https://$PROXY_HOST:$PROXY_PORT/.well-known/masque/ udp/{target_host}/{target_port}/" where $PROXY_HOST and $PROXY_PORT are the configured host and port of the proxy respectively.  Proxy <del> deployments SHOULD use the default template to facilitate interoperability with such clients. </del>  3.

Reviewer comments:
This change reduces the strength of recommendation for the default template. It also discusses how clients can figure out whether a server actually supports this template.
Please file an issue so we can have the discussion there instead of on a PR
For future reference, issue has been filed to discuss this topic.
NAME This PR now adjusts the default template recommendation text, instead of removing it.
that the URI template is not correct. Servers MUST NOT return these response codes if the request is well-formed and the URI matches a supported template. Generally, we shy away from saying "server MUST NOT return x status code " in HTTP because there are situations where that's the best thing to do. For example, a MASQUE server could decide that sending a 404 is the best thing to do to hide the existence of a service from a given client.
That paragraph was added as part of , and thinking about it more it adds more confusion that clarity so I'm going to remove the paragraph in .
As the author of this paragraph, I'm concerned about its removal. The purpose of this text is to enable clients to figure out that the template they are using is not correct. This is especially important given the default template, which will almost always be incorrect. Without a rule like this, error codes are specific to a single URI (i.e. a single destination), and the client never knows if MASQUE might work for a different destination. It therefore has to try MASQUE for every destination (even though it will always fail if the template is wrong), or implement and tune a heuristic to abandon the use of MASQUE after failures with many destinations (which creates compatibility problems with MASQUE servers that serve limited destinations).
I'm assuming that by "the template is not correct" you mean "the client was configured with a different URI template than what the UDP proxy expects", please correct me if that's not the case. Since these error codes don't tell the client what URI template they should have used, the clients will not treat any errors in in a different way, so specifying error codes doesn't change any outcome here. This is very much a binary outcome, either it works or it doesn't. Clients will implement heuristics based on this binary response, not on error codes. As Mark points out, error codes can't be used for this purpose in HTTP.
No, HTTP error codes can distinguish between transient failures (e.g. 429), permanent/cacheable failures (e.g. 404), and even non-error results that some clients might not support (e.g. 307/8). The "Proxy-Status" header provides further detail, and is normatively recommended in this draft precisely because a binary response is insufficient. Some clients might indeed do that, but HTTP also has many minimal or nearly-stateless clients for whom heuristics of this kind would be difficult to implement well. Also, the draft provides no mention of any such heuristics, or guidance on how they ought to work. Mark suggested a SHOULD, which does not seem to be the same as "can't be used for this purpose".
What is the purpose of the MAY and SHOULD in the resulting paragraph? In what way would it improve interoperability?
My goal with this text was to enable clients to determine whether an HTTP CONNECT server also supports MASQUE. I'm not too picky about how that works, but there ought to be some way to do it. The "MAY" documents an approved way to do that, and implicitly threatens servers with incompatibility if they don't hold up their end. Whether we say "SHOULD" or "MUST" on the server side, the "MAY" for the client creates an effective normative requirement on servers. To be clear, my main concern here has been that server implementors will be tempted to represent NXDOMAIN or "No Route To Host" as 404, etc. That's a very logical mapping that would break a lot of client heuristics, but is not prohibited by anything in the draft.
I share that goal. The problem is that this gets tricky because in HTTP a server and an origin aren't the same thing. So my thought is that our best outcome is a two-pronged approach: keep CONNECT-UDP simple, browsers will re-use their "if QUIC breaks often, mark QUIC as broken and use TCP" approach publish something more formalized like draft-schwartz-masque-access-descriptions later to have something that solves the problem for more than just CONNECT-UDP I think the underlying realization here is that browsers will need to interop with servers that do the wrong thing via a simple "mark CONNECT-UDP as broken for this proxy" heuristic, and that once they do that, adding requirements on error codes doesn't gain anything that isn't already covered by Proxy-Status
I think that's reasonably likely to be true for browsers, but not all clients are browsers. Part of the problem is that the TCP fallback heuristic is more complicated than that. The client needs to fall back to TCP, see that TCP works, and only then attribute the failure as likely proxy-related. This is only possible if the proxy client is also the HTTP client, able to change the HTTP version. It does not work for system-level proxy layers, as they cannot control, or even track, UDP->TCP fallback. Ultimately, some heuristic somewhere will probably make it work, but we're creating waste and delay that could be avoided by giving some clear instructions about how to tell if this thing is a MASQUE proxy.
I agree, though I'm not aware of system proxy layers having plans to implement CONNECT-UDP just yet. By the time those happen we'll have a more formalized approach. We can't avoid waste and delay with SHOULDs and MAYs so might as well wait for the formalized solution to tackle that problem.
I suggested a SHOULD because saying that you MUST send a particular status code in a particular situation precludes sending other status codes that might be more relevant. It also encourages clients to equate seeing that status code to only that error condition, even when it might have been generated by another component. However, there's something else going on here -- If you want to say something about many resources, it's best to do so explicitly. While you can infer things about server state from a few HTTP status codes (e.g., 505), most are specific to the resource in question. Saying otherwise is changing the semantics of those status codes, and that isn't something this specification can do.
The default template's purpose is to enable compatibility with origin-only proxy configuration schemes. This is a worthwhile goal, but the default template is not a suitable solution: It violates RFC 8615's definition of .well-known/ as the location for metadata about an origin. A MASQUE service is not metadata. It is not representable as a .well-known "URI suffix" as required by the .well-known registry (unless we register all (2^128 + 2^32)2^16 distinct paths). It conflicts with better discovery mechanisms, like the one in the MASQUE development process. It is not compatible with the use of HTTPS records. (In the targeted legacy context, the client has no other DNS server that can be used when a proxy is in use.) This is somewhat ironic, as HTTPS records allow bootstrapping QUIC connections, and proxying for QUIC is the primary motivation for CONNECT-UDP. We should defer this problem to a subsequent draft, and provide a cohesive proxy setup flow, presumably with a standardized configuration object that could be served from .well-known/ and extended to cover CONNECT-IP, DoH and other relevant capabilities.
Fundamentally I disagree with your assessment that this solution isn't good and should be removed. This serves a real purpose. Let's go into the issues individually: Those points are not an argument to remove the default template, they are an argument to revert PR and switch back to a non-well-known prefix. Let's set those aside for now. I don't see a conflict here: the default template doesn't preclude using other templates that have been discovered through other means. Can you clarify what the conflict is? Can you clarify what the incompatibility is here? I don't understand what the relationship between the default template and HTTPS records is. Clients are welcome to query their own HTTPS records before using CONNECT or CONNECT-UDP. The way that the client picks its template has no impact on its DNS settings.
... This is called "squatting on the HTTP namespace", and it would violate the in RFC 7320. It's also messy to implement, as it would require mixing MASQUE-specific "routing" rules with the user's application-specific routing rules. It doesn't prevent better discovery mechanisms, but it doesn't encourage them either. From the server side, there would be no way to "opt out" of the default path, due to the potential for clients that have implemented this specification but not a later, better discovery mechanism. Servers that would prefer a different path would still have to operate the default path for backwards-compatibility. The relationship is that the default template cannot express the existence of a DNS server affiliated with the MASQUE server. No, they are not, as this would violate the privacy guarantees implicit in the legacy proxy settings UI that this feature is trying to preserve.
You're conflating two types of proxies here: traditional enterprise proxies that speak CONNECT today and can be updated to speak CONNECT-UDP privacy proxies designed to protect a user's privacy from the network Folks won't ever be deploying both of these use cases on the same proxy. Your concerns are valid but they only apply to (2). (2) would never use the default template. The default template only applies to (1).
Client software generally can't tell why a proxy is being used. It just knows that an HTTP CONNECT proxy has been configured with a particular protocol, domain, and port. Its behavior has to be correct for any existing use case. I don't see why privacy proxies wouldn't use the default template. Privacy proxies that are configured via the existing Secure Web Proxy configuration mechanisms (e.g. browser extensions, system settings) would have no other way to use MASQUE. Also, I think this distinction is false. Enterprises are free to use HTTP CONNECT proxies to conceal certain information from the network (e.g. using an employees-only browser extension), and enterprises are often opinionated about which DNS server ought to be used (not controllable via a browser extension).
For completeness, here's how I think this ought to look: URL
Your discovery draft sounds great - however the default template doesn't get in the way of that. I don't think it's reasonable to remove a useful feature because we might have a more complete solution later when the useful feature doesn't get in the way of the future complete solution.
Thanks for the offline discussion, this seems like a good compromise.

Revised text:
there exist proxy configuration interfaces that only allow the user to configure the proxy host and the proxy port.  Client implementations of this specification that are constrained by such  <ins> limitations MAY attempt to access UDP Proxying capabilities using the default template, which is defined as: </ins> "https://$PROXY_HOST:$PROXY_PORT/.well-known/masque/ udp/{target_host}/{target_port}/" where $PROXY_HOST and $PROXY_PORT are the configured host and port of the proxy respectively.  Proxy  <ins> deployments SHOULD offer service at this location if they need to interoperate with such clients. Clients MAY interpret HTTP 400, 404, or 405 response codes as indications that the URI template is not correct.  Servers MUST NOT return these response codes if the request is well-formed and the URI matches a supported template. </ins> 3.