Next message: Geoffrey M. Clemm: "Re: Versioning TeleConf Agenda, 6/5/00 (Monday) 2pm-3pm EST"
Date: Tue, 6 Jun 2000 08:09:28 -0400 (EDT)
Message-Id: <200006061209.IAA04097@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: Versioning TeleConf Agenda, 6/5/00 (Monday) 2pm-3pm EST
Minutes:
Attending: Tim Ellison (OTI), Michael ? (OTI), Henry Harbury (Merant)
Jim Whitehead (USC), Jim Doubek (Macromedia), Geoff Clemm (Rational)
Agenda:
- Which requests are required to handle Target-Selector or
Workspace headers? In particular, does LOCK/UNLOCK?
We only discussed LOCK/UNLOCK. The group agreed that is
appropriate for LOCK/UNLOCK to disallow the Target-Selector or
Workspace headers. Since we now have URL's for all resources
(i.e. versioned resources, working resources, revisions, and
history resources), there is a URL suitable for passing to
LOCK/UNLOCK. In addition to simplifying the protocol, it allows
us to leave the locking protocol alone (otherwise we would have
to extend the lock state to include the value of the Target-Selector
and Workspace headers that were passed in with the LOCK request,
and define what the effect of this additional lock state is on
the semantics of locks).
Please send mail to the group if you agree/disagree with this
approach.
- Since we have working resource URL's and revision URL's
do we still need working resource id's or revision id's?
This has been discussed on the list recently.
The group agreed that we do not need to require the server
to provide two different server-defined strings for either
a working resource or a revision. Since a URL is more useful
to the protocol than an id (it can be used by itself while
and id requires a versioned resource URL and a header),
it is appropriate to only require that the server provide the URL.
- Should a Target-Selector header contain anything other
than a label?
Since we have history URL's we don't need the "versioned-resource"
Target-Selector value. If we don't have working resource id's or
revision id's, the only thing left are labels.
- Should checkout/checkin in a workspace be modeled as
a state change of a versioned resource, or as the
replacement of a versioned resource with a working resource
followed by the replacement of a working resource with
a versioned resource.
We spent most of the hour talking about the last item. The group agreed
that this change requires further discussion. In particular, the reasons
for making this change need to be clearly spelled out and mailed to
the list (Geoff agreed to do so), the effect of this change on the
protocol needs to be clearly identified (Geoff agreed to do this also).
Cheers,
Geoff