Next message: jamsden@us.ibm.com: "Issues from the May 25 Design Team meeting"
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <8525690E.005B7DC4.00@d54mta02.raleigh.ibm.com>
Date: Fri, 30 Jun 2000 12:42:45 -0400
Subject: DeltaV Design Team Meeting
Here are the meeting notes from the second day of the DeltaV design team
meeting. Sorry about getting these out so late, I've been on vacation.
DeltaV Design Team Meeting
May 25, 2000
Microsoft, Redmond, WA
In attendance:
Chris Kaler
Henry Harbury
Jim Whitehead (notetaker)
Jim Amsden
Geoff Clemm
Tim Ellison
Jim Doubek
Decided to work on issues related to core versioning, trying to come to
consensus on open issues.
Started out by listing the set of open issues in core versioning:
* VERSION vs. CHECKIN
* Is it possible to issue CHECKOUT to a revision URL
* Revisit decision to replace "working resource" term with "working
revision"
* Allow multiple checkouts of a "linear" versioned resource or checkout
from
other than the tip.
* Do we require labels to be case preserving?
* Do we allow the Depth header to be used with SET-TARGET, LABEL, CHECKIN,
CHECKOUT
* What are the interactions between Depth and Target-Selector?
* What is the scope of the target selector?
* Should a versioned resource have a stable URL?
* Should a working resource have a stable URL?
* Do we allow a structured version resource DAV:resourcetype value?
* Can you put a write locked URL under version control without the lock
token? No. (resolved).
* Is it server defined whether a PUT creates a versioned resource in a
versioned collection?
* Do we a define a "workspace private" unversioned resource
* Treatment of unknown XML elements in request bodies: ignore them, or fail
the request?
* Should SET-LABEL-TARGET be marshalled the old way (LABEL)? What are the
status
codes?
* Should the property report be a PROPFIND?
* Is it possible to delete a revision, and if so, what effect does it have
on predecessor/successor properties? And default target selector for
workspaces, baseline, etc.?
* What does it mean to delete a versioned resource?
Agreement to add a Target-Selector value of "latest" that selects the
latest
revision based on the checkin time.
Went around the room to collect issues in advanced versioning just to be
sure
we were aware of any consequences with respect to decisions on core
versioning
issues.
* Section, 8.3 Automatic content merging, this is considered to be
potentially dangerous, and perhaps out of scope for the protocol.
* 9.2.2 PROPPATCH of DAV:activity may fail due to activity semantics
* Does a working resource have a DAV:merge state if it has never been
merged? (Answer: no).
* Can different URLs on a single host have a different default workspaces?
* Is a baseline a role played by a versioned workspace? (Is it a revision
of a versioned workspace?)
* Is a configuration a workspace?
* Are there shared activities?
* Can one activity have checkouts in multiple workspaces? If so, how do you
find those working resources?
* Can a workspace have multiple activities?
* What does workspace-set and activity-set mean?
* Do baselines provide deep collection revision semantics?
* How do activities support/implement branching use cases? Is that
description of the problem biased towards specific solution mechanisms? Do
we need a branch construct in addition to an activity?
* MKBASELINE, MKACTIVITY can they not put the new resource other than at
the
request-URL?
* What do the reports mean?
* Expressions in Target-Selector headers?
* Should reports be optional/which reports are optional?
* Consider adding a new type of versioned collections, for example one
where, if the
properties are modified a new revision is made, but if its membership is
changed, no new revision is made.
* Can versioned collections have non-versioned members?
* Can baselines have non-versioned members?
* Do we need any other reports?
Next, we started discussing individual core versioning issues.
* Issue: VERSION vs. CHECKIN. Agreement to reinstate the VERSION method,
and
have it return a success status code when it is applied to a resource that
is already under version control.
* Is it possible to issue CHECKOUT to a revision URL? A lot of discussion
here. At the heart of some of the discussion was whether a CHECKOUT is
applied to a versioned resource, or to a revision. It turns out that the
intent is to apply CHECKOUT to a versioned resource, and hence according to
this model, it doesn't make sense to apply CHECKOUT to a revision URL.
There
is an additional issue that supporting CHECKOUT against a revision URL
would
require the server to be able to go from the revision URL back to the
versioned resource, i.e., maintain a backpointer to the versioned resource.
There was final agreement on adding the requirement that a server SHOULD
NOT
support CHECKOUT against a revision URL. However, there was not agreement
that the requirement would be a MUST.
* Revisit decision to replace "working resource" term with "working
revision". Decided not to work on this today.
* Allow multiple checkouts of a "linear" versioned resource or checkout
from
other than the tip. Two aspects to the semantics of DAV:linear. (1) Whether
multiple simultaneous checkouts are allowed. (2) What happens upon checkin.
There was agreement that multiple checkouts are allowed. Checkin must
result
in a linear version history. This implies that the client has
responsibility
for performing client-side merges prior to checkin. Need a switch that
would
make checkin/checkout fail if it would cause a branch.
* Do we require labels to be case preserving? Agreement that yes, labels
must be case preserving.
* Do we allow the Depth header to be used with SET-TARGET, LABEL, CHECKIN,
CHECKOUT? One issue was whether allowing Depth on SET-TARGET and LABEL
would
cause people to not use workspaces. People did not agree with this
argument.
Agreement that Depth should be allowable with SET-TARGET and LABEL.
Discussion on whether Depth SET-TARGET and LABEL should be best effort, or
have atomic semantics. Agreement that the semantics should be best effort.
Agreement that trying to set a label or doing SET-TARGET on a unversioned
resource would fail. This applies to collections, which are not versioned
in
core versioning. Agreement that trying to set a label or do a SET-TARGET on
an unversioned collection should report an error in the multistatus
response
(even though there will be many of these responses).
Discussion on whether CHECKIN or CHECKOUT should work with Depth. The
design
team felt that, since these are fairly expensive operations, the server
overhead for parsing the request would be small compared to the cost of
performing the operation. As a result, it did not seem that Depth on
checkin
and checkout would result in a large efficiency advantage. Agreement that
CHECKIN and CHECKOUT will not work with DEPTH.
* What are the interactions between Depth and Target-Selector? We believe
there are no known interactions. The Target-Selector is applied to every
resource encountered in Depth processing (this is the extension of RFC 2518
rules to this case).
* What is the scope of the target selector? Need to investigate the WebDAV
specification to see if there are any examples of when a URL appears in a
request body, and hence might be affected by the Target-Selector. Could not
think of any case where this occurs in WebDAV (RFC 2518), but this does
occur in the DASL specification.
* Should a versioned resource have a stable URL? Agreement that yes, it
should have a stable URL.
* Should a working resource have a stable URL? Agreement that yes, it
should
have a stable URL (only, we don't want to call them stable URLs, but we
don't have a better term yet. Had a little bit of discussion on new terms.)
* Do we allow a structured version resource DAV:resourcetype value?
Agreement that no, we don't allow it.
* Is it server defined whether a PUT creates a versioned resource in a
versioned collection? Changed this to:Is it server defined whether a PUT
creates a versioned resource at a 404 returning URL location. Agreement
that
this is a server policy issue, but there was significant disagreement over
whether a client should be able to indicate that a resource creating method
(like PUT, MKCOL), should create an unversioned resource, thus overriding a
server auto-create-versioned-resource policy. After much discussion,
decided
to take this issue to the mailing list.
* Treatment of unknown XML elements in request bodies: ignore them, or fail
the request? Agreed that we need to introduce a mechanism for indicating
whether an XML element has mandatory or ignore semantics. Mandatory
semantics are: fail the request if the element is not understood.
* Should SET-LABEL-TARGET be marshalled the old way? What are the status
codes? Tentative agreement that the marshalling of setting a label should
reflect that the label is being set on the versioned resource. However,
since there was a lot of discussion between the two models of (a) a label
is
set on the revision, and (b) a label is set on the versioned resource, the
specification should explicitly note that these two models exist, and this
specification explicitly chose one of them. However, we will end up raising
this issue on the list, since there was not total agreement.
* Should the property report be a PROPFIND? Agreement that core versioning
must provide a mechanism for efficiently creating a version history report.
Agreement that the version history report will have XML elements tailored
specifically for the history report. The version history report MUST be
supported by all servers. The properties returned by the version history
report will be fixed. At minimum, it must be possible to generate the
version history graph from the report.
* Should the property report be optional? Agreement that the property
report
is not part of core versioning. Agreement that the property report must be
supported if a server supports all advanced features.
* Should the property report be marshalled as a new extension of PROPFIND.
There was disagreement among the design team on this point. This will be
taken to the mailing list.
*** Jim Whitehead leaves at this point, hence stops taking notes :-) ***