The following diagram illustrates activities. Version V5 is the latest version of foo.html selected by activity Act-2, and version V8 is the latest version of bar.html selected by activity Act-2. foo.html History bar.html History +---+ +---+ Act-1| |V1 Act-1| |V6 +---+ +---+ | | | | +---+ +---+ Act-1| |V2 Act-2| |V7 +---+ +---+ / \ | / \ | +---+ +---+ +---+ Act-1| |V3 Act-2| |V4 Act-2| |V8 +---+ +---+ +---+ | | | | +---+ +---+ Act-2| |V5 Act-3| |V9 +---+ +---+ Activities appear under a variety of names in existing versioning systems. When an activity is used to capture a logical change, it is commonly called a "change set". When an activity is used to capture a line of descent, it is commonly called a "branch". When a system supports both branches and change sets, it is often useful to require that a particular change set occur on a particular branch. This relationship can be captured by making the change set activity be a "subactivity" of the branch activity.
property, but all DAV:activity-version-set versions from a given version history must be on a single line of descent from the root version of that version history. <!ELEMENT activity-version-set (href*)>
Additional Postconditions: (DAV:initialize-activity-set): The DAV:activity-set of the checked-out resource is set as follows: - If DAV:new is specified as the DAV:activity-set in the request body, then a new activity created by the server is used. - Otherwise, if activities are specified in the request body, then those activities are used. - Otherwise, if the version-controlled resource is a member of a workspace and the DAV:current-activity-set of the workspace is set, then those activities are used. - Otherwise, the DAV:activity-set of the DAV:checked-out version is used. (DAV:initialize-unreserved): If DAV:unreserved was specified in the request body, then the DAV:unreserved property of the checked-out resource MUST be "true".
controlled resource /x/a currently has V4 of VH19 as its DAV:checked-in version, while /x/b has V8 of VH24 as its DAV:checked-in version. VH19 +---------+ | +---+ | | | |V4 | | +---+ | | | | | | | | +---+ | | | |V5 | VH14 | +---+ | +---------+ | | | | +---+ | | | | a +---+ | | |V1 | | +---+ | ---->| |checked-in=V4 | +---+ | a | | |V6 | / +---+ | | ------>| +---+ | / | | / | +---------+ +---+ | +---+ | /x | |checked-in=V2 | | |V2 | +---+ | +---+ | VH24 \ | | \ | b +---------+ \ b +---+ | | ------>| +---+ | ---->| |checked-in=V8 | +---+ | | | |V7 | +---+ | | |V3 | | +---+ | | +---+ | | | | +---------+ | | | | +---+ | | | |V8 | | +---+ | | | | | | | | +---+ | | | |V9 | | +---+ | +---------+ For any request (e.g., DELETE, MOVE, COPY) that modifies a version- controlled binding of a checked-in version-controlled collection, the request MUST fail unless the version-controlled collection has a DAV:auto-version property that will automatically check out the version-controlled collection when it is modified. Although a collection version only records the version-controlled bindings of a collection, a version-controlled collection MAY contain both version-controlled and non-version-controlled bindings. Non-
version-controlled bindings are not under version control, and therefore can be added or deleted without checking out the version- controlled collection. Note that a collection version captures only a defined subset of the state of a collection. In particular, a version of a collection captures its dead properties and its bindings to version-controlled resources, but not its live properties or bindings to non-version- controlled resources. When a server supports the working-resource feature, a client can check out a collection version to create a working collection. Unlike a version-controlled collection, which contains bindings to version-controlled resources and non-version-controlled resources, a working collection contains bindings to version history resources and non-version-controlled resources. In particular, a working collection is initialized to contain bindings to the version history resources specified by the DAV:version-controlled-binding-set of the checked out collection version. The members of a working collection can then be deleted or moved to another working collection. Non- version-controlled resources can be added to a working collection with methods such as PUT, COPY, and MKCOL. When a working collection is checked in, a VERSION-CONTROL request is automatically applied to every non-version-controlled member of the working collection, and each non-version-controlled member is replaced by its newly created version history. The DAV:version-controlled-binding-set of the new version resulting from checking in a working collection contains the binding name and version history URL for each member of the working collection.
An UPDATE or MERGE request can give a version-controlled collection a version-controlled internal member that has the same name as an existing non-version-controlled internal member. In this case, the non-version-controlled internal member takes precedence and is said to "eclipse" the new versioned-controlled internal member. If the non-version-controlled internal member is removed (e.g., by a DELETE or MOVE), the version-controlled internal member is exposed.
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.
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. 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 RFC 2518, 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 RFC 3023. 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 RFC 3066) 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 RFC 2518, 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 RFC 3023 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. RFC 2518, 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.
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.
RFC 2518 for XML elements. All other IANA considerations from RFC 2518 are also applicable to WebDAV Versioning. 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.
[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, RFC 2026, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998. [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. Jensen, "HTTP Extensions for Distributed Authoring - WEBDAV", RFC 2518, 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", RFC 2616, June 1999. [RFC3023] Murata, M., St.Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001. [RFC3066] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
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. RFC2616] - MKCOL [RFC2518] - MKACTIVITY (activity) - VERSION-CONTROL (workspace) - MKWORKSPACE (workspace) RFC2518].
Supported methods: - CHECKIN (checkout-in-place or working-resource) - all DeltaV-compliant resource methods.
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 RFC Editor function is currently provided by the Internet Society.