RFC1630 (June 1994, Universal Resource Identifiers in WWW) introduces three fundamental concepts:
- Universal Resource Identifier (URI)
A general-purpose namespace mechanism
- Uniform Resource Locator (URL)
An instance of a URI that is the address of some resource, accessible by means of a protocol such as HTTP or NNTP
- Uniform Resource Name (URN)
An instance of a URI that, unlike a fragile URL, is guaranteed to remain always available
RFC1736 (February 1995, Functional Recommendations for Internet Resource Locators) recommends that URL schemes should be:
Global in scope
Readily parseable
Human readable and writable
Extensible
RFC1738 (December 1994, Uniform Resource Locators (URL)) describes common URL schemes, including http:, news:, mailto:, and file:. RFC1808 ( June 1995, Relative Uniform Resource Locators) defines the rules for relative URLs that are fully qualified with reference to a stated or implied base URL.
RFC2396 (August 1998, Uniform Resource Identifiers (URI): Generic Syntax) subsumes RFC1738 and RFC1808, defining “a single generic syntax for all URI.” A URI, say the authors, “can be further classifed as a name, a locator, or both.” It reiterates RFC1630’s URI/URL/URN taxonomy: “A URN differs from a URL in that its primary purpose is persistent labeling of a resource with an identifier.”
The URL/URN distinction can be misleading. A World Wide Web Consortium (W3C) document entitled “Cool URIs don’t change” (http://www.w3.org/Provider/Style/URI) notes astutely:
Some seem to think that because there is research about namespaces which will be more persistent, that they can be as lax about dangling links as they like as `URNs will fix all that’. If you are one of these folks, then allow me to disillusion you.
This W3C document suggests a number of ways that you can (and should) design URL namespaces that you’ll be able to maintain over time, even as underlying storage and organizational patterns evolve.
RFC1945 (May 1996, Hypertext Transfer Protocol—HTTP/1.0) and its successor, RFC2616 (June 1999, Hypertext Transfer Protocol—HTTP/1.1), document the basic plumbing of the Web. These RFCs describe: how clients connect to servers, issue requests, and optionally authenticate; the basic request types (GET, HEAD, POST); the headers sent by clients and servers; mechanisms for caching and proxying.
RFC2109 (February 1997, HTTP State Management Mechanisms) defines how
cookies work. It specifies the syntax and use of the
Set-Cookie: header that a server uses to plant a
cookie on a browser and the Cookie: header that a
browser uses to send a cookie back to a server.
As discussed earlier in Section 2.1, the mechanisms described in RFC2518 (February 1999, HTTP Extensions for Distributed Authoring—WEBDAV) could in theory support a new generation of collaborative tools that would supersede many of the technologies discussed in this book. Unlike HTTP/1.1, which encodes method parameters in HTTP headers, WebDAV requests are formatted in XML. The protocol includes support for locking, getting and setting of properties, defining collections, and copying or moving individual objects or entire subtrees.