Hi, On Wed, Jan 07, 2015 at 02:14:24AM +0100, Christian Grothoff wrote: > > onion://domain/ > or tor://domain/ > > instead of http://, as they are indeed not using HTTP and this would be > a nice way to indicate anonymous/non-anonymous use.
[…] > issue of the draft, especially as names for GNS and NameCoin are really > meant to be usable in any URL with any protocol (telnet://, http://, > gnunet://, mailto:, etc.) in the place where there is a domain name in > the URL. So it makes sense to write Thanks very much for this. You've just expressed, in a _much_ clearer way than I ever did, the reason that I think the various proposals need to be pulled apart into separate drafts. Some of these proposals are in fact using names in domain name slots as ways of indicating that the protocol itself ought to be different. The hint a name below onion is giving is, "Not really the protocol you think it is." It's a protocol-redirection trick. In the other case, it's an indication that the _namespace_ is different: that if you resolve that name on the Internet without special enabled software, you aren't getting the service you desired, regardless of the protocol you happen to be using. In theory, these kinds of applications actually ought to want a new DNS class; but since classes are broken (because of CNAMEs/DNAMEs and also because of the facts of deployed infrastructure), in-band signalling in the domain name is the preferred alternative. I'm not the sort of DNS purist who thinks these strategies are evil (they do of course make my inner database geek itchy, but I'm perfectly prepared to be pragmatic). But they're different kinds of problems, and so ought to be evaluated differently. It's really shameful that both the DNS community and the URI scheme community have been so hidebound that these differences are not totally obvious. I don't want to (ok, "to insist that we") fix those issues in proceeding with these proposals; I just want the different kinds of proposals to be pulled apart so that the Internet community can distinguish the kinds of problems we're talking about. Just to be clear, I hope it doesn't seem like I'm trying to say, "No," to everything. I really want to support all the various approaches to fixing the myriad problems before us. But I want also to separate different kinds of problems from one another. Moreover, I wonder whether using the special-names registry at the top level is justified in every case, given that in principle we've already assumed that top-level name space is managed by someone else. When that top-level name space was entirely stable, hiving out new chunks did not present inter-community risks, but now that the space is not so stable the technical and administrative risks are greater. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
