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 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. I am also rather curious as to where the TXT convention came in. RFC6335 does not contain the string TXT. It seems to have evolved. Now that is something that should have probably have been in a separate registry. 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. 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. 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.