Minutes Delta-V WG meeting 14-Dec-00

Delta-V Working Group Meeting
IETF San Diego

3:30 pm - 5:30 pm
Wednesday 14 December 2000

[Note: section references are based on draft-ietf-deltav-versioning-10.9]

Agenda for meeting presented by Geoff Clemm.

Use of LOCK/UNLOCK for core versioning and the moving of
CHECKOUT/CHECKIN/UNCHECKOUT to optional.
Eric S. observed that moving SET-TARGET and UNCHECKOUT to the optional
section will reduce the functionality of the existing core (and therefore
it will be smaller).  This was not considered to be a problem.

Defining he 'Overwrite: T' to mean update, not delete followed by create.
This means that COPY would not take an existing (version controlled)
destination out of version control.  Larry had suggested that this was the
original intent of 'Overwrite: T' described in RFC2518, so it should be
clarified there.
Suggestion that this behaviour be specified in a separate (small) RFC
rather than embedding it in delta-v or waiting for an update to 2518 which
may delay delta-v's progress.
Comment that implementations may not adhere to the DELETE description given
in 2518 anyway.
Jim A. to raise this issue with Jim W. to determine the best way to
proceed.

REPORT method to be marshalled as a PROPFIND of a DAV:report live property.
Geoff gave a description of how it would be marshalled as sub elements of
the DAV:property request.

Lisa D. said that she now believes that adding new behaviour via methods
may be preferable to introducing smart live properties.  Lisa noted that
delta-v is somewhat inconsistent since DAV:autoversion is a live property
that has a side effect on server behaviour and is updated via PROPPATCH
rather than a custom method.

Problems with using properties for reports etc. include the use XML schema
(empty element tags).  Questioned whether it allowed passing arguments in a
query language? it was argued it is possible to do in XML and this may be
used by DASL whereas a REPORT method would not.

Questioned whether core needs any reports, since the only report available
in core (to get the version history tree) is easily deduced by following
the predecessor set.  Clarified that the predecessor set contains only the
immediate predecessors, so it would require multiple requests to obtain.

Since the most common situation in core is linear history producing a
nested XML response may be verbose/cumbersome.

Adding version history resource to core?
Reported that someone didn't want to allocate a URL for history resources.
Observed that this would be a reasonable addition since it would be the
natural resource to request the version tree report from.  If the report
method were removed from core then there would not be any reports left in
core.

Reorganising the document.
The document has been split along lines of optional behaviour.  Compliments
received from the floor for the new layout.  Question raised about whether
it should be split into two documents and whether one should be a proper
subset of the other or if it should be duplicated.  Larry suggested that it
is purely an editorial decision -- one doc is advantageous since it does
not require repeating the boilerplate text, however, a split doc gives a
smaller document for those people only interested in core and makes
individual revision of core and optional behaviour easier.
There is less need to split the document now that it has been restructured.

Should introduce a section on what servers MUST implement to be considered
core compliant.  Suggestion that this be an appendix referenced from the
introduction.  Should include a definition of ?core? in the definitions
section.

Client side and server side workspaces.
Represent two fundamental implementation choices.  A stateful client only
contacts the server when there is something to record in version history,
however, since a resource has both content and properties there must be a
working resource on the server to ensure that there is a consistent
resource that is publicly viewable.  Furthermore, some servers will require
that there is a batch update to numerous resources
simultaneously/atomically.
Server side workspaces appeal to clients with no state, the server must
remember both the resource state and the names by which the client knows
the resources.
Guestimate that up to 20% of servers can do both client-side and
server-side, however, clients will predominantly be doing just one or the
other.
Once the checkin is completed, the clients? way of working is identical.

Question: can servers support both stateful and stateless clients?  Answer:
yes, but with difficulty.  Servers that can deal with client side state can
quite easily deal with stateless clients (i.e., store the state on the
server).
Question: Is the distinction between them (client side vs. server side)
that the client against a client side server can check out a resource
twice? Answer: No, both models support checking out 2 (or more) times
either by using two workspaces or two working resources.

