On 1/20/2016 9:33 PM, Phillip Hallam-Baker wrote:
I was going to let this lie like Stephen suggested. But I think we
might actually have a basis for agreement here.
Reading your response here, it is clear that you misunderstand what
the implications of merging the registries is. No, there was no
proposal to require every protocol that uses .well-known to make use
of SRV signaling or vice versa.
That is a very strong rationale for NOT merging the two registries.
We merged the port service names and SRV registries because they both
define protocols that run over IETF transport layers, i.e., TCP, UDP,
SCTP, and DCCP.
There is in fact no separate registry for SRV. When a protocol uses
SRV signaling it uses a code point from the registry whose full name
is "Service Name and Transport Protocol Port Number Registry".
These were separate until merged by the action of RFC 6335.
But
only a minority of protocols make use of SRV signaling.
Any of the entries can be used in an SRV record. Only a very small
number use additional TXT records for additional context for signalling.
There is an
entry for 'DNS' in that registry for a start. While SRV discovery of
DNS resolvers might well make sense to some people, it is not
something to be attempted without an RFC covering that exact usage.
See RFC 6762.
All that the use of the "Service Name and Transport Protocol Port
Number Registry" for SRV means is that IF the protocol uses SRV THEN
those are the identifiers to be used. And that is all I have proposed
for .well-known so far.
But these are completely different things. SRV-specific and
non-SRV-specific service names run over IETF transport protocols.
.well-known runs over HTTP/HTTPS.
Nor is that use of the registry limited to SRV. People have been
looking at using the same identifiers for a variation on DANE and
other proposals for making use of DNSSEC for security policy.
Whether you want to make use of _dnt._tcp SRV records in your protocol
or not, you probably don't want someone else registering that
identifier in the "Service Name and Transport Protocol Port Number
Registry" for a completely different purpose.
This is the crux of the issue, and I cannot see why it matters. These
are completely different service layers.
Even if you don't want
any of the current mechanisms based on putting a service prefix in the
DNS, how can you be so certain that there is no possibility of such a
need?
If the two can't be used in the same protocols or index mechanisms,
there's no reason that the two need to be merged.
Joe