Draft: draft-ietf-masque-connect-udp

Commentary: 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 ,  and other relevant capabilities . 
  I disagree with your assessment that this solution is n'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 do n't see a conflict here : the default template does n'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 do n'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 does n't prevent better discovery mechanisms , but it does n'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 can not 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 : enterprise proxies that speak CONNECT today and can be updated to speak CONNECT - UDP proxies designed to protect a user 's privacy from the network Folks wo n'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 ca n'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 do n't see why privacy proxies would n't use the default template . Privacy proxies that are configured via the existing    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 : 
 Your discovery draft sounds great - however the default template does n't get in the way of that . I do n't think it 's reasonable to remove a useful feature because we might have a more complete solution later when the useful feature does n't get in the way of the future complete solution . 
 Should the default URI template have a /.well - known prefix ? For example , ? ( issue based on by 
 While you are at it ... , how about something simpler ? would put the host and port in query parameters AND it would have smaller , shorter names . 
 Having implemented this , placing the variables in the path is easier to parse on the proxy than placing them in query parameters 
 From the discussion in the room at IETF 113 , it appeared folks were OK with . I 'm going to pick that to close this issue , and we can open another issue during WGLC if we really want to bikeshed this further 
 It sound like you 're writing your own URL parser ? Any reasonable URL library will handle this for you . 
 I do n't think placing these things in path components by default is reasonable .
Since the original HTTP CONNECT method allowed conveying the target
host and port but not the scheme, proxy authority, path, nor query,
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
limitations MUST use the default template which is defined as:
"https://$PROXY_HOST:$PROXY_PORT/{target_host}/{target_port}/" where
$PROXY_HOST and $PROXY_PORT are the configured host and port of the
proxy respectively.  Proxy deployments SHOULD use the default
template to facilitate interoperability with such clients.
Since the original HTTP CONNECT method allowed conveying the target
host and port but not the scheme, proxy authority, path, nor query,
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
limitations MUST use the default template which is defined as:
"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
deployments SHOULD use the default template to facilitate
interoperability with such clients.