RFC 2291

Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web

📅 published February 1998, from ietf

Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web ✨

okay bestie, here's the title block tea ☕ this is RFC 2291 from the Network Working Group, filed as Informational and dated February 1998 🌸. The authors are J. Slein (Xerox Corporation), F. Vitali (University of Bologna), E. Whitehead (U.C. Irvine), and D. Durand (Boston University) 🧚. The title block doesn't list anything it obsoletes or updates 💅.

Status of this Memo 📜

okay so this memo is just here to give info to the Internet community 💖. It is NOT an Internet standard of any kind, so nobody's being forced into anything. Distribution of the memo is unlimited 🌈.

Copyright (C) The Internet Society (1998). All Rights Reserved. 🔒

Abstract 💜

so the current World Wide Web (WWW or Web) standards give you simple support for apps that let people remotely edit typed data ✨. In practice though, the existing WWW capabilities have proven inadequate for efficient, scalable remote editing that's free of overwriting conflicts 😭. This doc lists features as requirements for a Web Distributed Authoring and Versioning protocol. If someone implements them, it would make common remote editing operations more efficient, add a locking mechanism to prevent overwrite conflicts, improve link management for non-HTML data types, add a simple attribute-value metadata facility, support creating and reading container data types, and integrate versioning into the WWW 🎀.

1. Introduction 🦋

so this doc describes functionality that, if added as an extension to the existing HTTP proposed standard [HTTP], would let tools for remotely loading, editing and saving (publishing) various media types on the WWW work with any compliant Web server 🫶. As much as possible, it's described without suggesting a specific implementation, bc there are tons of ways to do it within the WWW framework 💅. It's also possible that one mechanism could satisfy several requirements at once 🧚.

This doc reflects the consensus of the WWW Distributed Authoring and Versioning working group (WebDAV) on the functionality that should be standardized to support distributed authoring and versioning on the Web 📚. As with any set of requirements, practical considerations may make it impossible to satisfy them all. The WebDAV working group intends to get as close as possible to satisfying them in the specifications that make up the WebDAV protocol 💖.

2. Rationale 🍓

current Web standards already have stuff that lets you edit Web content at a remote location, without touching the storage media directly through an operating system 🙌. Several HTML distributed authoring tools use this, plus a growing number of mainstream apps (like word processors) that let users write (publish) their work to an HTTP server 💻. Honestly, experience from the HTML authoring tools shows they can't meet their users' needs using what Web standards offer 😩. So the result is either delayed distributed authoring capability, or nonstandard extensions to HTTP or other Web standards 🙈. Those extensions were developed in isolation, so they aren't interoperable 💀.

other authoring apps also wanted to reach document repositories or version control systems through Web gateways, and they got the same runaround 🥲. When that access exists at all, it's through nonstandard extensions to HTTP or other standards, which force clients to use a different interface for each vendor's service 👑.

this doc describes requirements for a set of standard extensions to HTTP, so distributed Web authoring tools can get the functionality their users need using the same standard syntax across all compliant servers 🌸. The broad categories of functionality that need to be standardized are:

  • Properties
  • Links
  • Locking
  • Reservations
  • Retrieval of Unprocessed Source
  • Partial Write
  • Name Space Manipulation
  • Collections
  • Versioning
  • Variants
  • Security
  • Internationalization

3. Terminology 📖

where there's overlap, usage is meant to match the HTTP 1.1 specification [HTTP] 🤓.

  • Client: a program that issues HTTP requests and accepts responses 📨.
  • Collection: a resource that contains other resources, either directly or by reference 📁.
  • Distributed Authoring Tool: a program that can retrieve a source entity via HTTP, let you edit it, and then save/publish it to a server using HTTP ✍️.
  • Entity: the information transferred in a request or response 📦.
  • Hierarchical Collection: a hierarchical organization of resources. It's a resource that contains other resources, including collections, either directly or by reference 🌳.
  • Link: a typed connection between two or more resources 🔗.
  • Lock: a mechanism for preventing anyone other than the owner of the lock from accessing a resource 🔐.
  • Member of Version Graph: a resource that's a node in a version graph. It's derived from the resources that come before it in the graph, and it's the basis for the ones that come after it 🌱.
  • Property: named descriptive information about a resource 🎀.
  • Reservation: a declaration that you intend to edit a resource 📝.
  • Resource: a network data object or service that can be identified by a URI 🌐.
  • Server: a program that receives and responds to HTTP requests 🖥️.
  • User Agent: the client that initiates a request 🚀.
  • Variant: a representation of a resource. A resource can have one or more representations associated with it at any given time 🦄.
  • Version Graph: a directed acyclic graph with resources as its nodes, where each node is derived from its predecessor(s) 🕸️.
  • Write Lock: a lock that prevents anyone except its owner from modifying the resource it applies to ✨.

