WEBDAV Working Group J. Slein, Xerox Corporation
INTERNET DRAFT J. Davis, Xerox Corporation
<draft-ietf-webdav-collection-reqts-03> November 10, 1998
Expires May 10, 1999
Requirements for Advanced Collection Functionality in WebDAV
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or made obsolete by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress".
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe),munnari.oz.au
(Pacific Rim), ftp.ietf.org (US EastCoast), or ftp.isi.edu (US West
Coast).
Distribution of this document is unlimited. Please send comments
to the Distributed Authoring and Versioning (WebDAV) working group
at <w3c-dist-auth@w3.org>, which may be joined by sending a
message with subject "subscribe" to <w3c-dist-auth-
request@w3.org>.
Discussions of the WEBDAV working group are archived at URL:
<http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth>.
Abstract
The base WebDAV protocol [WebDAV] provides basic support for
collections. It defines a MKCOL method for creating collections
and specifies how other HTTP and WebDAV methods interact with
collections. It supports internal members of collections, which it
defines as members whose URIs are immediately relative to the URI
of the collection.
This draft sets out requirements for more advanced, optional
collection functionality. It extends the base functionality in two
general directions: support for referential members, and support
for ordered collections. A separate WebDAV specification is
expected to define protocol elements providing the functionality
described here.
1 Terminology
The terminology used here follows and extends that in the base
WebDAV protocol specification [WebDAV].
Slein & Davis Page 1
INTERNET-DRAFT WebDAV Collection Requirements November 1998
Collection
A resource that contains member resources
Member Resource
A resource contained by a collection
Referential Resource (or Reference)
A resource that has no content of its own, but rather is
a reference to another resource
Ordinary Resource
A resource that is not a reference to another resource
Target Resource
The resource referenced by a referential resource
Direct Reference
A reference that is resolved by the server, giving the client
the illusion that it is operating directly on the target
resource
Redirect Reference
A reference that must be resolved by the client
Strong Reference
A reference whose referential integrity is guaranteed by the
server
Weak Reference
A reference whose referential integrity is not guaranteed by the
server
Referential Integrity
A server guarantees the integrity of a reference if it ensures
that the reference will not be broken, or enables the
reference's owner to ensure that the reference will not be
broken.
2 Introduction and Rationale
The simple collections that the base WebDAV specification supports
are powerful enough to be widely useful. They provide for the
hierarchical organization of resources, with mechanisms for
creating and deleting collections, copying and moving them,
locking them, adding resources to them and deleting resources from
them, and getting listings of their members. Delete, copy, move,
list, and lock operations can be applied recursively, so that a
client can operate on whole hierarchies with a single request.
Many applications, however, need more powerful collections. There
are two areas in particular where more powerful functionality is
often needed: referential members and ordering. This draft
details the additional functionality that is needed in these two
areas.
Slein & Davis Page 2
INTERNET-DRAFT WebDAV Collection Requirements November 1998
2.1 Referential Resources
Referential resources make it possible for many collections, on the
same or different servers, to share the same resource. Because
the collections share the resource by referencing it, only one
physical copy of the resource need exist, and any changes made in
the resource are visible from all the collections that reference
it.
So, for example, the mathematics department at one university can
create a collection of resources on fractals that contains some
local resources, but also references resources at several other
universities.
In another scenario, a manufacturing company develops and maintains
its product maintenance manuals on the Web. There is a separate
collection for each product manual. Each manual is divided into
sections, one section for every product component. Since many of
the companys products contain some of the same components, many of
the product maintenance manuals have sections in common. Each
manual may have some unique sections, which are internal members of
its collection. But for product components that are common to
multiple products, the manual has a referential member that
references a resource in a shared library.
Strong references and weak references are both useful in different
contexts. Some applications cannot tolerate broken links.
A software development application, for example, must be able to
rely on the integrity of references to component modules. Such
applications must be able to request strong references. Other
applications may want to reference target resources on multiple
servers, where referential integrity cannot be guaranteed, and may
be less concerned about possible broken references. Both strong
references and weak references should eventually be supported by
WebDAV.
Similarly, both redirect and direct references may be useful. Each
of these types of references is implemented in existing systems.
Existing HTTP servers are capable of supporting both types of
references. In effect, redirect references give clients access to
the reference itself, and allow the reference to bear properties.
Direct references, once created, simplify access to the target
resource by hiding from clients the fact that there is a reference
mediating between the client and the target resource.
2.2 Ordered Collections
For many applications, it is useful to be able to impose an
ordering on a collection. In the product manual application
above, the sections of each manual may be ordered so that they can
be printed together as a book. A configuration management
application might use a collection to represent a version series,
in which case the "derives from" relationship might be represented
as an ordering on the collection.
Slein & Davis Page 3
INTERNET-DRAFT WebDAV Collection Requirements November 1998
A collection ordering may sometimes be based on property values.
An example of such an ordering is one that is alphabetical by
authors last name, or one from most recent to oldest last-
modified-date. An ordering need not be based on property values,
however. A professor may order a collection of course readings in
the sequence that makes sense to coordinate them with her lectures,
where there is no property on the member resources that could be
used to create this ordering. This set of requirements is
primarily concerned with orderings that are not based on property
values.
Another useful distinction is between server-maintained and
client-maintained orderings. In server-maintained orderings, the
server enforces the semantics of the ordering by placing each
collection member at the appropriate position in the ordering;
clients cannot alter the ordering. In client-maintained orderings,
the client places each collection member in the ordering based on
its understanding of the semantics of the ordering; the server
does nothing to validate the client's positioning of the member
in the ordering. This set of requirements is concerned only with
client-maintained orderings.
WebDAV already provides tools that could be used for creating and
maintaining ordered collections. For example, using only the base
WebDAV specification, an application could create a WebDAV property
called "Order" on a collection resource. The value of this
property might be a list of the URIs of the collection members.
What the base WebDAV specification does not do is standardize a
single way to represent orderings for collections.
Different applications and services should be able to operate on
the same collection without private agreements about how to manage
and examine its order. To make this possible, there needs to be a
standard way to manipulate and retrieve the order of a collection,
and a standard representation of the ordering.
In any situation where collaborative management of a collection
takes place, and different authoring tools or WebDAV servers might
be used by the collaborators, standardization is important. It is
also important where a different tool may be used to view the
collection from the one that was used to create it.
So for example, two users from different organizations, using
different authoring tools, are working together to create a
collection. One of the tools uses a property on the collection
called "Order" to store an ordering of the collection. The other
tool uses a property on the member called "SequenceNumber". If
each user adds some members to the collection, there will be no
reliable ordering.
3 Requirements
3.1 Referential Resources
Slein & Davis Page 4
INTERNET-DRAFT WebDAV Collection Requirements November 1998
Requirements 3.1.1 - 3.1.8 apply to referential resources in
general. Requirements 3.1.9 - 3.1.12 apply to referential
resources only in the context of collections. Requirements
3.1.13 - 3.1.15 apply only to redirect references. Requirements
3.1.16 - 3.1.19 apply only to direct references. Requirements
3.1.20 - 3.1.24 relate to strong references and guarantees of
referential integrity.
3.1.1 A single target resource may be referenced by multiple
referential resources.
This is the primary benefit that referential resources bring.
They allow resources to be shared by multiple collections, which
may reside on the same server as the shared resource or on other
servers.
3.1.2 It is possible to create a referential resource.
3.1.3 It is possible to delete a referential resource.
It is important to note that this is a different operation from
deleting the references target resource. It must be possible to
delete a reference without deleting its target.
3.1.4 It is possible to set and retrieve the properties of a
reference, distinct from those of its target.
There are properties like "who created this reference" and "when
was this reference created", "what type of reference is this", and
"is referential integrity maintained for this reference" that
clearly belong to the redirect reference, and not to its target
resource, which may be referenced by many different referential
resources. Clients must be able to set properties on a reference,
and retrieve the properties of a reference.
3.1.5 Operations on a target resource do not affect references to it
except as needed to enforce referential integrity.
We do not expect operations on a target to affect references to
it. Locking a target does not cause the references to it to be
locked. Modifying the properties of a target does not cause
changes in the properties of references to it. Etc.
This requirement is qualified to allow for strong references. For
strong references, some operations on targets must cause changes in
the references to them. For example, if the target of a strong
reference is moved, the reference must change to reflect the new
location of the target.
3.1.6 For any target resource, it is possible to request a list of
the references to it.
There are many scenarios that use this capability. On a server
that does not provide strong references, a client may, as a good
citizen, want to check for references before deleting a resource.
Slein & Davis Page 5
INTERNET-DRAFT WebDAV Collection Requirements November 1998
Some servers enforce referential integrity by blocking deletes
for resources that have references to them. In this case, a client
may need to discover the references in order to delete them before
deleting their target.
3.1.7 A plain HTTP 1.1 browser is able to use a referential
resource to access its target.
This minimal level of compatibility with older browsers is needed
to make deployment of WebDAV collection functionality feasible.
References are a new type of resource whose main purpose is to
allow ordinary resources to be shared by multiple collections.
Although WebDAV clients may be needed to create and manipulate
these new resources, older clients should be able to read and
make use of the collections built using references.
3.1.8 There is no requirement that references be acyclic.
From a practical standpoint, servers generally cannot control what
happens on other servers. If a reference R on one server points to
a target T on another server, R's server cannot prevent T from
being changed to point back to R. In addition, there may be
applications where cyclic references are desirable.
3.1.9 A listing of the members of a collection shows both its
ordinary members and its referential members.
A listing of collection members with Depth = 1 or Depth = infinity
shows all members of the collection, whether ordinary or
referential. It follows from the definitions of redirect and
direct references that their behaviors in a listing of collection
members will differ from each other.
For redirect references, the reference itself, and not its target,
will be listed. If Depth = infinity, the listing will not
follow references into any collections to which they may refer.
This is to minimize the risk of being caught in a circle of
references or a long chain of references.
For direct references, the target will be listed. If Depth =
infinity and the target is a collection, the members of the target
collection will also be listed.
3.1.10 Multiple referential resources with the same target may reside
in the same collection.
It is often useful to allow the same resource to be referenced in
a collection multiple times. Typically, these are cases where the
collection is ordered. Consider a case where a collection
represents a book, with one member resource for each page in the
book. A particular graphic needs to appear in several places in
the book, and so needs to appear in the collection several times.
3.1.11 A reference and its target may both be in the same collection.
Slein & Davis Page 6
INTERNET-DRAFT WebDAV Collection Requirements November 1998
In the example just described, the collection might contain the
graphic as an ordinary member, which is also referenced by
referential members of the same collection so that it can appear
multiple times in the book.
3.1.12 For any target resource, it is possible to discover what
collections contain it by reference.
Though generally useful, this capability is especially critical
for Document Management Systems that populate collections entirely
with references. Users of these systems may wish to see what
collections a particular resource belongs to, and to be able to
navigate to any of those collections.
3.1.13 Operations on a redirect reference do not affect its target
resource except as needed to enforce referential integrity.
This requirement is really a restatement of the definition of
a redirect reference. There are many reasons for wanting to
support this sort of resource.
Redirect references allow clients to operate on the referential
resource itself. For example, they can store properties on the
reference distinct from those on its target. If requests to the
referential resource were automatically redirected to its target
resource, this would not be possible.
Passing operations through to the target resource exposes
servers to the risks of circular references and long chains of
references that refer to other references.
In addition, passing operations through to the target resource can
be problematic if the referential resource and the target resource
are on different servers. Issues about what credentials to use
would need to be addressed.
This requirement is qualified to allow for strong references.
Strong references are those whose referential integrity is
guaranteed by the server. Requirement 3.1.18 makes it possible
that some servers will support strong references. For some
implementations of strong references, operations on the
references may cause changes in their targets. For example, if a
server maintains a list of the strong references to a target in a
property on the target resource, creating or deleting a strong
reference will cause a change in this property of the target.
3.1.14 For any redirect reference, it is possible to obtain
the URI of its target resource.
This allows clients to resolve redirect references themselves
in order to operate on the target resources.
3.1.15 For any resource, it is possible to discover whether it is a
redirect reference.
Slein & Davis Page 7
INTERNET-DRAFT WebDAV Collection Requirements November 1998
Since operations on redirect references are not passed through to
their targets, it is important for clients to be able to discover
which resources are redirect references. Then the client can
resolve the references in order to perform operations on their
targets.
3.1.16 Operations on a direct reference, except for those that alter
the membership of the collection that contains it, are passed
through to its target resource.
The purpose of references is to allow clients to create collections
that include existing resources without making physical copies of
those resources.
The purpose of direct references is to simplify operations for
clients by hiding from them the fact that a reference is mediating
between their requests and the target resource. To achieve this
purpose, most operations must be passed through to the target
resource.
However, operations that alter collection membership should not be
passed through to the target. Examples of these operations are
delete and move operations. The purpose of references is to allow
collections to include resources that exist elsewhere. Deleting or
moving a resource from such a collection should affect only that
collection, not any other collection of which the target resource
is a member.
3.1.17 For any resource, it is possible to discover whether it is a
direct reference.
Since the behavior of direct references is radically different from
the behavior of redirect references, it is important for clients
to be able to discover whether they are operating on a direct
reference. The client must have a way of finding out whether the
properties it sets will be stored on the reference or on its
target, etc.
3.1.18 It is not possible for a client to set or retrieve properties
of a direct reference, distinct from those of its target.
Since all operations except those affecting collection membership
are passed through to the target, the client can operate only on
properties of the target.
3.1.19 When creating a direct reference, it is possible to request
that the location of its target be hidden.
The area of the server where the target is located may contain
other, sensitive information whose existence the owner of the
reference wants to keep secret.
3.1.20 It is possible to request creation of a referential resource
that the server will guarantee to have referential integrity.
Slein & Davis Page 8
INTERNET-DRAFT WebDAV Collection Requirements November 1998
For some applications, broken references are unacceptable.
Breakage may be unavoidable when a target resource resides on a
different server from the referential resource that references it.
Servers can, however, maintain the integrity of referential
resources when they receive MOVE or DELETE requests for target
resources under their own control. For applications that require
referential integrity, it must be possible to specify in a
request for creation of a referential resource that its integrity
be guaranteed. A referential resource whose integrity is
guaranteed by the server is called a strong reference.
3.1.21 It is possible when creating a reference to request that the
server not enforce referential integrity for that reference.
In some circumstances users may want to be able to create
dangling references. For example, an administrator may want to
populate a directory with references before their target resources
have been created. When updating a site, he may want to remove
target resources for a short period without having to destroy and
recreate all the references to them.
3.1.22 These requirements are silent as to what policy should be used
to ensure referential integrity.
A server guarantees the integrity of a reference if it ensures that
the reference will not be broken, or enables the reference's owner
to ensure that the reference will not be broken.
There are many policies that could be adopted to fulfill this
commitment. For example, a server could refuse to allow a target
to be deleted while there are strong references to the target.
Alternatively, the server could delete the strong references along
with the target. Alternatively, the server could flag the strong
references "Target Deleted" when it deletes the target. Or the
server could notify the owners of all strong references when it
deletes a target, allowing the owners to take whatever action they
wish. These requirements say nothing about what policy should be
used to enforce referential integrity.
3.1.23 It is possible to discover whether a referential resource is a
strong reference or a weak reference.
Knowing whether a referential resource is strong or weak allows a
client to intelligently choose its own strategy for working with
referential resources. For example, if a client does not know
whether a particular reference is strong or weak, it may choose to
recreate that referential resource to be sure of referential
integrity; but if it knows that the reference is strong, it will
not bother to do this.
3.1.24 It is possible to discover whether a resource is the target of
a strong reference.
This requirement insures that both ends of a referential integrity
relationship have the same information available.
Slein & Davis Page 9
INTERNET-DRAFT WebDAV Collection Requirements November 1998
3.2 Ordered Collections
3.2.1 Ordering is sufficiently standardized that different
applications and servers can operate on the same ordering
without private agreements.
Applications and servers can apply an ordering to a collections
members or discover the ordering of a collection's members without
private agreements. They can also modify an ordering, at least
with the help of a human user for semantics (See 3.2.3), without
private agreements.
This is the minimum that is needed to support collaborative
management of an ordered collection, where different authoring
tools might be used by the collaborators. It is also what allows
a different tool to be used to view the collection from the one
that was used to create it. Finally, it is needed in order for
servers to list collection members in order, as required by 3.2.6.
3.2.2 A collection is not required to be ordered.
A WebDAV server may support collections without supporting ordered
collections. Even if the server supports ordered collections,
there is no requirement that every collection on that server be
ordered. Since these requirements concern only client-maintained
orderings, clients will decide whether any given collection is
ordered.
The remaining requirements apply only to collections that are
ordered.
3.2.3 The semantics of an ordering are discoverable.
The semantics of an ordering is the principle or rule according to
which the collection members are ordered. This principle must be
discoverable if someone (or some application) other than the one
that created a collection is to be able to add a member to it and
determine where it makes sense to position the new member in the
collection's ordering.
In some cases it may be possible for the semantics to be expressed
in a machine-usable way, so that an application could automatically
position a new member in the ordering. In other cases the
semantics may require a human user to apply them. In either case
they should be discoverable.
3.2.4 Each collection member appears in the ordering exactly once.
It would be possible to support orderings that contain only a
subset of the collection members, or orderings that can contain
a single collection member more than once. It is not necessary,
however, since the same result can be achieved by creating a
new collection with exactly the desired members, and including
each member of the new collection in its ordering exactly once.
Slein & Davis Page 10
INTERNET-DRAFT WebDAV Collection Requirements November 1998
This requirement implies that the server will check, whenever a
member is added to an ordering, to make sure that it is not already
in the ordering. It also implies that either the protocol itself
or the server will insure that whenever a new member is added to
a collection, it is also added to the collection ordering.
3.2.5 An ordering does not include any resources that are not members
of the collection.
The server must insure that when a member is removed from a
collection, it is also removed from the collection's ordering.
3.2.6 When a client requests a listing of the members of a
collection, this listing is returned in the order specified by
the collection.
This requirement frees clients from the burden of applying the
ordering to the member listing.
3.2.7 It is possible to order the members of a collection in a
client-specified way, not necessarily based on property values.
Orderings that are based on property values can be obtained by a
search protocol that supports sorted result sets. This set of
requirements is not concerned with such orderings. It is intended
primarily to support orderings that cannot be obtained by sorting
on property values.
A property is not always available that can serve as the basis for
a desired ordering. For example, a professor may wish to order a
collection of course readings in the sequence that coordinates the
readings with her lectures. But the properties of resources at the
Web site are standardized and do not include one that is
appropriate to use for this purpose.
Even if the professor in the example could create a
"sequencenumber" property to use in sorting the collection, this
strategy would be undesirable unless she knew she would not be
adding any readings or changing the order of her lectures once the
values of sequencenumber were set. Inserting a new reading into
the sequence would require updating the sequencenumber property of
each reading that comes after the new one in the sequence. Ordered
collections are intended to support this sort of case, where
sorting based on a property value is impossible or inefficient.
3.2.8 A single ordering may contain both ordinary and referential
resources.
The professor in the previous example may store some readings as
internal resources of the collection, but reference others from
servers at another university. Nevertheless, all the readings
need to be included in the ordering for her students use.
4 Acknowledgements
Slein & Davis Page 11
INTERNET-DRAFT WebDAV Collection Requirements November 1998
This draft has benefited from thoughtful discussion by Jim Amsden,
Alan Babich, Steve Carter, Geoffrey Clemm, Ellis Cohen,
Bruce Cragun, Spencer Dawkins, Rajiv Dulepet, David Durand,
Chuck Fay, Roy Fielding, Yaron Goland, Fred Hitt, Alex Hopmann,
Marcus Jager, Chris Kaler, Rohit Khare, Daniel LaLiberte,
Steve Martin, Surendra Koduru Reddy, Sam Ruby, Nick Shelness,
John Stracke, John Turner, Jim Whitehead, and others.
5 References
[WebDAV] Y. Y. Goland, E. J. Whitehead, Jr., A. Faizi,
S. R. Carter, D. Jensen, "HTTP Extensions for Distributed
Authoring - WebDAV." work in progress,
Draft-ietf-webdav-protocol-09. Microsoft, U.C. Irvine, Netscape,
Novell. November, 1998.
6 Authors' Addresses
J. Slein
Xerox Corporation
800 Phillips Road
Webster, NY 14580
Email: jslein@crt.xerox.com
J. Davis
Xerox Corporation
3333 Coyote Hill Road
Palo Alto, CA 94304
Email: jdavis@parc.xerox.com
Expires May 10, 1999
Slein & Davis Page 12
Datatracker
draft-ietf-webdav-collection-reqts-03
This is an older version of an Internet-Draft whose latest revision state is "Expired".
| Document | Document type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| RFC stream |
|
||
| Other formats | |||
| Additional resources | Mailing list discussion |