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