Joe,
A question just to try to understand your position...
--On Wednesday, January 20, 2016 14:41 -0800 Joe Touch
<touch(_at_)isi(_dot_)edu> wrote:
- those which are not services, but are duplicates of HTTP
these are the "I really wanted port 80, but it's already
taken, but I need to run my own web server so users can
open a browser window to see how to monitor or configure
my device"
...
What we really need is a way for many interfaces to be able to
"register" with their local web server, to reserve URL
prefixes, etc.
This is not at all related to services over HTTP.
It sounds to me that what you are looking for would be satisfied
by something resembling
http://Domain.example.com<d>service/...
or
http<d>service://domain.example.com/...
(where <d> is some appropriately-chosen delimiter) as contrasted
with
http://domain.example.com:port/
which, by your reasoning as I understand it (and fwiw, by mine)
is basically a bad idea.
If one ignores for the moment the differences in difficulty of
fitting them in as extensions to the URI spec (RFC 3986) the
first two examples are assumed to be semantically equivalent or
what we used to call syntactic sugar. The definition of
<service> would ultimately depend on the domain, not some
necessary global convention although standardization of names
would help prevent confusion and duplication. But, in any
event, they would be service names, not different port numbers
for the same protocol.
Is that understanding correct?
john