4. General Principles 🌈

this section describes a set of general principles that the WebDAV extensions should follow 💫. These principles cut across categories of functionality, so they're kind of the vibe for the whole thing 💅.

4.1. User Agent Interoperability 🤝

all WebDAV clients should be able to work with any WebDAV-compliant HTTP server 💖. It is acceptable for some client/server combinations to provide special features that aren't universally available, but the protocol should be sufficient that a basic level of functionality will be universal 🌸.

4.2. Client Simplicity 🧸

the WebDAV extensions should be designed so client implementations can stay simple ✨.

4.3. Legacy Client Support 🫶

it should be possible to implement a WebDAV-compliant server in a way that it can interoperate with non-WebDAV clients 🤗. Such a server would be able to understand any valid HTTP 1.1 request from an ordinary Web client without WebDAV extensions, and it would provide a valid HTTP 1.1 response that doesn't require the client to understand the extensions 💜.

4.4. Data Format Compatibility 📄

WebDAV-compliant servers should be able to work with existing resources and URIs [URL]. Special additional information should not become a mandatory part of document formats 🙅.

4.5. Replicated, Distributed Systems 🌍

distribution and replication are at the heart of the Internet 💜. All WebDAV extensions should be designed to allow for distribution and replication 🫧. Version trees should be able to be split across multiple servers. Collections may have members on different servers. Any resource may be cached or replicated for mobile computing or other reasons 📱. So the WebDAV extensions must be able to operate in a distributed, replicated environment 👑.

4.6 Parsimony in Client-Server Interactions 🎯

the WebDAV extensions should keep the number of interactions between the client and the server needed to perform common functions to a minimum 🤏. For example, publishing a document to the Web will often mean publishing content together with related properties 🍓. A client may often need to find out what version graph a particular resource belongs to, or which resource in a version graph is the published one 🔍. The extensions should make it possible to do these things efficiently 🧚.

4.7. Changes to HTTP 🔧

WebDAV adds a bunch of new types of objects to the Web: properties, collections, version graphs, etc. ✨ Existing HTTP methods such as DELETE and PUT will have to operate in well-defined ways in this expanded environment 🙃. WebDAV should explicitly address not only new methods, headers, and MIME types, but also any required changes to the existing HTTP methods and headers 💅.

4.8. Alternate Transport Mechanisms 📬

it may be desirable to transport WebDAV requests and responses by other mechanisms, particularly EMail, in addition to HTTP 💌. The WebDAV protocol specification should not preclude a future body from developing an interoperability specification for disconnected operation via EMail 🦋.

5. Requirements 📋

in the requirement descriptions below, each requirement is stated first, followed by its rationale 🎀.

5.1. Properties 🏷️

5.1.1. Functional Requirements 🎯

it must be possible to create, modify, read and delete arbitrary properties on resources of any media type 💖.

5.1.2. Rationale 🧠

properties describe resources of any media type 🌈. They may include bibliographic information such as author, title, publisher, and subject, constraints on usage, PICS ratings, etc. 📚 These properties have lots of uses, like supporting searches on property values, enforcing copyrights, and creating catalog entries as placeholders for objects that aren't available in electronic form, or that will be available later 🔍.

5.2.1. Functional Requirements 🎯

it must be possible to create, modify, read and delete typed links between resources of any media type 💫.

5.2.2. Rationale 🧠

one type of link between resources is the hypertext link, which is browsable with a point-and-click user interface 🖱️. Links, whether they're browsable hypertext links or just a way of capturing a relationship between resources, have a bunch of purposes 🌟. They can support pushbutton printing of a multi-resource document in a prescribed order, jumping to the access control page for a resource, and quick browsing of related information, like a table of contents, an index, a glossary, a bibliographic record, help pages, etc. 📖 Link support is provided by the HTML LINK element, but that's limited to HTML resources [HTML] 😤. Similar support is needed for bitmap image types and other non-HTML media types 🖼️.

5.3. Locking 🔒

