W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 1997

Significant changes to protocol draft

From: Jim Whitehead <ejw@ics.uci.edu>
Date: Tue, 25 Nov 1997 14:29:40 -0800
Message-ID: <01BCF9AE.9271F9A0.ejw@ics.uci.edu>
To: "'WEBDAV WG'" <w3c-dist-auth@w3.org>
At the Design Team meeting last week, and also during editing between 
draft-04 and draft-05, many significant changes were made to the protocol 
document.  In general, the main trend of these changes was to remove or 
repackage features, making a leaner, cleaner design.  The post documents 
these proposed design changes, and indicates which changes are visible in 
the -05 draft, and which will become visible in the -06 draft.

As always, since the mailing list is the key determinant of consensus on 
the protocol draft, these should be viewed as proposals for changes, and 
are subject to the review of the mailing list.

Key changes:

1. Merge the Tree (recursive) operations specification with the main 
protocol specification.

The original intent of separating these documents was to allow for separate 
focusing on the semantics of recursive operations versus non-recursive 
operations.  Since the tree draft was stable, and since it was more 
straightforward to discuss recursive operation in context of an operation's 
initial definition, the tree draft was merged together with the protocol 
draft.  This change is visible in the -05 draft.

2. Make the PROPFIND method able to work recursively (i.e., find the 
properties on a single resource, on all resources in a collection, and on 
all the progeny of a collection).

3. Remove the INDEX method.

Since there has been some discussion on providing support for "INDEX with a 
PROPFIND header" we reexamined the semantics of INDEX, and found that it is 
really a convenience property lookup mechanism, returning an arbitrary (but 
useful) set of properties.  As a result, we increased the power of 
PROPFIND, allowing it to work recursively, and in so doing, made INDEX 
obsolete.  Everything that could be done with INDEX before, can now be done 
with PROPFIND.  In the -05 draft, PROPFIND has recursive semantics, but 
INDEX is there in a very stripped-down form.  In the -06 draft, INDEX will 
be removed.

4. Move versioning to a separate specification.

Versioning operations were moved to a separate specification for several 
reasons.  First, the current protocol draft is at 71 pages, and at this 
length is difficult to review well.  A longer specification would only 
increase this problem.  Second, I am planning on holding a working group 
last call on the protocol document in January, and there is no possible way 
versioning would be done by this time.  By moving versioning to a separate 
specification, work can proceed on versioning without holding up or being 
rushed by the distributed authoring draft.

However, let me stress that this is not intended to kill work on 
versioning. There is still extremely strong support within the Design Team 
to continue working on versioning, and I personally am very commited to 
seeing this group develop a versioning specification.  This change is in 
the -05 specification.

5. Move PATCH to a separate specification.

At present, the PATCH method is "MAY" functionality, and is specified using 
a home-grown XML difference format.  Recent work on HTTP differencing 
(e.g., gdiff) and on PUT with byteranges (currently under discussion in the 
HTTP WG) suggest that this method is premature.  PATCH is being moved into 
a separate specification so it can await the maturity of gdiff, and the 
outcome of the PUT with byteranges discussion.  This change will take 
effect in the -06 specification.

6. Rename methods:
   COPY -> DUP, MOVE -> RENAME, LOCK ->RESERVE, UNLOCK -> UNRESERVE.

The rationale for this change is to avoid a method name conflict with 
versions 2 and 3 of the Netscape Enterprise Server which contained 
prototype versions of these methods. This change will take effect in the 
-06 specification.

7. Move the Destroy header into the versioning draft.

Since the Destroy header only had singificance for versioned resources, it 
makes sense for the Destroy header to follow versioning into a new 
specification. This change will take effect in the -06 specification.

- Jim
Received on Tuesday, 25 November 1997 18:13:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:44 GMT