Network Working Group Y. Goland
`Request for Comments: 2518 Microsoft
`Category: Standards Track E. Whitehead
` UC Irvine
` A. Faizi
` Netscape
` S. Carter
` Novell
` D. Jensen
` Novell
` February 1999
`
` HTTP Extensions for Distributed Authoring -- WEBDAV
`
`Status of this Memo
`
` This document specifies an Internet standards track protocol for the
` Internet community, and requests discussion and suggestions for
` improvements. Please refer to the current edition of the "Internet
` Official Protocol Standards" (STD 1) for the standardization state
` and status of this protocol. Distribution of this memo is unlimited.
`
`Copyright Notice
`
` Copyright (C) The Internet Society (1999). All Rights Reserved.
`
`Abstract
`
` This document specifies a set of methods, headers, and content-types
` ancillary to HTTP/1.1 for the management of resource properties,
` creation and management of resource collections, namespace
` manipulation, and resource locking (collision avoidance).
`
`Table of Contents
`
` ABSTRACT............................................................1
` 1 INTRODUCTION .....................................................5
` 2 NOTATIONAL CONVENTIONS ...........................................7
` 3 TERMINOLOGY ......................................................7
` 4 DATA MODEL FOR RESOURCE PROPERTIES ...............................8
` 4.1 The Resource Property Model ...................................8
` 4.2 Existing Metadata Proposals ...................................8
` 4.3 Properties and HTTP Headers ...................................9
` 4.4 Property Values ...............................................9
` 4.5 Property Names ...............................................10
` 4.6 Media Independent Links ......................................10
` 5 COLLECTIONS OF WEB RESOURCES ....................................11
`
`Goland, et al. Standards Track [Page 1]
`
`Adobe - Exhibit 1013, page 1
`
`

`

`
`RFC 2518 WEBDAV February 1999
`
` 5.1 HTTP URL Namespace Model .....................................11
` 5.2 Collection Resources .........................................11
` 5.3 Creation and Retrieval of Collection Resources ...............12
` 5.4 Source Resources and Output Resources ........................13
` 6 LOCKING .........................................................14
` 6.1 Exclusive Vs. Shared Locks ...................................14
` 6.2 Required Support .............................................16
` 6.3 Lock Tokens ..................................................16
` 6.4 opaquelocktoken Lock Token URI Scheme ........................16
` 6.4.1 Node Field Generation Without the IEEE 802 Address ........17
` 6.5 Lock Capability Discovery ....................................19
` 6.6 Active Lock Discovery ........................................19
` 6.7 Usage Considerations .........................................19
` 7 WRITE LOCK ......................................................20
` 7.1 Methods Restricted by Write Locks ............................20
` 7.2 Write Locks and Lock Tokens ..................................20
` 7.3 Write Locks and Properties ...................................20
` 7.4 Write Locks and Null Resources ...............................21
` 7.5 Write Locks and Collections ..................................21
` 7.6 Write Locks and the If Request Header ........................22
` 7.6.1 Example - Write Lock ......................................22
` 7.7 Write Locks and COPY/MOVE ....................................23
` 7.8 Refreshing Write Locks .......................................23
` 8 HTTP METHODS FOR DISTRIBUTED AUTHORING ..........................23
` 8.1 PROPFIND .....................................................24
` 8.1.1 Example - Retrieving Named Properties .....................25
` 8.1.2 Example - Using allprop to Retrieve All Properties ........26
` 8.1.3 Example - Using propname to Retrieve all Property Names ...29
` 8.2 PROPPATCH ....................................................31
` 8.2.1 Status Codes for use with 207 (Multi-Status) ..............31
` 8.2.2 Example - PROPPATCH .......................................32
` 8.3 MKCOL Method .................................................33
` 8.3.1 Request ...................................................33
` 8.3.2 Status Codes ..............................................33
` 8.3.3 Example - MKCOL ...........................................34
` 8.4 GET, HEAD for Collections ....................................34
` 8.5 POST for Collections .........................................35
` 8.6 DELETE .......................................................35
` 8.6.1 DELETE for Non-Collection Resources .......................35
` 8.6.2 DELETE for Collections ....................................36
` 8.7 PUT ..........................................................36
` 8.7.1 PUT for Non-Collection Resources ..........................36
` 8.7.2 PUT for Collections .......................................37
` 8.8 COPY Method ..................................................37
` 8.8.1 COPY for HTTP/1.1 resources ...............................37
` 8.8.2 COPY for Properties .......................................38
` 8.8.3 COPY for Collections ......................................38
` 8.8.4 COPY and the Overwrite Header .............................39
`
`Goland, et al. Standards Track [Page 2]
`
`Adobe - Exhibit 1013, page 2
`
`

