> This brings us to one of the knottiest parts of special use names, which > is that they're all handled differently. For .onion, it's generally > handled in a SOCKS proxy in the application, for .local it's handled by > mDNS, and for .localhost it's special cased in the stub client library.
Let's please not bring .onion into this discussion. .onion is a hack with far-reaching consequences, and one that the IETF should never have standardised. The less we mention .onion, the better. .onion encodes the protocol into the hostname. Instead of .onion, tor should have used http+tor:// and https+tor://, which would have required no special-casing, since an application that doesn't understand the new scheme will return an error straight away rather than leaking .onion names into the DNS. (I understand why .onion was used -- it was an expedient way to avoid the need for special-case code in the browser --, but the tradeoff that was chosen requires special-case code in every single freaking DNS-speaking application. Yeah, I'm still pissed off.) Not so with .local and .homenet. Neither of these requires any special code in the application. From the point of view of the application, .local and .homenet are just ordinary domain names that are passed to the stub resolver, which yields a perfectly normal IP(v6) address that is then used with ICMP, TCP, UDP, DCCP (remember that?) or whatever your favourite transport-layer protocol happens to be. Completely unlike .onion. Now, granted, .local and .homenet require special casing in shared parts of the protocol stack (.local in the stub resolver, .homenet in the Homenet router's resolver), but this needs to be done just once in the protocol stack, not in every single application. Completely unlike .onion. Sorry for the rant. -- Juliusz _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
