Redmond: Changes to Collections Protocol

I've sent separate notes on issues related to the Collections Protocol that
could not be resolved at Redmond.  This note lists the proposed changes to
the protocol that I believe had consensus among the group that was present.
 Unless I hear protests from the mailing list, I propose to make these
changes:

1. The method for creating new references will be renamed to MKREF. The
request-URI for this method will be the URI of the new reference to be
created.  The Referential-Member header will therefore be removed from the
protocol. MKREF will behave like PUT: if a resource already exists at the
request-URI, its content and headers will be overwritten.  The issue of
what happens to DAV properties breaks new ground.  Live properties will get
the properties the server deems appropriate, and dead properties will keep
their original values. The protocol specification will state that MKREF
MUST have Content-Length = 0, and the server MUST ignore any content sent
with the request.

2. URIs in all headers will be changed to coded URIs.

3. All dependencies on the Mandatory Extensions draft will be removed.

4. The specification will be changed to say that servers MUST not follow
references into collections.

5. The DAV:reftarget property stays the same on a COPY or MOVE unless the
Ref-Target header is used to change it.

6. DAV:reftarget is a read-only property.  It can only be set using the
Ref-Target header on a MKREF, COPY, or MOVE request.

7. The specification will not include strong references for now.  The
Ref-Integrity header and DAV:refintegrity property will be defined, but the
only value defined for them will be "weak".  This will allow extension to
support strong references later.  The DAV:refsource property, which gets
used only for strong references, will be removed. 

8. There will be no DAV:ordering property defined by the protocol
specification.  Methods will be used to set the position of a collection
member in the collection ordering.  When a new member is added to a
collection using MKREF, PUT, COPY, or MOVE, its position in the ordering
can be set with the Position header.  At later times, its position can be
modified with MOVE and the Position header (It needs to be confirmed that
this makes sense.  If not, a new method will be added for modifying a
member's position in the ordering).

9. DAV:orderingtype, which is currently an element of the DAV:ordering
property, will become an independent property that can be directly accessed
and set by clients.

10. The current specification contains no explicit way to request that a
collection be ordered. It was agreed that an Ordered header will be defined
for use with MKCOL.  Its value will be the DAV:orderingtype of the
ordering.  There will be one value of DAV:orderingtype defined in the
specification, "Arbitrary." This is the default value if the header is not
present, and means that the client cannot depend on repeatability of the
ordering of results from PROPFIND.  That is, on compliant servers, all
collections MUST have a DAV:orderingtype property, whose value may be
"Arbitrary" or any client-defined ordering type. A client may change the
value of DAV:orderingtype after creating the collection, but is then
responsible for updating the ordering.

--Judy


Name:		Judith A. Slein
E-Mail:		slein@wrc.xerox.com
Phone:  	(716) 422-5169
Fax:		(716) 422-2938

Xerox Corporation
Mail Stop 105-50C
800 Phillips Road
Webster, NY 14580

Received on Thursday, 25 June 1998 16:26:14 UTC