Slashdot Mirror

Seriously. We do need ".local" TLDs reserved officially. But all ICANN does is money grabbing. .local is for mDNS and similar stuff: http://en.wikipedia.org/wiki/.local

They should also reserve a ".here" TLD for a RFC1918 style usage, for instance if people may want to run their own DNS and area servers so that airconditioner.here to refers to the airconditioners at their current area, and https://here/ goes to the main page for the current area. While people can do that already, a TLD (or more) should be reserved for such purposes. Just like while 10.x.x.x could have been used before RFC1918, RFC1918 officially reserved ranges of IPs for private use so that they should not ever clash with public IPs. So similarly one or more TLDs should be reserved for private use by everyone.

So apparently it isn't a standard, and can break zeroconf

That's why I said: "a .here TLD, reserved officially for local use" and "analogous way to the way that the RFC1918 IP addresses are reserved officially for private use".

If RFC1918 IP addresses didn't exist people could have used arbitrary IP ranges they hope won't conflict. The same reason why RFC1918 is a better idea than that, is the same reason why there should be a .here or similar TLD.

Once you have a standard, others can build upon it. For example: many areas might allow you to visit http://here/ so that you can get a list of publicly advertised stuff/people that you can interact with.

This sort of thing can make it easier for you to do virtual telekinesis in different areas, and not just in places you are "accustomed" to (home, office).

I have proposed this type of TLD to the ICANN (back when Vint Cerf and Esther Dyson were there) and also the IETF. But the ICANN prefers to keep inflicting "Yet Another dotCom TLD money grab" on us.

I've been waiting for the superpda wearable thingy since the late 1980s. After all it was obvious that if you could do away with the huge laptop screens they'd be lighter and consume less power.

Add the other advances e.g. controlling devices by thought - possible already just needs to be safer etc, and video neural interfaces current = very low res vision for blind. Google "seeing tongue".

Include a good UI, video cams and you'd have a "auxiliary brain" which allows people to perform virtual telepathy and virtual telekinesis as a day to day thing, with other benefits like photographic/videographic/audiographic memory.

Some years ago I also proposed that the .here TLD be reserved, to make it easier for people to find stuff ( devices, people, services, information) available in the general physical area. It would be useful to be able to quickly list, control and access stuff "virtually" in your surroundings. And I proposed .here and _one_ stepping stone to making the addressing easier. Right now when you use free WiFi at some place, it's often not easy to figure out who is providing it, why, what's the T&C, what local services are available, etc. Easier if you could just do http://here/.

I even submitted an internet draft: http://www.watersprings.org/pub/id/draft-yeoh-tldhere-01.txt
Also emailed some people who were in the ICANN.

But the ICANN seemed more interested in approving "Yet Another Dot Coms" like .biz and .info. Which to me added very little benefit to the world.

Anyway, I guess the MPAA and RIAA would require "auxiliary brains" to be crippled by DRM. Maybe people would have to pay USD0.99 for each recall ;).

Shame though. The technology is all there, all it needs is someone to put it all together in a form that's practical and usable.

So when Lenovo comes out and basically says the future of the netbook is a larger netbook aka "laptop", it's quite disappointing or even disgusting to me.

"Whereas people _do_ intentionally leave access points open and there is no way for the general public to know if an AP was left open intentionally or not."

You could rename the SSID to OPEN2PUBLIC, BUT even then most people would wish to have some terms and conditions, or provide some info.

And that's where a "local-only" TLD[1] comes in useful. You could do http://here/ and possibly get information about the network you are using.

Forcibly redirecting people to show them some webpage first has many disadvantages.

But, I didn't have a spare USD100k to throw at ICANN to apply to get the TLD and then give it to the world for free. I did ask them to reserve it (even wrote to Esther Dyson, etc and got one or two replies), but they obviously thought stuff like .museum, .name, .biz and .info were more useful.

I think something like a .here tld would be more useful to the world (much like the RFC1918 IP addresses) but I'm biased...

Oh well.

[1] http://www.circleid.com/posts/top_level_domains_fo r_addressing_by_physical_context/
http://www.potaroo.net/ietf/idref/draft-yeoh-tldhe re/

Easy: as I said, integrate it into the router. So, you set your SSID (fore example) to "bear", and the router automatically sets your domain to "bear". Beyond that it's guessing anyway, because you have no way of knowing if there is a "brown.bear" and a "polar.bear" or even a "teddy.bear". This behaviour would *at best* be acceptable in a home-router, because frankly, I've seen routers that don't even allow me to set DHCP ranges, which frankly, sucks!

What you are suggesting will not work because you need to know what is on the network. I used "bear" in the former, just to be able to give another example like my existing ones. Even if http://bear/ would give you a list, somebody needs to maintain this list. Or you'll end up with a list like this:

