Hi, On 1/19/16 9: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. As another reviewer of that registry, I concur that this is a problem. > > 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. I would prefer not to modify scheme names. It seems that .well-known is well suited for this sort of approach. I like Joe's suggestion, but would go further and suggest (as I have done on apps-discuss) that "specification required" is indeed too high of a bar, because there are such things as proprietary approaches that we as port reviewers cater to, and this .well-known registry is far less constrained. I also agree with Phill on one other point: it seems perfectly reasonable that should a request for an assignment be denied, the IANA should as a matter of course refer the applicant to RFC 5226 regarding the right of appeal. That process is there to allow for oversight of the designated technical expert and not to test the ability of an applicant to find the right RFC. Eliot
Attachment:
signature.asc
Description: OpenPGP digital signature