5.3.1. General Principles 🌸

5.3.1.1. Independence of locks.

it must be possible to lock a resource without performing an additional retrieval of the resource, and without committing to editing the resource 🙌.

5.3.1.2. Multi-Resource Locking.

it must be possible to take out a lock on multiple resources residing on the same server in a single action, and this locking operation must be atomic across these resources 👑.

5.3.2. Functional Requirements ✨

5.3.2.1. Write Locks. It must be possible to restrict modification of a resource to a specific person. 🔐

5.3.2.2. Lock Query. It must be possible to find out whether a given resource has any active locks, and if so, who holds those locks. 🔍

5.3.2.3. Unlock. It must be possible to remove a lock. 🔓

5.3.3. Rationale 🧠

okay so rn the web is kinda bad at stopping two people from stomping on each other's edits when they save to the same URI 😭. There's also no way to check whether someone else is actively editing a resource. This is called the "lost update problem," or the "overwrite problem" 💀. Cleaning up lost modifications can cost a LOT, so preventing this is crucial for distributed authoring 🫶. A write lock means only one person may modify a resource, so no overwrites. Locking is also a key part of lots of versioning schemes, which is a desirable capability for distributed authoring 💅.

An author might want to lock an entire web of resources even while editing just one of them, so the other resources don't change while they work 👑. That way, if a local hypertext web is consistent in their authoring tool, it'll still be consistent when they write it to the server 🎀. So it should be possible to take out a lock without also transmitting the contents of a resource 🦋.

It's often necessary to guarantee that a lock or unlock happens at the same time across multiple resources, and that's what the multiple-resource locking requirement is for 🔒. It prevents a collision between two people trying to lock the same set of resources, because with multi-resource locking, one of them will get a lock. If you did it by iterating atomic lock operations across the resources instead, the locks would get split between the two people based on resource ordering and race conditions 💀.

5.4. Reservations 📌

5.4.1. Functional Requirements

5.4.1.1. Reserve. It must be possible for a principal to register with the server an intent to edit a given resource, so that other principals can discover who intends to edit the resource. 👀

5.4.1.2. Reservation Query. It must be possible to find out whether a given resource has any active reservations, and if so, who currently holds reservations. 🔎

5.4.1.3. Release Reservation. It must be possible to release the reservation. 🫧

5.4.2. Rationale 💭

Experience from configuration management systems has shown that people need to know when they're about to enter a parallel editing situation 👀. Once they're notified, they either decide not to edit in parallel with the other authors, or they coordinate out-of-band (face-to-face, telephone, etc.) so merging their results is less painful 💅.

Reservations are separate from locking. A write lock doesn't necessarily mean a resource will actually be edited, and a reservation doesn't come with any access restrictions 🙃. This supports versioning, since a check-out usually involves taking out a write lock, making a reservation, and getting the resource to be edited 🌈.

5.5. Retrieval of Unprocessed Source for Editing 📜

5.5.1. Functional Requirement

The source of any given resource must be retrievable by any principal with authorization to edit the resource. 🔑

5.5.2. Rationale 🤯

Lots of times the source stored on a server isn't what you actually get back from an HTTP GET. The known cases right now are server side include directives, and Standard Generalized Markup Language (SGML) source that gets converted on the fly into HyperText Markup Language (HTML) [HTML] output entities 🧚.

There are loads of other possibilities too 🍓. Like automatically converting bitmap images into several variant bitmap media types (e.g. GIF, JPEG), or automatically converting an application's native media type into HTML. As an example of that last one: a word processor could store its native media type on a server that automatically converts it to HTML. A GET of this resource would retrieve the HTML, but retrieving the source would get you the word processor's native format 💖.

5.6. Partial Write. 🖊️

5.6.1. Functional Requirement

After editing a resource, it must be possible to write only the changes to the resource, rather than retransmitting the entire resource. ✂️

5.6.2. Rationale 😤

Distributed editing over wide geographic separations and/or low bandwidth connections is extremely inefficient and frustrating when you have to rewrite a large resource after a tiny change, like a one-character spelling correction. We need support for transmitting "insert" (e.g., add this sentence in the middle of a document) and "delete" (e.g., remove this paragraph from the middle of a document) style updates ✨. Partial resource updates make small edits way more efficient and let distributed authoring tools scale up to editing large documents 🚀.

5.7. Name Space Manipulation 🗺️

5.7.1. Copy 📦

