There already is a LOCation resource record defined for DNS.
DNS allows many attributes to be associated with a name - this is why DNS is so flexible. If one turns DNS on its head and make those attributes part of the name itself then the name space unnecessarily explodes manyfold and we end up with two different means of assigning attributes to names.
We already have a method to do location. It works and has worked for years.
Re: Top-Level Domains for Addressing by Physical ContextKarl Auerbach – Mar 31, 2004 9:55 AM PST
I want to extend my previous comment - I somewhat misunderstood what you are proposing.
I believe that what you want to do is more in the realm of discovery of local resources than in the realm of the domain name system. The concept of "proximity" is something that is full of nuances - for example in a high-rise office is the "nearest" printer the one 5m away, directly above on the next floor or is it the one that is 20m away across the hallway?
Proximity is a measured in multiple dimensions and is a relative metric. DNS, even if local zones were established, can merely represent a relatively static view of those dimensions.
I've proposed over the years a pheromone-like resource discovery protocol that does exhibit the kind of locality that you are looking for.
'Special use' TLDs would seem to have some limitations in the concept you describe. (I perceive this as internalizing them rather than making them useful for communications from external locations...i.e. "the rest of the net".)
We're fully supportive of the concept however and think that with proper coordination the .HERE TLD could fill a gap just as you describe. We've been approached by someone, in fact, who had a similar concept using a 'convention' of SLDs in .com/.net space, but he was only able to gather 15-20% of the domains needed for his convention to work in .com space.
I'd welcome the possibility of any collaboration from you or anyone on this concept and the idea could be tested here in ORSC namespace. :) Feel free to contact me.
It is already possible to define a location for any name in DNS. (See http://www.ckdhr.com/dns-loc/ )
There already is a LOCation resource record defined for DNS.
DNS allows many attributes to be associated with a name - this is why DNS is so flexible. If one turns DNS on its head and make those attributes part of the name itself then the name space unnecessarily explodes manyfold and we end up with two different means of assigning attributes to names.
We already have a method to do location. It works and has worked for years.
I want to extend my previous comment - I somewhat misunderstood what you are proposing.
I believe that what you want to do is more in the realm of discovery of local resources than in the realm of the domain name system. The concept of "proximity" is something that is full of nuances - for example in a high-rise office is the "nearest" printer the one 5m away, directly above on the next floor or is it the one that is 20m away across the hallway?
Proximity is a measured in multiple dimensions and is a relative metric. DNS, even if local zones were established, can merely represent a relatively static view of those dimensions.
I've proposed over the years a pheromone-like resource discovery protocol that does exhibit the kind of locality that you are looking for.
Hello Lincoln,
As you observed, we created the .HERE top level domain in December, 1999 which currently resolves in the ORSC Root Zone (as well as a few others).
'Special use' TLDs would seem to have some limitations in the concept you describe. (I perceive this as internalizing them rather than making them useful for communications from external locations...i.e. "the rest of the net".)
We're fully supportive of the concept however and think that with proper coordination the .HERE TLD could fill a gap just as you describe. We've been approached by someone, in fact, who had a similar concept using a 'convention' of SLDs in .com/.net space, but he was only able to gather 15-20% of the domains needed for his convention to work in .com space.
I'd welcome the possibility of any collaboration from you or anyone on this concept and the idea could be tested here in ORSC namespace. :) Feel free to contact me.
Regards,
Dena A. Whitebirch