Since 1969, the loosely organized Internet Engineering Task Force (IETF) has documented the standards that govern the Internet in a format called Request for Comment (RFC). Thirty years later, in August 1999, the series extended to 2,648 RFCs. The Internet groupware technologies discussed in this book are defined, for the most part, in this remarkable collection of documents. This appendix traces the evolution of email, news, the Web, security, directory services, and various metadata initiatives to their roots in the RFC series. You can find the RFCs in many places on the Web including the home page of the IETF (http://www.ietf.org/) and, in a more easily navigable and searchable form, at http://www.faqs.org/.
The Internet standards process moves slowly, and it surprises some people to learn that many seemingly well-established parts of the Internet’s infrastructure—for example, LDAP, IMAP, and S/MIME—are as yet merely proposed standards. Even such stalwarts as Dynamic Host Configuration Protocol (DHCP) and MIME are draft, not yet official standards.
We think of the RFCs as prescriptive, and indeed they’re full of legalistic phrases like “an implementation SHALL...” There is even an RFC (2119, Key words for use in RFCs to Indicate Requirement Levels) that defines what RFCs mean by terms like SHALL, SHOULD, and MAY. But in truth the RFCs function not so much as a body of law but rather as a kind of groupware docbase, embedded in a process of ongoing contribution and review. The IETF is, in fact, one of the greatest groupware stories of all time. The Internet is fundamentally a collaborative project, so perhaps we shouldn’t be surprised to find that some of its earliest technologies—such as email and news—remain some of the most mature, effective, and flexible groupware tools.
The seminal document that defines the basic plumbing of Internet email is RFC821 (August 1982, Simple Mail Transfer Protocol). It’s amazing to think that so much of the world’s communication now depends on a protocol in which one machine contacts another and says, in plain ASCII, “Hello, I have mail for Joe, here is the message.” It seems too simple, but that’s why it works so well.
A series of RFCs from RFC521 (September 1973, Standardizing Network Mail Headers) to RFC822 (August 1982, Standard for the Format of ARPA Internet Text Messages) traces the evolution of mail headers. These headers govern the delivery of Internet mail. More broadly, RFC822 formalizes the notion of a semistructured document that combines a structured header with a free-form body. In mailboxes, listserv archives, and newsgroups, these kinds of documents store vast quantities of intellectual capital.
Note that RFC822 specifies a mechanism for extending the mail header. A formal extension field, defined in a subsequent RFC, can carry extra metadata. For example, RFC2369 (July 1998, The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields) defines how email headers can document listserv commands, as shown in this fragment sent by the Lyris list server:
List-Software: Lyris Server version 3.0 List-Subscribe: <mailto:[email protected]> List-Owner: <mailto:[email protected]> X-List-Host: ActiveState Tool Corp. <http://www.activestate.com>
The first three headers in this example are what RFC822 callsextension fields. These are expected to be defined in another RFC (in this case, RFC2369) and must not begin with “X-”. The fourth header is what RFC822 calls a user-defined field. These are not defined in another RFC, typically begin with “X-”, and may be preempted by published extensions.
This mechanism suggests one way to create Internet-style custom messages. For example, an email or news message about the subject of custom message headers might categorize itself like this:
X-MetadataDomain: Internet X-MetadataCategory: messaging X-MetadataRefs: RFC822, RFC2369
These headers could be used by messaging clients, and by the tools
that build and manage message archives, to organize messages using a
richer metadata scheme than Author:,
Subject:, Date:.
An experimental application that uses these headers should also support—and propose in an RFC—formal variants that could become standard extension fields:
MetadataDomain: Internet MetadataCategory: messaging MetadataRefs: RFC822, RFC2369
Quite a few RFCs define headers that can appear in Internet messages. RFC2076 (February 1997, Common Internet Message Headers) usefully summarizes these various headers.