ietf
[Top] [All Lists]

Re: On IETF policy for protocol registries

2016-01-19 18:52:18


On 1/19/2016 12: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.

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