5.7.1.1. Functional Requirements

It must be possible to duplicate a resource without a client loading, then resaving the resource. After the copy operation, a modification to either resource must not cause a modification to the other. 👯

5.7.1.2. Rationale

There are many reasons a resource might need duplicating, like changing ownership, preparing for major modifications, or making a backup 💾. Because of the network costs of loading and saving a resource, it's way preferable for a server to perform a resource copy than a client 🫶.

5.7.2. Move/Rename 🚚

5.7.2.1. Functional Requirements

It must be possible to change the location of a resource without a client loading, then resaving the resource under a different name. After the move operation, it must no longer be possible to access the resource at its original location. 🙅

5.7.2.2. Rationale

Renaming happens a lot, like when there's a new naming convention or when a typing error was made entering the name originally 🙈. Loading, resaving, and then deleting the old resource is undesirable because of network costs. A single rename is also more efficient than a copy followed by a delete ✨. Note that moving a resource is considered the same function as renaming a resource 🦋.

5.8. Collections 🗂️

A collection is a resource that is a container for other resources, including other collections 🧺. A resource may belong to a collection either directly or by reference. If a resource belongs to a collection directly, name space operations like copy, move, and delete applied to the collection also apply to the resource. If a resource belongs to a collection by reference, name space operations applied to the collection affect only the reference, not the resource itself 💅.

5.8.1. Functional Requirements 📋

5.8.1.1. List Collection. A listing of all resources in a specific collection must be accessible. 👀

5.8.1.2. Make Collection. It must be possible to create a new collection. 🆕

5.8.1.3. Add to Collection. It must be possible to add a resource to a collection directly or by reference. ➕

5.8.1.4. Remove from Collection. It must be possible to remove a resource from a collection. ➖

5.8.2. Rationale 🌳

In [URL] it states that, "some URL schemes (such as the ftp, http, and file schemes) contain names that can be considered hierarchical." So yeah, hierarchy is literally baked in 🌳.

Especially for HTTP servers that directly map all or part of their URL name space into a filesystem, it's super useful to get a listing of all resources at a particular hierarchy level 📂. That's what powers "Save As..." dialog boxes, which show the entities at the current hierarchy level and let you navigate through the hierarchy 💾. It also supports graphical visualizations (typically as a network) of the hypertext structure among the entities at a hierarchy level or set of levels 🕸️, plus a tree visualization of the entities and their hierarchy levels 🌲.

Document management systems may also want to make their documents accessible through the Web 💼. They typically organize documents into collections, so they also want their users to be able to view the collection hierarchy through the Web 🗃️.

There are plenty of times a URL hierarchy level doesn't really match up with the notion of a collection 🤷. One example is a server where the URL hierarchy level maps to a computational process that performs some resolution on the name. In that case, the contents of the level can vary depending on the input to the computation, and the number of resources accessible through it can be enormous. Making a directory feature for that kind of name space doesn't make sense 🙅. But listing the contents of hierarchy levels that do correspond to collections, like the large number of HTTP servers that map their name space to a filesystem, argues for including this capability anyway, even though it isn't meaningful in every case 💅. If listing the contents of a URL hierarchy level doesn't make sense for a particular URL, then a "405 Method Not Allowed" status code could be issued 🚫.

Being able to create collections to hold related resources helps manage a name space by packaging its members into small, related clusters 📁. You can see how useful that is from the broad implementation of directories in recent operating systems 💻. It also supports "Save As..." dialog boxes with the "New Level/Folder/Directory" capability that's common in many applications ✨.

5.9. Versioning 🎀

5.9.1. Background and General Principles 💅

5.9.1.1. Stability of versions ✨

Okay so bestie, most versioning systems exist to keep an accurate record of how a document evolved over time 📜. The way they stay accurate is that a version eventually gets "frozen" and becomes immutable 🧊. Once it's frozen, any further change creates a new version instead of messing with the old one. For caching and persistent references to work, a client has to be able to tell that a version is frozen 🫶. Any successful attempt to retrieve a frozen version will always get back exactly the same content, or an error if that version (or the resource itself) is no longer available. No cap, that's the whole vibe 💀.

5.9.1.2. Operations for Creating New Versions 🌸

Version management systems are wildly different about which operations they need, what order those operations go in, and how they get bundled into atomic functions 🙈. In the most complete cases, the logical operations are:

  • Reserve existing version
  • Lock existing version
  • Retrieve existing version
  • Request or suggest identifier for new version
  • Write new version
  • Release lock
  • Release reservation

