NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01
Jim Amsden <jamsden@us.ibm.com>
Ned Freed <ned.freed@mrochek.com>
Patrik Faltstrom <paf@cisco.com>
Patrik Faltstrom <paf@cisco.com>
General Discussion:ietf-dav-versioning@w3.org
To Subscribe: ietf-dav-versioning-request@w3.org
In Body: subscribe
Archive: http://lists.w3.org/Archives/Public/ietf-dav-versioning/
This working group will define extensions to HTTP and the WebDAV Distributed Authoring Protocol necessary to enable distributed Web authoring tools to perform, in an interoperable manner, versioning and configuration management of Web resources.
Versioning, parallel development, and configuration management are important features for remote authoring of Web content. Version management is concerned with tracking and accessing the history of important states of a single Web resource, such as a standalone Web page. Parallel development provides additional resource availability in multi-user, distributed environments, letting authors make changes on the same resource at the same time, later merging together those changes. Configuration management addresses the problems of tracking and accessing multiple interrelated resources over time as sets of resources, not simply individual resources. Traditionally, artifacts of software development, including code, design, test cases, requirements, help files, and more have been a focus of configuration management. Web sites, comprised of multiple inter-linked resources (HTML, graphics, sound, CGI, and others), are an important class of complex information artifacts that benefit from the application of configuration management.
The WebDAV working group originally focused on defining version management capabilities for remote authoring applications. However, it has become clear that while versioning functionality alone is useful for a range of content authoring scenarios involving one, or a small set of resources, versioning alone is insufficient for managing larger sets of content. Protocol support for parallel development and simple remote configuration management of Web resources provides functionality for managing larger sets of interrelated content developed by multiple users at different locations.
A sub-group of the WebDAV working group has developed functional requirements for versioning and configuration management of Web content. These requirements encompass the following capabilities, which shall be considered by this working group:
IN-SCOPE:
* Naming and accessing resource versions and configurations
* Creating new revisions of a resource
* Placing a resource under version and configuration control
* Parallel development
* History retrieval
* Differencing
* Merging of revisions and configurations
* Operations on configurations
* Mapping resource versions and configurations to the URL namespace
* Versioning support for downlevel HTTP and WebDAV clients
Further information on these objectives can be found in the document, "Goals for Web Versioning".
NOT IN SCOPE:
* HTTP server to server communication protocols
* Development process management, workflow, or change request management
* Versioning and configuration management via non-HTTP and WebDAV protocols.
* Implementation of functionality by non-origin proxies
Deliverables
The following documents are expected to form the final output of this working group.
1. A goals document, which describes the high-level functional requirements for remote versioning and configuration management, including rationale.
2. A model document, which describes the semantics of versioning, configuration management, and parallel development in a protocol independent fashion.
3. A protocol specification, which describes new HTTP methods, headers, request bodies, response bodies, and WebDAV properties to implement the remote versioning and configuration management goals.
4. A traceability document, which describes the mapping between goals and protocol features.
Oct 99 |
|
(Goals) Create final version of distributed versioning and configuration management goals document. Submit for approval as Informational RFC. |
Oct 99 |
|
(Specification, Model) Produce revised model document, and distributed versioning and configuration management protocol specification. Submit both as Internet Drafts. |
Nov 99 |
|
(Meeting, Specification, Model) Meet at Washington, DC IETF and hold working group meeting to review the model document and the distributed versioning and configuration management protocol specification. |
Done |
|
(Specification, Model, Traceability) Submit revised model document, and distributed versioning and configuration management protocol specification as Internet Drafts. Submit revised traceability document as an Internet Draft. |
Mar 00 |
|
(Meeting, Specification, Model) Meet at Adelaide IETF and hold working group meeting to review the model document and |
Apr 00 |
|
(Specification, Model, Traceability) Submit revised model document, distributed versioning and configuration management protocol specification, and traceability document as Internet Drafts. Hold working group last call for comments on all drafts. |
May 00 |
|
(Specification, Model, Traceabiluty) Revise model document, distributed versioning and configuration management specification, and traceability document based on WG last call comments, and submit specification to the IESG for approval as a Proposed Standard RFC, and submit the model and traceability documents to IESG as Informational RFCs. |
Delta-V Working Group Meeting (1pm Wednesday August 8th, 2001)
IETF'51 London, England
Introduction by Jim Amsden, including status of working group document.
IETF-wide last call imminent and well on the path to Proposed Standard.
Geoff presented the changes made to the draft since versioning-16:
- Overview of DAV:auto-version values. Noted that DAV:locked-checkout implies unlock checkin.
- The supported live properties are marshalled as XML attributes, the proposal is to switch them back to name elements. However, method names may contain characters that are not valid as XML element names, so they will stay as attribute values, and there is no namespace to report.
- Remove DAV:ok as a defined value for the check-out fork and check-in fork, and just leave the DAV:forbidden and DAV:discouraged values. Servers should just check for these flags. This means that forking is ok if the value is empty (or DAV:ok).
- Similarly, an empty value for DAV:auto-version means that there is no auto-versioning happening for that resource.
- Change the specification to say that servers SHOULD implement the expand property report, and move the description of the report earlier in the document to illustrate that it is not an advanced feature.
- Should clarify the relationship between the DAV:supported-method-set and the Allow: header. Should it report for the current state of the resource ? or for any state of the resource? Current consensus is that 'supported' means for any state.
- Should we clarify what the Allow: header means? E.g. for a version-controlled resource, does Allow: include both CHECKIN and CHECKOUT or only ever just one of them?
- Note that we still require the supported-methods property to permit depth queries. Call for consensus within the room on what "allow" and "supported" means ? agreed that they should mean the same thing. Proposed that it means will succeed on some state of the resource, and not necessarily the current state.
- When a version-controlled resource is auto-checked-out, an explicit UNLOCK request will fail if the version-controlled resource cannot be auto-checked-in. However, when the server removes the lock (when the lock expires) what is the server allowed to do on CHECKIN failure? (a) leave the resource checked-out and unlocked, (b) fail the lock timeout, and leave the resource checked-out and locked, (c) something else? Discussion of coupling UNLOCK and CHECKIN ? how can a versioning aware client do the UNLOCK if the CHECKIN will fail? No resolution in the meeting.
- Discussion of adding extra data to the error conditions.
- Replace locate history
- Remove the PROPFIND semantics from UPDATE and MERGE (or justify its use in the specification).
- Discussion of procedure for IESG last call. Ned stated that there appears to be no major issues outstanding with the latest draft of the document, so Geoff will put produce versioning-17 sometime next week and let that go forward for IESG last call.
- Lisa presented a proposal for identifying a subset of DeltaV for document versioning without forking. It would include core, in-place check-out and maybe working resources package. It will be DeltaV compliant.
- Lisa stated that she has outstanding issues with supported-live-properties. The group agreed to compromise by stating that the specification will state that DAV:supported-live-properties MUST include the supported DeltaV and WebDAV live properties and SHOULD include other server-defined live properties.
- Lisa also requested an UNVERSION capability to remove the history resource and versions and working resources and leave the version-controlled resources as regular versionable resources. Maybe evenleave working resources as versionable resources.
- Question: What happens to version-controlled resources when a history resource is DELETEd? Should say in the spec?
- Future work should consider variant management and document work flow and change request management. Put out a request for participants in the WebDAV working group.
- WebDAV inter-op events should include DeltaV (rather than have a separate DeltaV event).
- Expected progression from here: Geoff writes versioning-17; one week to get through queue into draft; Ned gives Steve the ok to send versioning-17 to IESG last call; last call period is two weeks (min.); then it goes onto the IESG agenda for becoming a Proposed Standard (IESG meets every two weeks). The RFC editor output requires careful author review. Close down the working group. After six months consider going for draft standard which requires two clients and two servers with distinct code bases to inter-op. Finally go for full standard some time after that.
- Meeting closed at 2:45pm
Regards,
Tim Ellison
None received.