Comments on ACR draft of 10 Nov 1998

1. (3.3.1) I suggest we use the existing Destination header instead of
introducting a new header Ref-Target.  Destination is currently used with
COPY and MOVE.

2. (3.3.1) I agree that Hide-Target seems pointless.  The draft already
explains why.  Let's get rid of it.

3. (3.8) says that PUT with a redirect reference returns a 302 (as do GET
and HEAD) but also that is "MUST include an entity body for display to users".

I think this is a mistake for the following reasons

 a) Internationalization.  What language would you use for the message?

 b) Modularity.  It's up to the user's browser to interpret Web protocol
messages.  For example, my browser warns me when I am accepting a cookie,
when I am submitting a form via email, when I am leaving a secure area, and
when I am about to send a message that is misspelled, has bad grammar, or
might indicate intent to monopolize the market. ;-).  It should and could
also warn me if a PUT returns 302, rather than just blindly re-doing it.

The protocol should be kept simple.  it should convey sufficient
information  that a well written  program can take reasonable action.
There is no need to burden server implementors with creating a message that
will rarely if ever do any good.

4. (3.11) I don't believe the rationale that the DAV:references property
will be "much more efficient for the client to retrieve" that a DASL
search.  Indeed, I expect the underlying implementation to be identical
(that is, a DASL search for all references whose target is T will be
implemented by reading the DAV:references property of T.)

On the other hand, it is likely the expected initial version of DASL won't
be able to search structured values, and hence would not be able to search
the references property.  In any case, the references property seems more
natural to me, and does not add to the cost of the protocol (compared to
any other approach with the same functionality)

5. (4.3.1) The first sentence would be better if it read

When a resource is created (e.g., by PUT or MKCOL) its position in the
parent collection can be set with the new Position header.

because the current sentence omits MKCOL, and would have to be modified if
any new method was added to WebDAV.

6. (5.6) I don't think the Resource-Type entity header should be supported.
As the draft notes, this would only be needed if one can create a reference
with LOCK, or change resource type with MOVE or COPY.

 a) I don't think the LOCK case is important.  Normally, once a reference
is created, there's nothing more to be done.  I suppose a client might want
to create a reference then add some properties, but is this case important
enough to justify the additional complexity of the Resource-Type header?

Also, I don't see any reason from the protocol that one could not do a LOCK
followed by a MKREF.  Locking a non-existing resource creates a null
resource. The protocol says that MKREF overwrites the resource.  So what's
the problem?

Also, can one currently LOCK foo followed by MKCOL foo?  (If not, that's
perhaps a problem for the mainline WebDAV spec, not ACR.)

 b) We certainly should *not* allow clients to *change* a resource type
(with MOVE or COPY).

7. (5.9, DAV-Collections header).  Why can't we use additional values of
the DAV header in Options to convey this?  Note also that the versioning
draft proposes a more general way to indicate the DAV extensions supported,
namely the Verify-Extensions header.  If we can't use the DAV header, we
should at least pick up the same header that the versioning team is using.

best regards

Jim


------------------------------------
http://www.parc.xerox.com/jdavis/
650-812-4301

Received on Wednesday, 2 December 1998 15:16:31 UTC