On 1/22/2016 11:27 AM, Phillip Hallam-Baker wrote:
On Fri, Jan 22, 2016 at 1:59 PM, Joe Touch <touch(_at_)isi(_dot_)edu> 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