and "emulat[ing] the entire system" could be detected, as extant emulators have their telltale signatures
This just suggests that the emulation isn't complete. I guarantee that at some point it will be possible to emulate every aspect of a PC today within software, at least as far as the software can tell. Any "telltale signatures" are just artifacts of the emulation that could, in theory, be fixed.
The worst case hurdle is a sound card that has some hardware-based crypto used by the firmware to ensure integrity, and used by the OS drivers to ensure firmware and hardware integrity. You'd have to emulate this (which means reverse-engineering it or somehow hooking that hardware into your emulation system). No system like this is truly unbeatable, at least from a technological perspective.
Re:For those who wonder why no/. cache...
on
HDD Assault Cannon
·
· Score: 1
Seriously, small sites like this are NOT going to get mad if you cache them temporarily.
Further, no one has the right to get mad so long as your cache obeys HTTP caching rules. If their site expresses a cache-control header indicating the page can be considered fresh for an hour, and Slashdot is sent through such a cache (a proxy with a mirror-like front-end), your site will see one hit an hour for the duration of the Slashdotting.
If the site expresses an unwillingness to be cached (such as a "no-cache" header), then the site owner deserves the Slashdotting he gets. Otherwise, why not take advantage of the caching rules HTTP defines? There's no rule that says your caching HTTP proxy can't expose its cached content through its own separate URI. It just has to play by the rules with respects to the HTTP caching policies expressed by the origin server.
Seriously, this is something that can be set up in 5 minutes with anyone moderately familiar with Apache, mod_cache and mod_proxy. A bit of evangelism would then be needed to ensure about-to-be-hit sites are using clueful caching headers (which they should be anyway). Otherwise there's no point.
The FAQ entry for this amounts to some handwaving and some vague points about how it might make people mad. Nevermind that HTTP defines how caching can/should work right in the basic protocol.
Re:Slashdotted? How about Cachedotted?
on
HDD Assault Cannon
·
· Score: 2
I've read the FAQ and I don't buy it. I believe it's mainly laziness preventing the implementation of some caching layer here, combined with the cost of bandwidth they'd normally be able to shovel in the direction of the site the article is talking about.
So long as the cache/mirror honors HTTP caching headers, there's no true problem caching the information. Banner ads are usually served without caching headers (or with a must-revalidate header) to trigger a hit to the origin server, so they get credit for the impression. Real content usually (if the admin is clueful) expresses caching headers indicating the page can be held on to for a longer period of time. If the author is paranoid about people seeing his updates, a max-age of 1 minute or even 10 seconds would still spare his site from being slashdotted. If a good slashdotting results in, say, 100 hits per second, that's at least 1000 hits to the cache/proxy for every one hit the cache/proxy makes to his server. Not a bad reduction.
Of course, sites are always free to say "don't cache this page!" in HTTP, preventing any sort of proxy or cache from "legally" caching the page even for a short duration. If they're being dumb like that, though, they deserve the slashdotting they get.
A permanent magnet contains stored energy from when the magnet was made. An electomagnet uses electricity on the fly.
You make it sound like permanent magnets are merely electromagnets with some sort of "magnetic energy" stored within it that is consumed as the field is "used".
A ferromagnetic field is merely a property of a material, it's not some sort of energetic force that depletes over time as you use it. This is also precisely why I believe this "motor" doesn't work as advertised. An electromagnetic field is a completely different beast. In the former, it's the spin of the electrons, and the odd number of electrons in the atom that give the atom a tiny magnetic field. (The atoms then occasionally align instead of cancel each other out to form a macroscopic field.) In the case of an electromagic, it's the electrical current that induces a magnetic field. Don't think of it as generator vs. motor, where one consumes power and the other provides it.
Why advocate a plain-text arbitrary (english) label at all? Why not use PICS labels for mass e-mail? If you're going to legislate labelling of some kind, at least do it in a flexible, extensible fashion.
Maybe I do want to receive sexually-explicit spam, just not too explicit. I'd like to tune my spam filters to suit that requirement, not along an arbitrary government-specified line.
I disagree, but you're focusing upon an example while ignoring the greater argument. DNS contact information has uses beyond Big Brother and spammers. What about e-mail service problems? What about a problem with a user identified by e-mail or DNS hostname and not IP address? Maybe the only connection I have with a problem is through the DNS hostname.
I would probably try both avenues. The DNS domain is probably going to represent organizational lines better, so I would attempt that first. If that failed, I would hunt through netblock allocations.
Both DNS domains and netblocks are normally made available through the same WHOIS services, though, and I think ICANN has the same contact policies for netblocks that it does for DNS domains.
What happens when a host or a user on your network starts spewing forth harmful data (say, a DDoS attack)?
If it takes me a week to wind my way through the legal system because you chose to make it difficult for me to contact you, you can bet that I'm holding you partially responsible for the damages that extra week caused.
WHOIS contact information isn't about documenting your name and address for Big Brother, it's about being a responsible Internet organization. No one is twisting your arm and saying you have to have an Interweb presence with a.com DNS domain, but if you feel that it's necessary to have a presence that high in the DNS tree, someone needs to be reachable in the event you have a problem. The only one higher in the DNS hierarchy is the "com" domain, and I doubt ICANN or a gTLD registrar is going to take my calls about one of your users.
If nothing else, at least use the contact information of an agent (lawyer) or a proxy service (like Domains By Proxy), so that at least we have some path to get ahold of you if we need to.
This isn't about making ownership and contact information available to "the authorities". It's about being a good Internet entity and making yourself reachable when problems on your network arise. These could be connectivity problems, configuration problems (maybe your mail server is rejecting all mail) or abuse problems, where a DDoS drone on your network is causing problems elsewhere.
The rest of us hurt when your DNS domain information is bad. It's not about turning the domain owner in for kiddie porn found on his Interweb site, it's about being responsible. If you want to register a second-level.com, you need to provide contact information like every other.com. That doesn't have to be you, but it has to be someone that can take ownership of the problem (and call you privately if necessary).
That's not going to cut it. What happens when a user or a host on your network is flooding my own with virus traffic or a DDoS? What am I going to do here, subpoena the registrar to get your contact information? That's not going to work. This is not the Interweb. Web sites are not the sole use of DNS domains, they are one service running on one DNS host under a DNS domain.
If you are going to request resources as high as you possibly can in the DNS or network block heirarchy, you must provide contact information so that you can answer to problems that your network is causing. You can't funnel this through the legal system.
You have a couple of alternatives:
Get a DNS domain three or more levels down the DNS hierarchy and provide that entity with your contact information. They can be the ones woken up in the middle of the night when your DDoS-infected PC starts causing problems for someone else.
Register your DNS domain through a proxy service. They end up being the contact similar to #1, but you get a shiny second-level domain under a gTLD!
Why do you feel it's necessary to register a DNS domain under a gTLD? That's your decision, and with that decision comes an obligation to provide contact information for activity that occurs under that DNS domain. Just because you're on the Interweb and not the Internet like the rest of us doesn't exempt you from the rules.
Your registrar isn't going to accept calls in the middle of the night because your PC is infected with a virus or DDoS agent and is saturating my network with traffic. That's not their job. Either publish contact information or get your DNS domain and/or network addresses from a provider that will publish their own information on your behalf.
Absolutely, but this really only applies to the administrative contact for a DNS domain. There may be technical issues that need immediate technical action to resolve (abuse, protocol violations, other network problems). WHOIS typically provides different types of contact fields, and each one is useful in its own way.
Of course, that technical contact doesn't need to be the end user either. You can have a registered agent acting as an administrative contact, and your IT guy or Internet provider acting as your technical contact. One might suggest that this is actually a best practice.
That's great except for the fact that my domain and the WHOIS information associated with it has nothing to do with "my network."
Why not? Your DNS domain should be the naming root for the hosts on the Internet under your control.
If you choose to instead use your DNS domain for your interweb site address, that doesn't exempt you from the rules. There's nothing out there that says you need your own second-level DNS domain for every service "your network" provides, and in fact, there's a mountain of technical literature saying exactly the opposite.
Your organization should get its own DNS domain for its hosts. Nobody is forcing you to make that domain a second-level dot-com.
Somehow the public needs to have a number handy in case a host or user on your DNS domain is causing problems. That doesn't necessarily have to be you, but it needs to be somebody. If you choose to register a DNS domain under a gTLD, then you choose to publish contact information like a responsible Internet entity.
There's nothing saying somebody else can't register on your behalf, and there's nothing saying you can't obtain a DNS domain under someone else's allocation. In both of these situations it would be perfectly acceptable for the person you obtained that resource from to continue to act as the technical contact. But if you go above a typical provider's head and get DNS or network resources directly from a registrar or coordinator and nobody else is stepping up to handle calls on your behalf, you need to deal with it yourself.
I don't think this is very practical. How do you define who the "good guys" are? How do you keep the information away from the "bad guys"?
Every Joe in the country does not need his own second-level DNS domain. For those that believe they have a solid reason to have their DNS domain parented that far up the DNS hierarchy, they need to be aware that public registration is a requirement for that.
I don't really see a problem with that, especially for domains like ".com", which are meant to be commercial.
Now, for the new TLDs like ".name", I might see a case where DNS registration might not need to be accompanied with a publicly-visible registration, but for the rest, why not? It helps everyone identify who's responsible for a domain so that problem and abuse reports get handled in an efficient manner.
If we pull domain contact information from the public, someone still needs to be an effective first line for abuse and problem reports. If someone has a misconfiguration or malicious user that's impacting my network, I'd better damn well have a number I can call to get that issue resolved. If I can't get that in the WHOIS database, I'd better be able to call someone who can obtain it on my behalf.
I guess for me, it boils down to having responsible contact information available for every netblock and DNS domain that's registered. This doesn't necessarily need to be the end user (and in the case of third-level DNS domains or a customer's small netblock, it isn't even today), but if users are going to register assets high enough in the "tree" (second-level DNS domains and large IP netblocks), they need to accept the responsibility of keeping valid contact information available to the public, because nobody else is going to do it for them. You're free to sub-delegate those resources (third and fourth-level DNS domains or smaller blocks of IP addresses, for example), making you the contact for those end users, or if you choose to require their contact information be publicly available, they would be. It's just gotta be someone. The gTLD registrars I don't think are staffed to be that someone.
This is something that kind of ticks me off. Different operating systems have different conventions for what a "new line" is. That, of course, is why FTP has its two modes: binary and ASCII. The client is responsible for determining what type of newlines the server has, and converting those to native newlines if necessary.
Everybody knows about this problem. We've known about it for decades. So why is this still such a pain in the ass? I forget putting FTP in binary mode just as much as the next guy, but if I'm transferring a text file, it'd probably tick me off just as much to have it default to binary (where I forget to change it to ascii), since my text file is almost unusable.
(Arguably an almost unusable text file is better than a completely unusable binary one, however.)
HTTP and HTML made this worse. MIME says text/* content types must use normalized "network" newlines (CRLF). Every piece of text transferred with a text MIME type should undergo this transformation, and MIME clients should understand that they need to convert from network newlines to native newlines when working with the text. Then HTTP and HTML came along, and they said, "but that's going to be too hard!" and effectively said that any HTTP client should accept any type of newline, and HTTP servers shouldn't care what type of newlines are in their text.
As a result, when someone sends me a piece of text that originates from Unix, no matter what protocol they used to retrieve it, there's at least a 50% chance that the newlines will be wrong and I'll have to convert it.
I think everyone agrees that obtaining a machine-readable list of content (e.g. a list of files in a directory) over HTTP is painful. As another poster pointed out, however, the WebDAV extensions correct this deficiency and do indeed provide a simple, extensible mechanism to view the contents "behind" a typical filesystem-based HTTP server as well as allow for an easier mechanism for changing it.
HTTP auth is an afterthough tacked on to webbrowsers. It works quite poorly on the user's end, and there are no HTTP clients that work anywhere near as well as FTP client.
I'm not sure I follow this. Your "standard" HTTP and FTP authentication is effectively identical. Both protocols indicate a username and a password is required for entry. FTP does this by prompting for a username and then prompting for a password. HTTP does it by indicating "basic" HTTP authentication is required. The HTTP client does the rest.
Both FTP and HTTP clients end up giving you a prompt for a username and a password. I'm not following when you say that HTTP clients implement this poorly in comparison to FTP.
Not to mention that there's no real way to tell a browser you want to upload a file to an HTTP server.
A browser isn't a composer. A browser is there to retrieve content. Most browsers today allow for FTP and HTTP content retrieval through effectively the same interface.
A more fully-featured FTP suite would certainly allow users to send files to an FTP server, just as a more fully-featured HTTP suite tends to have a composer application designed to "PUT" a file over HTTP.
I do wholeheartedly agree with you, however, that setting up an HTTP server to handle this is an order of magnitude more difficult than an FTP server, but I'm not convinced yet that this is an unsolvable problem.
More often than not, people use FTP to update an HTTP server's document root, so there's no huge push to make this feature core or easy to use in most HTTP server platforms.
The HTTP error system is more for human interpretation, and doesn't do so well when you have a program try to understand them, and what to do about them. HTTP error messages are quite strange things, designed to work well in a web browser, and that's all. FTP error messages are quite a lot simpler, for both the program handling them, and the end user reading them.
I have to side with the original poster here. HTTP error messages are functionally identical to their FTP counterparts. They are numeric messages that mean something very specific. Usually these numeric messages are accompanied with a textual description. In the HTTP case, these numeric messages and textual descriptions can also be accompanied by an HTTP message body, usually in the form of an HTML document that is considerably more verbose about the problem.
But at the root of it all is an HTTP response code, just as in the case of FTP.
Also, how would your HTTP server be able to communicate a login message, or folder message like those on FTP servers?
Different conventions for different technologies. In HTTP, you don't "change directories" so much as you request a directory index directly. There's no state to remember here. In theory, a request for a directory index SHOULD (in a better HTTP world) result in a nice machine-readable directory listing, likely in combination with some "folder message" as you describe.
Arguably, when you request a directory index today, what you're getting is the "folder message". You just don't get a machine-readable directory index with it.
The only solution to this appears to be structural separation
I agree, and personally would like to see this even for telcos. The company owning the physical lines would be run more like a public utility.
The only problem with the approach that I can see is the probability that this utility will have no incentive to run in anything but a maintenance mode. They're not going to roll fiber out to every home, for example. What would be the point? They can't actually sell a service over it.
I'm not sure I agree with any of the situations where an incumbent carrier of any kind was required to give competitors access to its infrastructure. Yah, it's sucky that no competitor can afford to build out what the incumbent has already built, but is that really the community's problem? The incumbent carrier's? The FCC and/or legislatures say it is, but I'm not convinced yet.
Re:Where have we heard this before
on
ICANN Meets Annan
·
· Score: 1
Thanks for posting that, as I wasn't aware of this history. Either way, this is something the ICANN inherited. It's somewhat difficult to change the name of a country's TLD that's in widespread use, so I don't fault them for perpetuating it.
Prior to the breakup, at least for home users, there was no such thing as "your equipment". The phone company owned all of the infrastructure, the wiring and equipment. If there was a problem, they were right on top of it. 411 was free.
I'm not saying the breakup didn't create some positive things. The competition for service has certainly pushed companies to lower costs and provide customers with a bargain. The loss, of course, was service. In order to truly compete, they now had to stop raw research, trim unprofitable activities (giving away their equipment to customers and ending all technical support beyond the line to your house), and concentrate on bringing the technology they had to customers at a price that could compete with others.
How many technological advances have been made in telecommunications infrastructure since the breakup? DSL? How many were made in the years before?
But again, I'm not necessarily saying either way was bad. It's certainly a trade-off. With the old way, high rates paid for stellar service and a major research investment. Today, we have competition, more jobs, low rates, but poor service and virtually no new research.
Re:Where have we heard this before
on
ICANN Meets Annan
·
· Score: 2, Informative
The rightful code for Britain should be GB. But the British snatched UK, which should have gone to Ukraine.
To be fair, these codes are defined by ISO at a level that has nothing to do with the Internet. DNS merely exposes those country codes in the DNS for use by those ISO-defined entities.
This can actually be a good thing
on
ICANN Meets Annan
·
· Score: 1, Troll
I can think of no better way of hastening the demise of DNS than by turning it into a truly political asset. Once technical control and guidance over DNS is turned over to governments already keen to warp it for commercial interests, what remains of its technical usefulness will dwindle.
This gives us the perfect opportunity (and finally incentive) to come up with something better.
Slashdot Mirror
and "emulat[ing] the entire system" could be detected, as extant emulators have their telltale signatures
This just suggests that the emulation isn't complete. I guarantee that at some point it will be possible to emulate every aspect of a PC today within software, at least as far as the software can tell. Any "telltale signatures" are just artifacts of the emulation that could, in theory, be fixed.
The worst case hurdle is a sound card that has some hardware-based crypto used by the firmware to ensure integrity, and used by the OS drivers to ensure firmware and hardware integrity. You'd have to emulate this (which means reverse-engineering it or somehow hooking that hardware into your emulation system). No system like this is truly unbeatable, at least from a technological perspective.
Seriously, small sites like this are NOT going to get mad if you cache them temporarily.
Further, no one has the right to get mad so long as your cache obeys HTTP caching rules. If their site expresses a cache-control header indicating the page can be considered fresh for an hour, and Slashdot is sent through such a cache (a proxy with a mirror-like front-end), your site will see one hit an hour for the duration of the Slashdotting.
If the site expresses an unwillingness to be cached (such as a "no-cache" header), then the site owner deserves the Slashdotting he gets. Otherwise, why not take advantage of the caching rules HTTP defines? There's no rule that says your caching HTTP proxy can't expose its cached content through its own separate URI. It just has to play by the rules with respects to the HTTP caching policies expressed by the origin server.
Seriously, this is something that can be set up in 5 minutes with anyone moderately familiar with Apache, mod_cache and mod_proxy. A bit of evangelism would then be needed to ensure about-to-be-hit sites are using clueful caching headers (which they should be anyway). Otherwise there's no point.
The FAQ entry for this amounts to some handwaving and some vague points about how it might make people mad. Nevermind that HTTP defines how caching can/should work right in the basic protocol.
See my other response to a similar comment for details.
I've read the FAQ and I don't buy it. I believe it's mainly laziness preventing the implementation of some caching layer here, combined with the cost of bandwidth they'd normally be able to shovel in the direction of the site the article is talking about.
So long as the cache/mirror honors HTTP caching headers, there's no true problem caching the information. Banner ads are usually served without caching headers (or with a must-revalidate header) to trigger a hit to the origin server, so they get credit for the impression. Real content usually (if the admin is clueful) expresses caching headers indicating the page can be held on to for a longer period of time. If the author is paranoid about people seeing his updates, a max-age of 1 minute or even 10 seconds would still spare his site from being slashdotted. If a good slashdotting results in, say, 100 hits per second, that's at least 1000 hits to the cache/proxy for every one hit the cache/proxy makes to his server. Not a bad reduction.
Of course, sites are always free to say "don't cache this page!" in HTTP, preventing any sort of proxy or cache from "legally" caching the page even for a short duration. If they're being dumb like that, though, they deserve the slashdotting they get.
A permanent magnet contains stored energy from when the magnet was made. An electomagnet uses electricity on the fly.
You make it sound like permanent magnets are merely electromagnets with some sort of "magnetic energy" stored within it that is consumed as the field is "used".
A ferromagnetic field is merely a property of a material, it's not some sort of energetic force that depletes over time as you use it. This is also precisely why I believe this "motor" doesn't work as advertised. An electromagnetic field is a completely different beast. In the former, it's the spin of the electrons, and the odd number of electrons in the atom that give the atom a tiny magnetic field. (The atoms then occasionally align instead of cancel each other out to form a macroscopic field.) In the case of an electromagic, it's the electrical current that induces a magnetic field. Don't think of it as generator vs. motor, where one consumes power and the other provides it.
It's not violating any laws of thermodynamics, it's violating the law of conservation of energy. ...which is the first law of thermodynamics.
Why advocate a plain-text arbitrary (english) label at all? Why not use PICS labels for mass e-mail? If you're going to legislate labelling of some kind, at least do it in a flexible, extensible fashion.
Maybe I do want to receive sexually-explicit spam, just not too explicit. I'd like to tune my spam filters to suit that requirement, not along an arbitrary government-specified line.
If anything, I'd say that validates Linux's usefullness.
No disrespect, but there's a logic error here. Just because people trust it more does not necessarily mean it's more trustworthy.
I personally agree with what you're getting at, but we shouldn't make statements like this.
Is this a troll? The Internet is not the web. Web sites are network hosts like any other.
I disagree, but you're focusing upon an example while ignoring the greater argument. DNS contact information has uses beyond Big Brother and spammers. What about e-mail service problems? What about a problem with a user identified by e-mail or DNS hostname and not IP address? Maybe the only connection I have with a problem is through the DNS hostname.
I would probably try both avenues. The DNS domain is probably going to represent organizational lines better, so I would attempt that first. If that failed, I would hunt through netblock allocations.
Both DNS domains and netblocks are normally made available through the same WHOIS services, though, and I think ICANN has the same contact policies for netblocks that it does for DNS domains.
What happens when a host or a user on your network starts spewing forth harmful data (say, a DDoS attack)?
.com DNS domain, but if you feel that it's necessary to have a presence that high in the DNS tree, someone needs to be reachable in the event you have a problem. The only one higher in the DNS hierarchy is the "com" domain, and I doubt ICANN or a gTLD registrar is going to take my calls about one of your users.
If it takes me a week to wind my way through the legal system because you chose to make it difficult for me to contact you, you can bet that I'm holding you partially responsible for the damages that extra week caused.
WHOIS contact information isn't about documenting your name and address for Big Brother, it's about being a responsible Internet organization. No one is twisting your arm and saying you have to have an Interweb presence with a
If nothing else, at least use the contact information of an agent (lawyer) or a proxy service (like Domains By Proxy), so that at least we have some path to get ahold of you if we need to.
This isn't about making ownership and contact information available to "the authorities". It's about being a good Internet entity and making yourself reachable when problems on your network arise. These could be connectivity problems, configuration problems (maybe your mail server is rejecting all mail) or abuse problems, where a DDoS drone on your network is causing problems elsewhere.
.com, you need to provide contact information like every other .com. That doesn't have to be you, but it has to be someone that can take ownership of the problem (and call you privately if necessary).
The rest of us hurt when your DNS domain information is bad. It's not about turning the domain owner in for kiddie porn found on his Interweb site, it's about being responsible. If you want to register a second-level
That's not going to cut it. What happens when a user or a host on your network is flooding my own with virus traffic or a DDoS? What am I going to do here, subpoena the registrar to get your contact information? That's not going to work. This is not the Interweb. Web sites are not the sole use of DNS domains, they are one service running on one DNS host under a DNS domain.
If you are going to request resources as high as you possibly can in the DNS or network block heirarchy, you must provide contact information so that you can answer to problems that your network is causing. You can't funnel this through the legal system.
You have a couple of alternatives:
Why do you feel it's necessary to register a DNS domain under a gTLD? That's your decision, and with that decision comes an obligation to provide contact information for activity that occurs under that DNS domain. Just because you're on the Interweb and not the Internet like the rest of us doesn't exempt you from the rules.
Your registrar isn't going to accept calls in the middle of the night because your PC is infected with a virus or DDoS agent and is saturating my network with traffic. That's not their job. Either publish contact information or get your DNS domain and/or network addresses from a provider that will publish their own information on your behalf.
Absolutely, but this really only applies to the administrative contact for a DNS domain. There may be technical issues that need immediate technical action to resolve (abuse, protocol violations, other network problems). WHOIS typically provides different types of contact fields, and each one is useful in its own way.
Of course, that technical contact doesn't need to be the end user either. You can have a registered agent acting as an administrative contact, and your IT guy or Internet provider acting as your technical contact. One might suggest that this is actually a best practice.
That's great except for the fact that my domain and the WHOIS information associated with it has nothing to do with "my network."
Why not? Your DNS domain should be the naming root for the hosts on the Internet under your control.
If you choose to instead use your DNS domain for your interweb site address, that doesn't exempt you from the rules. There's nothing out there that says you need your own second-level DNS domain for every service "your network" provides, and in fact, there's a mountain of technical literature saying exactly the opposite.
Your organization should get its own DNS domain for its hosts. Nobody is forcing you to make that domain a second-level dot-com.
Somehow the public needs to have a number handy in case a host or user on your DNS domain is causing problems. That doesn't necessarily have to be you, but it needs to be somebody. If you choose to register a DNS domain under a gTLD, then you choose to publish contact information like a responsible Internet entity.
There's nothing saying somebody else can't register on your behalf, and there's nothing saying you can't obtain a DNS domain under someone else's allocation. In both of these situations it would be perfectly acceptable for the person you obtained that resource from to continue to act as the technical contact. But if you go above a typical provider's head and get DNS or network resources directly from a registrar or coordinator and nobody else is stepping up to handle calls on your behalf, you need to deal with it yourself.
I don't think this is very practical. How do you define who the "good guys" are? How do you keep the information away from the "bad guys"?
Every Joe in the country does not need his own second-level DNS domain. For those that believe they have a solid reason to have their DNS domain parented that far up the DNS hierarchy, they need to be aware that public registration is a requirement for that.
I don't really see a problem with that, especially for domains like ".com", which are meant to be commercial.
Now, for the new TLDs like ".name", I might see a case where DNS registration might not need to be accompanied with a publicly-visible registration, but for the rest, why not? It helps everyone identify who's responsible for a domain so that problem and abuse reports get handled in an efficient manner.
If we pull domain contact information from the public, someone still needs to be an effective first line for abuse and problem reports. If someone has a misconfiguration or malicious user that's impacting my network, I'd better damn well have a number I can call to get that issue resolved. If I can't get that in the WHOIS database, I'd better be able to call someone who can obtain it on my behalf.
I guess for me, it boils down to having responsible contact information available for every netblock and DNS domain that's registered. This doesn't necessarily need to be the end user (and in the case of third-level DNS domains or a customer's small netblock, it isn't even today), but if users are going to register assets high enough in the "tree" (second-level DNS domains and large IP netblocks), they need to accept the responsibility of keeping valid contact information available to the public, because nobody else is going to do it for them. You're free to sub-delegate those resources (third and fourth-level DNS domains or smaller blocks of IP addresses, for example), making you the contact for those end users, or if you choose to require their contact information be publicly available, they would be. It's just gotta be someone. The gTLD registrars I don't think are staffed to be that someone.
My two cents.
This is something that kind of ticks me off. Different operating systems have different conventions for what a "new line" is. That, of course, is why FTP has its two modes: binary and ASCII. The client is responsible for determining what type of newlines the server has, and converting those to native newlines if necessary.
Everybody knows about this problem. We've known about it for decades. So why is this still such a pain in the ass? I forget putting FTP in binary mode just as much as the next guy, but if I'm transferring a text file, it'd probably tick me off just as much to have it default to binary (where I forget to change it to ascii), since my text file is almost unusable.
(Arguably an almost unusable text file is better than a completely unusable binary one, however.)
HTTP and HTML made this worse. MIME says text/* content types must use normalized "network" newlines (CRLF). Every piece of text transferred with a text MIME type should undergo this transformation, and MIME clients should understand that they need to convert from network newlines to native newlines when working with the text. Then HTTP and HTML came along, and they said, "but that's going to be too hard!" and effectively said that any HTTP client should accept any type of newline, and HTTP servers shouldn't care what type of newlines are in their text.
As a result, when someone sends me a piece of text that originates from Unix, no matter what protocol they used to retrieve it, there's at least a 50% chance that the newlines will be wrong and I'll have to convert it.
This is stupid.
I think everyone agrees that obtaining a machine-readable list of content (e.g. a list of files in a directory) over HTTP is painful. As another poster pointed out, however, the WebDAV extensions correct this deficiency and do indeed provide a simple, extensible mechanism to view the contents "behind" a typical filesystem-based HTTP server as well as allow for an easier mechanism for changing it.
HTTP auth is an afterthough tacked on to webbrowsers. It works quite poorly on the user's end, and there are no HTTP clients that work anywhere near as well as FTP client.
I'm not sure I follow this. Your "standard" HTTP and FTP authentication is effectively identical. Both protocols indicate a username and a password is required for entry. FTP does this by prompting for a username and then prompting for a password. HTTP does it by indicating "basic" HTTP authentication is required. The HTTP client does the rest.
Both FTP and HTTP clients end up giving you a prompt for a username and a password. I'm not following when you say that HTTP clients implement this poorly in comparison to FTP.
Not to mention that there's no real way to tell a browser you want to upload a file to an HTTP server.
A browser isn't a composer. A browser is there to retrieve content. Most browsers today allow for FTP and HTTP content retrieval through effectively the same interface.
A more fully-featured FTP suite would certainly allow users to send files to an FTP server, just as a more fully-featured HTTP suite tends to have a composer application designed to "PUT" a file over HTTP.
I do wholeheartedly agree with you, however, that setting up an HTTP server to handle this is an order of magnitude more difficult than an FTP server, but I'm not convinced yet that this is an unsolvable problem.
More often than not, people use FTP to update an HTTP server's document root, so there's no huge push to make this feature core or easy to use in most HTTP server platforms.
The HTTP error system is more for human interpretation, and doesn't do so well when you have a program try to understand them, and what to do about them. HTTP error messages are quite strange things, designed to work well in a web browser, and that's all. FTP error messages are quite a lot simpler, for both the program handling them, and the end user reading them.
I have to side with the original poster here. HTTP error messages are functionally identical to their FTP counterparts. They are numeric messages that mean something very specific. Usually these numeric messages are accompanied with a textual description. In the HTTP case, these numeric messages and textual descriptions can also be accompanied by an HTTP message body, usually in the form of an HTML document that is considerably more verbose about the problem.
But at the root of it all is an HTTP response code, just as in the case of FTP.
Also, how would your HTTP server be able to communicate a login message, or folder message like those on FTP servers?
Different conventions for different technologies. In HTTP, you don't "change directories" so much as you request a directory index directly. There's no state to remember here. In theory, a request for a directory index SHOULD (in a better HTTP world) result in a nice machine-readable directory listing, likely in combination with some "folder message" as you describe.
Arguably, when you request a directory index today, what you're getting is the "folder message". You just don't get a machine-readable directory index with it.
The only solution to this appears to be structural separation
I agree, and personally would like to see this even for telcos. The company owning the physical lines would be run more like a public utility.
The only problem with the approach that I can see is the probability that this utility will have no incentive to run in anything but a maintenance mode. They're not going to roll fiber out to every home, for example. What would be the point? They can't actually sell a service over it.
I'm not sure I agree with any of the situations where an incumbent carrier of any kind was required to give competitors access to its infrastructure. Yah, it's sucky that no competitor can afford to build out what the incumbent has already built, but is that really the community's problem? The incumbent carrier's? The FCC and/or legislatures say it is, but I'm not convinced yet.
Thanks for posting that, as I wasn't aware of this history. Either way, this is something the ICANN inherited. It's somewhat difficult to change the name of a country's TLD that's in widespread use, so I don't fault them for perpetuating it.
Prior to the breakup, at least for home users, there was no such thing as "your equipment". The phone company owned all of the infrastructure, the wiring and equipment. If there was a problem, they were right on top of it. 411 was free.
I'm not saying the breakup didn't create some positive things. The competition for service has certainly pushed companies to lower costs and provide customers with a bargain. The loss, of course, was service. In order to truly compete, they now had to stop raw research, trim unprofitable activities (giving away their equipment to customers and ending all technical support beyond the line to your house), and concentrate on bringing the technology they had to customers at a price that could compete with others.
How many technological advances have been made in telecommunications infrastructure since the breakup? DSL? How many were made in the years before?
But again, I'm not necessarily saying either way was bad. It's certainly a trade-off. With the old way, high rates paid for stellar service and a major research investment. Today, we have competition, more jobs, low rates, but poor service and virtually no new research.
The rightful code for Britain should be GB. But the British snatched UK, which should have gone to Ukraine.
To be fair, these codes are defined by ISO at a level that has nothing to do with the Internet. DNS merely exposes those country codes in the DNS for use by those ISO-defined entities.
I can think of no better way of hastening the demise of DNS than by turning it into a truly political asset. Once technical control and guidance over DNS is turned over to governments already keen to warp it for commercial interests, what remains of its technical usefulness will dwindle.
This gives us the perfect opportunity (and finally incentive) to come up with something better.