WEBDAV Working Group                                   J. Slein Slein, Xerox
     INTERNET DRAFT                                         J. Davis, Xerox Corporation
     <draft-ietf-webdav-collection-protocol-00>                June 5,
     <draft-ietf-webdav-collection-protocol-01>          A. Babich, FileNet
                                              E.J. Whitehead Jr., UC Irvine
                                                              July 31, 1998
     Expires December 5, 1998 January 31, 1999

			WebDAV Advanced Collections Protocol

     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] [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 only internal members of collections, which it
        defines as members whose URIs are immediately relative to the URI
        of the collection.

        Many applications, however, need more powerful collections.  There
        are two areas in particular where more powerful functionality is
        often needed: referential members resources and ordering.

        This draft specifies extensions to the base WebDAV protocol to
        support these more powerful collections.

    Table of Contents

	1	Terminology					3
	2	Introduction					4
	3	Referential Resources				4
	  3.1	  Scope						4
	  3.2	  Overview					6
	  3.3	  Creating Referential Resources		6
	    3.3.1	The MKREF Method			6
	    3.3.2	Status Codes				7
	    3.3.3	Example					8
	  3.4	  Deleting Referential Resources		8
	    3.4.1	The DELREF Method			8
	    3.4.2	Status Codes				8
	    3.4.3	Example					8
	    3.4.4	Design Rationale			8
	  3.5	  Listing Referential Members of a Collection	9
	  3.6	  Other WebDAV Operations on Indirect References	9
	  3.7	  HTTP Operations on Indirect References 	10
	  3.8	  Operations on Targets of References		11
	4	Ordered Collections				11
	  4.1	  Overview					11
	  4.2	  Creating an Ordered Collection		11
	    4.2.1	Overview				11
	    4.2.2	Status Codes				12
	    4.2.3	Example					12
	  4.3	  Setting the Position of a Collection Member	12
	    4.3.1	Overview				12
	    4.3.2	Status Codes				13
	    4.3.3	Examples				13
	  4.4	  Changing the Semantics of a Collection Ordering	14
	  4.5	  Changing the Position of a Collection Member	14
	    4.5.1	The ORDERPATCH Method			14
	    4.5.2	Status Codes				14
	    4.5.3	Example					14
	    4.5.4	Design Rationale			15
	5	New Headers					16
	  5.1	  Ref-Target Request Header			16
	  5.2	  Ref-Integrity Request Header			16
	  5.3	  Pass-Through Request Header			17
	  5.4	  Resource-Type Response Header			17
	  5.5	  Ordered Request Header			17
	  5.6	  Position Request Header			18
	6	New Properties					18
	  6.1	  reftarget Property				18
	  6.2	  refintegrity Property				18
	  6.3	  passthrough Property				19
	  6.4	  orderingtype Property				19
	7	New XML Elements				20
	  7.1	  reference XML Element				20
	  7.2	  weak XML Element				20
	  7.3	  arbitrary XML Element				20
	  7.4	  order XML Element				20
	  7.5	  member XML Element				20
	  7.6	  position XML Element				21
	  7.7	  first XML Element				21
	  7.8	  last XML Element				21
	  7.9	  before XML Element				21
	  7.10	  after XML Element				22
	8	Compliance					22
	  8.1	  Class 3					22
	  8.2	  Class 4					22
	9	Dependencies on Other Specifications		22
	10	Security Considerations				22
	  10.1	  Redirect Loops				23
	  10.2	  References and Denial of Service		23
	  10.3	  Malicious Modifications of Ordering		23
	  10.4	  Denial of Service and DAV:orderingtype	23
	11	Internationalization Considerations		23
	12	IANA Considerations				24
	13	Copyright					24
	14	Intellectual Property				24
	15	Acknowledgements				24
	16	References					24
	17	Authors' Addresses				25

1 Terminology

        The terminology used here differs from follows and extends that in the base
        WebDAV protocol specification [Goland et al., 1998], particularly in its
        definition of internal member resource. [WebDAV].

        Collection
           A resource that contains member resources

        Member Resource
           A resource contained by a collection

        Referential Member Resource (or Reference)
           A member resource that has no content of its own, but rather is
           a reference to another resource

        Strong Reference

        Ordinary Resource
           A reference whose referential integrity member resource that is not a reference to another resource

        Target Resource
           The resource referenced by a referential member of a collection

        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

        Internal Member Resource
        Referential Integrity
           A member resource that either has content server guarantees the integrity of its own or is
           empty, but is not a reference if it ensures
           that the reference will not be broken, or enables the
           reference's owner to another resource

        Target Resource
           The resource referenced by a referential member of a collection ensure that the reference will not be
           broken.

2 Introduction

        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 resources and ordering.

        Referential members 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.

        It is useful for many applications to be able to impose an
        ordering on a collection. Orderings may be based on property
        values, but they may be completely independent of any properties
        on the collection's member resources.  Orderings based on
        properties can be obtained using a search protocol [DASL], but
        orderings not based on properties need some other mechanism.

        Since these two areas are independent of each other, servers may
        elect to comply with the Referential Members Resources section of this
        specification or with the Ordered Collections section or both.
        A server MUST advertise its compliance through its response to
        an OPTIONS request, as specified in [Goland et al., 1998]. [WebDAV].  New values for the
        DAV header are defined in Section 8 below to support this
        requirement.

3 Referential Members Resources

3.1 Overview

        A referential member of a collection is a resource that has no
        content of its own, but instead Scope

        [WebDAVReq] distinguishes between "weak" references another resource.  The
        resource it and "strong"
        references, and also between "indirect" references may be in the same collection or anywhere
        else. and "direct"
        references.  This target resource may be a collection or a simple
        resource or another referential member of a collection, or any
        other sort of resource specification supports only weak references and
        indirect references, but is designed so that may it can be defined extended
        to support strong references and direct references in the future.  A
        resource may be referenced

        Strong references are references whose integrity is guaranteed by any number of referential members of
        collections. (Req 3.1.1 - 3.1.3, 3.1.6, 3.1.15)

        Since a referential member of a collection
        the server; weak references are those whose integrity is a resource, it can
        have properties just like any other resource.  These properties not
        guaranteed.  Strong references and weak references are
        completely independent of the properties on its target resource
        (Req 3.1.9). both useful
        in different contexts.  Some applications cannot tolerate broken
        links.  A new DAV:reftarget property has as its value software development application, for example, must be
        able to rely on the
        URI integrity of the references to component modules.
        Such applications must be able to request strong references.  Other
        applications may want to reference target resource (3.1.6).

    3.2 Creating Referential Members of a Collection (Req 3.1.7)

(Add justification for using resources on multiple
        servers, where referential integrity cannot be guaranteed, and may
        be less concerned about possible broken references.

        Several considerations led to the extension mechanisms specified in
[Nielsen et al., 1998] "Mandatory Extensions decision not to support strong
        references in HTTP".)

        Clients MUST use the M-PUT method current specification.  First, there are many
        possible policies that applications and services might use to create a
        enforce referential member integrity.

	   o Delete strong references when their targets are deleted.

	   o Decline to delete targets of a collection.  (Clients MUST NOT use a plain PUT strong references.

           o Notify strong references when their targets have been
             deleted.

           o Let owners of resources decide whether strong references to create a
        referential member
             them are allowed.

        There appears to be no common practice in this area.  Moreover,
        some of the policies have significant security risks.

           o Moving a collection.  A PUT request with a
        request-URI of an existing collection will fail.)  The
        request-URI target of strong references could be a security
             risk to the M-PUT request identifies owner of the collection to which target by revealing secret
             locations on the new member is to target's server.

           o A strong reference could be added. The server recognizes a request security risk to
        create a referential member, rather than an internal member, by the
        presence owner of
             the Referential-Member header. This header identifies
        the referential member being added. reference by revealing secret locations on his server.

           o The Ref-Target header contains
        the URI presence of the strong references to resources on a server
             could make it impossible to reclaim space on that server
             by moving or deleting those target resource.

        An optional Ref-Integrity request header can be used resources.

        These considerations together led to tell the
        server decision not to create support
        strong references in the referential member unless it can guarantee
        referential integrity (Req 3.1.11).

        An optional Position request header supports ordering by allowing
        the client to specify where the new referential member is short term.

        Operations on indirect references do not affect their target
        resources, whereas operations on direct references are passed
        through to their targets.  Both indirect and direct references may
        be
        placed useful.  Each of these types of references is implemented in the collection's ordering.  (This header can also be used
        with M-PUT
        existing systems.  Existing HTTP servers are capable of supporting
        both types of references.  In effect, indirect references give
        clients access to create an internal collection member at a specific
        position in the ordering.)

        When a server processes an M-PUT request with the
        Referential-Member header, it MUST set reference itself, and allow the DAV:resourcetype
        property [defined in Goland et al, 1998] of reference to
        bear properties.  Direct references, once created, simplify access
        to the new target resource to be
        refmember (Req 3.1.12).

        When by hiding from clients the fact that there
        is a server processes an M-PUT request with reference mediating between the
        Referential-Member header, it MUST set client and the DAV:reftarget property target
        resource.  They also make access to the target more efficient,
        eliminating a round trip required by indirect references to get the
        URI of the target resource (Req 3.1.6).

        When a server processes an M-PUT request with the
        Referential-Member header, resource.

        Again, it MUST set was believed that supporting direct references would be
        too difficult in the DAV:refintegrity
        property (Req 3.1.13).

        If DAV:refintegrity short term.  Although convenient, they add no
        functionality beyond what is T, the server MUST insure that available through indirect references.
        Existing systems often implement hybrids of direct and indirect
        references, for which some operations are passed through to the
        target
        resource's DAV:refsource property reflects while others are not.  This fact muddies the new, strong
        reference to issue of what
        exactly WebDAV should support.  It also suggests that resource (Req 3.1.14).

        The server SHOULD ignore any content submitted with a request the
        definition of direct references as those for which operations are
        passed through to
        create their targets may not really capture a referential member class of
        references that are useful. [what else?]

        Consequently, it was decided not to support direct references in a collection.

        If an M-PUT request is submitted for an existing collection
        member,
        the existing member's content and properties will be
        overwritten.  This behavior short term.

3.2 Overview

        A referential resource is analogous to the behavior of a plain
        HTTP PUT method.  If the Position header is absent in this case,
        the server MUST leave the member at resource that has no content of its previous position
        own, but instead references another resource.  The resource it
        references may be in the same collection ordering.  If the Position header is present, the server
        MUST remove it from its previous position, and then insert it at
        the requested position.  (Req 3.2.4)  If the updated referential
        member changes from weak to strong or from strong to weak, the
        server MUST update anywhere else.  This
        target resource may be a collection or a simple resource or another
        reference, or any other sort of resource that may be defined in the target's DAV:refsource property to reflect
        future.  A resource may be the change.

        Example:

        Request:

        M-PUT /~whitehead/dav/ HTTP/1.1
        HOST: www.ics.uci.edu
        Man: "DAV:Coll-headers"
        Referential-Member: spec08.ref
        Ref-Target: http://www.ics.uci.edu/i-d/draft-webdav-protocol-08.txt
        Ref-Integrity: T
        Position: After requirements.html
        Content-Length: 0

        Response:

        HTTP/1.1 200 OK

    3.3 Deleting Referential Members target of any number of a Collection (Req 3.1.8)

        DELETE is the appropriate method to use to remove a referential
        member from a collection.  DELETE on
        resources.

        Since a referential member has no
        affect on its target resource unless the referential member is a
        strong reference.  In this case, the server MUST insure that the
        DAV:refsource property resource, it can have properties
        just like any other resource.  These properties are completely
        independent of the properties on its target resource reflects this change.

        Example:

        Request:

        DELETE /~whitehead/dav/spec08.ref HTTP/1.1
        HOST: www.ics.uci.edu

        Response:

        HTTP/1.1 200 OK

        The referential member spec08.ref resource.  A new
        DAV:reftarget property of collection /~whitehead/dav/ referential resources has been deleted, but as its target resource on www.ietf.org still
        exists.  The DAV:refsource property value
        the URI of http://www.ics.uci.edu/
        i-d/draft-webdav-protocol-08.txt has been updated
        so that the target resource.

        To make it no longer shows a reference possible to distinguish referential resources from spec08.ref.

    3.4 Listing Referential Members of a Collection (Req 3.1.10)

        Since
        ordinary resources, a referential member new value of a collection is just a resource in the collection, a listing of members DAV:resourcetype property
        is defined here.  The DAV:resourcetype property of the collection shows all referential members along with internal members.  That is, a
        PROPFIND on a collection resource with Depth = 1 or infinity
        resources MUST
        return a response XML element have the value reference.

        Although only weak, indirect references are currently supported,
        two new DAV properties are defined in anticipation of future
        support for each internal member strong references and for each direct references.  These
        properties, DAV:refintegrity and DAV:passthrough, will allow
        clients to distinguish between weak and strong references, and
        between indirect and direct references.  All referential member.

        If Depth = infinity resources
        MUST have these properties.  Although the only value currently
        defined for DAV:refintegrity is weak, other values may be defined
        in the PROPFIND request, future.  Although the server SHOULD NOT
        follow references into any collections to which they only value currently defined for
        DAV:passthrough is none, other values may refer.

    3.5 Other Operations on be defined in the future.

3.3 Creating Referential Members Resources

3.3.1 The MKREF Method

	Referential resources are created using the MKREF method.  The
        request-URI of a Collection

        In general, operations that modify resources, when applied the MKREF request identifies the resource to a
        referential member be
        created.  The required Ref-Target header contains the URI of a collection, affect the referential member,
        not its
        target resource (Req 3.1.4).  There resource.

        An optional Ref-Integrity request header is defined below,
        primarily for future support for strong references.  The only one exception
        to value
        currently defined for this general rule: For strong references, operations on the
        referential member header is "DAV:weak",although other
        values may cause changes to be used by private agreement.  "DAV:weak" is the refsource property
        of its target resource.

        A LOCK operation on a referential member of a collection locks default
        value if the
        referential member, header is not present.

        An optional Pass-Through request header is defined below, primarily
        for future support for direct references.  Currently, its target.  A LOCK on the collection with
        Depth = 1 or infinity locks the referential members along with all
        the value is
        always empty, although other members of values may be used by private
        agreement.  The default value is empty if the collection, but header is not
        present.

        An optional Position request header supports ordered collections by
        allowing the targets of client to specify where the
        referential members.

        A PROPPATCH on a new referential member of a collection modifies the
        properties of the referential member, not is
        to be placed in the properties of its
        target resource.

        A MOVE operation on a referential member of a collection's ordering.  (This header can also
        be used with PUT to create an ordinary collection moves the
        referential member to at a different collection, but has no effect on
        the location of its target. If
        specific position in the referential member was ordering.)

        When a strong
        reference at its old location, the server processes a MKREF request, it MUST remove its old URI
        from set the list
        DAV:resourcetype property (defined in [WebDAV]) of the target's refsource property.  If the client
        wants the referential member at its new location resource
        to be DAV:reference.

        When a strong
        reference, server processes a MKREF request, it must use the M-MOVE method with MUST set the Ref-Integrity
        header
        DAV:reftarget property to perform the move.  If URI of the target resource.

        When a server is able to comply with
        the processes a MKREF request, it MUST add the referential member's new URI to the
        list in set the refsource
        DAV:refintegrity property of its target.

        A COPY operation on a referential member copies the referential
        member, not its target resource, to another collection.  If and the DAV:passthrough property.

        The client wants MUST NOT send any content with the referential member in the new location to be a
        strong reference, it must MKREF request, and so
        MUST NOT use the M-COPY method with the
        Ref-Integrity header to perform the copy. Content-Length or Transfer-Encoding headers.  (See
        [HTTP].)

        If a MKREF request is submitted for an existing resource, the server
        existing resource's content and headers will be overwritten.  This
        behavior is able analogous to comply with the request, it MUST add the URI behavior of the HTTP PUT method.  Live
        properties may get new copy to values at the list server's discretion; dead
        properties will retain their existing values.  If the Position
        header is absent in this case and the refsource property of collection is ordered, the
        server MUST leave the member at its target.

        A PUT operation (or an M-PUT without a Referential-Member header)
        creates an internal previous position in the
        collection member, not a referential member. ordering.  If a strong reference the Position header is replaced by an internal member as a result
        of a PUT or M-PUT, present and the
        collection is ordered, the server MUST remove it from its previous
        position, and then insert it at the requested position.

