Next message: Tim Ellison: "IETF Breakout Meeting"
Message-ID: <398146D1000011EF@mail0.mailsender.net>
Date: Wed, 2 Aug 2000 08:09:48 -0400
From: "Tim Ellison" <tim@peir.com>
To: "Delta-V" <ietf-dav-versioning@w3.org>
Subject: Minutes from IETF breakout meeting, 1-Aug-00
Minutes from the Delta-V Breakout Meeting
held 9am - 5pm Tuesday 1 Aug 2000, IETF Pittsburg, PA
Attendees:
Jim Amsden (Chair)
Geoff Clemm
Jim Doubeck
Tim Ellison
Henry Harbury
Chris Kaler
Eric Sedlar
- Meeting opened at 9am.
- Set agenda.
Discuss open issues relating to core versioning.
Define scenarios for illustrating core versioning semantics and protocol,
and advanced semantics.
Discuss issues relating to advanced versioning.
- Discussion of auto version and target selector header.
Current prohibition of autoversion with target seletor header is to ensure
that "civilized" VCM systems don't generate new revisions in history when
a versioning aware client mistakenly thinks that they are working on a checked
out resource.
The protocol cannot distinguish between a versioning unaware client, and
a versioning aware client that gives no indication that it is versioning
aware, such as in a regular PUT request.
Auto-version is described as a checkout-operation-checkin and is effectively
the same as doing the three operations in succession (i.e. no working resource
is left at the end). Discussion as to whether it is sufficient to say the
effect should be the same, rather than this is how it should be implemented.
Agreed that servers may implement auto-checkout as they wish but MUST adhere
to the pre and post conditions of EACH of CHECKOUT, operation, and CHECKIN
as though they were done independently. This is a semantics requirement
not an implementation requirement.
- Core versioning issues, typos and minor editorial issues were raised.
- Consensus was that where PUT/MKCOL/etc. creates a new resource it is left
undefined as to whether the resulting resource is a versionable, unversioned,
or versioned resource (since some servers may be restrictive about what
they will create).
- LOCK with a target selector is undefined in the protocol document since
it may be interpreted as (a) locking the target selector (i.e. label) against
the target resource such that the label cannot be moved, or (b) lock the
resource that is currently identified by the target selector (and allow
the label to be subsequently moved). Since there was no consensus as to
what the 'correct' semantics should be it was decided to wait and see if
the mailing list would produce consensus, or leave it undefined and let
implementations agree on a consensus.
- Discussion of distinction between versioned resource and history resource
in advanced versioning and no such distinction in core versioning. Tentativley
agreed that both concepts should be introduced in core versioning although
there will be a one-to-one correspondence between them in core.
- Discussion of names stored as the state of a resource rather than member
attributes of a collection. It was agreed that systems that remember names
as resource state can present 'regular' webdav collections through the protocol.
- Discussion of the Target-Selector header being only a label and not, for
example, a revision URL. The argument was why should clients pass in a
revision URL and a 'human readable' URL when the revision URL is sufficient
to uniquely identify the resource? The human readable URL is redundant.
In this case the request URL would simply be the revision URL.
In addition, there are properties (and REPORT results) that only report
the revision URL of a resource, and it is infeasible to require clients
to provide the human readable URL to these resources.
Agreed that it is a philosophical discussion of the various marshaling alternatives
and not fundamental to the semantics of the protcol.
- Break for lunch
- "versioned bindings" property of a history resource is to be removed.
- Proposal that the names of the versioning artifacts be changed to better
represent their roles.
Various suggestions including history resource -> vesioned resource, and
versioned resource -> revision selector. Split vote on renames so will
continue to discuss and take the issue to the mailing list. Would like
to ensure a swift resolution to maintain continuity between draft documents.
- Promote the concepts of history and versioned resources to core versioning
since the term versioned resource may be confusion when moving from core
to advanced.
- When would a revisino have checkout = ok and checkin = forbidden? This
allows parallel development whilst ensuring a linear checkin history. It
is useful for processes that do early manual merging.
- Delete the sentence in 6.3 CHECKIN marshaling that says 'keep checked
out'.
- SET-TARGET discusion about the semantics and the reasons why its argumetns
are different to those accepted by Target-Selector header. Until a label
is set, it must accept a revision URL to identify the resoruce.
- 6.6 LABEL change the 'replace' directive to 'set'.
- 6.5 SET-TARGET with depth >0 will fail if given a revision URL directive
and the target is a collection, since revision URLs are allocated by the
server and in general will be invalid across versioned resources. The expected
result would be a 207 multistat indicating the failures.
- 6.5 SET-TARGET marshaling change 'label' to 'label-name'.
- 7.3 Presently says if multiple revisions have the same timestamp all are
selected, change this to the server picks one of the multiple revisions
at its discression (and not guaranteed to be the same one each time).
- 7.4.1 Should have a picture to represent the resource state so that the
XML is more understandable.
- Discussion of baselines and the property 'versioned baseline' URL. The
versioned baseline URL is the URL to the workspace to checkin and checkout
a baseline of the workspace rather than the workspace collection itself.
Proposed that we reintroduce the MKBASELINE method.
- Stepped through the protocol for the creation of a workspace and its subsequent
baselining.
- Guaranteed that the versioned resources are recreated in the same namespace
when a baseline is merged into a new workspace / workspace is created with
a baseline initializer. Servers can define how baselines are stored as
a resource.
- Agreed that workspaces MUST be collections, especially to support core
and versioning unaware clients.
- Creating baselines is conceptually the same as taking a snapshot of a
workspace.
- Discussion of private bindings and versioned collections.
- Discussion of activities, why revisions cannot be members of multiple
activities. Activities can be used to represent branches of development,
and change sets of related changes. Each 'world' (branching & change set)
will use activities in their own way. The few systems that do both change
sets and branching can do almost everything that they need to do using activities.
Shared resources between activities produces an interdependency that does
not allow merging of an activity without producing the partial merge of
the second activity -- the changes might have well been all in the same
activity.
- Will allow revisions in multiple activities to support branching model
and change sets, on the understanding that attempting to merge a 'branch
activity' into a 'change set activity' may fail due to semantics violation.
- Meeting closed at 6pm.
TPE