`

`
`RFC 2518 WEBDAV February 1999
`
` 8.8.5 Status Codes ..............................................39
` 8.8.6 Example - COPY with Overwrite .............................40
` 8.8.7 Example - COPY with No Overwrite ..........................40
` 8.8.8 Example - COPY of a Collection ............................41
` 8.9 MOVE Method ..................................................42
` 8.9.1 MOVE for Properties .......................................42
` 8.9.2 MOVE for Collections ......................................42
` 8.9.3 MOVE and the Overwrite Header .............................43
` 8.9.4 Status Codes ..............................................43
` 8.9.5 Example - MOVE of a Non-Collection ........................44
` 8.9.6 Example - MOVE of a Collection ............................44
` 8.10 LOCK Method ..................................................45
` 8.10.1 Operation .................................................46
` 8.10.2 The Effect of Locks on Properties and Collections .........46
` 8.10.3 Locking Replicated Resources ..............................46
` 8.10.4 Depth and Locking .........................................46
` 8.10.5 Interaction with other Methods ............................47
` 8.10.6 Lock Compatibility Table ..................................47
` 8.10.7 Status Codes ..............................................48
` 8.10.8 Example - Simple Lock Request .............................48
` 8.10.9 Example - Refreshing a Write Lock .........................49
` 8.10.10 Example - Multi-Resource Lock Request ....................50
` 8.11 UNLOCK Method ................................................51
` 8.11.1 Example - UNLOCK ..........................................52
` 9 HTTP HEADERS FOR DISTRIBUTED AUTHORING ..........................52
` 9.1 DAV Header ...................................................52
` 9.2 Depth Header .................................................52
` 9.3 Destination Header ...........................................54
` 9.4 If Header ....................................................54
` 9.4.1 No-tag-list Production ....................................55
` 9.4.2 Tagged-list Production ....................................55
` 9.4.3 not Production ............................................56
` 9.4.4 Matching Function .........................................56
` 9.4.5 If Header and Non-DAV Compliant Proxies ...................57
` 9.5 Lock-Token Header ............................................57
` 9.6 Overwrite Header .............................................57
` 9.7 Status-URI Response Header ...................................57
` 9.8 Timeout Request Header .......................................58
` 10 STATUS CODE EXTENSIONS TO HTTP/1.1 ............................59
` 10.1 102 Processing ...............................................59
` 10.2 207 Multi-Status .............................................59
` 10.3 422 Unprocessable Entity .....................................60
` 10.4 423 Locked ...................................................60
` 10.5 424 Failed Dependency ........................................60
` 10.6 507 Insufficient Storage .....................................60
` 11 MULTI-STATUS RESPONSE .........................................60
` 12 XML ELEMENT DEFINITIONS .......................................61
` 12.1 activelock XML Element .......................................61
`
`Goland, et al. Standards Track [Page 3]
`
`Adobe - Exhibit 1013, page 3
`
`

