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