Delta-V Breakout Sessions at IETF
jamsden@us.ibm.com
Tue, 16 Nov 1999 15:56:55 -0500
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <8525682E.00664910.00@d54mta03.raleigh.ibm.com>
Date: Tue, 16 Nov 1999 15:56:55 -0500
Subject: Delta-V Breakout Sessions at IETF
The Delta-V working group held two breakout session held at the Washington
IETF November 10 and 11. There were 11 members present: Jim Amsden, Pete
Carlson, Mike Chihaya, Jeff McAffer, Tim Ellision, Geoff Clemm, Brad
Seargant, Chris Kaler, James Hunt, Jim Whitehead, and Jason Crawford. I
would like to thank everyone involved for the excellent work and the high
degree of collaboration achieved in the meetings. Thanks to your good work,
we are on, or even a little ahead of our charter schedule. I am also very
pleased with the progress that was made in resolving the issues. Finally,
it is interesting to note that we haven't made any significant changes to
the versioning semantics since sometime before our meeting in Concord in
July. This is a real good indication of progress. Great work guys!
The next meeting of the working group design team is tentatively scheduled
for Feb 16 and 17, 2000 in Seattle. Any member of the Delta-V working group
is invited to attend. We'll have more meeting details when they are
available. We hope to cover the remaining issues, finish walking through
the versioning scenarios and how they are supported by the protocol, and
review the updated versioning spec.
Action items:
- Geoff will produce a versioning protocol scenarios appendix similar to
what we did in the Delta-V working group to show how the protocol supports
the goals scenarios.
- Jim Whitehead will provide some details on how URLs are
internationalized.
- Everyone will submit a list of timestamps they think are required.
Here's a list of issues covered. They are ordered roughly by the appearance
of the associated semantics in the goals document scenarios. All decisions
reached in the Delta-V Working Group and these unsanctioned breakout
sessions are recommendations that are subject to the scrutiny of the
complete Delta-V Working Group through the mailing list. I invite anyone
who has issues with any of these recommendations to make them known through
the mailing list and we will reconsider or re-open the issue.
----------------------------------
How are the versioning options communicated to clients, and what are they?
We discussed extending OPTIONS to take an entity request body and return an
entity response body containing the versioning options marshalled in XML.
But after some discussion we opted to extend the REPORT method to play this
role rather than extend OPTIONS. This seemed more extensible and less
intrusive to the existing OPTIONS method.
---------------------------------
Do we need MKRESOURCE, or will allowing PROPPATCH on a null resource do?
This was discussed in the WebDAV Working Group meeting, and we decided to
not allow PROPPATCH on a null resource and stick with the MKRESOURCE
method.
---------------------------------
How is a versionable resource put under version control?
There were suggestions to use CHECKIN or CHECKOUT, but neither of these
were quite right. They both had headers or entity body elements that
weren't appropriate to something that wasn't checked out, or didn't have a
predecessor. So we decided to use a new VERSION method that puts a
versionable resource under version control. The VERSION method can take a
Depth header to put all the members of a collection under version control
in a single request. As with CHECKIN, VERSION requires a workspace
specified in the target-selector which provides a current label or activity
for identifying the newly created revision.
Note that neither CHECKIN or VERSION apply a user-specified label to the
newly created revision. If this is necessary, either use the current-label
of the workspace, or use the revision id as a target-selector and apply the
label using the LABEL method.
-------------------------------
Are revision names URL segments?
We decided that this was required in order to marshall revision names in
HTTP headers, and to use them to construct URLs. Revision names that are
not valid URL segments can user URL encoding techniques.
------------------------------
How are labels internationalized?
By using URL encoding. Jim Whitehead will provide details in a separate
note.
-----------------------------
Are revision ids and labels in the same namespace?
After much discussion, most of which was already given on the mailing list,
we decided to keep them in separate namespaces and use a "namespace
indicator" of id: or label: in the header. The issue that convinced the
holdouts (mostly me) was that a client could use a label that would clash
with some server generated id at some time in the future. This would
restrict the server's ability to generate revision ids. There was some
discussion about leaving off the namespace indicator for convenience and
returning a error if the revision name was both an id and a label.
----------------------------
What is the semantics of locking on versioning artifacts like versioned
resources, revisions, working resources, workspaces, activities,
configurations, and baselines?
We decided to defer this issue until Jason Crawford has had a chance to
explore locking in the current WebDAV specification. However, since we are
no longer using "property collections" to specify WebDAV versioning
semantics (see below), there is no need to lock any of the versioning
artifacts in order to execute the versioning methods. Therefore the
versioning semantics will likely be able to accept standard WebDAV locking
semantics without requiring any changes.
---------------------------
Do we need a CHECKPOINT method/capability?
CHEKCPOINT creates a new revision, but keeps the resource checked out to
allow further changes. It is effectively an atomic CHECKIN followed by a
CHECKOUT of the newly created revision. That is, the old revision is no
longer checked out, and the working resource has the newly created revision
as its predecessor. It was decided to make this a parameter of CHECKIN
rather than introduce a new method. This was primarily because all of the
CHECKIN semantics must be followed.
---------------------------
Should the target selector be returned in a header for all requests? Echoed
on requests that specify it?
The concern is that certain WebDAV versioning unaware proxies might strip
off the target selector header causing the server to return an unexpected
revision without any error. We agreed that the target selector should be
echoed on any request that specifies it, and the client can use this
information to be sure it got the right version. However, this does not
address the larger issue of proxy compatibility with WebDAV extensions. We
assume that where WebDAV semantics must be protected by proxy servers,
suitably update proxy servers will be provided and configured to achieve
the desired results.
---------------------------
What timestamps do we need to collect?
We'll move this to the mailing list for the details. Everyone will submit a
list of what they think is needed. All dates use ISO format.
---------------------------
Is depth available on CHECKOUT?
No.
---------------------------
How is the workspace overridden to access a particular revision?
If the server supports versioned collections, there are times when a
workspace is used for revision selection, and times where the workspace
needs to be overridden with a specific label in the same request. For
example, say you want to examine an old version of
/projects/401k/index.html without changing your workspace revision
selection rule. If you just specify a revision label of "beta2" for
index.html, what revisions of the projects and 401k collections are used?
There are two possible solutions. One is to use both path-selector and
target-selector headers in the request. The path-selector is a revision
selector (usually a workspace) that is used to resolve all the URL path
segments. The target-selector specifies the revision of the leaf resource
(or collection). This is reasonable simple, but relies on there being more
stability in the namespaces than the contents or properties of a leaf
resource. Another approach is to provide a revision path header that has a
segment for each segment in the target URL. This is more complicated, but
allows specification of a revision for every segment in the URL path.
---------------------------
What are the versioning levels?
We decided at Concord to eliminate the notion of versioning levels, and
have core versioning with a number of optional capabilities. Geoff noticed
that a number of the capabilities fell into logical groupings both from the
semantics and from the protocol specification that could be used to
describe higher levels. We concluded that we would revisit this issue after
the protocol is more complete and look to see if it is possible to define a
small number of levels that represent a set of capabilities (not
necessarily methods) that address a cohesive set of use cases the we could
identify as important to achieving interoperability.
---------------------------
Can CHECKIN have depth?
Yes. We also need to be able to specify if the CHECKIN should fail if the
resource is not checked out, or be ignored.
---------------------------
Should the semantics of the protocol be specified by using "property
collections/resources"?
This issue resulted in a long and complex discussion. The conclusion was
that property collections would not be used to specify WebDAV semantics,
but that we would introduce new methods that specify the semantics in
simpler, more flexible, and method specific ways. This eliminated the
locking issues with the versioning artifacts, simplified the protocol,
eliminated most of the use of server-generated URLs, and resolved
long-standing issues in the working group. We arrived at the conclusion be
first examining a simple operation that used property collections -
labeling a revision. It became clear in the Delta-V working group meeting
that we were relying entirely too much on server-generated URLs and
property collections that weren't really collections. For example adding a
label to a revision required the following steps:
- Access the labels property of the revision and get its server-generated
URL.
- Using this URL, BIND a new member whose segment name is the label.
- The server updated other property collections of the versioned resource
We explored a number of alternatives for specifying labels:
- Use BIND and server-generated URLs for a labels property collection
(requires locking the property collection)
- Use PROPPATCH on a labels property (requires locking the revision)
- Extend PROPPATCH to support incremental add/delete of collection
properties (collection in the generic sense of set, bag, list, ordered
list, etc.).
- Introduce a LABEL method
- Perform operations on the versioned resource with a new XML entity
request body
Of all of these approaches, introducing a LABEL method was the simplest and
most straightforward. It didn't require locking the revision, didn't
introduce integrity issues resulting from PROPPATCH to update a composite
property, didn't require extensions to PROPPATCH, didn't require the use of
any server-generated URLs, and was very easy to explain.
We then examined all the places where property collections were used in the
specification:
1. label (on a revision) M (LABEL)
2. merge predecessor (of a revision) M (MERGE)
3. merge successor (of a revision) M (MERGE)
4. revisions (of a versioned resource) RO
5. labeled revisions (of a versioned resource) M (LABEL)
6. successors (of a revision) RO
7. workspaces (of a revision) RO
8. working resources (in a workspace) RO
9. activities (of a repository) R
10. required activities (of another activity) M (ACTIVITY)
11. activity revisions (revisions modified in that activity) RO
12. configurations (of a repository) R
13. workspaces (of a repository) R
14. (missing) required (configurations of a configuration) M
After examining all of these cases, we determined that they fell into a
number of groups:
RO - read only, no update required, simply a live property set as a result
of some other method
R - associated with a repository and created by MKRESOURCE
M - better handled by a separate method because of rich semantics
Since only three methods were being introduced (LABEL, MERGE, and
ACTIVITY), we are already beyond 16 methods (a current Apache restriction),
and these methods simplified the protocol, we decided to not use property
collections. The justification is that there are semantics in the server
that are viewed through live properties and must therefore be set by new
methods.
---------------------------
Do working resources have server-generated URLs that can be used to access
the working resource without a workspace?
Yes, but the protocol design will minimize the places where
server-generated URLs are required.
--------------------------
Should there be a default current-label and RSR for a newly created
workspace?
Often the current label for a workspace will be the same as the name of the
workspace, and this label is the only entry in the workspace RSR. However,
this would not be a safe default because users could have the same
workspace name in a different collection causing the different workspaces
to have the same current-label.
---------------------------
Currently Remaining Issues:
---------------------------
Can a revision selector be a compound name? For example, a specific
revision of a configuration to add to the workspace revision selection
rule.
---------------------------
Are baselines a kind of configuration or a separate concept? The issue is
that if they are configurations, how do we prevent them from being edited?
---------------------------
How are configurations created and members added, removed, or changed?
Current approach is a configuration is a kind of collection created with
MKRESOURCE and members are added/removed using BIND.
---------------------------
Are repositories necessary?
---------------------------
Do members of a versioned collection have to be versioned resources?
---------------------------
How and when is the checkin policy specified?
---------------------------
Can different workspaces use the same activity?
---------------------------
Should we support "frozen" labels?
---------------------------
How do we report the history of a versioned resource?
Could use REPORT or just get the properties of be versioned resource and
let the client do what they want. The issue is performance vs. efficient
access of versioning meta-data. Many of the versioning properties are hrefs
to other resources. This exposes a lot of server-generated URLs and
requires lots of round trips to gather all the information required for a
history report. On the other hand, casting the output in an XML document
generated by the REPORT method limits client flexibility.
---------------------------
How do we delete a revision?
---------------------------
How does the server determine when it should resolve a URL segment with a
workspace RSR, and when the segment is part of some server-specific
namespace containing versioning meta-data?
Servers are free to specify what portion of the namespace is reserved for
their use for server-generated URLs. The collections in these namespaces
need not be subject to workspace revision selection rules.
---------------------------
Do we need to separate merge predecessor from predecessor?
Yes. Merge successor/predecessor is mutable and can change to reflect the
actual merge that was performed. Successor/predecessor cannot as it is a
result of checkout/checkin.
---------------------------
How is the namespace protected on CHECKOUT?
Say you have /a/b.html checked out, someone deletes /a, and you don't have
versioned collections. What happens to /a/b.html? We may need to apply some
of the same logic used by LOCK to protect the namespace of locked
resources.
---------------------------
What reports provided by the REPORT method will be part of versioning core?
---------------------------
Creating a workspace requires write access on a server. How will this be
accomplished to get read-only access to a set of revisions when the user
does not have sufficient permission.
The server can provide different access permissions for workspace creation,
or access to a controlled collection where they can be created. This may
result in a denial of service security issue though.