• aeg-4577.bear
• electrolux-AC127.bear
• nb-zwingo

What if there are two airconditioners? airconditioner01.here and airconditioner02.here? You have to understand that naming is completely arbitrary. You'd be guessing anyway, because you don't know that there are two airconditioners, so you try airconditioner.here and it times out. Normal, because it's airconditioner01.here you should have accessed, but you coudln't know that. Besides, I could call my coffee machine "airconditioner01.here", if I wanted to.

As said: this changes nothing. You are free to do as you wish, and ICANN has no authority over *private* networks. It's that simple, no addition needed. You can setup your local hotspot exactly as you describe without any additional RFCs, rules or software. You all have it at your fingertips now.

It's a matter of helping people create defacto standards.

DNS is a de-facto standard.... You already have it.... Forcing names like "here" on me restricts me, because I actually like naming my own networks. Starbucks isn't going to like the fact that its network needs to be called "here", either... They would most certainly prefer, wait for it,.... "starbucks"! Oh, and what when two hotspots are next to each other? Both named "here"? That's going to be fun...

If you travel visit various spots around the world how would you find out whose network you are using?

You don't need to know... You only want to get on the Internet.... If you want to provide additional service, redirect to your http://here/ thingy (which requires maintenace in the first place!) and list the provided services. Over your local nameserver, they can reach those if they want.

You have all you need.... Nothing you propose is undoable with todays technological state.

About .xxx, are you really having so much trouble finding porn in the Internet that you need .xxx? ;-) .xxx is more justifiable than .biz or .info, but that really means that we should get rid of those two, and not create .xxx.

WRT .here, I think your proposal is a nice idea in principle, but not very practical.
First, you need to know which DNS is local to your location. That means you need to know at least something about the network, which means a chat with the local admin or getting some parameters via DHCP. In both cases you get to know the local domain (DHCP sends that too, usually).

Then, your solution is too www-centric. Let's assume it is possible to do what you're saying (in fact, you can emulate that behaviour with dns as it is right now). So, you want to check what's here. You type http://here/ and it takes you to the "local webserver" (whatever that means). Great. Now, you want to read news. You enter "here" as an nntp server and you go to the local webserver, not the NNTP server. DNS does not care about ports, only addresses (DOH!).

Now, how do you apply your solution to SSH? You don't because it is not reasonable to do so. Same for lots of other protocols. Basically, you are adding additional semantics to the ones defined in DNS (the rfcs specify what the db entries mean, and there's nothing about "here"). Whatever you do, you must consider that older clients and servers are still around, and will be for years. Backwards compatibility is a must.

It is also a problem, unless everyone has a dns server in every home. Let's say you have the typical Joe Sixpack setup: broadband, with dns, mail, etc provided by yur ISP, what would "airconditioner.here" mean? My house? Your house? The isp's datacenter? You could make it change depending the source ip, but it would complicate matters considerably.

You might have entities that don't have www servers, like my home. http://here/ would mean nothing useful (unless you count my linksys box as the "local webserver", not very reasonable).

You're assuming that Internet is just www servers, which it isn't. You're making exactly the same mistake as the .xxx guys, yours is for good, theirs is for evil, but it is the exact mistake.

Anyway, you could easily do as you want (on your domains of course), just by appending the local domain by default (you could send that via dhcp). That's what the "localdomain" domain is commonly used for. So, you could easily end with "http://airconditioner/set?temp=25c" or even set a "here" fake top level zone in your local dns server. When in doubt, try the "localdomain" domain. Me, I just use the domain I got from dyndns as a local domain and that works pretty well.

About .xxx, are you really having so much trouble finding porn in the Internet that you need .xxx? ;-) .xxx is more justifiable than .biz or .info, but that really means that we should get rid of those two, and not create .xxx.

WRT .here, I think your proposal is a nice idea in principle, but not very practical.
First, you need to know which DNS is local to your location. That means you need to know at least something about the network, which means a chat with the local admin or getting some parameters via DHCP. In both cases you get to know the local domain (DHCP sends that too, usually).

Then, your solution is too www-centric. Let's assume it is possible to do what you're saying (in fact, you can emulate that behaviour with dns as it is right now). So, you want to check what's here. You type http://here/ and it takes you to the "local webserver" (whatever that means). Great. Now, you want to read news. You enter "here" as an nntp server and you go to the local webserver, not the NNTP server. DNS does not care about ports, only addresses (DOH!).

Now, how do you apply your solution to SSH? You don't because it is not reasonable to do so. Same for lots of other protocols. Basically, you are adding additional semantics to the ones defined in DNS (the rfcs specify what the db entries mean, and there's nothing about "here"). Whatever you do, you must consider that older clients and servers are still around, and will be for years. Backwards compatibility is a must.