`

`
`RFC 2518 WEBDAV February 1999
`
` 12.1.1 depth XML Element .........................................61
` 12.1.2 locktoken XML Element .....................................61
` 12.1.3 timeout XML Element .......................................61
` 12.2 collection XML Element .......................................62
` 12.3 href XML Element .............................................62
` 12.4 link XML Element .............................................62
` 12.4.1 dst XML Element ...........................................62
` 12.4.2 src XML Element ...........................................62
` 12.5 lockentry XML Element ........................................63
` 12.6 lockinfo XML Element .........................................63
` 12.7 lockscope XML Element ........................................63
` 12.7.1 exclusive XML Element .....................................63
` 12.7.2 shared XML Element ........................................63
` 12.8 locktype XML Element .........................................64
` 12.8.1 write XML Element .........................................64
` 12.9 multistatus XML Element ......................................64
` 12.9.1 response XML Element ......................................64
` 12.9.2 responsedescription XML Element ...........................65
` 12.10 owner XML Element ...........................................65
` 12.11 prop XML element ............................................66
` 12.12 propertybehavior XML element ................................66
` 12.12.1 keepalive XML element ....................................66
` 12.12.2 omit XML element .........................................67
` 12.13 propertyupdate XML element ..................................67
` 12.13.1 remove XML element .......................................67
` 12.13.2 set XML element ..........................................67
` 12.14 propfind XML Element ........................................68
` 12.14.1 allprop XML Element ......................................68
` 12.14.2 propname XML Element .....................................68
` 13 DAV PROPERTIES ................................................68
` 13.1 creationdate Property ........................................69
` 13.2 displayname Property .........................................69
` 13.3 getcontentlanguage Property ..................................69
` 13.4 getcontentlength Property ....................................69
` 13.5 getcontenttype Property ......................................70
` 13.6 getetag Property .............................................70
` 13.7 getlastmodified Property .....................................70
` 13.8 lockdiscovery Property .......................................71
` 13.8.1 Example - Retrieving the lockdiscovery Property ...........71
` 13.9 resourcetype Property ........................................72
` 13.10 source Property .............................................72
` 13.10.1 Example - A source Property ..............................72
` 13.11 supportedlock Property ......................................73
` 13.11.1 Example - Retrieving the supportedlock Property ..........73
` 14 INSTRUCTIONS FOR PROCESSING XML IN DAV ........................74
` 15 DAV COMPLIANCE CLASSES ........................................75
` 15.1 Class 1 ......................................................75
` 15.2 Class 2 ......................................................75
`
`Goland, et al. Standards Track [Page 4]
`
`Adobe - Exhibit 1013, page 4
`
`

