Next message: Geoffrey M. Clemm: "Re: Why do we need working resource ids ?"
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <852568EF.0041132A.00@d54mta02.raleigh.ibm.com>
Date: Tue, 30 May 2000 07:50:26 -0400
Subject: DeltaV Design Team Meeting 5/24/00
The DeltaV working group held a design team meeting in Seattle May 24 and
25. Thanks to Chris Kaler for hosting a wonderful meeting. Also thanks to
Jim Whitehead for taking excellent notes. Finally thanks to Geoff Clemm for
his tireless work on the spec! I'll split the meeting notes by day to keep
them a little shorter. There will also be a follow-up note summarizing all
the issues and tentative decisions. All decisions on issues take place on
this mailing list, not in the design team or working group meetings. So
here's you chance to give your input. We look forward to your input and
insight.
The next meeting will be at 48 IETF July 30 to August 4 in Pittsburgh. We
are planning on having both a working group meeting, and an additional
design team meeting. Hope to see you all there.
DeltaV Design Team Meeting
May 24-25, 2000
Microsoft, Redmond, WA
Jim Doubek
Henry Harbury
Jim Amsden
Geoff Clemm
Chris Kaler
Jim Whitehead (minutes recorder)
Tim Ellison (arrived 1:45PM)
The meeting began by starting a walkthrough of the core versioning part of
the specification.
- Add goals/motivation paragraphs(s) to the introduction. Look at the
introductions of other IETF application layer protocol specifications to
see
what their introductions look like.
- VERSION vs. CHECKIN: topic noted for future discussion on issues list.
- Discussion on the definition of versioned resource. This led into
discussion on whether a checkout can be performed on a stable URL, or must
only be directed to a versioned resource. Agreed to delete the second
sentence, "To update the state of a versioned resource..." of the
definition of versioned resource.
- Discussion on whether a versioned resource should have a stable URL as
well. Currently a versioned resource can only be accessed by using
Target-Selector header.
- Discussion on having a working resource id be unified with the concept of
a revision id. Agreed to change the name of a working resource to a working
revision.
- Discussion about, for linear versioning, whether it is possible to check
out from other than the tip version. Concerns: want to track that the
checkout occurred from a specific revision, and this wouldn't be possible
if
you check out the tip, then get the previous revision, then check in to the
tip. But it is difficult to enforce linear versioning if checkouts are
allowed
on non-tip versions.
- Agreed to change the name of stable URL to revision URL (but then
proceeded to use the term stable URL for the rest of the meeting)
- Discussion over whether the mutable revision paragraph should be promoted
to a separate section, and have additional motivation, pros and cons, added
to it. Some agreement that a separate section is needed, to capture
or highlight semantics specific to mutable revisions.
- Discussion over what happens when a Target Selector is used to select a
specific resource, and that resource is dynamic, and during its dynamic
operation, it retrieves other resources. Should the value of the Target
Selector be used to select a revision of those other resources? Or should
the default target be used instead. This is related to the issue of, when
there are versioned collections, and there is a path specified, what should
the scope of the Target Selector header be? Should the Target Selector
(using something other than a workspace as a selector, since workspaces do
specific the revision of the collections) affect every collection in the
path, or should it only affect the leaf node, with interior nodes selected
using their default revision. Agreed to delete the last sentence of section
2.2.
- Need to constraints on what characters can appears in an id.
- Need to describe how ids are marshalled into a header
- May need to separate labels from ids, since they may end up being handled
separately.
- Need to explicitly state whether ids and labels are case sensitive,
and/or
case preserving. Tentatively in favor of requiring case preservation. Will
take this to the list. Concern that we need to be consistent with URL
behavior.
- Need to state how whitespace is handled, especially for ids and labels
marshalled within XML
- Discussion of the contents of the DAV:resourcetype property, as discussed
in section 3.3. Agreed that we no longer need a nested value of
DAV:versioned-resource.
- Discussion on the DAV:author property. Agreed that structured values are
not allowed. Discussed what "author" means. Decided that the property
really
was intending to capture the creator, and so changed the name to
creatordisplayname.
- Discussion over whether the value of the comment property should be
structured.
- Discussion of DAV:label-set. Issue: should the maximum length of the
header be specified? HTTP is silent on the length of headers. There is the
related issue of whether to restrict the length of labels. Discussion on
whether it should be possible to discover the maximum label length. Raised
the issue of whether there should be an error response for label too long
on
setting a label. Possibility to report the maximum length allowed in an
error response to setting a label. Some reports that automatically
generated
labels can be long, and can run into label length limitations.
- Issue: need for a destination target selector for use with diadic methods
(copy/move). With copy allowed, there now is a need for a destination
target
selector.
- Issue: need to introduce an option for overwrite, overwrite="update",
that
allows copying of a working revision from one versioned resource to
another.
Agreement to put the description of this into an Appendix that states that
the functionality will be added into the WebDAV spec. once it is moved to
draft standard status. The spec currently says that overwrite="T" requires
that the destination be deleted before the copy or move.
- Discussed whether there needs to be a section stating explicitly that
specific methods when applied to versioned resources are undefined. That
is,
the specification needs to describe the behavior of all methods (including
HTTP/1.1 and DAV methods) for all resource types defined in the DeltaV
specification.
- Need for some mechanism to allow a client to discover whether a revision
is mutable or not. Agreed to have a property called "mutable" defined on
revisions, that is Boolean, and potentially settable by the client. A
server may refuse to allow the property to be updated.
- Agreement that specified versioned resource, revision, and working
resource properties in the spec for core versioning must be present. For
all properties, must indicate when they must be present (e.g., only for
advanced versioning), or whether they are optional. Unless otherwise
specified, the default value of versioning properties is server defined.
So,
for booleans, the value must be true or false, it cannot be empty. That is,
all properties indicate which optional extension of WebDAV versioning that
introduces them, and the property is required to exist if this extension is
supported.
- For automatic versioning, it is possible for an error to result from
either the CHECKOUT, PUT/PROPPATCH, or CHECKIN. It is currently undefined
as to which error code should be returned. Agreement to continue to be
silent on this issue, but there is a preference to return an error code
associated with the PUT/PROPPATCH over one for CHECKOUT/CHECKIN, since
these
versioning-specific error codes are unlikely to be understood by the
versioning-unaware client. There was an awareness among design team members
that HTTP/1.1 does have existing semantics for how to handle unknown error
codes.
- Discussion of having a structured error response for DeltaV, or some
extensible error response mechanism.
- Need to have explanatory text on each example that explains what is
happening.
- Discussion of what happens when you issue a PROPFIND with depth of 1 or
infinity against the stable URL for a revision. General agreement that the
response in this case is undefined, and depends on how the server organizes
its namespace of stable URLs.
- Discussion on whether it should be possible for someone other than the
lock owner to place a locked resource under version control.
- The specification should explicitly state that it is OK for a versioning
server to have unversioned resources.
- Whether a PUT creates a versioned resource is server-defined. This may
vary across a server's namespace.
- Discussion on CHECKIN semantics. Need to update postconditions to
describe
behavior of successor-set (on revision), label-set (on revision), and
revision-set (on versioned resource) properties.
- Discussion on whether a label should be able to automatically propagate
(or "float") to the latest revision upon checkin, so as to simulate
"latest"
revision selection. General sentiment against adding this feature, but did
agree to include a DAV:latest functor for Target-Selector.
- Some discussion that there needs to be a new name for "private" checkin
option. New wording needed for DAV:private (express using positive language
"if DAV:private option is set then...")
- Can't copy a workspace?
- Issue: is it possible to have workspace-private unversioned resources
(for
example .o files, or other intermediate compilation files, created during a
build). This issue was discussed, but was not resolved. One of the
difficulties for DeltaV is the fact that workspaces are viewed as filters
on
the same portion of the namespace, as opposed to projections into different
sections of the namespace. When workspaces are projections, then having
unversioned, uncontrolled resources in a specific projection does not
affect
any other workspace/projection. But, when everyone is sharing the same
portion of the namespace, it is possible that people's unversioned objects
will end up overwriting each other. For example, since people are sharing
the same portion of the namespace, then the .o files created during
different user's compiles will overwrite each other.
- Issue: can versioned collection revisions contain non-versioned
resources.
- Issue: can baselines contain non-versioned resources.
- Discussion of extensibility of options for checkin and checkout. Need to
add some general language stating that these can have extra elements added
to them in the future. General issue of when to ignore unknown elements,
and
when unknown elements cause method failure.
- Try to remove use of the word "delete" in the definition of checkin, and
use "replace" or "convert".
- The use of the phrase "the server state preceding the request MUST be
restored" is too broad, and should be limited to either the versioned
resource, or the revision/working revision.
- For SET-TARGET, explain each of the set-target values, especially href.
SET-TARGET method must have a Target-Selector value of
"versioned-resource".
- Some discussion on the marshalling & name of the SET-LABEL-TARGET method.
Several people preferred to revert back to the name LABEL, which is applied
to a versioned resource with the revision picked using a Target-Selector
header. Discussion of using Depth with SET-LABEL-TARGET to set the label on
all revisions in a collection. Need to define the interaction with Depth.
Add an example showing what happens when a label is deleted. What response
should removing a content return on success (200 OK).
- Discussion of the REPORT method. Text needs to be added to motivate the
need for these reports (e.g., getting a history listing for a version tree,
for DAV:property-report). Another scenario is getting a couple of
properties off of just the predecessors of a particular resource in a tree
that has a lot of revisions. The example for REPORT should have a
description that lists, using ASCII art, the revision history that is being
listed in the REPORT result. Discussion on making the marshalling for
REPORT
more consistent with PROPFIND. Discussion on whether REPORT should be
optional. Discussion on how to add new reports in the future.
*** End of Meeting ***