3.3.2 Status Codes

        201 Created
        200 OK: modified an existing resource
        409 Conflict: no resource at Ref-Target
        unrecognized / unsupported value for Ref-Integrity
        unrecognized / unsupported value for Pass-Through
        400 Bad Request: content not allowed
        409 Conflict: Position Before / After a URI of that is not in this
                      collection
        400 Bad Request: Position Before / After self
        409 Conflict: Position header, but not an ordered collection
        425 Insufficient Space on Resource
        409 Conflict: Parent collection does not exist

3.3.3 Example

        Request:

        MKREF /~whitehead/dav/spec08.ref HTTP/1.1
        HOST: www.ics.uci.edu
        Ref-Target: <http://www.ics.uci.edu/i-d/draft-webdav-protocol-        08.txt>

        Response:

        HTTP/1.1 201 Created

        This request resulted in the creation of a new referential member from resource
        at www.ics.uci.edu/~whitehead/dav/spec08.ref, which points to the
        resource identified by the DAV:refsource Ref-Target header.  Its DAV:resourcetype
        property of its target.

        Similarly, operations that retrieve information, when applied is set to a
        referential member of a collection, retrieve information relating DAV:reference.  Its DAV:reftarget property is
        set to the referential member, not URI of its target resource.  A PROPFIND on
        a referential member returns  Its DAV:refintegrity
        property is set to the properties default value of DAV:weak.  Its
        DAV:passthrough property is set to the referential
        member, not the properties of its target resource.  A GET on a
        referential member of a collection returns its own content, which
        is the URI of its target resource, not the content of its target
        resource.

    3.6 Operations on Targets default value of EMPTY.

