[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05                                             
     WEBDAV Working Group                       J. Slein, Xerox Corporation
     INTERNET DRAFT                             J. Davis, Xerox Corporation
     <draft-ietf-webdav-collection-reqts-02>                  July 20, 1998
     Expires January 20, 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 [Goland et al., 1998] 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 [Goland et al., 1998].


Slein & Davis                                                    Page 1
INTERNET-DRAFT            WebDAV Collection Protocol          July 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 has the property that operations on it are
           passed through to its target

        Indirect Reference
           A reference that has the property that operations on it do
           not affect its target

        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 Protocol          July 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.

        A manufacturing company develops and maintains its product
        maintenance manuals on the Web, with a separate collection for
        each product manual.  Each manual is divided into sections, one
        section for every product component.  Since many of the company’s
        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, although the complexities of enforcing referential
        integrity make it unlikely that strong references will be supported
        in the short term.

        Similarly, both indirect 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, indirect 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.  Although it
        is desirable for WebDAV to support both indirect and direct
        references, the difficulties of supporting direct references make
        it unlikely that they will be supported in the short term.

     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

Slein & Davis                                                    Page 3
INTERNET-DRAFT            WebDAV Collection Protocol          July 1998

        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.

        A collection ordering may sometimes be based on property values.
        An example of such an ordering is one that is alphabetical by
        author’s 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.

Slein & Davis                                                    Page 4
INTERNET-DRAFT            WebDAV Collection Protocol          July 1998


     3  Requirements

     3.1  Referential Resources

        Requirements 3.1.1 - 3.1.7 apply to referential resources in
        general.  Requirements 3.1.8 - 3.1.10 apply to referential
        resources only in the context of collections.  Requirements
        3.1.11 - 3.1.14 apply only to indirect references.  Requirements
        3.1.15 - 3.1.17 apply only to direct references.  Requirements
        3.1.18 - 3.1.20 relate to strong references and guarantees of
        referential integrity.  The initial release of the WebDAV
        collections protocol specification is expected to focus on indirect
        references and weak references.  It is not expected to satisfy
        either the requirements for strong references or the requirements
        for direct references.

     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 referential resource’s target resource.  It must
        be possible to delete a reference without deleting its target.

     3.1.4  A referential resource is itself a resource.

        This makes explicit what is suggested by several of the other
        requirements.  Requirement 3.1.14 in particular, that indirect
        references carry their own properties, forces referential resources
        to be resources.  WebDAV properties can belong only to resources.

     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.  For indirect references, locking a target does not cause the
        indirect references to it to be locked.  Modifying the properties
        of a target does not cause changes in the properties of indirect
        references to it.  Etc.  For direct references, this issue is moot,
        since clients cannot operate on them in any case except to create
        them or delete them.  Clients cannot view their properties or
        headers.

        Just as in 3.1.11 passing operations through to the target can be
        problematic, so here reflecting operations back to the referencing
        resource can be problematic if the referential resource and the

Slein & Davis                                                    Page 5
INTERNET-DRAFT            WebDAV Collection Protocol          July 1998

        target resource are on different servers.  Issues about what
        credentials to use would need to be addressed.

        This requirement must be qualified to allow for strong references,
        however.  For strong references, whether direct or indirect, 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  A plain HTTP 1.1 browser should be 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.7  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.8  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 if indirect and
        direct references that their behaviors in a listing of collection
        members will differ from each other.

        For indirect 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.9  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

Slein & Davis                                                    Page 6
INTERNET-DRAFT            WebDAV Collection Protocol          July 1998

        the book, and so needs to appear in the collection several times.

     3.1.10 A reference and its target may both be in the same collection.

        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.11 Operations on an indirect reference do not affect its target
            resource except as needed to enforce referential integrity.

        This requirement is really a restatement of the definition of
        an indirect reference.  There are many reasons for wanting to
        support this sort of resource.

        Indirect 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 must be qualified to allow for strong references,
        however.  Strong references are those whose referential integrity
        is guaranteed by the server.  Requirement 3.1.n 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.12 For any indirect referential resource, it is possible to obtain
            the URI of its target resource.

        This will allow clients to resolve indirect references themselves
        in order to operate on the target resources.

     3.1.13 For any resource, it is possible to discover whether it is an
            indirect reference.

        Since operations on indirect references are not passed through to
        their targets, it is important for clients to be able to discover
        which resources are indirect references.  Then the client can
        resolve the references in order to perform operations on their
        targets.

Slein & Davis                                                    Page 7
INTERNET-DRAFT            WebDAV Collection Protocol          July 1998


     3.1.14 It is possible for an indirect reference to carry its own
            properties, distinct from those of its target.

        There are properties like "who created this reference" and "when
        was this reference created" that clearly belong to the indirect
        reference, and not to its target resource, which may be referenced
        by many different referential resources.

     3.1.15 Operations on a direct reference, except for creation and
            deletion of the reference itself, are passed through to its
            target resource.

        This requirement is really a restatement of the definition of
        a direct reference.  There are several reasons for wanting to
        support this sort of resource.

        Direct references simplify operations for clients, hiding from them
        the fact that a reference is mediating between their requests and
        the target resource.

        Many existing systems, including HTTP servers, implement direct
        references.

        Supporting direct references does introduce issues that make it
        unlikely that WebDAV will support them in the short term.  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.

     3.1.16 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 indirect 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.17 It is not possible for a client to set or view properties of
            a direct reference, distinct from those of its target.

        Again, this follows from the definition of a direct reference.
        Since all operations except creating the reference and deleting
        the reference are passed through to the target, the client can
        operate only on properties of the target.

     3.1.18 It is possible to request creation of a referential resource
            that the server will guarantee to have referential integrity.

        For some applications, broken references are unacceptable.

Slein & Davis                                                    Page 8
INTERNET-DRAFT            WebDAV Collection Protocol          July 1998

        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.  If the server cannot honor this request, it must
        decline to create the referential resource.  A referential resource
        whose integrity is guaranteed by the server is called a strong
        reference.

     3.1.19 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.20 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.21 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.

     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 collection’s
        members or discover the ordering of a collection's members without

Slein & Davis                                                    Page 9
INTERNET-DRAFT            WebDAV Collection Protocol          July 1998

        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.

        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.

Slein & Davis                                                    Page 10
INTERNET-DRAFT            WebDAV Collection Protocol          July 1998


        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 makes sense to
        coordinate 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

        This draft has benefited from thoughtful discussion by Alan Babich,
        Steve Carter, Ellis Cohen, Spencer Dawkins, Rajiv Dulepet,
        Chuck Fay, Roy Fielding, Yaron Goland, Fred Hitt, Alex Hopmann,
        Rohit Khare, Daniel LaLiberte, Steve Martin, Surendra Koduru Reddy,
        Sam Ruby, Nick Shelness, John Stracke, John Turner, Jim Whitehead,
        and others.

     5  References

Slein & Davis                                                    Page 11
INTERNET-DRAFT            WebDAV Collection Protocol          July 1998


        [Goland et al., 1998] Y. Y. Goland, E. J. Whitehead, Jr., A.
        Faizi, S. R. Carter, D. Jensen, "Extensions for Distributed
        Authoring on the World Wide Web - WebDAV." work in progress,
        Draft-ietf-webdav-protocol-08. Microsoft, U.C. Irvine, Netscape,
        Novell. April, 1998.

     6  Authors' Addresses

        J. Slein
        Xerox Corporation
        800 Phillips Road
        Webster, NY 14580
        Email: slein@wrc.xerox.com

        J. Davis
        Xerox Corporation
        3333 Coyote Hill Road
        Palo Alto, CA 94304
        Email: jdavis@parc.xerox.com

     Expires January 20, 1999
Slein & Davis                                                    Page 12