Hi Alec,
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