ietf
[Top] [All Lists]

Re: On IETF policy for protocol registries

2016-01-22 13:00:55


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