As per Relevance of the word resource, we have this rfc below:
Network Working Group J.
Request for Comments: 2291 Xerox
Category: Informational F.
University of
E.
U.C.
D.
Boston
February 1998
Requirements for a Distributed Authoring and
Protocol for the World Wide
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
Current World Wide Web (WWW or Web) standards provide simple
for applications which allow remote editing of typed data.
practice, the existing capabilities of the WWW have proven
to support efficient, scalable remote editing free of
conflicts. This document presents a list of features in the form
requirements for a Web Distributed Authoring and Versioning
which, if implemented, would improve the efficiency of common
editing operations, provide a locking mechanism to prevent
conflicts, improve link management support between non-HTML
types, provide a simple attribute-value metadata facility,
for the creation and reading of container data types, and
versioning into the WWW
1.
This document describes functionality which, if incorporated in
extension to the existing HTTP proposed standard [HTTP], would
tools for remote loading, editing and saving (publishing) of
media types on the WWW to interoperate with any compliant Web server
As much as possible, this functionality is described
suggesting a proposed implementation, since there are many ways
perform the functionality within the WWW framework. It is
Slein, et. al. Informational [Page 1]
RFC 2291 Distributed Authoring and Versioning February 1998
possible that a single mechanism could simultaneously satisfy
requirements
This document reflects the consensus of the WWW Distributed
and Versioning working group (WebDAV) as to the functionality
should be standardized to support distributed authoring
versioning on the Web. As with any set of requirements,
considerations may make it impossible to satisfy them all. It is
intention of the WebDAV working group to come as close as possible
satisfying them in the specifications that make up the
protocol
2.
Current Web standards contain functionality which enables the
of Web content at a remote location, without direct access to
storage media via an operating system. This capability is
by several existing HTML distributed authoring tools, and by
growing number of mainstream applications (e.g., word processors
which allow users to write (publish) their work to an HTTP server.
date, experience from the HTML authoring tools has shown they
unable to meet their users' needs using the facilities of
standards. The consequence of this is either postponed
of distributed authoring capability, or the addition of
extensions to the HTTP protocol or other Web standards.
extensions, developed in isolation, are not interoperable
Other authoring applications have wanted to access
repositories or version control systems through Web gateways,
have been similarly frustrated. Where this access is available
all, it is through nonstandard extensions to HTTP or other
that force clients to use a different interface for each vendor'
service
This document describes requirements for a set of standard
to HTTP that would allow distributed Web authoring tools to
the functionality their users need by means of the same
syntax across all compliant servers. The broad categories
functionality that need to be standardized are
Retrieval of Unprocessed
Partial
Name Space
Slein, et. al. Informational [Page 2]
RFC 2291 Distributed Authoring and Versioning February 1998
3.
Where there is overlap, usage is intended to be consistent with
in the HTTP 1.1 specification [HTTP].
A program which issues HTTP requests and accepts responses
A collection is a resource that contains other resources,
directly or by reference
Distributed Authoring
A program which can retrieve a source entity via HTTP,
editing of this entity, and then save/publish this entity to
server using HTTP
The information transferred in a request or response
Hierarchical
A hierarchical organization of resources. A
collection is a resource that contains other resources
including collections, either directly or by reference
A typed connection between two or more resources
A mechanism for preventing anyone other than the owner of
lock from accessing a resource
Member of Version
A resource that is a node in a version graph, and so is
from the resources that precede it in the graph, and is
basis of those that succeed it
Named descriptive information about a resource
A declaration that one intends to edit a resource
Slein, et. al. Informational [Page 3]
RFC 2291 Distributed Authoring and Versioning February 1998
A network data object or service that can be identified by
URI
A program which receives and responds to HTTP requests
User
The client that initiates a request
A representation of a resource. A resource may have one or
representations associated with it at any given time
Version
A directed acyclic graph with resources as its nodes, where
node is derived from its predecessor(s).
Write
A lock that prevents anyone except its owner from modifying
resource it applies to
4. General
This section describes a set of general principles that the
extensions should follow. These principles cut across categories
functionality
4.1. User Agent
All WebDAV clients should be able to work with any WebDAV-
HTTP server. It is acceptable for some client/server combinations
provide special features that are not universally available, but
protocol should be sufficient that a basic level of
will be universal
4.2. Client
The WebDAV extensions should be designed to allow
implementations to be simple
Slein, et. al. Informational [Page 4]
RFC 2291 Distributed Authoring and Versioning February 1998
4.3. Legacy Client
It should be possible to implement a WebDAV-compliant server in
a way that it can interoperate with non-WebDAV clients. Such
server would be able to understand any valid HTTP 1.1 request from
ordinary Web client without WebDAV extensions, and to provide a
HTTP 1.1 response that does not require the client to understand
extensions
4.4. Data Format
WebDAV-compliant servers should be able to work with
resources and URIs [URL]. Special additional information should
become a mandatory part of document formats
4.5. Replicated, Distributed
Distribution and replication are at the heart of the Internet.
WebDAV extensions should be designed to allow for distribution
replication. Version trees should be able to be split
multiple servers. Collections may have members on different servers
Any resource may be cached or replicated for mobile computing
other reasons. Consequently, the WebDAV extensions must be able
operate in a distributed, replicated environment
4.6 Parsimony in Client-Server
The WebDAV extensions should keep to a minimum the number
interactions between the client and the server needed to
common functions. For example, publishing a document to the Web
often mean publishing content together with related properties.
client may often need to find out what version graph a
resource belongs to, or to find out which resource in a version
is the published one. The extensions should make it possible to
these things efficiently
4.7. Changes to
WebDAV adds a number of new types of objects to the Web: properties
collections, version graphs, etc. Existing HTTP methods such
DELETE and PUT will have to operate in well-defined ways in
expanded environment. WebDAV should explicitly address not only
methods, headers, and MIME types, but also any required changes
the existing HTTP methods and headers
Slein, et. al. Informational [Page 5]
RFC 2291 Distributed Authoring and Versioning February 1998
4.8. Alternate Transport
It may be desirable to transport WebDAV requests and responses
other mechanisms, particularly EMail, in addition to HTTP.
WebDAV protocol specification should not preclude a future body
developing an interoperability specification for
operation via EMail
5.
In the requirement descriptions below, the requirement will
stated, followed by its rationale
5.1.
5.1.1. Functional
It must be possible to create, modify, read and delete
properties on resources of any media type
5.1.2.
Properties describe resources of any media type. They may
bibliographic information such as author, title, publisher,
subject, constraints on usage, PICS ratings, etc. These
have many uses, such as supporting searches on property values
enforcing copyrights, and the creation of catalog entries
placeholders for objects which are not available in electronic form
or which will be available later
5.2.
5.2.1. Functional
It must be possible to create, modify, read and delete typed
between resources of any media type
5.2.2.
One type of link between resources is the hypertext link, which
browsable using a hypertext style point-and-click user interface
Links, whether they are browsable hypertext links, or simply a
of capturing a relationship between resources, have many purposes
Links can support pushbutton printing of a multi-resource document
a prescribed order, jumping to the access control page for
resource, and quick browsing of related information, such as a
Slein, et. al. Informational [Page 6]
RFC 2291 Distributed Authoring and Versioning February 1998
of contents, an index, a glossary, a bibliographic record,
pages, etc. While link support is provided by the HTML "LINK
element, this is limited only to HTML resources [HTML].
support is needed for bitmap image types, and other non-HTML
types
5.3.
5.3.1. General
5.3.1.1. Independence of locks. It must be possible to lock
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
lock on multiple resources residing on the same server in a
action, and this locking operation must be atomic across
resources
5.3.2. Functional
5.3.2.1. Write Locks. It must be possible to restrict modification
a resource to a specific person
5.3.2.2. Lock Query. It must be possible to find out whether a
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.
At present, the Web provides limited support for preventing two
more people from overwriting each other's modifications when
save to a given URI. Furthermore, there is no way to discover
someone else is currently making modifications to a resource. This
known as the "lost update problem," or the "overwrite problem."
there can be significant cost associated with discovering
repairing lost modifications, preventing this problem is crucial
supporting distributed authoring. A write lock ensures that only
person may modify a resource, preventing overwrites. Furthermore
locking support is a key component of many versioning schemes,
desirable capability for distributed authoring
An author may wish to lock an entire web of resources even though
is editing just a single resource, to keep the other resources
changing. In this way, an author can ensure that if a local
web is consistent in his distributed authoring tool, it will then
Slein, et. al. Informational [Page 7]
RFC 2291 Distributed Authoring and Versioning February 1998
consistent when he writes it to the server. Because of this,
should be possible to take out a lock without also
transmission of the contents of a resource
It is often necessary to guarantee that a lock or unlock
occurs at the same time across multiple resources, a feature which
supported by the multiple-resource locking requirement. This
useful for preventing a collision between two people trying
establish locks on the same set of resources, since with multi
resource locking, one of the two people will get a lock. If this
multiple-resource locking scenario was repeated by using atomic
operations iterated across the resources, the result would be
splitting of the locks between the two people, based on
ordering and race conditions
5.4.
5.4.1. Functional
5.4.1.1. Reserve. It must be possible for a principal to
with the server an intent to edit a given resource, so that
principals can discover who intends to edit the resource
5.4.1.2. Reservation Query. It must be possible to find out whether
given resource has any active reservations, and if so, who
holds reservations
5.4.1.3. Release Reservation. It must be possible to release
reservation
5.4.2.
Experience from configuration management systems has shown
people need to know when they are about to enter a parallel
situation. Once notified, they either decide not to edit in
with the other authors, or they use out-of-band communication (face
to-face, telephone, etc.) to coordinate their editing to minimize
difficulty of merging their results. Reservations are separate
locking, since a write lock does not necessarily imply a
will be edited, and a reservation does not carry with it any
restrictions. This capability supports versioning, since a check-
typically involves taking out a write lock, making a reservation,
getting the resource to be edited
Slein, et. al. Informational [Page 8]
RFC 2291 Distributed Authoring and Versioning February 1998
5.5. Retrieval of Unprocessed Source for
5.5.1. Functional
The source of any given resource must be retrievable by any
with authorization to edit the resource
5.5.2.
There are many cases where the source stored on a server does
correspond to the actual entity transmitted in response to an
GET. Current known cases are server side include directives,
Standard Generalized Markup Language (SGML) source which is
on the fly to HyperText Markup Language (HTML) [HTML]
entities. There are many possible cases, such as automatic
of bitmap images into several variant bitmap media types (e.g. GIF
JPEG), and automatic conversion of an application's native media
into HTML. As an example of this last case, a word processor
store its native media type on a server which automatically
it to HTML. A GET of this resource would retrieve the HTML
Retrieving the source would retrieve the word processor
format
5.6. Partial Write
5.6.1. Functional
After editing a resource, it must be possible to write only
changes to the resource, rather than retransmitting the
resource
5.6.2.
During distributed editing which occurs over wide
separations and/or over low bandwidth connections, it is
inefficient and frustrating to rewrite a large resource after
changes, such as a one-character spelling correction. Support
needed for transmitting "insert" (e.g., add this sentence in
middle of a document) and "delete" (e.g. remove this paragraph
the middle of a document) style updates. Support for partial
updates will make small edits more efficient, and allow
authoring tools to scale up for editing large documents
Slein, et. al. Informational [Page 9]
RFC 2291 Distributed Authoring and Versioning February 1998
5.7. Name Space
5.7.1.
5.7.1.1. Functional
It must be possible to duplicate a resource without a client loading
then resaving the resource. After the copy operation, a
to either resource must not cause a modification to the other
5.7.1.2.
There are many reasons why a resource might need to be duplicated
such as changing ownership, preparing for major modifications,
making a backup. Due to network costs associated with loading
saving a resource, it is far preferable to have a server perform
resource copy than a client
5.7.2. Move/
5.7.2.1. Functional
It must be possible to change the location of a resource without
client loading, then resaving the resource under a different name
After the move operation, it must no longer be possible to access
resource at its original location
5.7.2.2.
It is often necessary to change the name of a resource, for
due to adoption of a new naming convention, or if a typing error
made entering the name originally. Due to network costs, it
undesirable to perform this operation by loading, then resaving
resource, followed by a delete of the old resource. Similarly,
single rename operation is more efficient than a copy followed by
delete operation. Note that moving a resource is considered the
function as renaming a resource
5.8.
A collection is a resource that is a container for other resources
including other collections. A resource may belong to a
either directly or by reference. If a resource belongs to
collection directly, name space operations like copy, move,
delete applied to the collection also apply to the resource. If
resource belongs to a collection by reference, name space
applied to the collection affect only the reference, not the
itself
Slein, et. al. Informational [Page 10]
RFC 2291 Distributed Authoring and Versioning February 1998
5.8.1. Functional
5.8.1.1. List Collection. A listing of all resources in a
collection must be accessible
5.8.1.2. Make Collection. It must be possible to create a
collection
5.8.1.3. Add to Collection. It must be possible to add a resource
a collection directly or by reference
5.8.1.4. Remove from Collection. It must be possible to remove
resource from a collection
5.8.2.
In [URL] it states that, "some URL schemes (such as the ftp, http
and file schemes) contain names that can be considered hierarchical."
Especially for HTTP servers which directly map all or part of
URL name space into a filesystem, it is very useful to get a
of all resources located at a particular hierarchy level.
functionality supports "Save As..." dialog boxes, which provide
listing of the entities at a current hierarchy level, and
navigation through the hierarchy. It also supports the creation
graphical visualizations (typically as a network) of the
structure among the entities at a hierarchy level, or set of levels
It also supports a tree visualization of the entities and
hierarchy levels
In addition, document management systems may want to make
documents accessible through the Web. They typically allow
organization of documents into collections, and so also want
users to be able to view the collection hierarchy through the Web
There are many instances where there is not a strong
between a URL hierarchy level and the notion of a collection.
example is a server in which the URL hierarchy level maps to
computational process which performs some resolution on the name.
this case, the contents of the URL hierarchy level can vary
on the input to the computation, and the number of
accessible via the computation can be very large. It does not
sense to implement a directory feature for such a name space
However, the utility of listing the contents of those URL
levels which do correspond to collections, such as the large
of HTTP servers which map their name space to a filesystem, argue
the inclusion of this capability, despite not being meaningful in
Slein, et. al. Informational [Page 11]
RFC 2291 Distributed Authoring and Versioning February 1998
cases. If listing the contents of a URL hierarchy level does
makes sense for a particular URL, then a "405 Method Not Allowed
status code could be issued
The ability to create collections to hold related resources
management of a name space by packaging its members into small
related clusters. The utility of this capability is demonstrated
the broad implementation of directories in recent operating systems
The ability to create a collection also supports the creation
"Save As..." dialog boxes with "New Level/Folder/Directory
capability, common in many applications
5.9.
5.9.1. Background and General
5.9.1.1. Stability of versions. Most versioning systems are
to provide an accurate record of the history of evolution of
document. This accuracy is ensured by the fact that a
eventually becomes "frozen" and immutable. Once a version is frozen
further changes will create new versions rather than modifying
original. In order for caching and persistent references to
properly maintained, a client must be able to determine that
version has been frozen. Any successful attempt to retrieve a
version of a resource will always retrieve exactly the same content
or return an error if that version (or the resource itself) is
longer available
5.9.1.2. Operations for Creating New Versions. Version
systems vary greatly in the operations they require, the order of
operations, and how they are combined into atomic functions. In
most complete cases, the logical operations involved are
o Reserve existing
o Lock existing
o Retrieve existing
o Request or suggest identifier for new
o Write new
o Release
o Release
With the exception of requesting a new version identifier, all
these operations have applications outside of versioning and
either already part of HTTP or are discussed in earlier sections
these requirements. Typically, versioning systems
reservation, locking, and retrieval -- or some subset of these --
into an atomic checkout function. They combine writing,
Slein, et. al. Informational [Page 12]
RFC 2291 Distributed Authoring and Versioning February 1998
the lock, and releasing the reservation -- or some subset of these --
into an atomic checkin function. The new version identifier may
assigned either at checkout or at checkin
The WebDAV extensions must find some balance between
versioning servers to adopt whatever policies they wish with
to these operations and enforcing enough uniformity to keep
implementations simple
5.9.1.3. The Versioning Model. Each version typically stands in
"derived from" relationship to its predecessor(s). It is possible
derive several different versions from a single version (branching),
and to derive a single version from several versions (merging).
Consequently, the collection of related versions forms a
acyclic graph. In the following discussion, this graph will
called a "version graph". Each node of this graph is a "version"
"member of the version graph". The arcs of the graph capture
"derived from" relationships
It is also possible for a single resource to participate in
version graphs
The WebDAV extensions should support this versioning model,
particular servers may restrict it in various ways
5.9.1.4. Versioning Policies. Many writers, including Feiler [CM]
Haake and Hicks [VSE], have discussed the notion of versioning
(referred to here as versioning policies, to reflect the nature
client/server interaction) as one way to think about the
policies that versioning systems implement. Versioning
include decisions on the shape of version histories (linear
branched), the granularity of change tracking, locking
made by a server, etc. The protocol should clearly identify
policies that it dictates and the policies that are left up
versioning system implementors or administrators
5.9.1.5. It is possible to version resources of any media type
5.9.2. Functional
5.9.2.1. Referring to a version graph. There must be a way to
to a version graph as a whole
Some queries and operations apply, not to any one member of a
graph, but to the version graph as a whole. For example, a
may request that an entire graph be moved, or may ask for a
history. In these cases, a way to refer to the whole version graph
required
Slein, et. al. Informational [Page 13]
RFC 2291 Distributed Authoring and Versioning February 1998
5.9.2.2. Referring to a specific member of a version graph.
must be a way to refer to each member of a version graph. This
that each member of the graph is itself a resource
Each member of a version graph must be a resource if it is to
possible for a hypertext link to refer to specific version of a page
or for a client to request a specific version of a document
editing
5.9.2.3. A client must be able to determine whether a resource is
version graph, or whether a resource is itself a member of a
graph
A resource may be a simple, non-versioned resource, or it may be
version graph, or it may be a member of a version graph. A
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
member of a version graph
The server should return a default version of a resource for
that ask for the default version, as well as for requests where
specific version information is provided. This is one of the
ways to guarantee non-versioning client compatibility. This does
rule out the possibility of a server returning an error when
sensible default exists
It may also be desirable to be able to refer to other special
of a version graph. For example, there may be a current version
editing that is different from the default version. For a graph
several branches, it may be useful to be able to request the
version of any branch
5.9.2.5. It must be possible, given a reference to a member of
version graph, to find out which version graph(s) that
belongs to
This makes it possible to understand the versioning context of
resource. It makes it possible to retrieve a version history for
graphs to which it belongs, and to browse the version graph. It
supports some comparison operations: It makes it possible
determine whether two references designate members of the
version graph
5.9.2.6. Navigation of a version graph. Given a reference to
member of a version graph, it must be possible to discover and
the following related members of the version graph
Slein, et. al. Informational [Page 14]
RFC 2291 Distributed Authoring and Versioning February 1998
o root member of the
o predecessor member(s
o successor member(s
o default member of the
It must be possible in some way for a versioning client to
versions related to a resource currently being examined
5.9.2.7. Version Topology. There must be a way to retrieve
complete version topology for a version graph, including
about all members of the version graph. The format for
information must be standardized so that the basic information can
used by all clients. Other specialized formats should
accommodated, for servers and clients that require information
cannot be included in the standard topology
5.9.2.8. A client must be able to propose a version identifier to
used for a new member of a version graph. The server may refuse
use the client's suggested version identifier. The server
tell the client what version identifier it has assigned to the
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
to be associated with a new member of a version graph. (See
5.1 "Properties" above.) At a minimum, it must be possible
associate comments with the new member, explaining what changes
made
5.9.2.11. A client must be able to query the server for
about a version tree, including which versions are locked, which
reserved for editing, and by whom (Session Tracking).
5.9.3.
Versioning in the context of the world-wide web offers a variety
benefits
It provides infrastructure for efficient and controlled management
large evolving web sites. Modern configuration management systems
built on some form of repository that can track the revision
of individual resources, and provide the higher-level tools to
those saved versions. Basic versioning capabilities are required
support such systems
Slein, et. al. Informational [Page 15]
RFC 2291 Distributed Authoring and Versioning February 1998
It allows parallel development and update of single resources.
versioning systems register change by creating new objects,
enable simultaneous write access by allowing the creation of
versions. Many also provide merge support to ease the
operation
It provides a framework for coordinating changes to resources.
specifics vary, most systems provide some method of controlling
tracking access to enable collaborative resource development
It allows browsing through past and alternative versions of
resource. Frequently the modification and authorship history of
resource is critical information in itself
It provides stable names that can support externally stored links
annotation and link-server support. Both annotation and link
frequently need to store stable references to portions of
that are not under their direct control. By providing stable
of resources, version control systems allow not only stable
into those resources, but also well-defined methods to determine
relationships of those states of a resource
It allows explicit semantic representation of single resources
multiple states. A versioning system directly represents the
that a resource has an explicit history, and a persistent
across the various states it has had during the course of
history
5.10.
Detailed requirements for variants will be developed in a
document
5.10.1. Functional
It must be possible to send variants to the server, describing
relationships between the variants and their parent resource.
addition, it must be possible to write and retrieve variants
property labels, property descriptions, and property values
5.10.2.
The HTTP working group is addressing problems of content
and retrieval of variants of a resource. To extend this work to
authoring environment, WEBDAV must standardize mechanisms for
to use when submitting variants to a server. Authors need to be
to provide variants in different file or document formats,
different uses. They need to provide variants optimized for
Slein, et. al. Informational [Page 16]
RFC 2291 Distributed Authoring and Versioning February 1998
clients and for different output devices. They need to be able
provide variants in different languages in the
environment of the Web. In support of
requirements (See 5.12 below), variants need to be supported not
for the content of resources, but for any information intended
human use, such as property values, labels, and descriptions
5.11.
5.11.1. Authentication. The WebDAV specification should state how
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
a separate access control work in progress [AC].
5.11.3. Interoperability with Security Protocols. The
specification must provide a minimal list of security protocols
any compliant server / client must support. These protocols
insure the authenticity of messages and the privacy and integrity
messages in transit
5.12.
5.12.1. Character Sets and
Since Web distributed authoring occurs in a multi-
environment, information intended for user comprehension must
to the IETF Character Set Policy [CHAR]. This policy
character sets and encodings, and language tagging
5.12.2.
In the international environment of the Internet, it is important
insure that any information intended for user comprehension can
displayed in a writing system and language agreeable to both
client and the server. The information encompassed by
requirement includes not only the content of resources, but also
things as display names and descriptions of properties,
values, and status messages
6.
Our understanding of these issues has emerged as the result of
thoughtful discussion, email, and assistance by many people,
deserve recognition for their effort
Slein, et. al. Informational [Page 17]
RFC 2291 Distributed Authoring and Versioning February 1998
Terry Allen, tallen@sonic.
Alan Babich, FileNet, babich@filenet.
Dylan Barrell, Open Text, dbarrell@opentext.
Barbara Bazemore, PC DOCS, barbarab@pcdocs.
Martin Cagan, Continuus Software, Marty_Cagan@continuus.
Steve Carter, Novell, srcarter@novell.
Dan Connolly, World Wide Web Consortium, connolly@w3.
Jim Cunningham, Netscape, jfc@netscape.
Ron Daniel Jr., Los Alamos National Laboratory, rdaniel@lanl.
Mark Day, Lotus, Mark_Day@lotus.
Martin J. Duerst, mduerst@ifi.unizh.
Asad Faizi, Netscape, asad@netscape.
Ron Fein, Microsoft, ronfe@microsoft.
David Fiander, Mortice Kern Systems, davidf@mks.
Roy Fielding, U.C. Irvine, fielding@ics.uci.
Mark Fisher, Thomson Consumer Electronics, FisherM@indy.tce.
Yaron Y. Goland, Microsoft, yarong@microsoft.
Phill Hallam-Baker, MIT, hallam@ai.mit.
Dennis Hamilton, Xerox PARC, hamilton@parc.xerox.
Andre van der Hoek, University of Colorado, Boulder
andre@cs.colorado.
Del Jensen, Novell, dcjensen@novell.
Gail Kaiser, Columbia University, kaiser@cs.columbia.
Rohit Khare, World Wide Web Consortium, khare@w3.
Ora Lassila, Nokia Research Center, ora.lassila@research.nokia.
Ben Laurie, A.L. Digital, ben@algroup.co.
Mike Little, Bellcore, little@bellcore.
Dave Long, America Online, dave@sb.aol.
Larry Masinter, Xerox PARC, masinter@parc.xerox.
Murray Maloney, SoftQuad, murray@sq.
Jim Miller, World Wide Web Consortium, jmiller@w3.
Howard S. Modell, Boeing, howard.s.modell@boeing.
Keith Moore, University of Tennessee, Knoxville, moore@cs.utk.
Henrik Frystyk Nielsen, World Wide Web Consortium, frystyk@w3.
Jon Radoff, NovaLink, jradoff@novalink.
Alan Robertson, alanr@bell-labs.
Henry Sanders, Microsoft
Andrew Schulert, Microsoft, andyschu@microsoft.
Christopher Seiwald, Perforce Software, seiwald@perforce.
Einar Stefferud, stef@nma.
Richard Taylor, U.C. Irvine, taylor@ics.uci.
Robert Thau, MIT, rst@ai.mit.
Sankar Virdhagriswaran, sv@hunchuen.crystaliz.
Dan Whelan, FileNet, dan@FILENET.
Gregory J. Woodhouse, gjw@wnetc.
Slein, et. al. Informational [Page 18]
RFC 2291 Distributed Authoring and Versioning February 1998
7.
[AC] J. Radoff, "Requirements for Access Control within
Authoring and Versioning Environments on the World Wide Web",
unpublished manuscript,
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
Environments", Software Engineering Institute Technical
CMU/SEI-91-TR-7,
[HTML] Berners-Lee, T., and D. Connolly, "HyperText Markup
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
Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane."
[URL] Berners-Lee, T., Masinter, L., and M. McCahill. "
Resource Locators (URL)", RFC 1738, December 1994.
[VSE] A. Haake, D. Hicks, "VerSE: Towards Hypertext
Styles", Proc. Hypertext'96, The Seventh ACM Conference on Hypertext
1996, pages 224-234.
Slein, et. al. Informational [Page 19]
RFC 2291 Distributed Authoring and Versioning February 1998
8. Authors'
Judith
Xerox
800 Phillips Road 128-29
Webster, NY 14580
EMail: slein@wrc.xerox.
Fabio
Department of Computer
University of
EMail: fabio@cs.unibo.
E. James Whitehead, Jr
Department of Information and Computer
University of
Irvine, CA 92697-3425
Fax: 714-824-4056
EMail: ejw@ics.uci.
David G.
Department of Computer
Boston
Boston,
EMail: dgd@cs.bu.
Slein, et. al. Informational [Page 20]
RFC 2291 Distributed Authoring and Versioning February 1998
9. Full Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Slein, et. al. Informational [Page 21]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