Except for requesting a new version identifier, all of these have uses outside of versioning. They're either already part of HTTP or covered in earlier sections of these requirements 🧚. Usually versioning systems mash reservation, locking, and retrieval (or some subset of them) into an atomic checkout function 🛒. They also combine writing, releasing the lock, and releasing the reservation (or some subset of those) into an atomic checkin function 🎀. The new version identifier can be assigned at checkout or at checkin, either one 🦋.

The WebDAV extensions must find some balance between letting versioning servers adopt whatever policies they wish for these operations and enforcing enough uniformity to keep client implementations simple 💖.

5.9.1.3. The Versioning Model 🔥

Each version typically has a "derived from" relationship with its predecessor(s) 👑. You can derive several different versions from one version (branching), and you can derive one version from several versions (merging) 🌿. So the collection of related versions forms a directed acyclic graph. In what follows, this graph is called a "version graph". Each node is a "version" or "member of the version graph", and the arcs capture the "derived from" relationships ✨.

It's also possible for a single resource to participate in multiple version graphs 🌈.

The WebDAV extensions should support this versioning model, though particular servers may restrict it in various ways 🍓.

5.9.1.4. Versioning Policies 📚

Lots of writers, including Feiler [CM] and Haake and Hicks [VSE], have talked about versioning styles (called versioning policies here, to reflect the client/server interaction) as a way to think about the different policies versioning systems implement 🧠. Policies cover things like the shape of version histories (linear or branched), the granularity of change tracking, locking requirements made by a server, etc. The protocol should clearly identify the policies it dictates, and the ones left up to versioning system implementors or administrators 💜.

5.9.1.5. It is possible to version resources of any media type. 🎨

5.9.2. Functional Requirements 🎀

5.9.2.1. Referring to a version graph 🦋

There must be a way to refer to a version graph as a whole.

Some queries and operations apply not to any one member of a version graph, but to the graph as a whole 🌸. For example, a client may request that an entire graph be moved, or may ask for a version history. In these cases, a way to refer to the whole version graph is required.

5.9.2.2. Referring to a specific member of a version graph 💫

There must be a way to refer to each member of a version graph. This means that each member of the graph is itself a resource.

Each member of a version graph must be a resource if it's going to be possible for a hypertext link to refer to a specific version of a page, or for a client to request a specific version of a document for editing 🔗.

5.9.2.3. A client must be able to determine whether a resource is a version graph, or whether a resource is itself a member of a version graph. 🕵️

A resource may be a simple, non-versioned resource, or it may be a version graph, or it may be a member of a version graph. A client needs to be able to tell which sort of resource it is accessing 🧐.

5.9.2.4. There must be a way to refer to a server-defined default member of a version graph.

The server should return a default version of a resource for requests that ask for the default version, as well as for requests where no specific version information is provided. This is one of the simplest ways to guarantee non-versioning client compatibility ✨. It doesn't rule out the server returning an error when no sensible default exists 🙅.

It may also be desirable to refer to other special members of a version graph. For example, there may be a current version for editing that's different from the default version. For a graph with several branches, it may be useful to request the tip version of any branch 🌳.

5.9.2.5. It must be possible, given a reference to a member of a version graph, to find out which version graph(s) that resource belongs to.

This makes it possible to understand the versioning context of the resource 🧩. It makes it possible to retrieve a version history for the graphs it belongs to, and to browse the version graph. It also supports some comparison operations: it makes it possible to determine whether two references designate members of the same version graph 🔍.

5.9.2.6. Navigation of a version graph 🗺️

Given a reference to a member of a version graph, it must be possible to discover and access the following related members of the version graph:

  • root member of the graph
  • predecessor member(s)
  • successor member(s)
  • default member of the graph

It must be possible in some way for a versioning client to access versions related to a resource currently being examined 🧭.

5.9.2.7. There must be a way to retrieve the complete version topology for a version graph, including information about all members of the version graph. The format for this information must be standardized so that the basic information can be used by all clients. Other specialized formats should be accommodated, for servers and clients that require information that cannot be included in the standard topology 📊.

5.9.2.8. A client must be able to propose a version identifier to be used for a new member of a version graph. The server may refuse to use the client's suggested version identifier. The server should tell the client what version identifier it has assigned to the new member of the version graph 🏷️.

