Hi Alec,
You wrote:
You wrote:
To address Edward’s implicit request for information - rather than to address his request for document pointers - I’d like to share that I sketched how onion addressing works in previous discussion at:
https://www.ietf.org/mail-archive/web/dnsop/current/msg13758.html
…and am happy to answer questions to the best of my ability, or punt in the right direction.Onion addresses may in future be >64 characters long, perhaps even >80, when new code rolls; the principles are likely invariant, however.
Thanks for the pointer and for the additional information on the address name length. Reading through the highlights two issues that have been raised in the past with the description of the special use names registry. The first is the continuing problem distinguishing between names in the DNS (e.g. the .onion "TLD") and names in some larger namespace which is not limited to the DNS. The second is the likelihood that names that are not in DNS may eventually cease to be parsed well by software which naively expects them to match the DNS world.
I believe that the registry we have currently defined doesn't do a great job of capturing the actual needs here. It doesn't define what the larger namespace encompassing the DNS is or could be well, and it doesn't provide a way to note the continuing evolution of the non-DNS resolution processes. It does a fine job with .example since that's fundamentally just a reservation, but .onion is showing its warts.
I understand the urgency of the .onion case, but I suspect that we're going to have to split it back out of the current registry once we have fixed the problems with the registry itself. I am wondering if there is a way forward here where we permit the registration in the existing registry, but with a note that it will likely move into either a different registry or an expanded registry in the future.
regards,
Ted