Greg S.?s server will have activities, baselines, and stateful clients (to
achieve high scalability), it also versions the entire repository (by
efficient deltas of namespace and content/properties) to retain a coherent,
version-consistent, public state.
We need to combine the client-side workspaces with baselining; can checkout
a resource in the context of a baseline, then version the baseline (which
checks in all the working resources ? atomically).  The atomicity is
important to ensure that consistency is maintained, and there is not a
partial checkin state left on the server.  It is also required that the
result of the checkin can be made public atomically.
Question: Is making the resources public an integral part of the checkin
atomicity?  Answer: Don?t know what Greg will be doing.  In current
protocol it would be two steps (1) to checkin the baseline and (2) to make
the baseline public (merge?)

Jim A. interjected and explained that these are detailed topics that may be
difficult to grasp ? people should study the list to get the issues being
debated.  Although clients may support both client side and server side
workspaces ? they are not like the other options that servers may add in
(e.g., activities).

Working collections ? they are there to support client side workspaces that
need a place to acquire updates to a collection.

Adding a ?latest version of a given version history in a given activity?,
so that before you do a merge you can do a diff using the resources that
would have been selected by the merge method.

DAV:must-support attribute.  Description of proposal to make it a token
passed in an If: header.  Need to check the protocol to see if this
behaviour is required in the protocol, if not it can be dropped, and if it
is the issue should be raise in the general WebDAV WG.  In either case
remove it from delta-v.

Use an explicit value to denote that the checkin date is unavailable.
Maybe look at the XML schema work to see if they solve this problem.
Suggestion that they do not, they only allow xml:null.  Specifying it to be
DAV:unknown may be problematic since it would be a different type (in an
XML schema).  Take the issue to the list.

Should define which live properties a write lock protects.
Should enumerate which live properties can be changed on a version?  Maybe
useful.
Changing dead properties must require the server create a new version, live
properties may or may not.  Servers may define new live properties and it
is up to them to decide if it creates new versions.
Supported-live-properties has an impact on RFC2518 this should be raised on
the webdav list.

Comment that XML schema have already agreed on using ?true? and ?false?,
RFC2518 use ?T? and ?F?, which should delta-v use?  Agreement that we
should defer to whatever RFC2518 uses (without re-specifying it in delta-v
protocol doc.)  Noted that RFC2518 doesn?t use ?T? and ?F? in an XML body,
only in a header value so that doesn?t help for validating XML parsers.
Just state that the value is ?like RFC2518 or successors?.

Discussion on whether or not a version URL can be reused.  Lisa?s
implementation will count up from one for each time the resource at a given
URL is brought under version control.  It remains the responsibility of the
client to check the equivalence of the resource state using Etags.
Question: Since properties and content cannot change in a version, why
should clients need to check an Etag.  Support from the floor for reusing
version URLs.  Larry suggested that the spec say that ?version URLs SHOULD
NOT be reused?.  Lisa believes that clients should ALWAYS use Etags to
ensure that resources have not changed.  Comment that this is impractical
in circumstances where only a URL is supported (not a URL/Etag pair) such
as links, server side includes, existing APIs, etc.

Jim A. opened up to the floor to ask where the working group should go from
here.  We?ve had some feedback on working group last call, and we want to
move to proposed standard last call in January.  Suggestion that we make
the changes discussed in the meeting and go to last call in one month.
Larry?s comment was that it depends upon how quickly these items can be put
into the doc. And the existing open issues resolved, but that a further two
week discussion period should be ample and will encourage people to get it
done.  Once the WG last call has been made and there are no open issues,
send it to the ISG.

Lisa presented an e-mail about the overwrite header semantics, which lead
into a general discussion about COPY and MOVE semantics in a versioning
world.

Meeting closed at 5:30pm.

Received on Friday, 15 December 2000 13:13:23 UTC