https://www.icann.org/en/system/files/files/name-collision-f...
Besides, accidentally resolving a file extension to a TLD is only one of many possible different serious errors that can result from exposing an API that can load files locally or remotely, and thus make network calls that you might not be expecting. Fundamentally you need to fix that API either way.
The biggest mistake we made with DNS was the "shortcut" of implicitly adding the root domain to random strings treated as domain names (turning "example.com." into "example.com"). The file "foo.zip" and the website "foo.zip" wouldn't even be ambiguous if we called the website "foo.zip.". "ndots" also causes operators of DNS servers a lot of pain -- some malfunctioning program tries to resolve "example.invalid" in a tight loop and it balloons to asking for "example.invalid.", "example.invalid.local.", "example.invalid.cluster.local.", "example.invalid.svc.cluster.local.", and then DNS blows up, breaking everything.
Floor 13.
It's easy to say "we should never have" in retrospect. But you're basically accusing programmers back in the late 70s of having insufficient foresight to see problems that would make their decisions seem bad almost half a decade later.
We also should never have let companies sell cigarettes. Or burn fossil fuels. Or start social networks.
Having said that, though, we could at least wish that some variant of the Mac's old idea of separate creator and document codes stored as metadata had caught on. Sure, it'd have been a few more bytes per directory entry (to be specific, five more bytes!), but it was a lot more flexible -- and if more operating systems had been built with that "document types are metadata" idea, that metadata could have been replaced with MIME types later on, like it was on BeOS.
The URL standard was published in 1994.
Sure, in a vacuum you could read view my comment as meaning in all time, but given that the parent comment is discussing ICANN domains and my comment was relevant to that, I think it’s a little uncharitable to do so.
A simple workaround is to add a preceding space or something like inurl: but that's isn't an automatic behavior so whoever owns mlpdwarfporn.zip is getting a lot of unintentional hits.
For example, in firefox and chrome ctrl-l will clear the URL bar and put the cursor and focus there to take you to the location you enter, and ctrl-k will do similar but pre-fill the location bar with a preceding '?' so a search is triggered on the input.
These shortcuts have existed for quite a while. They used to just focus the respective separate input boxes, when it wasn't all done through one.
Typing `?bla.py` in the omnibar will perform a search for `bla.py` on both Firefox and Chrome
http//com.google.www.
vs
http//com.google.www./file.zip
2. also I think ! was used rather than . for some networks at some times. Certainly I’ve heard this anecdote from some early users of the internet (or maybe other computer networks)
3. Traditionally the dot is the zero-level or extra-top level domain, a bit like / for root in the Unix file system. Indeed if you use dig you may be familiar that it writes domains like “www.google.com.” My web browser only partly seems to accept this format.
https://en.wikipedia.org/wiki/UUCP#Bang_path
! was used for manual routing from the source to the destination, when messages were copied from server to server via UUCP. People would write paths like ...!ucbvax!deptserver!myname , which means "you probably know how to get messages to ucbvax; from there, here's how to reach me".
https://en.wikipedia.org/wiki/UUCP#/media/File:UUCP_Email_Ad...
So com.gmail/cydeweys maybe?
Or it could be just an object in a global namespace (accesses through a protocol specific facade). So com.gmail.cydeweys
com.gmail.cydeweys doesn't really work because you need some way to distinguish that as an email address and not just a subdomain on com.gmail. So it really does need a different delimiter, like how you need a different delimiter in URLs when it switches from the domain to the path (and then also to the querystring and fragment).
https://en.wikipedia.org/wiki/At_sign
It was used as 'at' in computing in Algol 68 where it was a shorthand for a keyword 'at'. It has a different application as 'at' in Dyalog APL.
https://com.google. for the main page
https://com.google.mail for gmail
https://com.google.mail/localpart for one's own gmail account
mail://com.gmail/localpart to send mail to what is currently [email protected]
Alternately, we could continue to use '@' and put the localpart first. The URL method of specifying a username or username and password does this for HTTP/HTTPS.
http://username:[email protected]/login
And currently we use mailto:[email protected] but we could use mailsend:[email protected] instead.
The other nice thing about this system, is that you can drop the domain when the communication is internal.
And if you really wanted to, you could force the communication protocol xmpp//com.twitter@dan vs smtp//com.twitter@dan
But I could _kinda_ of make an argument for it. When I open my browser, I want to go to "the homepage of the company running New Your Times, so [email protected] - or perhaps the menu from French Laundry - [email protected]
The browser actually handles it just fine, but some webservers refuse to handle it, despite it being a spec. Most famously Traefik and Caddy as webservers refuse to support these, just because their devs don’t understand the spec and think they know better (what a surprise, both are written in go after all)
This actually causes quite a bit of trouble when you have internal systems resolving pretty much everything as local domain first, and some external webservers don’t support the spec. Most famously, caddyserver.com. itself is broken
at that point i expected the story to go "and then they sued me for stealing their documents"
When I read reddit (before it jumped the shark imo) there was something similar in a non-tech way called /r/idontworkherelady
I switched to using subdomain.ourdomain.staging instead and got on with life. I wonder if anyone's gonna have to deal with the fallout of that decision when someone oneway pays ICANN enough money to own the .staging TLD?
(I wonder how much "interesting" stuff would land in your mail/web/ssh/whatever log files, if you registered .staging and .dev and just logged everything that came past (or intentionally/actively honey potted everything there?)
You could weaponise this the same way companies use defensive patents... "Sure, I opened one of your emails, but you've connected to my mail server without authorisation <checks logs> 27,943 time so far this month. Go on, lawyer up. Bring it on!"