Advanced Collections issues for the RFC 2518 Issues List

Jim, 

It seems as if there should be an issue on the RFC 2518 list for everything
we flag in the advanced collections drafts as inconsistent with RFC 2518.
In effect, we are requesting a change to RFC 2518 for each of these.

(If you are waiting to see which of these actually survive last call on the
advanced collections drafts before adding them to the issues list, OK.)

Here's what I see at the moment:

In the bindings draft:

1. Separate the notion of binding from the notion of URI mapping, and change
the definition of internal member URI and collection state accordingly.

2. Change DELETE on a collection to be an atomic operation.

3. Change Section 8.6.1 so that it doesn't require a server to remove all
bindings to a resource for a DELETE operation.

4. Change MOVE to be rename rather than COPY / fixup / DELETE.

5. Change MOVE on a collection to be an atomic operation.

6. Change Section 7.7 to say that write locks do move when the locked
resource is moved.

7. Weaken the requirement to protect URIs of locked resources to be only
that the URI used to lock the resource be protected.

In the redirect references draft:

8. Extend the DAV:response XML element to allow a DAV:prop element to be
included:
<!ELEMENT response (href, ((href*, status, prop?) | (propstat+)),
responsedescription?) >

In the ordering draft:

9. A DAV:options element is defined in the ordering draft to allow clients
to ask for more detailed information about capabilities than you can get
just from a list of compliance classes in the DAV: response header.  It
might be better if the DAV:options element were defined in the WebDAV spec
so that authors of other extension specs would be more likely to find it and
use it rather than inventing their own.

--Judy

Judith A. Slein
Xerox Corporation
jslein@crt.xerox.com
(716)422-5169
800 Phillips Road 105/50C
Webster, NY 14580

Received on Wednesday, 20 October 1999 16:57:53 UTC