On 1/22/2016 11:27 AM, Phillip Hallam-Baker wrote: > On Fri, Jan 22, 2016 at 1:59 PM, Joe Touch <touch@xxxxxxx> wrote: > >> 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. > > If we were designing from a clean slate, sure. Having XXX mean > different things at different layers of the stack isn't a problem. > > But this problem is difficult precisely because the response to the > port shortage has been addressed piecemeal and gradually as a result > of a series of individual initiatives rather than through a top-down > directive. I don't see how this is related to port shortage per se. It is clearly related to the issue of layer - i.e., that transport service names describe the entire stack from layer 5-7, but some systems want to split those out. However, that cat is already out of the bag for URIs - again, "scheme" includes some port/SRV names, but has other names as well, and there's no attempt to merge *that* registry with port/SRV names. .well-known is even less justified in merging registries. > I can design a protocol with very clear separation between my protocol > layers but I can't guarantee that anyone else will follow them. > Looking at this thread it looks pretty clear that other people have > different opinions about where they should go. Agreed; that seems like an open problem. Way too early to recommend merging all registries at all layers into a single namespace. > I am also rather curious as to where the TXT convention came in. rfc6763 > RFC6335 does not contain the string TXT. It points to [DNS-SD], a precursor to rfc6763. > It seems to have evolved. Now > that is something that should have probably have been in a separate > registry. They were, but the SRV names to which they are linked were deemed essentially identical to port names. We could have had a separate registry for each SRV name that used TXT records, but it seemed compact to include them in the portname/SRV list. > We seem to be building things in an ad-hoc way in which every service > designs its own discovery mechanism. I want to see consistency. Consistency is only important if we expect orthogonal design - the Internet hasn't evolved that way. We don't have services over services most other places except HTTP, and the services we run over HTTP don't really have a relationship to the services we run over TCP/UDP/etc. > One of the big obstacles that has held back use of SRV has been the > lack of API support on many platforms. I had to write my own DNS > library to implement it for .NET. And Patrik's URI proposal faces the > same problem. That's going to be a problem for any solution. > I don't think we can really blame the platform providers when this is > being left to a handful of individuals to push in a bottom up fashion. > If any of these mechanisms is going to be adopted by all the platforms > and become ubiquitous it needs to have backing from IETF as a whole. Agreed, but again, I don't see any of this as a rationale for merging .well-known and SRV. Joe