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@xxxxxxx> 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 >