On 1/19/2016 12:32 AM, Eggert, Lars wrote: > Hi, > > On 2016-01-18, at 23:07, Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx> wrote: >> >> It is natural for the client resolving alice@xxxxxxxxxxx to use the >> following Web Service Endpoints: >> >> http://host1.example.com/.well-known/mmm/ >> http://host2.example.com/.well-known/mmm/ >> >> In effect we are providing the SRV prefix to the HTTP server using the >> URI request line in the same way that we use the Host: header to tell >> the server which service is being accessed (example.com in either case >> as following the prcedent set for CNAME lookup. we give the original >> DNS query name, not the internal DNS translations). > > as a reviewer for the ports registry, we frequently see requests for > port assignments for services over HTTP/HTTPS where the applicant states > that port 80/443/8080/etc. are already "taken". So they want to be able > to use URLs with a fixed port other than those. Some context on these requests: They typically fall into two categories: 1) I want to run a configuration system, monitoring system, etc. using existing web interfaces 2) I have a completely custom protocol that happens to be encoded over HTTP/HTTPS #2 is no different than X over SOAP, etc. That's just another encoding, and is a separate service. #1 is the difficulty. It becomes nearly impossible to determine how this is a distinct "service" from ports 80/443. However, there is a legitimate need to run multiple "services" over an encoding. There are two ways to handle this case: - build the differentiator into HTTP as Lars suggested using a new URL extension (which would work only for HTTP sharing) - build the differentiator into TCP see draft-touch-tcpm-sno which would work for any X over Y service Joe