On Fri, Jan 22, 2016 at 4:08 AM, Eggert, Lars <lars@xxxxxxxxxx> wrote: > On 2016-01-20, at 23:41, 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" >> >> these have been turned down, but not at any astounding rate. >> They are declined as duplicates of HTTP, the same way that >> requesting your own DNS port or NFS port would be. >> >> 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. > > Right. Or the ability to run multiple web servers on different ports in a way that results in a priori known URLs, such as result from assigning unique ports and then including them in the URLs. (That is why I earlier in the thread proposed to start allowing service names in addition to ports in URLs.) Some platforms already have this. On the Windows platform, there is a Web Server that is tightly coupled with the TCP/IP stack so that you can register to serve a subset of the http:// space on the machine. The system is quite comprehensive, you can specify permissions at the system level so that different users have permission to bind to http://example.com/foo and http://example.com/bar. It really is very clever if you are fortunate enough to find the pages on Stackoverflow where the missing bits of the documentation are explained. It would be so much easier to use if there was a note in the API documentation to tell people they need to configure netsh http urlacl. Referring to Joe Touch's post yesterday, yes this is a different protocol layer to transport. But it isn't an application layer. One of the problems of HTTP/2 was that there is a tension between the use of HTTP as an application protocol in the browser and as a platform in Web Services. And as he points out, we are using different identifiers to transport layer, so it certainly isn't transport. What I think has emerged is a new layer between transport and application. We could call it presentation layer but people seem to resist that because of the OSI history. So for the sake of argument, call it the platform layer. Unlike the OSI presentation layer, the platform layer is very thin. It is basically using SRV or SRV+TXT to resolve domain+service to domain+port rather than using A/AAAA to resolve domain+port to a TCP or UDP endpoint. It is also a bit confused because the SRV record is a bit of a hack and doesn't have all the information we need. The specification of TCP or UDP should have been an output of the SRV query rather than an input. In fact I agree with pretty much all the statements Joe T. makes in his post. The only thing I disagree with is the assertion that being a separate layer means this needs to be a separate registry. It seems to me that it is worthwhile looking into such issues here because when all is said and done, understanding of that type of issue is going to have a lot more impact on the future of the net than the choice of location for future IETFs. I agree that the redefinition of SRV registrations did make the Services and Ports registry somewhat odd. Normally we expect a registry to be a mapping from an code point to a set of related data. By merging in SRV the way we did, the S&P registry is now a mapping of two sets of identifiers of different types to a data record. [Port#] -> [Service description] [String-ID] -> [Service description] Is this really a problem? The issue not unique, it turns up in cryptography as well where we have different ways to identify algorithms in ASN.1, XML, PEM and now JOSE. In this case the relevant parts of the two registries are both functions of the form: [String-ID] -> [Service description] By 'merging the registries' I mean adding in a constraint so that a given String-ID has the same meaning wherever it appears. This can be achieved in different ways: 1) Merging the registry tables. 2) Establishing a constraint that an identifier that appears in one is automatically reserved in the other and cannot be registered there. 3) Establishing a constraint that an identifier that appears in one is automatically reserved in the other and cannot be registered there except for the same service.