3.4 Deleting Referential Collection Members

        Operations Resources

3.4.1 The DELREF Method

        The new DELREF method is used to delete referential resources.
        DELREF on targets of a referential collection members have resource has no effect on the referential member unless the referential member is
        a strong reference.  When the its target of
        resource.

3.4.2 Status Codes

        200 OK
        405 Method Not Allowed: Request-URI is not a strong reference is
        MOVEd, the server MUST update the DAV:reftarget property of the
        404 Not Found: No resource at Request-URI

3.4.3 Example

        Request:

        DELREF /~whitehead/dav/spec08.ref HTTP/1.1
        HOST: www.ics.uci.edu

        Response:

        HTTP/1.1 200 OK

        The referential member to reflect resource /~whitehead/dav/spec08.ref has been
        deleted, but its new location.  When a client
        attempts target resource still exists.

3.4.4 Design Rationale

        The HTTP DELETE method can be used to delete indirect references,
        since by definition these references do not pass operations through
        to their targets.

        If direct references are supported in the future, however, a target of a strong reference, method
        distinct from the server
        MUST maintain referential integrity, either by HTTP DELETE method will be needed for deleting
        the
        strong reference at the same time, or by failing the request itself.  Since direct references do pass operations
        through to their targets, DELETE would delete the target.

(Provide an error code and response type to tell the client the value of target resource
        rather than the refsource property)

    4   Ordered Collections

        A new optional property DAV:ordering is defined to support ordered
        collections. (Req 3.2.1)  It reference itself.

        DELREF is a property only being introduced now in anticipation of collections, future needs,
        and can be used in all cases where a reference is not required to be present on deleted.

3.5 Listing Referential Members of a collection.  That is, even
        compliant servers may have Collection

        Since a mix referential member of ordered and unordered
        collections.  The client decides whether a particular collection is ordered or not. (Req 3.2.2)  The value DAV:ordering is an
        ordering-type (Req 3.2.3) followed by just a list of resource in
        the URIs collection, a listing of members of the
        collection's collection shows
        referential members along with ordinary members. Each  That is, a WebDAV
        PROPFIND request on a collection member, whether internal resource with Depth = 1 or
        referential, must be
        infinity MUST return a response XML element for each ordinary
        member and for each referential member.

        If Depth = infinity in the list exactly once (Req 3.2.4, 3.2.8),
        and PROPFIND request, the list must not include server MUST NOT
        follow indirect references into any resource that is not a member of
        the collection (Req 3.2.5).  Only one ordering can be attached collections to
        any collection (Req 3.2.5a).  Multiple orderings of which they may
        refer.