It is also a problem, unless everyone has a dns server in every home. Let's say you have the typical Joe Sixpack setup: broadband, with dns, mail, etc provided by yur ISP, what would "airconditioner.here" mean? My house? Your house? The isp's datacenter? You could make it change depending the source ip, but it would complicate matters considerably.

You might have entities that don't have www servers, like my home. http://here/ would mean nothing useful (unless you count my linksys box as the "local webserver", not very reasonable).

You're assuming that Internet is just www servers, which it isn't. You're making exactly the same mistake as the .xxx guys, yours is for good, theirs is for evil, but it is the exact mistake.

Anyway, you could easily do as you want (on your domains of course), just by appending the local domain by default (you could send that via dhcp). That's what the "localdomain" domain is commonly used for. So, you could easily end with "http://airconditioner/set?temp=25c" or even set a "here" fake top level zone in your local dns server. When in doubt, try the "localdomain" domain. Me, I just use the domain I got from dyndns as a local domain and that works pretty well.

Block .xxx? Huh, all along I thought a valid technical reason for having .xxx was so people looking for porn could do the following google searches:

site:.xxx ;).

Seriously though IMO .xxx is more justifiable than .biz or .info.

However, I disagree with you and the GP on TLDs.

I have long been arguing for .here to be a reserved TLD for free use for everyone - like the private RFC1918 IP addresses (10.x.x.x 192.168.x.x etc).

Basically everybody can host their own airconditioner.here in their houses/offices/rooms, and control it with http://airconditioner.here/set?temp=25c. And _polite_ people trying to figure out whether they are explicitly allowed to use an open WAP can go to http://here/ to look for terms and conditions, more info etc.

For more do a search on tldhere:
http://www.watersprings.org/pub/id/draft-yeoh-tldh ere-01.txt

I think my proposal had and has a lot more merit and utility than .xxx, .biz, .info and maybe even .tel.

But I just don't have USD100K to give to ICANN to try to get .here and then give .here to the whole world.

while i see you understand more than i first thought, im still not sure why this would be something ICANN would have any control over. DNS servers are still not going to give a damn about your private address space it's still going to have to rely on the administrators of every network using this http://.here/ convention to set one up. once again, reserved or not this is already possible, and i'm not so sure that ICANN reserving the TLD would cause people to adopt such a system.

It does sound like a nice concept but i dont think that ICANN would be the cause of such a standard taking off

This article proposes the reservation of a special use TLD to allow a more convenient addressing of devices by general physical location or context.

Introduction

As wireless networking and devices become more common there may be a need for a convenient way to address hosts by physical location or context, especially when the users themselves are using mobile or wearable devices.

A step towards this could be by reserving a special public use TLD (.here in the examples). Then this TLD can be independently hosted at various locations, so that each resulting .here domain falls under the context of that particular location. For a similar concept see RFC1918.

Example Usage of .here TLD

As an example a user could obtain a list of registered devices in each particular room or building by visiting https://all.here/ or perhaps just https://here/. Other forms could include https://who.here/ and https://what.here/

Say if the user wishes to control an air conditioner in a room, the user could visit https://airconditioner.here/ for the control page. The user could also "bookmark" popular settings such as https://airconditioner.here/settemp?celsius=25 and use it from room to room (assuming the air conditioners accept the same parameters).

Users of wearable devices could also address and access each other in a similar manner after registering with the location - e.g. https://lyeoh.here/sendobjectform or https://somebody.here/getobject?id=12345

Registration with an area could be done with DHCP [RFC2131] and dynamic DNS.

Various Considerations

Users could get the wrong address depending on how the default domain search is implemented - e.g. xxxx.here first, then xxxx.mydomain.com or vice versa. Also, it should be assumed that parties controlling the physical location could attempt to spoof or subvert communications.

Specifying .here. does not guarantee locality. Users may inadvertently or intentionally access devices at a different physical location.

Third parties could reserve a similar TLD (e.g. .her.) in order to catch typographical errors or unsuspecting users. As .her. and .he. may well become future TLDs, perhaps a less vulnerable name than .here should be used instead. A less elegant alternative is to also reserve the typos, but the Gere's (e.g. Richard) of the world may protest.

The .here TLD has already been reserved by a member of the ORSC. So to avoid conflict another TLD may have to be chosen, giving due consideration to the various alternative root zones. It seems that .local or .loc could be used but at risk of confusion with .localhost [RFC2606].

References

[RFC2606] D. Eastlake and A. Panitz, "Reserved Top Level DNS Names", RFC2606, June 1999.

[RFC2131] R. Droms, "Dynamic Host Configuration Protocol", March 1997.

[RFC1918] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear, "Address Allocation for Private Internets", February 1996.