Settle on /dns4 and /dns6

[ghost]

tl;dr this PR removes the "experimental" protocols like /exp-dns.

David brought up good points against introducing multiaddr protocols with and "experimental" prefix in multiformats/js-multiaddr#39:

I'm feeling that is going to bite us, in the same way that today we have X- HTTP headers everywhere because the rationale was "We are going to try this and then remove it", in reallity what happen is that so many tools started checking for the X- specifically, that they never got removed.

See: https://tools.ietf.org/html/rfc6648
tl;dr; in the answer here: http://stackoverflow.com/questions/3561381/custom-http-headers-naming-conventions

3. Recommendations for Creators of New Parameters

...

SHOULD NOT prefix their parameter names with "X-" or similar constructs.
4. Recommendations for Protocol Designers

...

SHOULD NOT prohibit parameters with an "X-" prefix or similar constructs from being registered.
MUST NOT stipulate that a parameter with an "X-" prefix or similar constructs needs to be understood as unstandardized.
MUST NOT stipulate that a parameter without an "X-" prefix or similar constructs needs to be understood as standardized.

Right now, multiaddrs with DNS are just used to be passed around, to be announce and to be used for things like the WebSockets dialing to the Signalling Server on WebRTC-Star, I've avoided implementing the .resolve method for names as it is not directly a need for the current sprint and I agree with you, that shed will get some more coats of paint.

I now think we should settle on /dns4 and /dns6 because of the above, and because they carry less complexity than /dns:

• They do unambiguously address a specific listener. With /dns, there would need to be a mechanism like RFC6555 to decide betwen ip4 and ip6. This reliefs us of most of the immaturatiy risk that was motivation for coming up with the "exp-" protocols.
• You know which kind of multiaddrs the resolve() step will yield: . With /dns, you don't know whether your libp2p stack actually supports the multiaddr, until after you've resolved it.

And in addition to this, we still keep /dns free for future uses :)

[daviddias]

Thank you @lgierth, going to go ahead and merge this one so that the table is up to date.

[jbenet]

SGTM on not repeating the X- issue and accidentally standardizing /exp-dns

One caveat / word of warning on dns{4,6}: as is now, dns4 and dns6 are meant for A and AAAA records to IPv4 and IPv6 addresses respectively. this is fine because dns is so tied up with IPv{4,6}, but want to comment that many other uses of dns may want to instead use something less specific, like dnslink. (dnslink could refer to any multiaddr. like dnslink=<multiaddr> or something). So keep in mind for an eventual /dns thing if we do that.

we should also consider what does /dns/ipfs.io/a/b/c refer to. As far as IPFS/IPNS are concerned, it should check TXT record for a dnslink to resolve ipfs.io -> <ipfs-path>. it could be that /dns should be dnslink. or maybe /dnslink should be a thing, and /dns is some meta thing that tries to surface all the things (dns4, dns6, dnslink)and lets you decide what to do.