3.6 Other WebDAV Operations on Indirect Referential Resources

        By definition, operations on an indirect reference affect only the same
        resources can be achieved by creating multiple collections
        referencing those resources,
        reference, and attaching a different ordering to
        each collection.

        The ordering-type, represented not its target resource.  Since only indirect
        references are supported by this specification, WebDAV operations
        that are applied to them affect only the new DAV:orderingtype XML
        element,is referential resource, not
        its target resource.

        A LOCK operation on an href identifying the semantics of the ordering.  The
        href SHOULD point to a resource that contains a definition of indirect reference locks the
        semantics of referential
        resource, not its target.  A LOCK on the ordering, allowing a human user or software
        package to insert new collection members into the ordering
        intelligently. (Req 3.2.3)

        A client may order with
        Depth = 1 or infinity locks the referential members of a collection along with all
        the
        DAV:ordering property other members of the collection.  The client may use
        PROPFIND to discover collection, but not the current ordering targets of the collection, and
        indirect referential members.

        A PROPPATCH on an indirect referential resource modifies the
        properties of the ordering property to modify the ordering.  It is
        also possible to insert an internal or referential collection
        member into resource, not the ordering at properties of its
        target resource.

        A PROPFIND on an indirect referential resource returns the time
        properties of the member is is added to referential resource, not the
        collection, by using properties of its
        target resource.

        A MOVE operation on an indirect referential resource moves the Position header with
        referential resource to a different location, but has no effect on
        the M-PUT, M-COPY,
        or M-MOVE request. (Req 3.2.9) location of its target. The DAV:ordering DAV:reftarget property is live only to the extent that the
        server MUST remove an href from the ordering when unchanged
        after a member is
        removed from the collection, and the server MUST add the href to MOVE unless the ordering whenever a member Ref-Target header is added used to change it.

        A COPY operation on an indirect referential resource copies the collection.  It MUST
        insert the new member at the location specified in the Position
        header, if present in the M-PUT request; otherwise, it MUST append
        the new member
        referential resource, not its target resource, to the end another location.
        The DAV:reftarget property of the ordering. If a PUT or M-Put causes
        an existing destination resource to be replaced, and if the Position header is absent, the server MUST leave same
        as the member at its previous
        position in DAV:reftarget of the collection ordering.  If source resource, unless the Position Ref-Target
        header is
        present, the server MUST remove the member from its previous
        position, and then insert it at the requested position. Whenever
        the server receives a PROPPATCH request on the DAV:ordering
        property, it MUST verify that each member of the collection appears
        in the ordering exactly once.  (Reqs 3.2.4, 3.2.5)

        When responding used to a PROPFIND change it.

3.7 HTTP Operations on a collection, the server MUST
        order the response elements according to the DAV:ordering property
        on the collection.  (Req 3.2.6)

    5   New Headers

    5.1 Referential-Member Request Header

        Referential-Member = "Referential-Member" ":"  relative URI

        The Referential-Member request header is used with the M-PUT method
        to identify the new Indirect Referential Resources

        Although existing HTTP clients cannot create referential member to resources,
        they should be added to the
        collection.  The URI is relative able to the collection identified read collections created by
        the request-URI.  It is a required header Class 3 WebDAV
        clients.  They should be able to follow any references in requests those
        collections to add their targets.  To make this possible, a
        referential member to server that
        receives a collection.

    5.2 Ref-Target Request Header

        Ref-Target = "Ref-Target" ":" URI GET or HEAD on an indirect reference MUST return a 302
        (Moved Temporarily) status code.  The Ref-Target request header is used server MUST follow [HTTP]
        Section 10.3.3 "302 Moved Temporarily," but with the M-PUT method to
        identify these additional
        rules:

           o The Location header MUST contain the target resource URI of the new referential member being
        added to a collection.  It is
             reference.

           o The response MUST include a required Resource-Type header in requests to add
        a referential member with the
             value "Reference".  This header allows Class 3 WebDAV clients
             to recognize the resource as a collection.

    5.2 Ref-Integrity Request Header

        Ref-Integrity = "Ref-Integrity" ":" ("T" | "F")

        The Ref-Integrity header specifies whether reference and understand the server should
        enforce referential integrity
             reason for the redirection.

           o The response MUST also include those HTTP headers that make
             sense for a referential member of resources, at a
        collection being created with M-PUT.  If minimum: Cache-Control,
             Age, ETag, Expires, and Last-Modified.

        POST cannot be applied to an indirect reference.  A reference
        cannot accept another entity as its subordinate.  Depending upon
        the value nature of the header is
        "T", target resource, however, it might make sense to
        apply POST to the target.  A server that receives a POST request
        on an indirect reference MUST fail return a 302 (Moved Temporarily).
        The rules for constructing and using the request unless it can guarantee
        referential integrity.  If response are the header is not used, the server MUST
        treat the request same as if it has a Ref-Integrity header set
        for GET and HEAD, except that there is no requirement to "F".

    5.3 Position Request Header

        Position = "Position" ":" ("First" | "Last" | ("At" index) |
                                  (("Before" | "After") URI))
        index = integer

        The Position header may return
        Cache-Control, Age, ETag, Expires, or Last-Modified.

        PUT cannot be used with M-PUT to tell the server
        where in the collection ordering applied to position an indirect reference.  To replace one
        indirect reference with another, MKREF MUST be used.  To replace an
        indirect reference with an ordinary resource, the collection member
        being added.  It may reference MUST
        first be deleted with DELREF, after which a PUT MUST be used for both internal and referential
        members.

        If to
        create the Position request header is ordinary resource.

        Existing HTTP clients that do not used, then:

            If the understand referential resources
        need to be accommodated, however.  To enable these clients to
        operate reasonably on indirect references, a server that receives a
        PUT request is replacing on an existing resource, the server indirect reference MUST preserve the present ordering.

            If the request is adding return a new member to the collection, the 302 (Moved
        Temporarily).  The client and server MUST append the new member to follow [HTTP] Section
        10.3.3 "302 Moved Temporarily," but with these additional rules:

           o The Location response header MUST contain the end target URI of
             the list reference.

           o The response MUST include a Resource-Type header, defined in
             Section 5.n below, with the
            DAV:ordering property (if value "Reference".  This header
             allows Class 3 WebDAV clients to recognize the collection is ordered).

    6   New Properties

    6.1 reftarget Property

        Name:		reftarget
        Namespace:	DAV:
	Purpose:	A property of referential collection members that
                        provides resource as a
             reference and understand the reason for the redirection.

           o The response MUST include an efficient way entity body for clients display to discover users.
             The entity body explains that the URI of requested resource is a
             reference to another resource, and allows the target resource.
        Value:          URI of user to choose
             whether to replace the target resource.

        <!ELEMENT reftarget href>

    6.2 refsource Property
        Name:		refsource
        Namespace:	DAV:
        Purpose:        A property of targets of strong referential
			collection members resource or to replace the
             reference.

	This last rule is needed for PUT, but not for GET, HEAD, or
        POST.  Only for PUT does it make sense for the user to confirm
        that provides a list of the operation is to be performed at the request-URI.  GET or
        HEAD will already have returned all
			strong referential collection members that useful information about the
        request-URI.  POST makes no sense for the indirect reference at the resource.  Aids
        request-URI.  But the server user might really want to replace the
        indirect reference with the entity in
			maintaining referential integrity, and allows
			clients the PUT request.

        Although the new DELREF method has been defined for deleting
        references, DELETE can be used to discover which strong referential
			members delete an indirect reference.
        Since by definition operations on an indirect reference affect the
        reference, and not its target, DELETE will delete the indirect
        reference and leave its target resource.
	Value:		List untouched.

