14.4 Additional DELETE Semantics
Additional Preconditions:
(DAV:cannot-modify-checked-in-parent): If the request-URL
identifies a version-controlled resource, the DELETE MUST fail
when the collection containing the version-controlled resource is
a checked-in version-controlled collection, unless DAV:auto-
version semantics will automatically check out the version-
controlled collection.
14.5 Additional MKCOL Semantics
Additional Preconditions:
If the request creates a new resource that is automatically placed
under version control, all preconditions for VERSION-CONTROL apply
to the request.
Additional Postconditions:
If the new collection is automatically put under version control,
all postconditions for VERSION-CONTROL apply to the request.
14.6 Additional COPY Semantics
Additional Preconditions:
(DAV:cannot-copy-collection-version): If the source of the request
is a collection version, the request MUST fail.
14.7 Additional MOVE Semantics
Additional Preconditions:
(DAV:cannot-modify-checked-in-parent): If the source of the
request is a version-controlled resource, the request MUST fail
when the collection containing the source is a checked-in
version-controlled collection, unless DAV:auto-version semantics
will automatically check out that version-controlled collection.
(DAV:cannot-modify-destination-checked-in-parent): If the source
of the request is a version-controlled resource, the request MUST
fail when the collection containing the destination is a checked-
in version-controlled collection, unless DAV:auto-version
semantics will automatically check out that version-controlled
collection.
14.8 Additional VERSION-CONTROL Semantics
Additional Preconditions:
(DAV:cannot-modify-checked-in-parent): If the parent of the
request-URL is a checked-in version-controlled collection, the
request MUST fail unless DAV:auto-version semantics will
automatically check out that version-controlled collection.
Additional Postconditions:
(DAV:new-version-controlled-collection): If the request body
identified a collection version, the collection at the request-URL
MUST contain a version-controlled internal member for each
DAV:version-controlled-binding specified in the DAV:version-
controlled-binding-set of the collection version, where the name
and DAV:version-history of the internal member MUST be the
DAV:binding-name and the DAV:version-history specified by the
DAV:version-controlled-binding. If the internal member is a
member of a workspace, and there is another member of the
workspace for the same version history, those two members MUST
identify the same version-controlled resource; otherwise, a
VERSION-CONTROL request with a server selected version of the
version history MUST have been applied to the URL for that
internal member.
14.9 Additional CHECKOUT Semantics
Additional Postconditions:
(DAV:initialize-version-history-bindings): If the request has been
applied to a collection version, the new working collection MUST
be initialized to contain a binding to each of the history
resources identified in the DAV:version-controlled-binding-set of
that collection version.
14.10 Additional CHECKIN Semantics
Additional Postconditions:
(DAV:initialize-version-controlled-bindings): If the request-URL
identified a version-controlled collection, then the DAV:version-
controlled-binding-set of the new collection version MUST contain
a DAV:version-controlled-binding that identifies the binding name
and version history for each version-controlled binding of the
version- controlled collection.
(DAV:version-control-working-collection-members): If the request-
URL identified a working collection, a VERSION-CONTROL request
MUST have been automatically applied to every non-version-
controlled member of the working collection, and each non-
version-controlled member MUST have been replaced by its newly
created version history. If a working collection member was a
non-version-controlled collection, every member of the non-
version-controlled collection MUST have been placed under version
control before the non-version-controlled collection was placed
under version control. The DAV:version-controlled-binding-set of
the new collection version MUST contain a DAV:version-controlled-
binding that identifies the binding name and the version history
URL for each member of the working collection.
14.11 Additional UPDATE and MERGE Semantics
Additional Postconditions:
(DAV:update-version-controlled-collection-members): If the request
modified the DAV:checked-in version of a version-controlled
collection, then the version-controlled members of that version-
controlled collection MUST have been updated. In particular:
- A version-controlled internal member MUST have been deleted if
its version history is not identified by the DAV:version-
controlled-binding-set of the new DAV:checked-in version.
- A version-controlled internal member for a given version
history MUST have been renamed if its binding name differs from
the DAV:binding-name for that version history in the
DAV:version-controlled-binding-set of the new DAV:checked-in
version.
- A new version-controlled internal member MUST have been created
when a version history is identified by the DAV:version-
controlled-binding-set of the DAV:checked-in version, but there
was no member of the version-controlled collection for that
version history. If a new version-controlled member is in a
workspace that already has a version-controlled resource for
that version history, then the new version-controlled member
MUST be just a binding (i.e., another name for) that existing
version-controlled resource. Otherwise, the content and dead
properties of the new version-controlled member MUST have been
initialized to be those of the version specified for that
version history by the request. If no version is specified for
that version history by the request, the version selected is
server defined.
15 Internationalization Considerations
This specification has been designed to be compliant with the IETF
Policy on Character Sets and Languages [RFC2277]. Specifically,
where human-readable strings exist in the protocol, either their
charset is explicitly stated, or XML mechanisms are used to specify
the charset used. Additionally, these human-readable strings all
have the ability to express the natural language of the string.
Most of the human-readable strings in this protocol appear in
properties, such as DAV:creator-displayname. As defined by RFC2518,
properties have their values marshaled as XML. XML has explicit
provisions for character set tagging and encoding, and requires that
XML processors read XML elements encoded, at minimum, using the UTF-8
[RFC2279] encoding of the ISO 10646 multilingual plane. The charset
parameter of the Content-Type header, together with the XML
"encoding" attribute, provide charset identification information for
MIME and XML processors. Proper use of the charset header with XML
is described in RFC3023. XML also provides a language tagging
capability for specifying the language of the contents of a
particular XML element. XML uses either IANA registered language
tags (see RFC3066) or ISO 639 language tags in the "xml:lang"
attribute of an XML element to identify the language of its content
and attributes.
DeltaV applications, since they build upon WebDAV, are subject to the
internationalization requirements specified in RFC2518, Section 16.
In brief, these requirements mandate the use of XML character set
tagging, character set encoding, and language tagging capabilities.
Additionally, they strongly recommend reading RFC3023 for
instruction on the use of MIME media types for XML transport and the
use of the charset header.
Within this specification, a label is a human-readable string that is
marshaled in the Label header and as XML in request entity bodies.
When used in the Label header, the value of the label is URL-escaped
and encoded using UTF-8.
16 Security Considerations
All of the security considerations of WebDAV discussed in RFC2518,
Section 17 also apply to WebDAV versioning. Some aspects of the
versioning protocol help address security risks introduced by WebDAV,
but other aspects can increase these security risks. These issues
are detailed below.
16.1 Auditing and Traceability
WebDAV increases the ease with which a remote client can modify
resources on a web site, but this also increases the risk of
important information being overwritten and lost, either through user
error or user maliciousness. The use of WebDAV versioning can help
address this problem by guaranteeing that previous information is
saved in the form of immutable versions, and therefore is easily
available for retrieval or restoration. In addition, the version
history provides a log of when changes were made, and by whom. When
requests are appropriately authenticated, the history mechanism
provides a clear audit trail for changes to web resources. This can
often significantly improve the ability to identify the source of the
security problem, and thereby help guard against it in the future.
16.2 Increased Need for Access Control
WebDAV versioning provides a variety of links between related pieces
of information. This can increase the risk that authentication or
authorization errors allow a client to locate sensitive information.
For example, if version history is not appropriately protected by
access control, a client can use the version history of a public
resource to identify later versions of that resource that the user
intended to keep private. This increases the need for reliable
authentication and accurate authorization.
A WebDAV versioning client should be designed to handle a mixture of
200 (OK) and 403 (Forbidden) responses on attempts to access the
properties and reports that are supported by a resource. For
example, a particular user may be authorized to access the content
and dead properties of a version-controlled resource, but not be
authorized to access the DAV:checked-in, DAV:checked-out, or
DAV:version-history properties of that resource.
16.3 Security Through Obscurity
While it is acknowledged that "obscurity" is not an effective means
of security, it is often a good technique to keep honest people
honest. Within this protocol, version URLs, version history URLs,
and working resource URLs are generated by the server and can be
properly obfuscated so as not to draw attention to them. For
example, a version of "http://foobar.com/reviews/salaries.html" might
be assigned a URL such as "http://foobar.com/repo/4934943".
16.4 Denial of Service
The auto-versioning mechanism provided by WebDAV can result in a
large number of resources being created on the server, since each
update to a resource could potentially result in the creation of a
new version resource. This increases the risk of a denial of service
attack that exhausts the storage capability of a server. This risk
is especially significant because it can be an unintentional result
of something like an aggressive auto-save feature provided by an
editing client. A server can decrease this risk by using delta
storage techniques to minimize the cost of additional versions, and
by limiting auto-versioning to a locking client, and thereby
decreasing the number of inadvertent version creations.
17 IANA Considerations
This document uses the namespace defined by RFC2518 for XML
elements. All other IANA considerations from RFC2518 are also
applicable to WebDAV Versioning.
18 Intellectual Property
The following notice is copied from RFC2026, 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.
19 Acknowledgements
This protocol is the collaborative product of the authors and the
rest of the DeltaV design team: Boris Bokowski, Bruce Cragun
(Novell), Jim Doubek (Macromedia), David Durand (INSO), Lisa
Dusseault (Xythos), Chuck Fay (FileNet), Yaron Goland, Mark Hale
(Interwoven), Henry Harbury (Merant), James Hunt, Jeff McAffer (OTI),
Peter Raymond (Merant), Juergen Reuter, Edgar Schwarz (Marconi), Eric
Sedlar (Oracle), Bradley Sergeant, Greg Stein, and John Vasta
(Rational). We would like to acknowledge the foundation laid for us
by the authors of the WebDAV and HTTP protocols upon which this
protocol is layered, and the invaluable feedback from the WebDAV and
DeltaV working groups.
20 References
[ISO639] ISO, "Code for the representation of names of languages",
ISO 639:1988, 1998.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC2277, January 1998.
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC2279, January 1998.
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC2396,
August 1998.
[RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D.
Jensen, "HTTP Extensions for Distributed Authoring -
WEBDAV", RFC2518, February 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
L., Leach, P. and T.Berners-Lee, "Hypertext Transfer
Protocol -- HTTP/1.1", RFC2616, June 1999.
[RFC3023] Murata, M., St.Laurent, S. and D. Kohn, "XML Media Types",
RFC3023, January 2001.
[RFC3066] Alvestrand, H., "Tags for the Identification of Languages",
BCP 47, RFC3066, January 2001.
Appendix A - Resource Classification
This document introduces several different kinds of versioning
resources, such as version-controlled resources, versions, checked-
out resources, and version history resources. As clients discover
resources on a server, they may find it useful to classify those
resources (for example, to make UI decisions on choice of icon and
menu options).
Clients should classify a resource by examining the values of the
DAV:supported-method-set (see Section 3.1.3) and DAV:supported-live-
property-set (see Section 3.1.4) properties of that resource.
The following list shows the supported live properties and methods
for each kind of versioning resource. Where an optional feature
introduces a new kind of versioning resource, that feature is noted
in parentheses following the name of that kind of versioning
resource. If a live property or method is optional for a kind of
versioning resource, the feature that introduces that live property
or method is noted in parentheses following the live property or
method name.
A.1 DeltaV-Compliant Unmapped URL (a URL that identifies no resource)
Supported methods:
- PUT [RFC2616]
- MKCOL [RFC2518]
- MKACTIVITY (activity)
- VERSION-CONTROL (workspace)
- MKWORKSPACE (workspace)
A.2 DeltaV-Compliant Resource
Supported live properties:
- DAV:comment
- DAV:creator-displayname
- DAV:supported-method-set
- DAV:supported-live-property-set
- DAV:supported-report-set
- all properties defined in WebDAV [RFC2518].
Supported methods:
- REPORT
- all methods defined in WebDAV [RFC2518]
- all methods defined in HTTP/1.1 [RFC2616].
A.3 DeltaV-Compliant Collection
Supported live properties:
- all DeltaV-compliant resource properties.
Supported methods:
- BASELINE-CONTROL (baseline)
- all DeltaV-compliant resource methods.
A.4 Versionable Resource
Supported live properties:
- DAV:workspace (workspace)
- DAV:version-controlled-configuration (baseline)
- all DeltaV-compliant resource properties.
Supported methods:
- VERSION-CONTROL
- all DeltaV-compliant resource methods.
A.5 Version-Controlled Resource
Supported live properties:
- DAV:auto-version
- DAV:version-history (version-history)
- DAV:workspace (workspace)
- DAV:version-controlled-configuration (baseline)
- all DeltaV-compliant resource properties.
Supported methods:
- VERSION-CONTROL
- MERGE (merge)
- all DeltaV-compliant resource methods.
A.6 Version
Supported live properties:
- DAV:predecessor-set
- DAV:successor-set
- DAV:checkout-set
- DAV:version-name
- DAV:checkout-fork (in-place-checkout or working resource)
- DAV:checkin-fork (in-place-checkout or working resource)
- DAV:version-history (version-history)
- DAV:label-name-set (label)
- DAV:activity-set (activity)
- all DeltaV-compliant resource properties.
Supported methods:
- LABEL (label)
- CHECKOUT (working-resource)
- all DeltaV-compliant resource methods.
A.7 Checked-In Version-Controlled Resource
Supported live properties:
- DAV:checked-in
- all version-controlled resource properties.
Supported methods:
- CHECKOUT (checkout-in-place)
- UPDATE (update)
- all version-controlled resource methods.
A.8 Checked-Out Resource
Supported live properties:
- DAV:checked-out
- DAV:predecessor-set
- DAV:checkout-fork (in-place-checkout or working resource)
- DAV:checkin-fork (in-place-checkout or working resource)
- DAV:merge-set (merge)
- DAV:auto-merge-set (merge)
- DAV:unreserved (activity)
- DAV:activity-set (activity)
Supported methods:
- CHECKIN (checkout-in-place or working-resource)
- all DeltaV-compliant resource methods.
A.9 Checked-Out Version-Controlled Resource (checkout-in-place)
Supported live properties:
- all version-controlled resource properties.
- all checked-out resource properties.
Supported methods:
- UNCHECKOUT
- all version-controlled resource methods.
- all checked-out resource methods.
A.10 Working Resource (working-resource)
Supported live properties:
- all DeltaV-compliant resource properties
- all checked-out resource properties
- DAV:auto-update.
Supported methods:
- all checked-out resource methods.
A.11 Version History (version-history)
Supported live properties:
- DAV:version-set
- DAV:root-version
- all DeltaV-compliant resource properties.
Supported methods:
- all DeltaV-compliant resource methods.
A.12 Workspace (workspace)
Supported live properties:
- DAV:workspace-checkout-set
- DAV:baseline-controlled-collection-set (baseline)
- DAV:current-activity-set (activity)
- all DeltaV-compliant collection properties.
Supported methods:
- all DeltaV-compliant collection methods.
A.13 Activity (activity)
Supported live properties:
- DAV:activity-version-set
- DAV:activity-checkout-set
- DAV:subactivity-set
- DAV:current-workspace-set
- all DeltaV-compliant resource properties.
Supported methods:
- all DeltaV-compliant resource methods.
A.14 Version-Controlled Collection (version-controlled-collection)
Supported live properties:
- DAV:eclipsed-set
- all version-controlled resource properties.
Supported methods:
- all version-controlled resource methods.
A.15 Collection Version (version-controlled-collection)
Supported live properties:
- DAV:version-controlled-binding-set
- all version properties.
Supported methods:
- all version methods.
A.16 Version-Controlled Configuration (baseline)
Supported live properties:
- DAV:baseline-controlled-collection
- all version-controlled resource properties.
Supported methods:
- all version-controlled resource methods.
A.17 Baseline (baseline)
Supported live properties:
- DAV:baseline-collection
- DAV:subbaseline-set
- all version properties.
Supported methods:
- all version methods.
A.18 Checked-Out Version-Controlled Configuration (baseline)
Supported live properties:
- DAV:subbaseline-set
- all version-controlled configuration properties.
Supported methods:
- all version-controlled configuration methods.
Authors' Addresses
Geoffrey Clemm
Rational Software
20 Maguire Road, Lexington, MA 02421
EMail: geoffrey.clemm@rational.com
Jim Amsden
IBM
3039 Cornwallis, Research Triangle Park, NC 27709
EMail: jamsden@us.ibm.com
Tim Ellison
IBM
Hursley Park, Winchester, UK S021 2JN
EMail: tim_ellison@uk.ibm.com
Christopher Kaler
Microsoft
One Microsoft Way, Redmond, WA 90852
EMail: ckaler@microsoft.com
Jim Whitehead
UC Santa Cruz, Dept. of Computer Science
1156 High Street, Santa Cruz, CA 95064
EMail: ejw@cse.ucsc.edu
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.