RE: Comments on ACR draft of 10 Nov 1998

Jim,

Thanks for reviewing the draft.

> -----Original Message-----
> From: Jim Davis [mailto:jdavis@parc.xerox.com]
> Sent: Wednesday, December 02, 1998 3:16 PM
> To: w3c-dist-auth@w3.org
> Subject: 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.

Good idea.  Then the corresponding property would be DAV:destination. OK?
 
> 2. (3.3.1) I agree that Hide-Target seems pointless.  The 
> draft already
> explains why.  Let's get rid of it.

This issue is on the agenda for Orlando.
 
> 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.

Agreed, all good arguments.  This just reflected my confusion in trying to
think about these down-level cases.

I'm still confused about OPTIONS.  If we assume the rules will be the same
as for PUT, down-level clients will redirect to the target resource based on
the headers.  But a reference-aware client might really want to get OPTIONS
for the reference rather than its target.  There would be no way to do this,
unless maybe we introduce a new request header.  Should I do that?  I'm
pretty sure that OPTIONS is the only one of the HTTP methods where this is a
problem -- GET and HEAD already returned all the information there is about
the reference with the 302, and PUT and POST don't make sense to apply to
references.

> 
> 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)

On the agenda for Orlando.
 
> 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.

I can make this change.  I tried in the formal definitions of the headers
(Section 5) to list all the methods that the header can be used with --
you're thinking that this is also a bad idea?  I can try to replace each
list with a conceptual description of the set of methods.  (Any method that
creates a new resource, etc.)

> 
> 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).

I agree with all of your points.  Unless others disagree, I'll get rid of
the Resource-Type header.

(The DAV spec does allow MKCOL to be applied to a locked null resource.  If
I read the spec correctly, the locked null resource has a DAV:resourcetype
of empty until MKCOL gets applied, when the value of DAV:resourcetype would
change to DAV:collection.)

> 
> 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.
>

Well, I was trying to follow the Versioning model, but didn't entirely get
it.  The DAV-Collections header is analogous to the Versioning-Support
header.  Then I guess I need to add a new value DAV:collections for
Verify-Extensions.
 
> best regards
> 
> Jim
> 
> 
> ------------------------------------
> http://www.parc.xerox.com/jdavis/
> 650-812-4301
>

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

Received on Wednesday, 2 December 1998 16:59:57 UTC