On 1/20/2016 3:05 PM, John C Klensin wrote:
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.
So here's the issue:
There are two reasons people want to use HTTP:
1) they want to run a webserver
2) they want a framing protocol over TCP
#1 occurs because you want to really run a webserver, or because you've
decided that a webserver/client are a quicker way of writing a remote
management console, e.g., for a printer, home router, etc.
#2 occurs because you either want to just use HTTP framing because there
are existing generation and parsing tools, or because you're developing
something called a "web service" - which, IMO, are a lot like
subroutines you can call from HTTP.
---
Requests for assigned ports for #1 are commonly rejected because they
duplicate ports 80/443. It's really one service - generic web server,
which is being used for different purposes.
Requests for assigned ports for #2 are commonly approved because framing
isn't the issue; the issue is whether the service has a distinct
protocol that doesn't replicate an existing service. Consider that both
HTTP and telnet both use ASCII encodings, but HTTP is a different
service because the language is restricted, the semantics are different
etc. That's what's sought by reviewers.
------
That said, I'm not entirely sure what .well-known is needed for. I'm now
beginning to understand it might be for web services, not for duplicate
uses of generic web servers.
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/...
A little. It's like having a service name that can be parsed or
automatically generated - which is closer to http<d>service, AFAICT.
(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.
I don't think it's a bad idea. I think allocating a new assigned port
for this purpose is a bad idea. You can run whatever service on whatever
port you want - either by mutual agreement with the other endpoint or as
indexed by mDNS records.
What I don't like is assigning port after port after port for vendors
who want to use web browsers to access their devices configuration and
control interface. Yes, there's a problem if many system entities want
to 'register' web pages for remote access with a single web server, but
that's not a port number problem. That's a web page registration problem.
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.
Yes, but as I noted, X over HTTP where X is a custom protocol or service
is already eligible for its own port number, and we do that a lot already.
Joe
Is that understanding correct?
john