MMDS has one serious problem that Sprint has been unable to solve. It's really expensive. In order to get themselves into the black they have to either oversubscribe like crazy or charge a lot for the service. The cost will fall over time (that much is inevitable) but right now I personally don't think it's an economically viable product.
Earthlink is using a system developed by Broadlink which uses 802.11b. We will evaluate 802.11a once quality parts are available.
(note: I work for broadlink but I'm a programmer not PR so please consider anything I say as unofficial)
I've been thinking lately about massive video storage for entirely different purposes.
Lets suppose you have a TiVo with broadband internet access (DSL/Cable/Fixed Wireless, whatever).
You want to watch something that aired yesterday. You did not tell your Tivo to record it. Instead, you request the show through your broadband internet connection. It streams to your Tivo in the background (doesn't matter if it's slower than real-time, the Tivo has become a streaming video cache).
Now consider the storage and bandwidth requirements for the back-end of this 'service'. You would need incoming feeds from every supported channel. To leave room for expansion we'll call it 1000 channels. If you're clever with your algorithms you wouldn't need to re-capture reruns (you would need to properly handle commercials which would significantly increase the overall complexity of the problem). So each unique 'episode' is stored, then each scheduled viewing indexes the locations of commericals as well as which commercials to insert. A little complex but I would estimate 80%+ of what is broadcast is rerun material. That reduces the number of effective 'new' material to 200 channels.
In a perfect world we'd store the complete history of television. But if we just stored the last week it would still be a great feature. So 200 channels of mpeg2, 24 hours a day for 7 days. 33,600 hours of video. It will be randomly accessed by N simultanious customers (where N should be as large as economically possible) which effectivly cancels out the option of using tape.
(warning: shameless abuse of Moores Law follows)
100 GB ~= 30 hours, so we'd need 112 TB of storage (ouch!) for one week. Scarry stuff huh? If hard drives continue to improve at current rates, we can reasonably expect to have 1 TB consumer level drives in three or four years. We can also reasonably expect gig ether in the server farm, 5-10Ghz processing with 3-6GB of RAM and 20-50Mbit consumer broadband transfer speeds. Our 112 TB isn't nearly so difficult in that environment. With a farm of 256 boxes with 8 consumer level 1TB drives each we'd have 2048TB or 18 weeks of programming. Of course we'd want to have hdtv resolutions in that timeframe...
So my question: Is this reasonable? In five years will we be able to randomly access television?
Recently (well, over the last few months) the 802.11b WEP encryption suite has been shattered. But most folks don't seem to understand the role of encryption (particularly radio encryption) in the overall scheme of things.
Lets compare two situations. One is a guy on a dialup through AOL who has his email client configured to poll for his office email every 10 minutes over pop3.
Next is a lady that happens to live across the street from her office. She uses an 802.11b PCMCIA radio card and a small antenna. She also polls for her email every 10 minutes using pop3.
All the security minded folks around here will agree that both of these people are begging to get themselves hacked.
The guy on the dialup is sending packets "in the clear" to AOL. Those clear packets hop through the internet until they reach the guys office. Any server along that path (which could easily be 10-15 or more hops) could be hacked and those clear packets could be sniffed. Any of the routing tables along the way could be corrupted with false data redirecting those pop3 reqests to an arbitrary IP. And thanks to god-knows-who, pop3 includes a clear-text username and password.
In the case of our lady friend, anyone with the proper equiptment could camp out within a few thousand feet of her house and sniff out the same information. Such an attack would be effectivly impossible to detect or backtrace. If the radio link is WEP encrypted, they will have to sit long enough to gather a chunk of data, how long varies (2-12 hours?) but that's not nearly long enough to matter.
Snagging either password is non-trivial. Which is 'easier' depends on the attacker. If you live in the same city a radio link is a real invite. But if you can't get physically close, you're not going to be able to sniff into the pop session. Our gentleman friend isn't so lucky. Anyone in the world can (try to) hack him. Are you worried about your neighbors or the script-kiddies continents away?
Security is sort of a non-issue in a community network. It's like everyone in the area is plugged into a big hub. If you want to keep them out of your traffic, you have to use your own endpoint-to-endpoint encryption.
It all comes down to scalability. Lets suppose you covered a small town with a mesh of roof-top radio AP's. Since you're probably interested in getting out to the internet you'll need some kind soul to forward your traffic.
Therein lies problem number one. Who foots the bill for the bytes?
Lets assume you can find enough people willing to contribute bandwidth for the good of the community or charge a small amount every month to maintain a dedicated line.
Now you'll note that the closer you are to the internet uplink the faster your connection is going to be (fewer hops). Anyone on the fringes of such a network is going to have to hop-hop-hop their way to the uplink. This is bad for the fringes. People right next to the uplink might _think_ they have it made, but then you remember.. everyone further away from the uplink than you is going to be hopping through you.
So, lets assume you figure out a static routing method that takes advantage of all available radio channels, avoids massive short hops and avoids overloading the AP's nearest to the uplink.
Plunk, someone between you and the uplink flips the wrong breaker and powers down their AP. Goodbye static routing. Clearly not an appropriate choice in this environment. Lets try to create a dynamic routing system for hundreds of nodes none of which have global visibility and none of which can be a point of failure. We'll need to ensure that AP's can be added and removed anywhere on the mesh at any time.
After all that, how much 'free' bandwidth will your 200-300$ AP investment give you? Enough to compete with dial-up modems. Maybe.
It's not all dark and grim. 802.11a is right around the corner and it's five times faster than 802.11b. It's probably reasonable to assume that 802.11* types of radio systems will only get faster over the next half-dozen years.
----------
I should mention that I work for a company that develops high-speed radio networks. Rooftop mesh might be the future, but it sure ain't the present.
Hence the "for handhelds", I'm not giving up my keyboard anytime soon for exactly the reasons you've described. At the desktop it would still be nice for mouse control, and there are a few gestures that can be make without moving your fingers from the keyboard that might be really useful. (point toward the escape key with your 'j' finger and hold that gesture for a moment to go 'back' in your browser, point toward the backspace with your 'f' finger (hehe) to go forward, press non-existant buttons below your space bar to scroll down, add non-existant buttons above your F-row with assigned macros..
There are clearly tons of ways in which this kind of technology can augment a traditional keyboard.
You could just as easily add virtual-buttons to your monitor, your desk, whatever is within the sensitivity of the hardware.
As far as direct operation of a device with gestures, it's quite possible that a computer is (in it's current form) too complex a device. But it sure would be easy to work out the necessary gestures to comfortably operate a TV, VCR and/or Tivo.
Think about it. You have these sensors in each of your fingertips and any flat surface becomes an instant full-size keyboard.
It also one-ups the mouse-keyboard combination, no more mouse/touchpad. Just lift your forefinger off the virtual keyboard and move the mouse pointer by pointing at the screen. Your fingers never have to leave the home-row.
For those that can't touch-type, unroll a cheat-sheet and type on it.
Your analogy would make sense if she found her way to the party by following signs for "Brittney Spears Party" along with a bunch of other kids who followed signs to "Backstret Boys Party" and "Madona Party"; upon arrival was presented with pornography and when she flags a taxi in an attempt to return home, the driver circles around the block and kicks her back to the 'party'.
What is the fundamental difference between a person intentionally creating a javascripted page that 'traps' a browser and an annoying but relativly benign 'traditional' trojan horse bomb (ala: cookie monster)?
In both case:
1) you download something from the net which advertises itself as being desirable.
2) when that download is processed/executed the results of execution are not the desired or advertised results.
In addition:
Removal of the downloaded item generally requires the end-user to take an undesirable action. (popups require you to exit the browser, trojan bombs often require extensive cleanup).
I would be the first to admit that popup traps are not as directly harmful (in general) as a traditional trojan. But that is only a difference in degree. There are trojans which have equally minor effects.
Should the method used to spread and execute malicious code matter? I would think a popup trap would be viewed as much worse than most trojan horse efforts since the effects are cross-platform. Even worse, the author must be making some serious $$ off our annoyance. How many of our CPU cycles have been wasted by this loser?
It comes down to speed vs. privacy. You can ignore WEP and use IPsec or a VPN. You'll take a speed hit, but you'll have reasonable privacy.
If you don't mind exchanging some privacy for additional speed, 128 bit WEP isn't a bad choice. It hasn't lived up to it's "Wired Equivalent" name but sniffing and decrypting is a non-trivial operation.
For more speed with minimal privacy, 80 bit WEP doesn't cost much bandwidth (2%) and you're still only going to be sniffed and decrypted by folks with a clue.
In some situations, speed is most important and privacy is meaningless. Suppose you're downloading Debian ISO's over a wireless link. There are times (one might argue the majority of internet traffic) when privacy just doesn't matter. If you can use reliable encrypted protocols for the exceptions then open mode 802.11b is fine. What are you trying to hide?
As long as we're able to encrypt those transactions that require privacy none of the WEP "stuff" matters. How secure is your wired network internet traffic after it gets to your ISP?
20 miles point-to-point or point-to-multipoint? Fixed or roaming? 128Kbps, 5mbps, faster? And budget.. can you spend $$ for MMDS freqency space? And location, do you have line-of-sight?
There are a lot of highly relevant variables. MMDS is the 'easy' answer, that's the route sprint broadband has taken (20 miles is still a bit of a long run).
That's a problem of publicity. Bluetooth has at least as many security problems as 802.11b (http://www.mcommercetimes.com/Technology/41). More importantly now that the errors in the design of WEP have been uncovered measures are being taken to properly secure the protocol (noteably Cisco with LEAP in the BR350 assigning a unique expiring key to each node). Can this also be cracked? Sure. Is it less secure than unencrypted ethernet frames on a wire? Will we hear about the same kinds of attacks on bluetooth once it actually gets to market?
That's the really important question. WEP is Wired Equivalent Privacy and does not need to be strong encryption. If use of an 802.11b radio gives you the same level of security that you get from a wire running across the office then there is no problem.
If you are sending something over a network and don't want anyone to see it, encrypt it. That is why we have ssh, https and PGP.
If you can't admire people that strive for excellence in a single field you've got some serious issues.
It's those unbalanced individuals that are shoving the world from present to future. Keep in mind that you can admire without emulating. If a 24 hour continuous hack isn't your thing, don't do it. Such things appeal to a particular sort of person. Regardless of their weight or sex life, I like these sorts of people because they can concentrate and get things done. Simple things, but worth a little praise.
Every method of communication has an inherent propery indicating the amount of privacy that can be reasonably expected. This is a nice and simple concept. Yelling accross a crowded room inherently lends itself to less privacy than a whisper.
Similarly, every method of communication has a distribution topology. A phone call from you to your uncle Joe has a 1:1 distribution (unless of course Uncle Joe is in the Mafia and the feds are tapping the line). The distribution of a communication carries with it the same reasonable expectations as the privacy.
Now for Email. The most important email in your box has a 1:1 distribution. You and only you are the intended audience. The second kind of email has a 1:many distribution where the 'many' represents a finite group of individuals with a shared interest in recieving such messages.
It's very important to note that the email system was not really designed for 1:many distributions. Newsgroups are, and the web is. But email in it's most generic form only supports 1:many messages through an ill-designed hack.
The Spammers of the world are 'successful' only because email software (not an accurate placement of blame, the problem is inherent to the protocol/spec which was based on a non-commercial internet) is based upon 1:1 messages.
Joe Blow the PC Whiz is now thinking, you moron, what about CC and BCC? These are clearly intended for 1:many distribution of messages. That's right. My argument is that this is a well-intentioned misfeature.
Sending the same email to multiple recipients is a waste of bandwidth and storage which expands linearly with the number of recipients. Thats a very bad thing. We would never use a sorting algorithm with that kind of performance.
But darlin, I wanna send the same love letter to both my sweethearts! Sure you do, but since there are multiple recipients how about storing that message on your mail server and only sending the headers to your sweeties? The technology isn't hard, it's a nearly trivial project.
But we can't just change the way email works! This is the big-time stupid responce (don't you just love my straw men?). Given: the internet as a whole is growing rapidly and the larger the 'net is the more difficult it's going to be to make a basic change in the way a basic service like email is implimented. If it eventually must be changed then every minute we wait makes the inevitable more difficult, painful, and costly.
You know I'm right. You might not like it, but the less hardware is needed by an ISP the faster the connection per dollar. If massive disk space for email is so cheap, we might as well make the spammers buy it.
"Your example of Word formats changing is a perfect one. If Word95 used XML, Word97 could still be incompatible if it used different elements and attributes."
You're overlooking a fundamental feature of XML. If Word21 needs to add additional elements or attributes to support new features, they simply create new tags. If the document is loaded in Word20 (ignorant of those tags) it won't look quite right (whatever feature was implimented with those tags will be skipped) but it will still display. If M$ wanted to try and maintain it's current upgrade-4-compatability approach, they could change all the tags with every version, but such obvious and outlandish behavior would only serve to destroy whatever fragment of reputation they still have.
"XML can't replace proprietary document formats. That's like asking if ASCII could replace proprietary document formats."
I must not be understanding what you mean when you're refering to ASCII since simple texts replace proprietary document formats all the time. TeX, CSV, RTF, HTML, PS, all are human readable text files. Certainly XML is only part of the solution, it stores the content while the format is handled elsewhere. In that sense it differs from the traditional mixed approach.
The most important thing about the transition from mixed formatting/content to clearly delineated content vs. formatting is that the author isn't (ultimatly) going to have any control over formatting. Relax and give a little thought. The format of a document should be determined (or at least be determinable) by the person reading it. If I counted the times I've read the source of someone's HTML because their background is obnoxious I would have wasted much time.
Slashdot Mirror
MMDS has one serious problem that Sprint has been unable to solve. It's really expensive. In order to get themselves into the black they have to either oversubscribe like crazy or charge a lot for the service. The cost will fall over time (that much is inevitable) but right now I personally don't think it's an economically viable product.
Earthlink is using a system developed by Broadlink which uses 802.11b. We will evaluate 802.11a once quality parts are available.
(note: I work for broadlink but I'm a programmer not PR so please consider anything I say as unofficial)
Broadlink currently provides fixed wireless connectivity in Santa Rosa CA, Stockton CA and now in Atlanta.
Our wireless network is ISP agnostic. We can provide transport for multiple service providers.
(note: I work for broadlink but I'm a programmer not PR so please consider anything I say as unofficial)
It's not like Sprint's service. Sprint uses MMDS based technology, Broadlink uses 802.11b commodity parts and an unusually 'intelligent' edge device.
(note: I work for broadlink but I'm a programmer not PR so please consider anything I say as unofficial)
I've been thinking lately about massive video storage for entirely different purposes.
Lets suppose you have a TiVo with broadband internet access (DSL/Cable/Fixed Wireless, whatever).
You want to watch something that aired yesterday. You did not tell your Tivo to record it. Instead, you request the show through your broadband internet connection. It streams to your Tivo in the background (doesn't matter if it's slower than real-time, the Tivo has become a streaming video cache).
Now consider the storage and bandwidth requirements for the back-end of this 'service'. You would need incoming feeds from every supported channel. To leave room for expansion we'll call it 1000 channels. If you're clever with your algorithms you wouldn't need to re-capture reruns (you would need to properly handle commercials which would significantly increase the overall complexity of the problem). So each unique 'episode' is stored, then each scheduled viewing indexes the locations of commericals as well as which commercials to insert. A little complex but I would estimate 80%+ of what is broadcast is rerun material. That reduces the number of effective 'new' material to 200 channels.
In a perfect world we'd store the complete history of television. But if we just stored the last week it would still be a great feature. So 200 channels of mpeg2, 24 hours a day for 7 days. 33,600 hours of video. It will be randomly accessed by N simultanious customers (where N should be as large as economically possible) which effectivly cancels out the option of using tape.
(warning: shameless abuse of Moores Law follows)
100 GB ~= 30 hours, so we'd need 112 TB of storage (ouch!) for one week. Scarry stuff huh? If hard drives continue to improve at current rates, we can reasonably expect to have 1 TB consumer level drives in three or four years. We can also reasonably expect gig ether in the server farm, 5-10Ghz processing with 3-6GB of RAM and 20-50Mbit consumer broadband transfer speeds. Our 112 TB isn't nearly so difficult in that environment. With a farm of 256 boxes with 8 consumer level 1TB drives each we'd have 2048TB or 18 weeks of programming. Of course we'd want to have hdtv resolutions in that timeframe...
So my question: Is this reasonable? In five years will we be able to randomly access television?
That's an understandable position.
Recently (well, over the last few months) the 802.11b WEP encryption suite has been shattered. But most folks don't seem to understand the role of encryption (particularly radio encryption) in the overall scheme of things.
Lets compare two situations. One is a guy on a dialup through AOL who has his email client configured to poll for his office email every 10 minutes over pop3.
Next is a lady that happens to live across the street from her office. She uses an 802.11b PCMCIA radio card and a small antenna. She also polls for her email every 10 minutes using pop3.
All the security minded folks around here will agree that both of these people are begging to get themselves hacked.
The guy on the dialup is sending packets "in the clear" to AOL. Those clear packets hop through the internet until they reach the guys office. Any server along that path (which could easily be 10-15 or more hops) could be hacked and those clear packets could be sniffed. Any of the routing tables along the way could be corrupted with false data redirecting those pop3 reqests to an arbitrary IP. And thanks to god-knows-who, pop3 includes a clear-text username and password.
In the case of our lady friend, anyone with the proper equiptment could camp out within a few thousand feet of her house and sniff out the same information. Such an attack would be effectivly impossible to detect or backtrace. If the radio link is WEP encrypted, they will have to sit long enough to gather a chunk of data, how long varies (2-12 hours?) but that's not nearly long enough to matter.
Snagging either password is non-trivial. Which is 'easier' depends on the attacker. If you live in the same city a radio link is a real invite. But if you can't get physically close, you're not going to be able to sniff into the pop session. Our gentleman friend isn't so lucky. Anyone in the world can (try to) hack him. Are you worried about your neighbors or the script-kiddies continents away?
Security is sort of a non-issue in a community network. It's like everyone in the area is plugged into a big hub. If you want to keep them out of your traffic, you have to use your own endpoint-to-endpoint encryption.
It all comes down to scalability. Lets suppose you covered a small town with a mesh of roof-top radio AP's. Since you're probably interested in getting out to the internet you'll need some kind soul to forward your traffic.
Therein lies problem number one. Who foots the bill for the bytes?
Lets assume you can find enough people willing to contribute bandwidth for the good of the community or charge a small amount every month to maintain a dedicated line.
Now you'll note that the closer you are to the internet uplink the faster your connection is going to be (fewer hops). Anyone on the fringes of such a network is going to have to hop-hop-hop their way to the uplink. This is bad for the fringes. People right next to the uplink might _think_ they have it made, but then you remember.. everyone further away from the uplink than you is going to be hopping through you.
So, lets assume you figure out a static routing method that takes advantage of all available radio channels, avoids massive short hops and avoids overloading the AP's nearest to the uplink.
Plunk, someone between you and the uplink flips the wrong breaker and powers down their AP. Goodbye static routing. Clearly not an appropriate choice in this environment. Lets try to create a dynamic routing system for hundreds of nodes none of which have global visibility and none of which can be a point of failure. We'll need to ensure that AP's can be added and removed anywhere on the mesh at any time.
After all that, how much 'free' bandwidth will your 200-300$ AP investment give you? Enough to compete with dial-up modems. Maybe.
It's not all dark and grim. 802.11a is right around the corner and it's five times faster than 802.11b. It's probably reasonable to assume that 802.11* types of radio systems will only get faster over the next half-dozen years.
----------
I should mention that I work for a company that develops high-speed radio networks. Rooftop mesh might be the future, but it sure ain't the present.
Hence the "for handhelds", I'm not giving up my keyboard anytime soon for exactly the reasons you've described. At the desktop it would still be nice for mouse control, and there are a few gestures that can be make without moving your fingers from the keyboard that might be really useful. (point toward the escape key with your 'j' finger and hold that gesture for a moment to go 'back' in your browser, point toward the backspace with your 'f' finger (hehe) to go forward, press non-existant buttons below your space bar to scroll down, add non-existant buttons above your F-row with assigned macros..
There are clearly tons of ways in which this kind of technology can augment a traditional keyboard.
You could just as easily add virtual-buttons to your monitor, your desk, whatever is within the sensitivity of the hardware.
As far as direct operation of a device with gestures, it's quite possible that a computer is (in it's current form) too complex a device. But it sure would be easy to work out the necessary gestures to comfortably operate a TV, VCR and/or Tivo.
Think about it. You have these sensors in each of your fingertips and any flat surface becomes an instant full-size keyboard.
It also one-ups the mouse-keyboard combination, no more mouse/touchpad. Just lift your forefinger off the virtual keyboard and move the mouse pointer by pointing at the screen. Your fingers never have to leave the home-row.
For those that can't touch-type, unroll a cheat-sheet and type on it.
This will be a GREAT technology once it matures.
Your analogy would make sense if she found her way to the party by following signs for "Brittney Spears Party" along with a bunch of other kids who followed signs to "Backstret Boys Party" and "Madona Party"; upon arrival was presented with pornography and when she flags a taxi in an attempt to return home, the driver circles around the block and kicks her back to the 'party'.
It not poor judgment. It _is_ a crime.
What is the fundamental difference between a person intentionally creating a javascripted page that 'traps' a browser and an annoying but relativly benign 'traditional' trojan horse bomb (ala: cookie monster)?
In both case:
1) you download something from the net which advertises itself as being desirable.
2) when that download is processed/executed the results of execution are not the desired or advertised results.
In addition:
Removal of the downloaded item generally requires the end-user to take an undesirable action. (popups require you to exit the browser, trojan bombs often require extensive cleanup).
I would be the first to admit that popup traps are not as directly harmful (in general) as a traditional trojan. But that is only a difference in degree. There are trojans which have equally minor effects.
Should the method used to spread and execute malicious code matter? I would think a popup trap would be viewed as much worse than most trojan horse efforts since the effects are cross-platform. Even worse, the author must be making some serious $$ off our annoyance. How many of our CPU cycles have been wasted by this loser?
It comes down to speed vs. privacy. You can ignore WEP and use IPsec or a VPN. You'll take a speed hit, but you'll have reasonable privacy.
If you don't mind exchanging some privacy for additional speed, 128 bit WEP isn't a bad choice. It hasn't lived up to it's "Wired Equivalent" name but sniffing and decrypting is a non-trivial operation.
For more speed with minimal privacy, 80 bit WEP doesn't cost much bandwidth (2%) and you're still only going to be sniffed and decrypted by folks with a clue.
In some situations, speed is most important and privacy is meaningless. Suppose you're downloading Debian ISO's over a wireless link. There are times (one might argue the majority of internet traffic) when privacy just doesn't matter. If you can use reliable encrypted protocols for the exceptions then open mode 802.11b is fine. What are you trying to hide?
As long as we're able to encrypt those transactions that require privacy none of the WEP "stuff" matters. How secure is your wired network internet traffic after it gets to your ISP?
20 miles point-to-point or point-to-multipoint? Fixed or roaming? 128Kbps, 5mbps, faster? And budget.. can you spend $$ for MMDS freqency space? And location, do you have line-of-sight?
There are a lot of highly relevant variables. MMDS is the 'easy' answer, that's the route sprint broadband has taken (20 miles is still a bit of a long run).
That's a problem of publicity. Bluetooth has at least as many security problems as 802.11b (http://www.mcommercetimes.com/Technology/41). More importantly now that the errors in the design of WEP have been uncovered measures are being taken to properly secure the protocol (noteably Cisco with LEAP in the BR350 assigning a unique expiring key to each node). Can this also be cracked? Sure. Is it less secure than unencrypted ethernet frames on a wire? Will we hear about the same kinds of attacks on bluetooth once it actually gets to market?
That's the really important question. WEP is Wired Equivalent Privacy and does not need to be strong encryption. If use of an 802.11b radio gives you the same level of security that you get from a wire running across the office then there is no problem.
If you are sending something over a network and don't want anyone to see it, encrypt it. That is why we have ssh, https and PGP.
If you can't admire people that strive for excellence in a single field you've got some serious issues.
It's those unbalanced individuals that are shoving the world from present to future. Keep in mind that you can admire without emulating. If a 24 hour continuous hack isn't your thing, don't do it. Such things appeal to a particular sort of person. Regardless of their weight or sex life, I like these sorts of people because they can concentrate and get things done. Simple things, but worth a little praise.
Every method of communication has an inherent propery indicating the amount of privacy that can be reasonably expected. This is a nice and simple concept. Yelling accross a crowded room inherently lends itself to less privacy than a whisper.
Similarly, every method of communication has a distribution topology. A phone call from you to your uncle Joe has a 1:1 distribution (unless of course Uncle Joe is in the Mafia and the feds are tapping the line). The distribution of a communication carries with it the same reasonable expectations as the privacy.
Now for Email. The most important email in your box has a 1:1 distribution. You and only you are the intended audience. The second kind of email has a 1:many distribution where the 'many' represents a finite group of individuals with a shared interest in recieving such messages.
It's very important to note that the email system was not really designed for 1:many distributions. Newsgroups are, and the web is. But email in it's most generic form only supports 1:many messages through an ill-designed hack.
The Spammers of the world are 'successful' only because email software (not an accurate placement of blame, the problem is inherent to the protocol/spec which was based on a non-commercial internet) is based upon 1:1 messages.
Joe Blow the PC Whiz is now thinking, you moron, what about CC and BCC? These are clearly intended for 1:many distribution of messages. That's right. My argument is that this is a well-intentioned misfeature.
Sending the same email to multiple recipients is a waste of bandwidth and storage which expands linearly with the number of recipients. Thats a very bad thing. We would never use a sorting algorithm with that kind of performance.
But darlin, I wanna send the same love letter to both my sweethearts! Sure you do, but since there are multiple recipients how about storing that message on your mail server and only sending the headers to your sweeties? The technology isn't hard, it's a nearly trivial project.
But we can't just change the way email works! This is the big-time stupid responce (don't you just love my straw men?). Given: the internet as a whole is growing rapidly and the larger the 'net is the more difficult it's going to be to make a basic change in the way a basic service like email is implimented. If it eventually must be changed then every minute we wait makes the inevitable more difficult, painful, and costly.
You know I'm right. You might not like it, but the less hardware is needed by an ISP the faster the connection per dollar. If massive disk space for email is so cheap, we might as well make the spammers buy it.
"Your example of Word formats changing is a perfect one. If Word95 used XML, Word97 could still be incompatible if it used different elements and attributes."
You're overlooking a fundamental feature of XML. If Word21 needs to add additional elements or attributes to support new features, they simply create new tags. If the document is loaded in Word20 (ignorant of those tags) it won't look quite right (whatever feature was implimented with those tags will be skipped) but it will still display. If M$ wanted to try and maintain it's current upgrade-4-compatability approach, they could change all the tags with every version, but such obvious and outlandish behavior would only serve to destroy whatever fragment of reputation they still have.
"XML can't replace proprietary document formats. That's like asking if ASCII could replace proprietary document formats."
I must not be understanding what you mean when you're refering to ASCII since simple texts replace proprietary document formats all the time. TeX, CSV, RTF, HTML, PS, all are human readable text files. Certainly XML is only part of the solution, it stores the content while the format is handled elsewhere. In that sense it differs from the traditional mixed approach.
The most important thing about the transition from mixed formatting/content to clearly delineated content vs. formatting is that the author isn't (ultimatly) going to have any control over formatting. Relax and give a little thought. The format of a document should be determined (or at least be determinable) by the person reading it. If I counted the times I've read the source of someone's HTML because their background is obnoxious I would have wasted much time.