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. To cater to their needs without assigning more ports for HTTP, I floated a slightly different proposal with a few people, namely, to extend the "port" component in the URL scheme and allow a service name there. The browser could then look that up against the given host with DNS-SD and connect on the returned port. scheme:[//[user:password@]host[:port]][/]path[?query][#fragment] I don't feel strongly about this variant either. I would love to see some scheme that would allow folks to run HTTP services on arbitrary dynamic ports without burning more port numbers. Happy to help write something up. Lars
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail