Per G. Bilse wrote:
In the good (but somewhat boring) old
days, there wasn't really a lot of applications outside the normal
UNIX and TCP-based environment, with multicasting being the exception
Yesterday I watch a "cyber-TV-program" on US TV. They showed a "cool
screensaver" that was continuously displaying new stock quotes it was
getting over the net. And another screensaver that displayed video
pictures of the Olympic Games.
What worries me here is that people are developing applications that
use (lots of) bandwidth, even when people are not even using their
computers.
Henk.
I agree. This will get worse and worse as more and more companies build
products and test them on a LAN or with a local ISP at the other end of
their T1 line. It would help a lot if there was an RFC because even though
many developpers can be clueless when designing and implementing these
products, they *DO* listen when someone points them to a standards
authority like IETF. You and I may know that IETF is just a bunch of plain
folks who understand networks and try to figure out the best way to build
them.
But it is much much easier to tell a developper that their product
violates RFC2001 than it is to try to convince them that they are wrong
based just on engineering grounds. The developper and their managers will
dispute engineering reasons much sooner than they will dispute an official
Internet standard from the IETF.
Maybe we could get an RFC that requires screensaver type applications to
have a standalone mode that works with stored data and require user
overrides in order to initiate video or other data feeds. Maybe it could
also require that video and data feeds automatically shut down if there is
no user interaction within a specified time period. Kind of a higher level
view of the smae kind of timing specs that make TCP work.
Michael Dillon - ISP & Internet Consulting
Memra Software Inc. - Fax: +1-604-546-3049
http://www.memra.com - E-mail: michael@memra.com
But it is much much easier to tell a developper that their product
violates RFC2001 than it is to try to convince them that they are wrong
based just on engineering grounds. The developper and their managers will
dispute engineering reasons much sooner than they will dispute an official
Internet standard from the IETF.
An RFC would also make it a lot easier to justify restraints on what
users can do. RFC compliance could even be turned into a marketing
advantage, which would put pressure on other networks to comply as
well.
I much prefer pressuring developers than pressuring users, but I think
anyone who runs a "retail" network or is aware of mailbombing
software, spamming software, or cracking software knows that being
part policeman and part parent comes with the territory. "Bad"
applications will be written no matter what the RFC says.