Expires April 1, 2003
Geoffrey Clemm, Rational Software
Variant Support for WebDAV
Status of this Memo
This document is an Internet-Draft and is in full conformance with all provisions of RFC 2026, Section 10.
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 obsoleted 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."
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This document specifies a set of properties and method semantics that define the WebDAV Variants extensions to the HTTP/1.1 protocol.† WebDAV Variants will minimize the complexity of clients that are capable of interoperating with a variety of repository managers, to facilitate widespread deployment of applications capable of utilizing the WebDAV Variant services.
Table of Contents
This document specifies an extension of the DeltaV/WebDAV protocol that provides support for Variant resources.
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.
The term "protected" is placed in parentheses following the definition of a protected property (see RFC3253).
The term "computed" is placed in parentheses following the definition of a computed property (see RFC3253).
When an XML element type in the "DAV:" namespace is referenced in this document outside of the context of an XML fragment, the string "DAV:" will be prefixed to the element type.
When a precondition or postcondition of a method is defined in this document, the definition can be prefixed by a parenthesized XML element type.† If a precondition is violated by a request or a postcondition cannot be satisfied, the XML element of the violated precondition or unsatisfied postcondition will be returned in the response body (see RFC3253).
This document uses the terms defined in RFC3253 and in this section.
A "variant resource", or simply "variant", is a special kind of version-controlled resource whose name is allocated by the server.
A "variant-controlled resource" is a special kind of version-controlled resource that maintains a set of variants.† Each variant of a variant-controlled resource selects a version from the version history of that variant-controlled resource.
The variant option provides a mechanism for a server to expose a subset of the versions from the history of a version-controlled resource as a set of special version-controlled resources called "variants" of that version-controlled resource.† When variants of a version-controlled resource are being maintained, that version-controlled resource is called a "variant-controlled resource".† Variants of a resource might be distinguished by language, format, or any other category of interest to a client.
Like any other version-controlled resource, a variant can be checked out in order to modify its content or dead properties.† When a variant of a variant-controlled resource is checked in, a new version is added to the version history of the variant-controlled resource.† When the variant-controlled resource itself is checked out and checked in, both a new version and a new variant is created.† The new variant becomes the "default variant" of that variant-controlled resource.
Unlike the URL for a version, which uniquely identifies exactly that version and is therefore inevitably quite obscure, the URL for a variant is intended to be meaningful to a user, but there is no guarantee that a URL for a variant will continue to identify that variant.† In particular, the URL for a variant of a version-controlled resource will usually change whenever that version-controlled resource is moved.
Since a variant-controlled resource is a version-controlled resource, it has all the properties of a version-controlled resource.† In addition, the variant option introduces the following REQUIRED properties for a variant-controlled resource.
This property identifies the set of version-controlled resources that are the variants of the variant-controlled resource.
<!ELEMENT variant-set (href*)>
This property identifies the default variant of the variant-controlled resource.† Whenever the DAV:checked-in value of the default variant is updated, the content, dead properties, and DAV:checked-in property of the variant-controlled resource are updated to be those of the default variant.
<!ELEMENT default-variant (href)>
(DAV:cannot-delete-default-variant): The request-URL MUST NOT identify a variant identified by the DAV:default-variant of a variant-controlled resource.
(DAV:delete-variant-reference): If the request-URL identifies a variant, any reference to that variant in a DAV:variant-set MUST be removed.
(DAV:cannot-rename-variant): If the request-URL identifies a variant, the request MUST fail.
A VERSION-CONTROL request may specify that variants MUST be maintained for the version-controlled resource, i.e. that the version-controlled resource will also be a variant controlled resource.
<!ELEMENT version-control ANY>
ANY value: A sequence of elements with at most one DAV:variant-control element.
<!ELEMENT variant-control EMPTY>
(DAV:variant-control): The DAV:default-variant property of the version-controlled resource MUST identify a new variant resource whose DAV:checked-in property identifies the new version.† The DAV:variant-set of the version-controlled resource MUST contain a URL for this new variant.
(DAV:create-new-variant): If the request-URL identifies a variant-controlled resource, the DAV:default-variant of the variant-controlled resource MUST have been updated to identify a new variant whose DAV:checked-in property identifies the new version, and the DAV:variant-set of the variant-controlled resource MUST have been updated to contain a URL for this new variant.
(DAV:update-variant-controlled-resource): If the request-URL identifies the default variant of a variant-controlled resource, then the DAV:checked-in property of the variant-controlled resource MUST have been updated to identify the new version.† If the variant-controlled resource is checked in, then the content and dead properties of the variant-controlled resource MUST have been updated to be those of the new version.
(DAV:delete-variant-predecessor): If the DAV:checked-in property of a variant is modified, the version previously identified by the DAV:checked-in property MAY have been automatically deleted by the server.
<!ELEMENT update ANY>
ANY value: A sequence of elements with at most one DAV:variant element.
<!ELEMENT variant (href)>
(DAV:must-select-variant): If the request-URL identifies a variant-controlled resource, the request body MUST contain a DAV:variant element that identifies a variant in the DAV:variant-set of the variant-controlled resource.
(DAV:update-default-variant): If the request-URL identifies a variant-controlled resource, the DAV:default-variant property of the variant-controlled resource MUST have been updated to identify the variant identified by the DAV:variant element in the request body.† The content, dead properties, and DAV:checked-in property of the variant-controlled resource MUST have been updated to be those of that variant.
(DAV:update-variant-controlled-resource): If the request-URL identifies the default variant of a variant-controlled resource, then the DAV:checked-in property of the variant-controlled resource MUST have been updated to identify the new version.† If the variant-controlled resource is checked in, then the content and dead properties of the version-controlled resource MUST have been updated to be those of the new version.
The internationalization considerations of DeltaV/WebDAV discussed in RFC 3253 also apply to WebDAV Variant support.
This document uses the namespace defined by RFC 2518 for XML elements.† All IANA considerations from RFC 3253 are also applicable to WebDAV Variant support.
The following notice is copied from RFC 2026, Section 10.4, and describes the position of the IETF concerning intellectual property claims made against this document.
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use other technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights.† Information on the procedures of the IETF with respect to rights in standards-track and standards-related documentation can be found in BCP-11.† Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to practice this standard.† Please address the information to the IETF Executive Director.
This protocol is the joint work of the author and the DeltaV working group.
[RFC2026] S.Bradner, "The Internet Standards Process", RFC 2026, October 1996.
[RFC2119] S.Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[RFC2518] Y.Goland, E.Whitehead, A.Faizi, S.R.Carter, D.Jensen, "HTTP Extensions for Distributed Authoring - WEBDAV", RFC 2518, February 1999.
[RFC2616] R.Fielding, J.Gettys, J.C.Mogul, H.Frystyk, L.Masinter, P.Leach, and T.Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3253] G.Clemm, J.Amsden, T.Ellison, C.Kaler, J.Whitehead , "Versioning Extensions to WebDAV", RFC 3253, May 2002.
20 Maguire Road, Lexington, MA 02421