NOTE: This charter is a snapshot of the 48th IETF Meeting in Pittsburgh, Pennsylvania. It may now be out-of-date. Last Modified: 17-Jul-00
Chair(s):
Jim Amsden <jamsden@us.ibm.com>
Applications Area Director(s):
Ned Freed <ned.freed@innosoft.com>
Patrik Faltstrom <paf@cisco.com>
Applications Area Advisor:
Patrik Faltstrom <paf@cisco.com>
Mailing Lists:
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/
Description of Working Group:
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.
Goals and Milestones:
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. |
Feb 00 |
|
(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. |
Internet-Drafts:
No Request For Comments
Minutes from the Delta-V Working Group Meeting
held 3:30pm - 5:30pm Wednesday 2 Aug 2000, IETF Pittsburg, PA
Special thanks to Tim Ellison for taking such great minutes.
Participant suggested that the server should have a better understanding of the resource types stored on the server (i.e. formats) to simplify the versioning problem. For example, binariews can't (in general) be delta encoded, and text can.
Discussion of the 'agnostic' approach to resource type -- and what delta-v is trying to achieve.
Discussion of granularity and scope of versioning, one resource per versioned object, or multiple resources per object. Not interpreting resources to version control 'links' or compound documents. delta-v is applicable to individual resource level versioning.
Is there any representation in delta-v that captures inter-resource relationships (links) Answer: No. Are additional parts of URL (i.e. fragments, query strings preserved)?
Answer: yes, the actions are against the resource, but the whole URL is relevant. Byte ranges in range requests preserved?
Question regarding reuse of existing error codes. Response was that is done for versioning unaware clients to understand what happened, and because it is recognized that there is a limited number of new codes left to define.
Observation that now we can see that the work on versioning is 'for real' this work should be better known within the IETF. Maybe broadcast a ietf.org.
Question, are we working with W3C to ensure good adoption? Answer that there is good vendor participation and interest in the work.
MKWORKSPACE 13.1 has premature sentence termination.
Explanation regarding initializing the content of a workspace. Requires a better explanation in the motivation document/book of why.
Has the working group considered the use of checksums to determine if a resource already exists, say on the local hard drive? Response was that the history resource on the server is used to show how resources are 'shared' between distinct URLs, and could use e-tag etc. to determine equivalence on the client.
Discussion regarding the coverage of implementation 'tricks' that can be used to implement delta-v, and how they are envisaged to cover RCS and comma-v file for a 'local' server implementation, thru CVS, up to high end multi-site caching CMS -- all using the same protocol. Observation that collaborating machines across the world could use the protocol for distributed systems. The working group compared many different VCM systems when designing the protocol.
Question: Is there any server now available for testing delta-v? Answer: Nothing is publicly available.
Can you roll back a server state or must you checkout and checkin again to move back to a previous state? You can restore to the state of a baseline en masse, or use SET-TARGET to specify the selected revision.
Deleting a revision is left server defined. Discussion of various options for DELETE on a versioning server. Agreed that this will be an interop issue.
Observation that the goals are ill-defined in the protocol document. How does it relate to collaboration support-and what about versioning the web? Response is that delta-v will probably not to represent the 'state of the web'; rather for private corporate use. A different response was that ACLs will allow broader access to storing the state of the web, with restricted visibility of history.
Observation that versioning the 'active web' would be possible, i.e., running programs on distributed systems, SNMP, or router.
Parallel development and merging; how do you merge binary content? Response: there is no requirement to merge resource content, conflicts are flagged as requiring manual intervention.
Overview of MERGE semantics. If you merge into something that is checked-out already, that should be flagged as a conflict -- make that more explicit in the protocol doc.
Predecessors can be modified using a PROPPATCH on the predecessor set, for servers that support that.
Should the checked out revision be remembered as a distinguished predecessor? Divided opinion amongst group.
In activities, all revisions must be on a single line of descent. Clients would use an activity to show the distinguished predecessor relationships between revisions related in this way.
Discussion about the meaning of activities. Worked through some examples of checkin, and checkout in activities.
Further discussion about a distinguished predecessor. The predecessor set is ordered, so clients are free to imply an order if they choose to do so. Protocol doc. should point this out.
Question regarding spreading the history of a versioned resource across multiple servers. Assuming that different revisions of a versioned resource can be on different servers. Response was that such situations are not prevented by the protocol specification, a revision URL is a URL i.e., that resource can be located anywhere. Expect that workspaces will be on different machines.
Reminder that we are coming up to the last call, request that you get the fixes in now.
Question: Are there any recommendations made about notifications or polling frequency to determine when history has been modified on the server. Answer is that notification is not part of delta-v, but may be in the realm of others, look at Instant Messaging (IM).
Is this compatible with the delta encoding internet draft? Should be compatible, may need to send back a revision URL as an e-tag supplement. Maybe delta-encoding could make more use of versioning information to provide more efficient deltas? Was not in the scope of delta-v working group.
Is delta-v based on a stable webdav (i.e., is RFC2518 stable)? Yes, and delta-v will be in a position by Nov. 2000 to make a more formal statement about how stable it is (i.e., state that it is or explain specifically what needs to be done).
Throughout the document should check 'MUST' and 'must' etc. to ensure caps are correct.
Further prediction of how notification would be dovetailed with delta-v.
Should have some place to refer to the other behaviors of delta-v, i.e., in a non-goals section of the goals document to discuss which other working groups / technologies can be used to cover non-goals areas e.g., notification, ACLs, etc.
Suggestion that the protocol should de-couple the making of a baseline and the workspace to which it relates, so that the baseline is linked to the workspace as an explicit operation. Response-A checked out baseline is a surrogate for the workspace itself, without the coupling the baseline must be explicitly updated and it is too easy to get out of sync. Coupling also allows for significant server optimization. An open baseline would be akin to a collection that has yet to be baselined.
Baselines retain names of resources that are relative to the collection of which they are a baseline.
Must have the concept of a default workspace to be able to use baselines -- maybe some variation on MKCOL to link it to an existing baseline?
Checked out baselines must track the state of the arbitrary collection to which they are bound--but unclear about what this means.
Further discussion of implementations of delta-v servers.
Discussion of latest changes -- core is stable, and advanced is not changing a great deal.
Should move goals document into delta-v working group, resubmit it to IETF so that it is visible within delta-v. Can add dependencies in the charter to other standards activities.
Meeting closed at 5:39pm
None received.