`

`
`RFC 2518 WEBDAV February 1999
`
` 16 INTERNATIONALIZATION CONSIDERATIONS ...........................76
` 17 SECURITY CONSIDERATIONS .......................................77
` 17.1 Authentication of Clients ....................................77
` 17.2 Denial of Service ............................................78
` 17.3 Security through Obscurity ...................................78
` 17.4 Privacy Issues Connected to Locks ............................78
` 17.5 Privacy Issues Connected to Properties .......................79
` 17.6 Reduction of Security due to Source Link .....................79
` 17.7 Implications of XML External Entities ........................79
` 17.8 Risks Connected with Lock Tokens .............................80
` 18 IANA CONSIDERATIONS ...........................................80
` 19 INTELLECTUAL PROPERTY .........................................81
` 20 ACKNOWLEDGEMENTS ..............................................82
` 21 REFERENCES ....................................................82
` 21.1 Normative References .........................................82
` 21.2 Informational References .....................................83
` 22 AUTHORS’ ADDRESSES ............................................84
` 23 APPENDICES ....................................................86
` 23.1 Appendix 1 - WebDAV Document Type Definition .................86
` 23.2 Appendix 2 - ISO 8601 Date and Time Profile ..................88
` 23.3 Appendix 3 - Notes on Processing XML Elements ................89
` 23.3.1 Notes on Empty XML Elements ...............................89
` 23.3.2 Notes on Illegal XML Processing ...........................89
` 23.4 Appendix 4 -- XML Namespaces for WebDAV ......................92
` 23.4.1 Introduction ..............................................92
` 23.4.2 Meaning of Qualified Names ................................92
` 24 FULL COPYRIGHT STATEMENT ......................................94
`
`1 Introduction
`
` This document describes an extension to the HTTP/1.1 protocol that
` allows clients to perform remote web content authoring operations.
` This extension provides a coherent set of methods, headers, request
` entity body formats, and response entity body formats that provide
` operations for:
`
` Properties: The ability to create, remove, and query information
` about Web pages, such as their authors, creation dates, etc. Also,
` the ability to link pages of any media type to related pages.
`
` Collections: The ability to create sets of documents and to retrieve
` a hierarchical membership listing (like a directory listing in a file
` system).
`
`Goland, et al. Standards Track [Page 5]
`
`Adobe - Exhibit 1013, page 5
`
`

`

`
`RFC 2518 WEBDAV February 1999
`
` Locking: The ability to keep more than one person from working on a
` document at the same time. This prevents the "lost update problem,"
` in which modifications are lost as first one author then another
` writes changes without merging the other author’s changes.
`
` Namespace Operations: The ability to instruct the server to copy and
` move Web resources.
`
` Requirements and rationale for these operations are described in a
` companion document, "Requirements for a Distributed Authoring and
` Versioning Protocol for the World Wide Web" [RFC2291].
`
` The sections below provide a detailed introduction to resource
` properties (section 4), collections of resources (section 5), and
` locking operations (section 6). These sections introduce the
` abstractions manipulated by the WebDAV-specific HTTP methods
` described in section 8, "HTTP Methods for Distributed Authoring".
`
` In HTTP/1.1, method parameter information was exclusively encoded in
` HTTP headers. Unlike HTTP/1.1, WebDAV encodes method parameter
` information either in an Extensible Markup Language (XML) [REC-XML]
` request entity body, or in an HTTP header. The use of XML to encode
` method parameters was motivated by the ability to add extra XML
` elements to existing structures, providing extensibility; and by
` XML’s ability to encode information in ISO 10646 character sets,
` providing internationalization support. As a rule of thumb,
` parameters are encoded in XML entity bodies when they have unbounded
` length, or when they may be shown to a human user and hence require
` encoding in an ISO 10646 character set. Otherwise, parameters are
` encoded within HTTP headers. Section 9 describes the new HTTP
` headers used with WebDAV methods.
`
` In addition to encoding method parameters, XML is used in WebDAV to
` encode the responses from methods, providing the extensibility and
` internationalization advantages of XML for method output, as well as
` input.
`
` XML elements used in this specification are defined in section 12.
`
` The XML namespace extension (Appendix 4) is also used in this
` specification in order to allow for new XML elements to be added
` without fear of colliding with other element names.
`
` While the status codes provided by HTTP/1.1 are sufficient to
` describe most error conditions encountered by WebDAV methods, there
` are some errors that do not fall neatly into the existing categories.
` New status codes developed for the WebDAV methods are defined in
` section 10. Since some WebDAV methods may operate over many
`
`Goland, et al. Standards Track [Page 6]
`
`Adobe - Exhibit 1013, page 6
`
`

`

`
`RFC 2518 WEBDAV February 1999
`
` resources, the Multi-Status response has been introduced to return
` status information for multiple resources. The Multi-Status response
` is described in section 11.
`
` WebDAV employs the property mechanism to store information about the
` current state of the resource. For example, when a lock is taken out
` on a resource, a lock information property describes the current
` state of the lock. Section 13 defines the properties used within the
` WebDAV specification.
`
` Finishing off the specification are sections on what it means to be
` compliant with this specification (section 15), on
` internationalization support (section 16), and on security (section
` 17).
`
`2 Notational Conventions
`
` Since this document describes a set of extensions to the HTTP/1.1
` protocol, the augmented BNF used herein to describe protocol elements
` is exactly the same as described in section 2.1 of [RFC2068]. Since
` this augmented BNF uses the basic production rules provided in
` section 2.2 of [RFC2068], these rules apply to this document as well.
`
` The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
` "SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
` document are to be interpreted as described in RFC 2119 [RFC2119].
`
`3 Terminology
`
` URI/URL - A Uniform Resource Identifier and Uniform Resource Locator,
` respectively. These terms (and the distinction between them) are
` defined in [RFC2396].
`
` Collection - A resource that contains a set of URIs, termed member
` URIs, which identify member resources and meets the requirements in
` section 5 of this specification.
`
` Member URI - A URI which is a member of the set of URIs contained by
` a collection.
`
` Internal Member URI - A Member URI that is immediately relative to
` the URI of the collection (the definition of immediately relative is
` given in section 5.2).
`
` Property - A name/value pair that contains descriptive information
` about a resource.
`
`Goland, et al. Standards Track [Page 7]
`
`Adobe - Exhibit 1013, page 7
`
`

`

`
`RFC 2518 WEBDAV February 1999
`
` Live Property - A property whose semantics and syntax are enforced by
` the server. For example, the live "getcontentlength" property has
` its value, the length of the entity returned by a GET request,
` automatically calculated by the server.
`
` Dead Property - A property whose semantics and syntax are not
` enforced by the server. The server only records the value of a dead
` property; the client is responsible for maintaining the consistency
` of the syntax and semantics of a dead property.
`
` Null Resource - A resource which responds with a 404 (Not Found) to
` any HTTP/1.1 or DAV method except for PUT, MKCOL, OPTIONS and LOCK.
` A NULL resource MUST NOT appear as a member of its parent collection.
`
`4 Data Model for Resource Properties
`
`4.1 The Resource Property Model
`
` Properties are pieces of data that describe the state of a resource.
` Properties are data about data.
`
` Properties are used in distributed authoring environments to provide
` for efficient discovery and management of resources. For example, a
` ’subject’ property might allow for the indexing of all resources by
` their subject, and an ’author’ property might allow for the discovery
` of what authors have written which documents.
`
` The DAV property model consists of name/value pairs. The name of a
` property identifies the property’s syntax and semantics, and provides
` an address by which to refer to its syntax and semantics.
`
` There are two categories of properties: "live" and "dead". A live
` property has its syntax and semantics enforced by the server. Live
` properties include cases where a) the value of a property is read-
` only, maintained by the server, and b) the value of the property is
` maintained by the client, but the server performs syntax checking on
` submitted values. All instances of a given live property MUST comply
` with the definition associated with that property name. A dead
` property has its syntax and semantics enforced by the client; the
` server merely records the value of the property verbatim.
`
`4.2 Existing Metadata Proposals
`
` Properties have long played an essential role in the maintenance of
` large document repositories, and many current proposals contain some
` notion of a property, or discuss web metadata more generally. These
` include PICS [REC-PICS], PICS-NG, XML, Web Collections, and several
` proposals on representing relationships within HTML. Work on PICS-NG
`
`Goland, et al. Standards Track [Page 8]
`
`Adobe - Exhibit 1013, page 8
`
`

`