3.8 Operations on Targets of URIs Referential Resources

        Operations on targets of strong weak, indirect referential collection
                        members that reference resources have
        no effect on the resource.

	<!ELEMENT refsource href+>

    6.3 refintegrity Property

        Name:		refintegrity
	Namespace:	DAV:
	Purpose:	A property of referential collection members that
			indicates resource.

4 Ordered Collections

4.1 Overview

        Collections on a compliant server may be ordered, but need not be.
        It is up to the client to decide whether a given collection is
        ordered and, if so, to specify the server guarantees referential
 			integrity for that reference.
	Value:		"T" for strong references, "F" semantics to be used for weak references.

	<!ELEMENT refintegrity ("T" | "F")>

    6.4 ordering Property

        Name:
        ordering
        Namespace:	DAV:
        Purpose:	A property of its members.  If a collection, specifying the order
                        of the members of the collection.
        Value:  	A typed list of URIs collection is ordered, each of the its
        members of the
			collection.  Each member of the collection, whether
                        internal or referential, must be in the list ordering exactly once. once, and the ordering must
        not include any resource that is not a member of the collection.
        Only one ordering can be attached to any collection.  Multiple
        orderings of the same resources can be achieved by creating
        multiple collections referencing those resources, and attaching a
        different ordering to each collection.

        The server is responsible for enforcing these constraints on
        orderings.  The server MUST remove a resource from the ordering
        when it is removed from the collection. The server MUST add a
        resource to the ordering when it is added to the collection.

        When responding to a PROPFIND on a collection, the server MUST
        order the response elements according to the ordering defined
        on the collection.

4.2 Creating an Ordered Collection

4.2.1 Overview

        When a collection is created, the client can request that it be
        ordered and specify the semantics of the ordering by using the
        new Ordered header in the MKCOL request, setting its value to the
        URI of the semantics to be used.  If the client does not want the
        collection to be ordered, it may omit the Ordered header, or use
        it with the value "DAV:arbitrary".

        Every collection MUST have the new DAV:orderingtype property,
        which indicates whether the collection is ordered and, if so,
        identifies the semantics of the ordering.  A value of DAV:arbitrary
        indicates that that collection is not ordered.  That is, the client
        cannot depend on the repeatability of the ordering of results from
        a PROPFIND request.  Otherwise the value of DAV:orderingtype is an
        href that SHOULD point to a resource that contains a definition of
        the semantics of the ordering, allowing a human user or software
        package to insert new collection members into the ordering
        intelligently.

        If the Ordered header is present on a MKCOL request, the server
        MUST set the collection's DAV:orderingtype property to the value of
        the Ordered header.  If the Ordered header is not present, the
        server MUST treat the request as if it had an Ordered header with
        the value "DAV:arbitrary", meaning that the collection is not
        ordered.  If the collection is ordered, the server MUST respond to
        PROPFIND requests on the collection using the specified ordering.

4.2.2 Status Codes

        No new error conditions are introduced.

4.2.3 Example

        Request:

        MKCOL /theNorth/ HTTP/1.1
        Host: www.server.org
        Ordered: <http://www.server.org/orderings/compass.html>

        Response:

        HTTP/1.1 201 Created

        In this example, a new, ordered collection was created.  Its
        DAV:orderingtype property has as its value the URI from the
        Ordered header.  In this case, the URI points to a description of
        the semantics governing the ordering.  As new members are added to
        the collection, clients or end users can consult the semantics to
        determine how to position the new members in the ordering.

4.3 Setting the Position of a Collection Member

4.3.1 Overview

        When a new member is added to a collection with MKREF, PUT, COPY,
        or MOVE, its position in the ordering can be set with the new
        Position header.  The Position header allows the client to specify
        that the member should be first in the collection's ordering, last
        in the collection's ordering, before some other collection member
        in the collection's ordering, or after some other collection member
        in the collection's ordering.

        The server MUST insert the new member into the ordering at the
        location specified in the Position header, if one is present (and
        if the collection is ordered); otherwise, it MUST append the new
        member to the end of the ordering (if the collection is ordered).
        If a PUT or MKREF causes an existing resource to be replaced, and
        if the Position header is absent, the server MUST leave the member
        at its previous position in the collection ordering.  If the
        Position header is present, the server MUST remove the member from
        its previous position, and then insert it at the requested
        position.

4.3.2 Status Codes

        201 Created
        409 Conflict: Before / After a URI that is not in this collection
        400 Bad Request: Before / After self
        405 Method Not Allowed: Not an ordered collection

4.3.3 Examples

        Request:

        MKREF /~whitehead/dav/spec08.ref HTTP/1.1
        HOST: www.ics.uci.edu
        Ref-Target: <http://www.ics.uci.edu/i-d/draft-webdav-protocol-08.txt>
        Position: After <requirements.html>

        Response:

        HTTP/1.1 201 Created

        This request resulted in the creation of a new referential resource
        at www.ics.uci.edu/~whitehead/dav/spec08.ref, which points to the
        resource identified by the Ref-Target header.  The Position header
        in this example caused the server to set its position in the
        ordering of the /~whitehead/dav/ collection immediately after the
        requirements.html resource.

        Request:

        MOVE /i-d/draft-webdav-protocol-08.txt HTTP/1.1
        Host: www.ics.uci.edu
        Destination: </~whitehead/dav/draft-webdav-protocol-08.txt>
        Position: First

        Response:

        HTTP/1.1 409 Conflict

        In this case, the server returned a 409 Conflict status code
        because the /~whitehead/dav/ collection is an unordered collection.

        Consequently, the server was unable to satisfy the Position
        header.

4.4 Changing the Semantics of a Collection Ordering

        After a collection has been created, a client can change its
        ordering semantics, or change an ordered collection to an unordered
        collection or vice versa, by using PROPPATCH to change the value of
        its DAV:orderingtype property.  The client is then responsible for
        updating the ordering of the collection members according to the
        new semantics.  PROPPATCH is defined in [WebDAV], Section 7.2.

4.5 Changing the Position of a Collection Member

4.5.1 The ORDERPATCH Method

        To change the position of a collection member in the collection's
        ordering, the client MUST use an ORDERPATCH request with a request
        body containing an order XML element.  The request-URI of an
        ORDERPATCH request is the URI of the collection whose ordering is
        to be updated.  The order XML element identifies the member
        resource whose position is to be changed, and describes its new
        position in the ordering.  The new position can be specified as
        first in the ordering, last in the ordering, before some other
        collection member in the ordering, or after some other collection
        member in the ordering.

