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. > 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