Previous Issue | Search NetBITS | NetBITS Home Page | Next Issue
On the Web, nearly anyone can create a page that reflects who they are - but what happens to those pages when people die? David Blatner looks at the search for an electronic AfterLife. Also, Editor in chief Glenn Fleishman explains exactly how you came to view this issue on the Internet by examining how bits and bytes travel across the Internet. We also share readers' responses in NettersLetters and attempt to answer the question: How do you pronounce GIF?
Contents:
Copyright 1997 TidBITS Electronic Publishing. All rights reserved. To subscribe to our weekly list, email <netbits-on@netbits.net>. Thanks to our sponsors for their financial support of NetBITS.
Thanks for the tremendous outpouring of support for our first issue of NetBITS. We inadvertently caused some confusion by leading with an article aimed at kids: NetBITS is not a publication specifically for the under-20 crowd. We aim to provide great information for all ages of Internet users.
One other source of confusion for some people is that we use the netbits.net domain for NetBITS, not netbits.com, which was already taken when we registered with the InterNIC. The kind folks at netbits.com have graciously put a note on their home page to direct readers to us, but please be careful when sending mail to us. [GF]
Spread the Word -- If you're a TidBITS subscriber, you must now subscribe to NetBITS separately, or this is the last issue you will receive. We didn't want to force you to opt out of NetBITS, but we hope you'll opt in by subscribing. And, if you like NetBITS, one of the best things you can do to help us is to spread the word to your friends and colleagues. To subscribe, either send mail to <netbits-on@netbits.net> or use the form on our Web site. You can also receive NetBITS in HTML form in email by sending email to <netbits-html-on@netbits.net>, but few email programs deal well with HTML yet. [ACE]
Web Design -- NetBITS managing editor Jeff Carlson will be winging his way to Orlando, Florida, next week to provide on-site email reports from the Web Design '97 conference run by Thunder Lizard Productions. Although joining this temporary mailing list isn't the same as being at the conference itself, the reports will be crammed with useful information about the techniques and people involved with Web design. You can read Jeff's reports from July's Seattle event at the URL below to get an idea of what to expect; that page also contains instructions for subscribing to this free list. [JLC]
<http://www.thunderlizard.com/wd_coverage.html>
Umbrage -- In introducing our first issue, we mentioned the demise of the print versions of Web Developer and NetGuide magazines. The editor in chief of Web Developer and a CMP (NetGuide's parent publication) staffer wrote in to take some umbrage at the characterization of the publications' Web presence. We miss both print publications and use both online sites, and we regret not saying that as clearly as we would have liked.
David Fiedler, Web Developer's editor in chief, points out most of the content on the Web Developer home page is new, and generated by himself or his staffer. Very little is cross-linked from Mecklermedia. Web Developer used to have contributing editors and columnists who still make occasional appearances in shorter articles online.
<http://www.webdeveloper.com/>
NetGuide still has a dozen staffers who update the Web site daily, although the editorial staff for the print publication used to be considerably larger.
Since we're addressing Web resources, I want to mention three other sites that provide technical how-to instruction in Web production and scripting. Web Reference is a compendium of useful articles on topics like Dynamic HTML, Cascading Style Sheets, and JavaScript. Builder.com has a bit more of a news and features approach to building Web sites; it's brought to you by CNET. Finally, Microsoft's Site Builder Network focuses on using Microsoft products, but they give away some great tools and tips. [GF]
<http://www.webreference.com/>
<http://www.builder.com/>
<http://www.microsoft.com/sitebuilder/>
by David Blatner <david@afterlife.org>
Perhaps it speaks to my Western-based culture that I was so surprised when a friend of mine [not our friend and colleague Cary Lu, who had no desire to build a Web site before he passed away, as mentioned in TidBITS-399. -Adam] asked me some time ago if I would host his Web site after he died. I had simply not given any thought to the problem of what happens to a site after someone passes away or can no longer support it for health reasons.
This man had put several years of work into his Web site, and it had become an archive of his life's musings and beliefs. He felt (and feels) strongly that this material should remain available to people after he is no longer around to share it, and there is no reason why this shouldn't be possible. The site takes up little space, requires no real maintenance, and holds a treasure-trove of wonderful writing that will probably never see its way into print.
I don't know how many elderly people or people with terminal illnesses are currently building Web pages, but I can only assume that the number is increasing and that within the next few years the "passing on" question will become one of significance. There are many important and emotional issues at stake here, as people's personal Web sites become repositories and reflections of who they are and what they feel is important to share with others.
I believe this situation calls for an international not-for-profit organization. People could bequest their Web sites to this organization with the knowledge that the site will be available indefinitely to their loved ones and other interested parties. Some small commercial startups already offer this kind of service, but I'm more concerned about people who won't be able to afford an expensive solution that requires trust funds or other sophisticated financing.
Enter the AfterLife -- AfterLife is just such an organization. Over the past few months, several volunteers have been working together to address the concerns and issues of archiving Web sites after their authors die. The effort is still very much in its developmental stage, and more volunteers are needed. Currently, AfterLife has been donated server space and bandwidth, and the organization is applying for tax-exempt status in the United States.
I was honored that my friend asked me to protect something so precious to him, and I willingly agreed. But I wonder how many people's sites are simply being "turned off" when they no longer have a voice (or a checkbook) to sustain them? I keep thinking: if my grandparents had built a Web site, wouldn't I want it archived and available online in the years to come for my grandchildren?
Of course, no one knows what the online world will look like in my grandchildren's time. There's no question that the Web will evolve during the intervening years, and AfterLife will be exploring issues surrounding the conversion of Web pages into other formats for the continuance of access when that becomes necessary. Since HTML is relatively simple and HTML files are pure text, Web pages stand a much better chance of surviving into an unknown technical future than content that requires specific hardware or operating systems. CD-ROMs, for instance, may physically last for many years, but that's no help if there aren't any CD-ROM drives to read them or applications that understand the file formats used.
You can find more information about AfterLife at the Web site below or by sending email to <info@afterlife.org>. If you are interested in either participating as a volunteer or bequeathing your Web site to AfterLife, drop us a line. Although AfterLife is still at an early stage, we want to encourage people to start thinking about the issues involved as the Web, along with the rest of us, continues to age.
by Glenn Fleishman <glenn@netbits.net>
Last week, in the first part of this article in NetBITS-001, I explained how one machine finds another on a local area network (LAN) using Ethernet. But the Internet doesn't run on Ethernet - it can't, in fact - so how do two machines find each other on the Internet?
Matching Names to Faces -- The Internet relies on TCP/IP, a protocol that allows TCP packets to run over Internet Protocol, or IP. TCP is just a method of allowing applications to exchange data with other applications. (There's a streaming protocol called UDP that also runs over the Internet; it's used in cases where it doesn't matter if some data is lost, like sending audio or video.)
Every TCP packet, just like an Ethernet packet, has a "from" and a "to" address in its header. TCP travels over a LAN in encapsulated form. That is, Ethernet packets contain both addresses and other administrative information and your data; the data part of the packet can contain anything - including a different kind of networking protocol packet.
Ethernet delivers the packet to the correct destination, whether that's a computer or a router or a printer. The receiving device peels the Ethernet packet off and uses the material inside. It's like a nut: you crack the shell, and then remove the husk, finally finding the meat deep inside.
The IP part of TCP/IP comes in where packets leave the world of Ethernet and travel from machine to machine over the Internet using IP addresses.
I have to introduce one more protocol, and then it all falls into place. The final bit is ARP: Address Resolution Protocol. ARP is software that creates a list of associations between Ethernet MAC addresses and IP addresses. This list is called a table, but you can visualize it like a spreadsheet with two columns. (You'll recall from Part 1 that a MAC address is the unique identifier for each Ethernet device in the world; each Ethernet card has the number built in at the time of manufacture and the numbers never overlap.)
The ARP table is part of the TCP/IP system, and it's stored separately on each machine that can talk Ethernet and TCP, whether it's a Unix box or a Macintosh. When one machine connects with another it either finds an association between the MAC address and IP address and enters that in its ARP table; or, if the association is already in the table, the connecting machine retrieves and uses it.
Whew! Wasn't that easier than you expected?
Getting from A to B and Back Again -- A router is a special piece of hardware that understands different protocols and converts one type of packet into another. In the simplest case, a company with high-speed Internet access, such as a T1 line (1.544 Mbps), connects its internal Ethernet network to the rest of the Internet using a router.
This archetypal router would have an Ethernet interface that plugs into the Ethernet network; it would also have a serial interface that plugs into a device which, in turn, connects to a higher-level network that eventually leads to the Internet.
When a packet destined for a machine on a company's Ethernet network is sent over the internal LAN, the router ignores it. It possesses a list of internal network addresses; by default, everything else is external. The internal-to-internal packets find their destinations without help from the router.
The device trying to send a packet broadcasts a message saying, "Does anybody on the Ethernet network know where I can find IP address a.b.c.d?" The correct device responds, "That's me!" and the sending machine makes a note in its ARP table for future reference. (The table is flushed occasionally to eliminate stale information.)
If a machine broadcasts a message saying, "I'm looking for a.b.c.d" and the router notices that a.b.c.d isn't an internal network number, it grabs the packet, and passes it up the ladder. The router connects, usually through leased phone company lines, to another router at a network service provider (NSP). The NSP router it connects to is also on an Ethernet or similar high-speed network, usually with a bunch of other routers, all of which transfer packets rapidly back and forth. Some of these devices handle billions of packets an hour.
(This is called store-and-forward communication, by the way, even though it might "store" the packets for only milliseconds. In contrast, within an Ethernet network, packets are received at the speed of electricity on all connected devices. A better example of store-and-forward networks were the old dial-up systems that exchanged Usenet newsgroup posts: they would actually retrieve posts from one site and store them on hard disks where they might sit for hours or days before being transmitted to the next site.)
The NSP's router knows much more than the company's router. It knows where all IP networks in the world live and how to reach them through other routers. I won't go into much detail about that; another set of protocols, known as BGP, allow routers to exchange information about the paths to other networks.
So, the NSP router sends the packet through anywhere from a couple to even a dozen more routers - 30 is the maximum, but 10 to 15 is typical - where each in turn compares the destination to its table to see where to send the packet next.
The packet finally lands in the router that's electrically connected via Ethernet to the machine for which the packet is destined. That router also has an ARP table that matches IP numbers to local Ethernet MAC addresses. It takes the incoming TCP package, wraps it in an Ethernet envelope with the destination machine's MAC address on it, and sends it on to its final destination.
Take a deep breath and read the next sentence: This happens billions of times per minute around the world. That's right, billions. Someday, and not too distantly, it will be trillions.
Real Situations -- Since you now know exactly how data moves from machine to machine over the Internet, how does this apply when you dial in to an Internet service provider (ISP)? The modem-to-modem connection you make using PPP (Point-to-Point Protocol) or SLIP (Serial Line Interface Protocol) enables your machine to communicate with a machine on the other end of the connection. That machine receives your packets just like a router and passes them out onto the Ethernet network to which it's connected. In turn, your packets are passed up the chain and out (and back again) just as though you were on a full-blown network.
What happens if a router receives incorrect information about all the other networks on the Internet? The fact is, this happens occasionally. You might recall on 17-Jul-97 the Internet was sluggish due to routing problems that were described vaguely in the media. What happened relates to the fact that routers share information about networks with each other using the BGP protocol, and routers don't always check the veracity of the information they share. In this case, one small network provider erred in creating its routing tables; these tables were distributed in a cascade, which caused failures in connections, which in turn prevented the routers from getting updates with new, better information. A lot of power cycling and flushing went on before everything settled down. The good news is that router software manufacturers are working to make this harder to muck up, so the devices do more verification and can dump bad information faster and better.
Why doesn't the Internet work more like a phone conversation, rather than via all these little packets flitting around? After all, when you download a file from an FTP site, it looks like information is streaming to you through that connection. The answer is that even though the data transmits in individual chunks, a continuous "channel" (called a socket) opens on both the sending and receiving machine. When you send a request, the server knows where the data is coming from and replies to the sender until it has sent everything requested. It then shuts down the socket, as does the requesting machine. This is one way hackers cause problems. They can send a vast number of requests to open sockets and then fail to acknowledge them - this acknowledgment is part of the normal handshaking that occurs for every socket connection. Earlier operating systems didn't know what to do in these cases, so they would leave more and more sockets open until they crashed, ran out of memory, or stopped responding. Most servers have been patched to prevent this from causing confusion. They just terminate connections after a reasonable period of inactivity.
Why doesn't the Internet use Ethernet, if it's so fast? The main problem with Ethernet is that it's bounded by distance. The farthest points on an Ethernet network must be half the distance it takes to transmit a single packet. This seems odd, until you realize that Ethernet networks are limited by the speed of electricity through the physical wire. The speed of electricity is a fraction of the speed of light: it's constrained by "friction" or resistance in the medium itself. Bits over an Ethernet network can only be sent from one place to another at this speed. Ethernet sends the second bit when the first one is about a foot and a half away.
If the transmitting machine started sending a packet but couldn't "hear" an interfering packet being sent by the most distant machine before it has sent the entire packet, the transmitting machine wouldn't know a collision had taken place. The packet would be lost; the Ethernet devices wouldn't know to retry; and the network wouldn't work.
The Internet uses serial transmission for long distances, where two and only two devices are connected by a single connection. This could be copper wire, fiber optic cable, satellite transmission - whatever. The point is that serial protocols transmit a bit at a time; speed is irrelevant and you don't have to worry about collisions.
Summing Up -- I recommend that you visualize this whole array of transmissions and receptions as a hierarchy. Application software, like an email program, sits on top of the heap in its own little palanquin. It knows how to talk with the next level down - a TCP stack, which is an implementation of the TCP protocol on a particular machine.
The TCP stack in turn knows how to create and decipher packets and deliver them between an interface (such as provided by PPP or Ethernet) and the application software (like an email program) that's talking and responding.
Finally, the devices that make up the public IP network themselves know how to interact and pass data between all of the hundreds of thousands of networks that comprise this thing that we can name with a single word: the Internet.
Question: What is the best way to write URLs in print? Several readers wrote in to ask about how to specify URLs in print and email, asking specifically about the angle brackets we use around URLs and the trailing slashes that follow some URLs.
Answer: As with anything in print, publications often have different styles. Some remove the http:// part of a Web URL, others set the URL in a different color or typeface, and still others reference URLs within the text and include the URLs at the bottom of the page. Here's our take on what's necessary; keep in mind that there are no specific rules.
In our opinion, URLs should always include the "scheme," which is http for a Web URL, ftp for an FTP URL and news for a newsgroup URL. Without the scheme, the URL type can be ambiguous, which serves no one.
The angle brackets that we and many others use to surround the URL in plain text are recommended but not required by the URL specification in the Internet Draft written by the World Wide Web Consortium (W3C). The angle brackets serve to separate the URL from the text around it and to eliminate ambiguity that would stem from punctuation following the URL (would the punctuation be part of the URL or not?). We encourage the use of angle brackets around URLs.
<http://www.w3.org/Addressing/URL/URL_TOC.html>
Trailing slashes are a different issue. There are essentially two places where you might use a trailing slash - a URL that is just a domain name, as in <http://www.netbits.net/> and a URL that contains a domain name and a directory name, which tells the Web server to load the default page (usually called either index.html or default.html) for that directory, such as <http://www.tidbits.com/bookbits/>. (A third type of URL would point directly at a file, such as <http://www.netbits.net/list.html>, and a trailing slash would never be correct in such a URL.)
In URLs that include just a domain name, the trailing slash is optional. We prefer it for consistency with URLs that end in directory names; other publications ignore that issue. In URLs that end in a directory name, the trailing slash is required. However, many Web servers will handle such URLs (like <http://www.tidbits.com/bookbits>) correctly, although they may log an error when they fail to find a file by the specified name. The full RFC1738 (Request for Comment) for the URL specification is available at the URL below. [ACE]
<http://www.w3.org/Addressing/rfc1738.txt>
Question: How Do You Pronounce GIF? A number of readers asked how to pronounce GIF, which stands for Graphic Interchange Format and is a graphics format originally developed by CompuServe. As much as we don't want to turn this column into "Ask Mr. Online Language Guy," the pronunciation of GIF has troubled many Internet users.
Answer: Frankly, we're not sure there is an answer to this one. People pronounce GIF in two ways, with a hard "g" like "goat," and with a soft "g" like "Germany." In fact, we find ourselves switching back and forth relatively randomly, perhaps indicating that the preference of the hard or soft "g" is related to the words that surround GIF in a sentence. Of the reference sources we have on hand, the Microsoft Press Computer Dictionary (from 1991) doesn't include GIF. Robin Williams's Jargon: An Informal Dictionary of Computer Terms, weighs in on the "jiff" side of the pronunciation, but it seems dangerous to declare that the canonical pronunciation given that the "g" in "graphics" is a hard "g." In other words, we don't know, and if anyone can provide a truly authoritative source (we couldn't find one searching on the Web), let us know. As an aside, Partridge's Concise Dictionary of Slang and Unconventional English includes an entry for "gifs," which is RAF (Royal Air Force) slang meaning "pilots," or "guys in the front seat." [ACE]
[Please send us any and all Internet questions, including those involving the safe use of power tools on recalcitrant modems, at <faqtoids@netbits.net>, and include your full name and email address. Questions may be edited for content and length. We cannot guarantee publication or a reply.]
Netiquette for Execs -- Casimir Couvillion <casimir@tgsgeo.com> passed along an excellent suggestion that we'll be sure to work on for a future issue of NetBITS:
I really liked the first issue of NetBITS. I particularly enjoyed the Real Life Internet Lessons for Kids article, which was a great synopsis of netiquette and what to look out for on the Internet. It will certainly get passed around a lot (with appropriate citation of course). I would love to see a version of this edited to speak strictly to adults. While the lessons are valid for adults, I would find it difficult to forward it as it is to executives in our company. They need to read it, but might feel that I'm talking down to them by giving it to them as it is.
Kids on the Net -- Benoit Deshaies <desben@infoteck.qc.ca> took slight exception with some of our comments about chat rooms and IRC:
First of all, I'm 16 years old - soon to be 17 - and I've been using the Internet since 1991. I'd like to make a comment about your article's claim that most people using chat on the Internet are teenage boys or men. Perhaps this is true for the U.S. The only international channel I frequent on IRC is #c++, a technical channel, which is an estimated 98 percent male. On the other hand, the main local channel I visit (#trois-rivieres, which is the channel of my town, located in Quebec, Canada) is about 30 to 40 percent female. We verified this at our Get Togethers, which are real-world meetings of the people on IRC. The percentages are similar for other Quebecois channels I've visited.
U.K. Pronunciations -- Jonathan Sanderson <jonathan@quern.demon.co.uk> commented on our FAQtoids 001 answer about the pronunciation of URL and a specific part of the URL:
The U.K. magazine New Scientist last year asked for suggestions on how to pronounce the "http://www" part of many Web URLs. Most people agreed that the finest idea was "Hitweb." For example, you'd read <http://www.apple.com/> as "Hitweb apple dot com." Sadly, it hasn't caught on. Also, URL is usually pronounced "you are ell" on this side of the pond. I had no idea what you were writing about when I first saw "earls" - they're something else over here.
Kind Words -- Jenny O'Brien <jennyo@mpls.coremktg.com> sent along some kind words that were music to our editing ears, if that's not mixing metaphors too much. Though we have a small staff and a short deadline, we try our best to produce a professionally written and edited publication.
Let me congratulate you on your fine first issue! My boss forwarded it to me - not too uncommon - but I usually find the recommended newsletters to be poorly written and edited - even downright boring sometimes. Your newsletter, however, was a welcome surprise and I will be subscribing momentarily. I especially like the section aimed at kids because although I have no children, I am the "favorite" aunt to 13 nieces and nephews, some of whom are already surfing the Internet! I wouldn't have even thought to mention some of the included safeguards to them - and wait until my father goes online soon!
[Please send NettersLetters to us at <letters@netbits.net>. Please include your full name and email address. Letters may be edited for content and length. We cannot guarantee publication or a reply.]
Non-profit, non-commercial publications and Web sites may reprint or link to articles if full credit is given. Others please contact us. We do not guarantee accuracy of articles. Caveat lector. Publication, product, and company names may be registered trademarks of their companies.
Previous Issue | Search NetBITS | NetBITS Home Page | Next Issue