5.9.2.9. A version identifier must be unique across a version graph. 🔑

5.9.2.10. A client must be able to supply version-specific properties to be associated with a new member of a version graph. (See Section 5.1 "Properties" above.) At a minimum, it must be possible to associate comments with the new member, explaining what changes were made 📝.

5.9.2.11. A client must be able to query the server for information about a version tree, including which versions are locked, which are reserved for editing, and by whom (Session Tracking). 👀

5.9.3. Rationale 💜

Versioning in the context of the world-wide web offers a bunch of benefits, bestie:

It provides infrastructure for efficient and controlled management of large evolving web sites. Modern configuration management systems are built on some form of repository that can track the revision history of individual resources, and provide the higher-level tools to manage those saved versions. Basic versioning capabilities are required to support such systems 🏗️.

It allows parallel development and update of single resources. Since versioning systems register change by creating new objects, they enable simultaneous write access by allowing the creation of variant versions. Many also provide merge support to ease the reverse operation 👯.

It provides a framework for coordinating changes to resources. While specifics vary, most systems provide some method of controlling or tracking access to enable collaborative resource development 🤝.

It allows browsing through past and alternative versions of a resource. Frequently the modification and authorship history of a resource is critical information in itself 🕰️.

It provides stable names that can support externally stored links for annotation and link-server support. Both annotation and link servers frequently need to store stable references to portions of resources that are not under their direct control. By providing stable states of resources, version control systems allow not only stable pointers into those resources, but also well-defined methods to determine the relationships of those states of a resource 🔗.

It allows explicit semantic representation of single resources with multiple states. A versioning system directly represents the fact that a resource has an explicit history, and a persistent identity across the various states it has had during the course of that history 🌟.

5.10. Variants 🦋

Detailed requirements for variants will be developed in a separate document.

5.10.1. Functional Requirements 🎀

It must be possible to send variants to the server, describing the relationships between the variants and their parent resource. In addition, it must be possible to write and retrieve variants of property labels, property descriptions, and property values 🧩.

5.10.2. Rationale 💡

The HTTP working group is addressing problems of content negotiation and retrieval of variants of a resource. To extend this work to an authoring environment, WEBDAV must standardize mechanisms for authors to use when submitting variants to a server. Authors need to be able to provide variants in different file or document formats, for different uses. They need to provide variants optimized for different clients and for different output devices. They need to be able to provide variants in different languages in the international environment of the Web. In support of internationalization requirements (See 5.12 below), variants need to be supported not just for the content of resources, but for any information intended for human use, such as property values, labels, and descriptions 🌍.

5.11. Security 🔐

5.11.1. Authentication 🪪

The WebDAV specification should state how the WebDAV extensions interoperate with existing authentication schemes, and should make recommendations for using those schemes.

5.11.2. Access Control 🚪

Access control requirements are specified in a separate access control work in progress [AC].

5.11.3. Interoperability with Security Protocols 🛡️

The WebDAV specification must provide a minimal list of security protocols which any compliant server / client must support. These protocols should insure the authenticity of messages and the privacy and integrity of messages in transit.

5.12. Internationalization 🌏

5.12.1. Character Sets and Languages ✨

Okay so, distributed authoring happens in a totally multi-lingual world 🌍, which means anything meant for a human to read must conform to the IETF Character Set Policy [CHAR]. That policy covers character sets, encodings, and language tagging, so it's the go-to rulebook 📖💖

5.12.2. Rationale 🌸

The Internet is global, so it's super important to make sure any info meant for people to read can be displayed in a writing system and language that both the client and the server are happy with 🫶 And this isn't just about resource content! It also covers display names, property descriptions, property values, and status messages. Everything counts 💅

6. Acknowledgements 🎀

Honestly, these ideas came from so much thoughtful discussion, emails, and help from a ton of people, and they deserve a huge shoutout 😭🫶

