rfc2518.txt

RFC 的详细文档！

   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]

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]

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]

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]

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]

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