4.5.2 Status Codes

        Although the protocol currently allows only a single change to be
        requested with ORDERPATCH, it is anticipated that this may change
        in the future.  Consequently, the server MUST return a 207
        Multi-Status response, as defined in [WebDAV].

        Within the 207 Multi-Status response, the following status codes
        are possible:

        200 OK
        409 Conflict: Before / After a URI that is not in this collection
        409 Conflict: href doesn't point to a member of this collection
        400 Bad Request: only one change allowed
        400 Bad Request: Before / After self
        405 Method Not Allowed: Not an ordered collection
        405 Method Not Allowed: Not a collection
        (It's ok to reposition to the same position)

4.5.3 Example

        Consider a collection /coll-1/ with members ordered as follows:

                nunavut.map
                nunavut.img
		baffin.map
                baffin.desc
                baffin.img
                iqaluit.map
                nunavut.desc
                iqaluit.desc
                iqaluit.img

        Request:

        ORDERPATCH /coll-1/ HTTP/1.1
        Host: www.nunanet.com
        Content-Type: text/xml
        Content-Length: xxx

        <?xml version="1.0" ?>
        <?xml:namespace ns="DAV:" prefix="d" ?>
        <d:order>
	   <d:member>
              <d:href>nunavut.desc</d:href>
              <d:position>
                 <d:after>
                    <d:href>nunavut.map</d:href>
                 </d:after>
              </d:position>
           </d:member>
        </d:order>

        Response:

        HTTP/1.1 207 Multi-Status
        Content-Type: text/xml
        Content-Length: xxx

        <?xml version="1.0" ?>
        <?xml:namespace ns="DAV:" prefix="d" ?>
        <d:multistatus>
	   <d:response>
              <d:href>http://www.nunanet.com/coll-1/nunavut.desc</d:href>
              <d:status>HTTP/1.1 200 OK</d:status>
           </d:response>
        </d:multistatus>

        In this example, after the request has been processed, the
        map of nunavut is the first member in the collection's ordering:

                nunavut.map
                nunavut.desc
                nunavut.img
		baffin.map
                baffin.desc
                baffin.img
                iqaluit.map
                iqaluit.desc
                iqaluit.img

4.5.4 Design Rationale
        The decision to introduce the new ORDERPATCH method was made after
        investigating the possibility of using the existing MOVE method
        with a Position header.  The use of MOVE initially looked
        appealingly simple:

        MOVE /root/coll-1/foo HTTP/1.1
        Host: www.somehost.com
        Destination: </root/coll-1/foo>
        Position: First

        Unfortunately, several features of the semantics of MOVE make it
        unsuitable for changing the position of a collection member in the
        collection's ordering.  First, [WebDAV] defines MOVE as logically
        equivalent to a copy followed by a delete of the source resource.
        This definition makes it impossible to MOVE a resource to a
        destination URL that is the same as the source URL.  The resource
        would be deleted rather than moved.  Second, [WebDAV] states that
        when moving a resource to a destination where a resource already
        exists, the Overwrite header must be "T", and in this case the
        server must DELETE the resource at the destination before
        performing the MOVE.  Again, this makes it impossible to MOVE
        a resource to the same location.  Finally, [WebDAV] states that
        locks are lost on a MOVE, an outcome that seems undesirable in this
        case.

        The decision to allow only a single change to be described in a
        PROPPATCH request was made in order to accommodate many existing
        systems that do not allow multiple changes to be requested at once.
        However, the protocol design is extensible to support multiple
        requests in the future.

        In particular, the decision to define a new order XML element for
        ORDERPATCH was made for the sake of extensibility.  Although the
        current definition of the order XML element allows only a single
        change in the ordering per ORDERPATCH request, using an XML element
        keeps open the option of later allowing multiple changes to be
        described in a single ORDERPATCH request.  Similarly, a
        Multi-Status response is used in order to keep open the option of
        multiple changes in a single request in the future.

5 New Headers

5.1 Ref-Target Request Header

        Ref-Target = "Ref-Target" ":" Coded-url

        Coded-url is defined in [WebDAV], Section 8.4.

        The Ref-Target request header is used with the MKREF method to
        identify the target resource of the new referential resource being
        created.  It is a required header in MKREF requests.  This header
        may also be used with COPY and MOVE requests to change the target
        of the destination reference.

5.2 Ref-Integrity Request Header
        Ref-Integrity = "Ref-Integrity" ":" ("DAV:weak")

        The Ref-Integrity header is defined to allow future support for
        strong references.  It specifies whether the server should
        enforce referential integrity for a referential resource being
        created with MKREF.  The only value currently defined for the
        Ref-Integrity header is "DAV:weak", which means that the server
        need not [should not? must not?] enforce referential integrity for
        the newly created reference.  Other values may be used by private
        agreement between the client and server.  If the header is not
        present on a MKREF request, the server MUST treat the request as
        if it has a Ref-Integrity header set to "DAV:weak".  This header
        may also be used with COPY and MOVE requests.  If this header is
        not present on a COPY or MOVE request, the DAV:refintegrity
        property MUST be treated like any other live property, as
        specified in [WebDAV] sections 7.8.2 and 7.9.1.

5.3 Pass-Through Request Header

        Pass-Through = "Pass-Through" ":" ""

        The Pass-Through header is defined to allow future support for
        direct references.  Indirect references do not pass operations
        through to their target resources, so for them the value of
        the Pass-Through header is empty.  Direct references pass all
        operations through to their target resources.  Other types of
        references may pass certain operations through, while others may
        affect the reference itself.  Since only indirect references are
        supported today, the only value currently defined for Pass-Through
        is empty.  Other values may be used by private agreement between
        the client and server.  If the header is not present on a MKREF
        request, the server MUST treat the request as if it has a
        Pass-Through header with the value empty.  This header may also be
        used with a COPY or MOVE request on a reference.  If this header is
        not present on a COPY or MOVE request, the DAV:passthrough
        property MUST be treated like any other live property, as
        specified in [WebDAV] sections 7.8.2 and 7.9.1.

5.4 Resource-Type Response Header

        Resource-Type = "Resource-Type" ":" ["DAV:collection" |
                                             "DAV:reference" | ""]

        The Resource-Type response header contains the value of the
        DAV:resourcetype property.  It is used with 302 responses to PUT,
        POST, GET, or HEAD requests on referential resources to indicate to
        the client that the reason for the redirection is that the
        request-URI pointed to a referential resource.

5.5 Ordered Request Header

        Ordered = "Ordered" ":" ("DAV:arbitrary" | Coded-url)

        The Ordered request header may be used with MKCOL to request that
        the new collection be ordered and to specify its ordering
        semantics.  A value of "DAV:arbitrary" indicates that the
        collection is not ordered.  That is, the client cannot depend on
        the repeatability of the ordering of results from a PROPFIND
        request. A Coded-url value indicates that the collection is
        ordered, and identifies the semantics of the ordering.  The
        Coded-url SHOULD point to a resource that contains a definition of
        the semantics of the ordering, allowing a human user or software
        package to insert new collection members into the ordering
        intelligently.

        If the Ordered header is not present on a MKCOL request, the
        server MUST treat the request as if it had an Ordered header with
        the value "DAV:arbitrary".

5.6 Position Request Header

        Position = "Position" ":" ("First" | "Last" |
                                  (("Before" | "After") Coded-url))

        The Position header may be used with MKREF, PUT, COPY, or MOVE to
        tell the server where in the collection ordering to position the
        resource being added to the collection.  It may be used for both
        ordinary and referential members.

        If the Coded-url is a relative URL, it is interpreted relative to
        the collection in which the resource is being created.

        If the Position request header is not used, then:

            If the request is replacing an existing resource, the server
            MUST preserve the present ordering.

            If the request is adding a new member to the collection, the
            server MUST append the new member to the end of the ordering
            (if the collection is ordered).

6 New Properties

6.1 reftarget Property

        Name:		reftarget
        Namespace:	DAV:
	Purpose:  	A required property of referential resources that
                        provides an efficient way for clients to discover
                        the URI of the target resource.  This is a readonly
                        property, whose value can only be set by using the
                        Ref-Target header with a MKREF, COPY, or MOVE
                        request.
        Value:          URI of the target resource.

        <!ELEMENT reftarget href>

6.2 refintegrity Property
        Name:		refintegrity
	Namespace:	DAV:
	Purpose:	A required property of a referential resource that
			indicates whether the server guarantees referential
 			integrity for that reference.  The refintegrity
                        property is defined to allow future support for
                        strong references.  The only value currently
                        defined for refintegrity is weak, which means that
                        the server need not [does not?] enforce referential
                        integrity for the reference.  Other values may be
                        used by private agreement between the client and
                        server.  This is a readonly property, whose value
                        can only be set by using the Ref-Integrity header
                        with a MKREF, COPY, or MOVE request.
	Value:		weak

	<!ELEMENT refintegrity (weak)>

6.3 passthrough Property

        Name:           passthrough
        Namespace:      DAV
        Purpose:        A required property of a referential resource that
                        indicates what operations are passed through to its
                        target resource.  The passthrough property is
                        defined to allow future support for direct
                        references, which pass all operations through to
                        their targets.  This specification currently
                        supports only indirect references, which do not
                        pass any operations through to their targets.  The
                        only value currently defined for passthrough is
                        EMPTY.  Other values may be used by private
                        agreement between the client and server.  This is
                        a read-only property, whose value can only be set
                        by using the Pass-Through header with a MKREF,
                        COPY, or MOVE request.
        Value:          EMPTY

        <!ELEMENT passthrough EMPTY>

6.4 orderingtype Property

        Name:		orderingtype
        Namespace:	DAV:
        Purpose:  	Indicates whether the collection is ordered and, if
                        so, uniquely identifies the semantics of the
                        ordering being used.  SHOULD also provide an
                        explanation of the semantics in human and / or
                        machine-readable form.  At a minimum, this allows
                        human users who add members to the collection to
                        understand where to position them in the ordering.
	Value:		arbitrary for an unordered collection, or a URI
                        that uniquely identifies the semantics of the
                        collection's ordering.  The URI SHOULD point to
                        a definition of the ordering semantics.

	<!ELEMENT orderingtype (arbitrary | href) >

7 New XML Elements

7.1 reference XML Element

        Name: 		reference
        Namespace: 	DAV:
        Purpose:  	A new value of the DAV:resourcetype property that
			identifies its resource as a referential resource.
                        The DAV:resourcetype property of a referential
                        resource MUST have this value.
	Value:		EMPTY

	<!ELEMENT reference EMPTY >

7.2 weak XML Element

        Name:           weak
        Namespace:      DAV:
        Purpose:        The only value currently defined for the
                        DAV:refintegrity property.  It means that the
                        server need not [does not?] enforce referential
                        integrity for the reference to which the property
                        belongs.
        Value:          EMPTY

        <!ELEMENT weak EMPTY >

7.3 arbitrary XML Element

        Name:           arbitrary
        Namespace:      DAV:
        Purpose:        A value of the DAV:orderingtype property that
                        indicates that the collection is not ordered.  That
                        is, the client cannot depend on the repeatability
                        of the ordering of results from a PROPFIND request.
        Value:          EMPTY

        <!ELEMENT arbitrary EMPTY >

7.4 order XML Element

        Name:           order
        Namespace:      DAV
        Purpose:        For use with the new ORDERPATCH method.  Describes
                        a change to be made in a collection ordering.
        Value:          A description of the new position of a collection
                        member in the collection's ordering.

        <!ELEMENT order member >

7.5 member XML Element
        Name:           member
        Namespace:      DAV
        Purpose:        Occurs in the order XML Element, and describes the
                        new position of a single collection member in the
                        collection's ordering.
        Value:          An href containing the relative URI of the
                        collection member, and a description of its new
                        position in the ordering.  The href XML element is
                        defined in [WebDAV], Section 11.3.

        <!ELEMENT member (href, position) >

7.6 position XML Element

        Name:           position
        Namespace:      DAV
        Purpose:        Occurs in the member XML element.  Describes the
                        new position in a collection's ordering of one of
                        the collection's members.
        Value:          The new position can be described as first in the
                        collection's ordering, last in the collection's
                        ordering, before some other member of the
                        collection, or after some other member of the
                        collection.

        <!ELEMENT position (first | last | before | after)>

7.7 first XML Element

        Name:           first
        Namespace:      DAV
        Purpose:        Occurs in the position XML element.  Describes the
                        collection member's position as first in the
                        collection's ordering.
        Value:          EMPTY

        <!ELEMENT first EMPTY >

7.8 last XML Element

        Name:           last
        Namespace:      DAV
        Purpose:        Occurs in the position XML element.  Describes the
                        collection member's position as last in the
                        collection's ordering.
        Value:          EMPTY

        <!ELEMENT last EMPTY >

7.9 before XML Element

        Name:           before
        Namespace:      DAV
        Purpose:        Occurs in the position XML element.  Describes the
                        collection member's position as coming before some
                        other collection member in the collection's
                        ordering.
        Value:          href of the member it precedes in the ordering (orderingtype, href*)

        <!ELEMENT before href >

    7   New XML Elements

    7.1 orderingtype

7.10 after XML Element

        Name:		orderingtype           after
        Namespace:	DAV:      DAV
        Purpose:	Uniquely identifies        Occurs in the semantics position XML element.  Describes the
                        collection member's position as coming after some
                        other collection member in the collection's
                        ordering.
        Value:          href of the member it follows in the ordering

        <!ELEMENT after href >

8 Compliance

        Section 14 of [Goland et al, 1998] defined a DAV header for use
        when responding to OPTIONS requests.  This header provides a way
        for clients to discover which parts of WebDAV a resource supports.
        The WebDAV specifications define numbered compliance classes
        corresponding to collections of related functions that resources
        may support.  When the server receives an OPTIONS request, it lists
        the classes that the request-URI supports in the DAV response
        header.

        Since this specification defines two independent sets of
        functionality, it defines two new compliance classes.  A WebDAV
        server may support neither, one or the other, or both for any
        resource.

8.1 Class 3

        This new compliance class indicates compliance with Section 3
        "Referential Resources" of this specification.  Servers that comply
        with Section 3 MUST list this class in the DAV response header
        when they respond to an OPTIONS request.

8.2 Class 4

        This new compliance class indicates compliance with Section 4
        "Ordered Collections" of this specification.  Servers that comply
        with Section 4 MUST list this class in the DAV response header
        when they respond to an OPTIONS request.

9 Dependencies on Other Specifications

	  TBD

10 Security Considerations

        This section is provided to detail issues concerning security
        implications of which WebDAV applications need to be aware.

        All of the ordering
                        being used.  SHOULD also provide an explanation security considerations of
                        the semantics in human HTTP/1.1 and / or machine-readable
                        form.  At a minimum, this allows human users who
			add members to the collection to understand where base WebDAV
        protocol also apply to position them in WebDAV collections.  In addition,
        referential resources and ordered collections introduce several
        new security concerns and increase the ordering.
	Value:		URI that uniquely identifies risk of some existing
        threats.  These issues are detailed below.

10.1 Redirect Loops

         Although redirect loops were already possible in HTTP 1.1, the semantics
         introduction of referential resources creates a new avenue for
         clients to create loops accidentally or maliciously.  If the
                        ordering
         referential resource and that SHOULD point to an definition of its target are on the ordering semantics.

	<!ELEMENT orderingtype href >
    7.2 refmember XML Element

        Name: 		refmember
        Namespace: 	DAV:
        Purpose: 	A new value of same server, the DAV:resourcetype property
         server may be able to detect MKREF requests that
			identifies its resource as a referential member would create
         loops. See also [HTTP], Section 10.3 "Redirection 3xx."

10.2 References and Denial of
			a collection. Service

         The DAV:resourcetype property introduction of a referential member of resources creates a collection MUST have this
			value.
	Value:		EMPTY

	<!ELEMENT refmember EMPTY >

    8   Compliance

        Section 14 new avenue
         for denial of [Goland et al, 1998] defined a DAV header service attacks. Clients can create heavily used
         references to target locations that were not designed for use
        when responding heavy
         usage.

10.3 Malicious Modifications of Ordering

         Particularly in large collections, moving a collection member to OPTIONS requests.  This header provides
         a way different position in the ordering can make it very difficult
         for clients users to discover which parts find.

10.4 Denial of WebDAV a resource supports.
        The WebDAV specifications define numbered compliance classes
        corresponding to collections Service and DAV:orderingtype

         There may be some risk of related functions denial of service at sites that resources
        may support.  When are
         advertised in the server receives an OPTIONS request, DAV:orderingtype property of collections.
         However, it lists
        the classes is anticipated that widely-deployed applications will
         use hard-coded values for frequently-used ordering semantics
         rather than looking up the semantics at the location specified by
         DAV:orderingtype.

11 Internationalization Considerations

         This specification follows the request-URI supports practices of [WebDAV] in encoding
         all human-readable content using XML [XML] and in the DAV response
        header.

        Since treatment
         of names.  Consequently, this specification defines two independent sets of
        functionality, it defines two new compliance classes.  A complies with the
         IETF Character Set Policy [Alvestrand].

         WebDAV
        server may applications MUST support neither, one or the other, or both for any
        resource.

    8.1 Class 3

        This new compliance class indicates compliance with Section 3
        "Referential Members" character set tagging,
         character set encoding, and the language tagging functionality of this
         the XML specification.  Servers  This constraint ensures that comply
        with Section 3 MUST list this class in the DAV response header
        when they respond to an OPTIONS request.

    8.2 Class 4

        This new compliance class indicates compliance with Section 4
        "Ordered Collections" human-
         readable content of this specification.  Servers that comply specification complies with Section 4 MUST list [Alvestrand].

         As in [WebDAV}, names in this class specification fall into three
         categories: names of protocol elements such as methods and
         headers, names of XML elements, and names of properties.  Naming
         of protocol elements follows the precedent of HTTP, using English
         names encoded in USASCII for methods and headers.  The names of
         XML elements used in this specification are English names encoded
         in UTF-8.

         For error reporting, [WebDAV] follows the DAV response header
        when they respond to convention of HTTP/1.1
         status codes, including with each status code a short, English
         description of the code (e.g., 423 Locked).  Internationalized
         applications will ignore this message, and display an OPTIONS request.

9   Dependencies on Other Specifications

    [Nielsen et al., 1998] "Mandatory Extensions appropriate
         message in HTTP."

10  Security Considerations

11  Internationalization Considerations the user's language and character set.

         For rationales for these decisions and advice for application
         implementors, see [WebDAV].

12 IANA Considerations

	  TBD

13 Copyright

14 Intellectual Property

15 Acknowledgements

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

16 References

        [Goland et al., 1998]

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

        [Slein, 1998]

        [DASL] Saveen Reddy, D. Jensen, Surendra Reddy,
        R. Henderson, J. Davis, A. Babich, "DAV Searching & Locating."
        Draft-reddy-dasl-protocol-02. Internet Draft, work in progress.
        Microsoft, Novell, Oracle, Netscape, Xerox, Filenet.  June, 1998.

        [WebDAVReq] J. Slein, J. Davis, "Requirements for Advanced
        Collection Functionality in WebDAV." Draft-ietf-webdav-collection-reqts-01. Draft-ietf-webdav-collection-
        reqts-02. Internet Draft, work in progress.  Xerox, 1998.

        [Nielsen et al., 1998]

        [HTTP] R. Fielding, J. Gettys, J. Mogul, H. F. Nielsen, P. Leach, S. Lawrence,
        "Mandatory Extensions in HTTP." Draft-ietf-http-ext-mandatory-00.
        Internet Draft, work in progress. W3C, Microsoft, Agranat, 1998. Frystyk,
        T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1."
        RFC 2068.  UC Irvine, DEC, MIT/LCS.  January, 1997.

        [XML] T. Bray, J. Paoli, C.M. Sperberg-McQueen, "Extensible Markup
        Language (XML)."  World Wide Web Consortium Recommendation
        REC-xml-19980210. http://www.w3.org/TR/1998/REC-xml-19980210.

17 Authors' Addresses

        J. Slein
        Xerox Corporation
        800 Phillips Road, 105-50C
        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

        A. Babich
        FileNet Corporation
        3565 Harbor Boulevard
        Costa Mesa, CA 92626-1420
        Email: ababich@filenet.com

        E.J. Whitehead Jr.
        Dept. of Information and Computer Science
        University of California, Irvine
        Irvine, CA 92697-3425
        Email: ejw@ics.uci.edu

    Expires December 5, 1998 January 31, 1999