`
`RFC 2518 WEBDAV February 1999
`
` and Web Collections has been subsumed by the Resource Description
` Framework (RDF) metadata activity of the World Wide Web Consortium.
` RDF consists of a network-based data model and an XML representation
` of that model.
`
` Some proposals come from a digital library perspective. These
` include the Dublin Core [RFC2413] metadata set and the Warwick
` Framework [WF], a container architecture for different metadata
` schemas. The literature includes many examples of metadata,
` including MARC [USMARC], a bibliographic metadata format, and a
` technical report bibliographic format employed by the Dienst system
` [RFC1807]. Additionally, the proceedings from the first IEEE Metadata
` conference describe many community-specific metadata sets.
`
` Participants of the 1996 Metadata II Workshop in Warwick, UK [WF],
` noted that "new metadata sets will develop as the networked
` infrastructure matures" and "different communities will propose,
` design, and be responsible for different types of metadata." These
` observations can be corroborated by noting that many community-
` specific sets of metadata already exist, and there is significant
` motivation for the development of new forms of metadata as many
` communities increasingly make their data available in digital form,
` requiring a metadata format to assist data location and cataloging.
`
`4.3 Properties and HTTP Headers
`
` Properties already exist, in a limited sense, in HTTP message
` headers. However, in distributed authoring environments a relatively
` large number of properties are needed to describe the state of a
` resource, and setting/returning them all through HTTP headers is
` inefficient. Thus a mechanism is needed which allows a principal to
` identify a set of properties in which the principal is interested and
` to set or retrieve just those properties.
`
`4.4 Property Values
`
` The value of a property when expressed in XML MUST be well formed.
`
` XML has been chosen because it is a flexible, self-describing,
` structured data format that supports rich schema definitions, and
` because of its support for multiple character sets. XML’s self-
` describing nature allows any property’s value to be extended by
` adding new elements. Older clients will not break when they
` encounter extensions because they will still have the data specified
` in the original schema and will ignore elements they do not
` understand. XML’s support for multiple character sets allows any
` human-readable property to be encoded and read in a character set
` familiar to the user. XML’s support for multiple human languages,
`
`Goland, et al. Standards Track [Page 9]
`
`Adobe - Exhibit 1013, page 9
`
`

`

