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