On 1/22/2016 6:37 AM, Phillip Hallam-Baker wrote: ... > Referring to Joe Touch's post yesterday, yes this is a different > protocol layer to transport. But it isn't an application layer. Then it doesn't belong in the IANA ports registry, IMO. > 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. That's fine, but that then argues that it legitimately a separate namespace, defined only in the context of HTTP. There should be no issue at all with collisions between that namespace and port/SRV names. port/SRV names are the entire stack to the user above IETF transport. > 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. I have no idea how to parse that. If you're running over HTTP/HTTPS, the SRV will either resolve to 80/443 or a dynamic port that's locally assigned. You still need a way to coordinate that you're using this service - which means the service indicator still needs to be inside the URI passed over HTTP/HTTPS. > 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. Right - when that information is common across all uses of a port number, that extra info is in the TXT record associated with the SRV. But there's no way to coordinate that information once you have a port number and transport - that info has to be exchanged in-band or used only locally. When that information is local to a specific HTTP/HTTPS connection, it ought to be coordinated in-band over HTTP - e.g., in the URI. > The specification of TCP > or UDP should have been an output of the SRV query rather than an > input. SRV tells you how you MAY connect; you have to decide how you WANT to connect. Depending on the way you query the DNS, you might be able to wildcard the transport. > 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. I do understand that this is your position, but I still don't quite understand why. Can you focus on this point? ... > 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] SRV records are supposed to be: SRV [IP-addr, String-ID] -> [port number] TXT [IP-addr, String-ID] -> [name=value pairs] More specifically: _service._proto.name. TTL class SRV priority weight port target. where: service is the String-ID proto is an IETF transport protocol (tcp/udp/stcp/dccp) name is a domain name where this definition is valid TTL, class, priority, and weight determine the nature of the record and how to handle multiple entries port is the port number target is the CNAME of the machine providing the service Note that none of these actually are a "service description", and that the lookup is from the left to the right - you provide the service/proto/name tuple and get the rest back. The TXT record is only meaningful if the SRV record exists, and in the context of that SRV record. Both are for a given IP address. I don't know of any reverse lookup support for SRV, but if there were, it would be from [IP-addr, port] -> [String-ID]. There's no real "description" of a service in an SRV record. > In this case the relevant parts of the two registries are both > functions of the form: > > [String-ID] -> [Service description] That'e the issue - they're really not. Can you tell me what .well-known returns? > By 'merging the registries' I mean adding in a constraint so that a > given String-ID has the same meaning wherever it appears. In order for that to be appropriate, it has to make sense. I can't imagine what that means, though - unless you're now proposing that every IANA assigned port and SRV name might also be a service that runs over HTTP. I *really* think that's a bad idea. > This can be achieved in different ways: Before we consider how to achieve it, we really need to understand why it is necessary to have these namespaces be mutually distinct. Joe