ietf
[Top] [All Lists]

Re: On IETF policy for protocol registries

2016-01-19 02:47:21
Hi,

On 1/19/16 9:32 AM, Eggert, Lars wrote:
Hi,

On 2016-01-18, at 23:07, Phillip Hallam-Baker 
<phill(_at_)hallambaker(_dot_)com> wrote:
It is natural for the client resolving alice(_at_)example(_dot_)com 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