Terry Allen, tallen@sonic.net
Alan Babich, FileNet, babich@filenet.com
Dylan Barrell, Open Text, dbarrell@opentext.ch
Barbara Bazemore, PC DOCS, barbarab@pcdocs.com
Martin Cagan, Continuus Software, Marty_Cagan@continuus.com
Steve Carter, Novell, srcarter@novell.com
Dan Connolly, World Wide Web Consortium, connolly@w3.org
Jim Cunningham, Netscape, jfc@netscape.com
Ron Daniel Jr., Los Alamos National Laboratory, rdaniel@lanl.gov
Mark Day, Lotus, Mark_Day@lotus.com
Martin J. Duerst, mduerst@ifi.unizh.ch
Asad Faizi, Netscape, asad@netscape.com
Ron Fein, Microsoft, ronfe@microsoft.com
David Fiander, Mortice Kern Systems, davidf@mks.com
Roy Fielding, U.C. Irvine, fielding@ics.uci.edu
Mark Fisher, Thomson Consumer Electronics, FisherM@indy.tce.com
Yaron Y. Goland, Microsoft, yarong@microsoft.com
Phill Hallam-Baker, MIT, hallam@ai.mit.edu
Dennis Hamilton, Xerox PARC, hamilton@parc.xerox.com
Andre van der Hoek, University of Colorado, Boulder,
  andre@cs.colorado.edu
Del Jensen, Novell, dcjensen@novell.com
Gail Kaiser, Columbia University, kaiser@cs.columbia.edu
Rohit Khare, World Wide Web Consortium, khare@w3.org
Ora Lassila, Nokia Research Center, ora.lassila@research.nokia.com
Ben Laurie, A.L. Digital, ben@algroup.co.uk
Mike Little, Bellcore, little@bellcore.com
Dave Long, America Online, dave@sb.aol.com
Larry Masinter, Xerox PARC, masinter@parc.xerox.com
Murray Maloney, SoftQuad, murray@sq.com
Jim Miller, World Wide Web Consortium, jmiller@w3.org
Howard S. Modell, Boeing, howard.s.modell@boeing.com
Keith Moore, University of Tennessee, Knoxville, moore@cs.utk.edu
Henrik Frystyk Nielsen, World Wide Web Consortium, frystyk@w3.org
Jon Radoff, NovaLink, jradoff@novalink.com
Alan Robertson, alanr@bell-labs.com
Henry Sanders, Microsoft,
Andrew Schulert, Microsoft, andyschu@microsoft.com
Christopher Seiwald, Perforce Software, seiwald@perforce.com
Einar Stefferud, stef@nma.com
Richard Taylor, U.C. Irvine, taylor@ics.uci.edu
Robert Thau, MIT, rst@ai.mit.edu
Sankar Virdhagriswaran, sv@hunchuen.crystaliz.com
Dan Whelan, FileNet, dan@FILENET.COM
Gregory J. Woodhouse, gjw@wnetc.com

7. References 📚

  • [AC] J. Radoff, "Requirements for Access Control within Distributed Authoring and Versioning Environments on the World Wide Web", unpublished manuscript, http://lists.w3.org/Archives/Public/w3c-dist-auth/1997AprJun/0183.html
  • [CHAR] Alvestrand, H., "IETF Policy on Character Sets and Languages", RFC 2277, January 1998.
  • [CM] P. Feiler, "Configuration Management Models in Commercial Environments", Software Engineering Institute Technical Report CMU/SEI-91-TR-7, http://www.sei.cmu.edu/products/publications/91.reports/91.tr.007.html
  • [HTML] Berners-Lee, T., and D. Connolly, "HyperText Markup Language Specification - 2.0", RFC 1866, November 1995.
  • [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
  • [ISO 10646] ISO/IEC 10646-1:1993. "International Standard -- Information Technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane."
  • [URL] Berners-Lee, T., Masinter, L., and M. McCahill. "Uniform Resource Locators (URL)", RFC 1738, December 1994.
  • [VSE] A. Haake, D. Hicks, "VerSE: Towards Hypertext Versioning Styles", Proc. Hypertext'96, The Seventh ACM Conference on Hypertext, 1996, pages 224-234.

8. Authors' Addresses 💌

Judith Slein
Xerox Corporation
800 Phillips Road 128-29E
Webster, NY 14580

EMail: slein@wrc.xerox.com


Fabio Vitali
Department of Computer Science
University of Bologna
ITALY

EMail: fabio@cs.unibo.it


E. James Whitehead, Jr.
Department of Information and Computer Science
University of California
Irvine, CA 92697-3425

Fax: 714-824-4056
EMail: ejw@ics.uci.edu


David G. Durand
Department of Computer Science
Boston University
Boston, MA

EMail: dgd@cs.bu.edu

Last but not least, the legal bit. Please read it, bestie 🫶

Copyright (C) The Internet Society (1998). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🦋

📦 where this page comes from