`
`RFC 2518 WEBDAV February 1999
`
` using the "xml:lang" attribute, handles cases where the same
` character set is employed by multiple human languages.
`
`4.5 Property Names
`
` A property name is a universally unique identifier that is associated
` with a schema that provides information about the syntax and
` semantics of the property.
`
` Because a property’s name is universally unique, clients can depend
` upon consistent behavior for a particular property across multiple
` resources, on the same and across different servers, so long as that
` property is "live" on the resources in question, and the
` implementation of the live property is faithful to its definition.
`
` The XML namespace mechanism, which is based on URIs [RFC2396], is
` used to name properties because it prevents namespace collisions and
` provides for varying degrees of administrative control.
`
` The property namespace is flat; that is, no hierarchy of properties
` is explicitly recognized. Thus, if a property A and a property A/B
` exist on a resource, there is no recognition of any relationship
` between the two properties. It is expected that a separate
` specification will eventually be produced which will address issues
` relating to hierarchical properties.
`
` Finally, it is not possible to define the same property twice on a
` single resource, as this would cause a collision in the resource’s
` property namespace.
`
`4.6 Media Independent Links
`
` Although HTML resources support links to other resources, the Web
` needs more general support for links between resources of any media
` type (media types are also known as MIME types, or content types).
` WebDAV provides such links. A WebDAV link is a special type of
` property value, formally defined in section 12.4, that allows typed
` connections to be established between resources of any media type.
` The property value consists of source and destination Uniform
` Resource Identifiers (URIs); the property name identifies the link
` type.
`
`Goland, et al. Standards Track [Page 10]
`
`Adobe - Exhibit 1013, page 10
`
`

`

`
`RFC 2518 WEBDAV February 1999
`
`5 Collections of Web Resources
`
` This section provides a description of a new type of Web resource,
` the collection, and discusses its interactions with the HTTP URL
` namespace. The purpose of a collection resource is to model
` collection-like objects (e.g., file system directories) within a
` server’s namespace.
`
` All DAV compliant resources MUST support the HTTP URL namespace model
` specified herein.
`
`5.1 HTTP URL Namespace Model
`
` The HTTP URL namespace is a hierarchical namespace where the
` hierarchy is delimited with the "/" character.
`
` An HTTP URL namespace is said to be consistent if it meets the
` following conditions: for every URL in the HTTP hierarchy there
` exists a collection that contains that URL as an internal member.
` The root, or top-level collection of the namespace under
` consideration is exempt from the previous rule.
`
` Neither HTTP/1.1 nor WebDAV require that the entire HTTP URL
` namespace be consistent. However, certain WebDAV methods are
` prohibited from producing results that cause namespace
` inconsistencies.
`
` Although implicit in [RFC2068] and [RFC2396], any resource, including
` collection resources, MAY be identified by more than one URI. For
` example, a resource could be identified by multiple HTTP URLs.
`
`5.2 Collection Resources
`
` A collection is a resource whose state consists of at least a list of
` internal member URIs and a set of properties, but which may have
` additional state such as entity bodies returned by GET. An internal
` member URI MUST be immediately relative to a base URI of the
` collection. That is, the internal member URI is equal to a
` containing collection’s URI plus an additional segment for non-
` collection resources, or additional segment plus trailing slash "/"
` for collection resources, where segment is defined in section 3.3 of
` [RFC2396].
`
` Any given internal member URI MUST only belong to the collection
` once, i.e., it is illegal to have multiple instances of the same URI
` in a collection. Properties defined on collections behave exactly as
` do properties on non-collection resources.
`
`Goland, et al. Standards Track [Page 11]
`
`Adobe - Exhibit 1013, page 11
`
`

`

`
`RFC 2518 WEBDAV February 1999
`
` For all WebDAV compliant resources A and B, identified by URIs U and
` V, for which U is immediately relative to V, B MUST be a collection
` that has U as an internal member URI. So, if the resource with URL
` http://foo.com/bar/blah is WebDAV compliant and if the resource with
` URL http://foo.com/bar/ is WebDAV compliant then the resource with
` URL http://foo.com/bar/ must be a collection and must contain URL
` http://foo.com/bar/blah as an internal member.
`
` Collection resources MAY list the URLs of non-WebDAV compliant
` children in the HTTP URL namespace hierarchy as internal members but
` are not required to do so. For example, if the resource with URL
` http://foo.com/bar/blah is not WebDAV compliant and the URL
` http://foo.com/bar/ identifies a collection then URL
` http://foo.com/bar/blah may or may not be an internal member of the
` collection with URL http://foo.com/bar/.
`
` If a WebDAV compliant resource has no WebDAV compliant children in
` the HTTP URL namespace hierarchy then the WebDAV compliant resource
` is not required to be a collection.
`
` There is a standing convention that when a collection is referred to
` by its name without a trailing slash, the trailing slash is
` automatic