On Fri, Jan 22, 2016 at 9:57 AM, Eggert, Lars <lars@xxxxxxxxxx> wrote: > On 2016-01-22, at 10:42, Eliot Lear <lear@xxxxxxxxx> wrote: >> On 1/22/16 10:08 AM, Eggert, Lars wrote: >>> Right. Or the ability to run multiple web servers on different ports >>> in a way that results in a priori known URLs, such as result from >>> assigning unique ports and then including them in the URLs. (That is >>> why I earlier in the thread proposed to start allowing service names >>> in addition to ports in URLs.) >> >> But .well-known could easily provide, if nothing else, a redirect to >> such services. > > If whoever wants to deploy this other service has the ability to change the configuration of the server running on 80/443, to add that redirect. For the IANA assignment requests we see, they usually don't. (Fragile or impossible due to permissions to have one software install change the configuration of another.) > > Allowing a service name in the URL that is looked up with DNS-SD > > Lars Just to see we are discussing the same issue: Alice is the administrator of the system, she is running a Web Server for the company on http://example.com/ with a redirect mapping from http://www.example.com/* Bob wants to setup an XXX service which is a Web Service with a HTTP binding. Alice will let him run that service but does not want to grant unrestricted access to the corporate Web service on port 80/443. How do we support that? Like many other IETF questions, this is one that comes up repeatedly and consistency is important. It is not at all helpful if the answer for protocol X is different from that for protocol Y. The tools we have at our disposal are: 1) TCP/UDP port assignments 2) SRV Records 3) .well-known Port assignments are a finite resource which was one of the reasons SRV was invented in the first place. The other equally important benefit of SRV is that we can direct services to different ports. One solution to the permissions problem is to use SRV * Alice assigns Bob the use of a port - 666 say and configures the SRV record to point to that port: _xxx._tcp.example.com SRV 0 10 666 example.com Note that it is not necessary for 666 to be reserved, it is a purely local choice. It doesn't even need to be constant at the same site. For testing purposes, this is my current config: _mmm._tcp.example.com SRV 0 10 9001 mmm.test.com _mmm._tcp.example.com SRV 0 10 9002 mmm.test.com Running both service host instances on the same machine makes debugging the clustering code rather easier. SRV solves the need to isolate Web Services from the corporate Web service without needing to assign a separate port per service at the global level. Bob can run a completely different Web Server which is quite likely necessary if the Web Service is a standalone executable with its own server code. The only problem with this approach is that you don't always want to burn a port on the local machine. Let us say that Bob has permission to deploy multiple Web Services. Alice is willing to cut as many SRV records as he likes but she doesn't want to give him multiple ports because she has to reconfigure the firewall for each one. That is what makes use of .well-known the natural adjunct to SRV.