- From: Jim Whitehead <ejw@ics.uci.edu>
- Date: Tue, 24 Nov 1998 17:05:24 -0800
- To: "Mark D. Anderson" <mda@discerning.com>, WEBDAV WG <w3c-dist-auth@w3.org>
This is the third, and final, part of a multi-part response to Mark D.
Anderson's comments on draft-ietf-webdav-protocol-09, available at:
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0099.html
> >6 Locking
> >
> > The ability to lock a resource provides a mechanism for serializing
> > access to that resource. Using a lock, an authoring client can
> > provide a reasonable guarantee that another principal will not
> > modify a resource while it is being edited. In this way, a client
> > can prevent the "lost update" problem.
>
> [OBJECTION] There you go again with the "lost update".
Please see my comments concerning how WebDAV *prevents* lost updates in the
first part of this message, available at:
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0230.html
>
> > This specification allows locks to vary over two client-specified
> > parameters, the number of principals involved (exclusive vs. shared)
> > and the type of access to be granted. This document defines locking
> > for only one access type, write. However, the syntax is extensible,
> > and permits the eventual specification of locking for other access
> > types.
>
> [OBJECTION] Locking is not critical to basic authoring, as I
> have outlined earlier. Locking has much greater affiliation
> with versioning and with ACL, and so should be proposed either
> as part of those drafts, or on its own, not here. Actually, I
> suspect that locking may not need to be proposed at all, as a
> suitably rich pair of versioning and ACL proposals would not
> require a special LOCK method and protocol which distinguishes
> that property from general properties which might be
> associated with a resource and manipulated. However, I don't
> have the time or space to explore that direction right now.
Please see my comments on why we chose to use a locking scheme, instead of
an access control modification scheme, in the first part of this response.
Another issue to consider is that, with systems which handle multiple people
working on a resource simultaneously with a branching approach, the
subsequent merge operation, where branched versions are reconciled, requires
the client (or possibly the server) to have a deep knowledge of the internal
structure of the data being edited, and furthermore, to be able to handle a
merge operation. This certainly raises the barrier to entry for WebDAV
clients above that for locking.
>
> >6.1 Exclusive Vs. Shared Locks
> > The most basic form of lock is an exclusive lock. This is a lock
> > where the access right in question is only granted to a single
> > principal.
>
> [CLARITY] The term "principal" is not one that appears in the HTTP 1.1
> spec, and needs to be explicitly defined. Is a "principal" intended
> to be a single user? A role? A particular user agent? How does HTTP
> authentication relate to it?
Good catch. A principal is an abstraction which models both a user operating
an HTTP/DAV user-agent and an HTTP/DAV client which is not directly operated
by a human user (e.g. a Web crawler). Within HTTP Digest authentication, a
principal is identified by a (username, realm) combination.
> [OBJECTION] Obviously all this has to do with ACLs, which
> reinforces my suggestion that locking should be deferred to an
> ACL or versioning proposal anyway. In particular, it is
> senseless to suggest a locking protocol until there is a
> supporting mechanism for administrative actions (lock
> override, etc.), and such a mechanism can not be effectively
> articulated except as part of an ACL proposal.
Some of the interactions between locking and principals are discussed in the
thread which begins:
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JulSep/0017.html
Especially the posts starting with:
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JulSep/0033.html
>
> > The need for this arbitration results from a desire to
> > avoid having to merge results.
>
> [CLARITY] Note that an exclusive lock doesn't rule out the eventual
> need for merging, because the exclusive lock may be in an SCM branch.
True, although this can safely be considered out of scope in this document.
> > However, there are times when the goal of a lock is not to exclude
> > others from exercising an access right but rather to provide a
> > mechanism for principals to indicate that they intend to exercise
> > their access rights. Shared locks are provided for this case. A
> > shared lock allows multiple principals to receive a lock. Hence any
> > principal with appropriate access can get the lock.
>
> [OBJECTION] It makes sense to me to have exclusive and advisory
> locks (aka pessimistic and optimistic). That distinction has a
> long tradition in SCM and elsewhere. However, these "shared
> locks" are different. They seem to want to provide the
> notification capability, as well as accomplish an ACL: a "shared
> lock" is essentially owned by a group, not a user, and can be
> used by any of them.
This is a good characterization of shared locks.
> I would instead prefer to see pure advisory
> locks -- which are associated with a particular user -- and leave
> to an ACL proposal the configuration of what subset of users are
> allowed to do what. Again, locking needs to await a coherent ACL
> proposal.
But this part comes without any justification. What benefits, exactly,
would be had by only supporting "pure advisory locks"? You don't say.
Furthermore, even if there are benefits, what are the benefits over the
existing shared lock mechanism?
>
> > Of the small number who do have write
> > access, some principals may decide to guarantee their edits are free
> > from overwrite conflicts by using exclusive write locks. Others may
> > decide they trust their collaborators will not overwrite their work
>
> [OBJECTION] Ok, now you are just trying to hurt me.
Noted.
>
> > For example, some repositories only support shared write locks while
> > others only provide support for exclusive write locks while yet
> > others use no locking at all.
>
> [CLARITY] Not shared locks as you have defined them.
>
> >6.3 Lock Tokens
> >
> > A lock token is a type of state token, represented as a URI, which
> > identifies a particular lock. A lock token is returned by every
> > successful LOCK operation in the lockdiscovery property in the
> > response body, and can also be found through lock discovery on a
> > resource.
>
> [OBJECTION] Locks certainly need a URI, but I'm not convinced that
> the supposed benefit of carrying this cookie around in the protocol
> (the "If" header, etc.) outweighs the hassles in implementation and
> (probably) eventual usage. SCM systems have gotten along just fine
> without this. A user needs to be able to perform authoring from
> multiple client machines and UA's, and so needs to be able to
> recover these tokens (so they can be sent back). With that, there
> will still be ample room for users to shoot themselves in the foot.
> This is mostly a UI issue.
Performing an assessment of the utility/need for lock tokens is one of many
actions we'll be able to perform once we advance to Proposed Standard and
start getting some use feedback.
However, your assertion that "SCM systems have gotten along just fine
without this" is a bit deceptive. Most SCM systems I know are intended for
use in a LAN environment, and thus avoid a lot of the issues we encountered
when trying to develop a locking mechanism for use with a stateless
protocol.
> A user can certainly authenticate as
> a different identity,
This would be a problem with the SCM systems I know.
> or an ACL proposal might allow for a single
> identity to authenticate in "readonly" mode.
Since WebDAV locks only affect writing, I don't see how this case affects
DAV locks.
>
> >6.4.1 Node Field Generation Without the IEEE 802 Address
>
> [CLARITY] Surely this can go in an appendix.
Perhaps -- although it seemed to go best right after the discussion of lock
tokens.
> >6.5 Lock Capability Discovery
> >
> > Since server lock support is optional, a client trying to lock a
> > resource on a server can either try the lock and hope for the best,
> > or perform some form of discovery to determine what lock
> > capabilities the server supports. This is known as lock capability
> > discovery. Lock capability discovery differs from discovery of
> > supported access control types, since there may be access control
> > types without corresponding lock types. A client can determine what
> > lock types the server supports by retrieving the supportedlock
> > property.
> >
> > Any DAV compliant resource that supports the LOCK method MUST
> > support the supportedlock property.
>
> [CLARITY] So which is it: the server, or the resource, that is
> the subject of "supports"? And what does "supports" mean: that the
> user is allowed (according to ACL) to do it on this particular resource,
> or that the server is in theory capable of it?
Ultimately, it is the resource. However, if a server doesn't support
locking, then most likely, all resources on that server also do not support
locking. So, when we say "server lock support is optional", we are really
saying, "the server's core code base may or may not support locking, and
hence most resources on that server can be expected to support, or not
support locking, depending on the how the server's core code base was
implemented. However, it is possible that by using NSAPI, ISAPI, CGI, or
some other server extension mechanism, an individual resource on that server
could support locking." We felt that "server lock support" was an adequate
shorthand means of expressing this.
> [OBJECTION] It appears that in this property framework, that only
> lock properties can have queriable metadata (supportedlock,
> lockscope, locktype)? Is supportedlock the only property with a
> documented nested xml structure? It would be easier to answer
> these questions if the property proposal were spelled out more,
> so that the reader is not forced to rely so heavily on the
> implications of examples.
No, the DAV:source property can also have a nested XML structure, as can the
DAV:supportedlock and DAV:resourcetype properties.
It's pretty easy to figure this out by following the XML DTD language
specification at the end of each property description in section 13.
Properties which do not have nested XML have a value of #PCDATA, those that
have nested XML have a value other than #PCDATA.
> >6.7 Usage Considerations
> >
> > Although the locking mechanisms specified here provide some help in
> > preventing lost updates, they cannot guarantee that updates will
> > never be lost. Consider the following scenario:
>
> [OBJECTION] Again, "lost updates" are a red herring, entirely
> orthogonal to SCM locking.
Please see my other rebuttals to your comments.
> >7 Write Lock
> >
> > This section describes the semantics specific to the write lock
> > type. The write lock is a specific instance of a lock type, and is
> > the only lock type described in this specification.
> >
> >7.1 Methods Restricted by Write Locks
> >
> > A write lock MUST prevent a principal without the lock from
> > successfully executing a PUT, POST, PROPPATCH, LOCK, UNLOCK, MOVE,
> > DELETE, or MKCOL on the locked resource. All other current methods,
> > GET in particular, function independently of the lock.
>
> [OBJECTION] Again, locking belongs with ACL. When complemented with
> a full ACL specification, the specific method set restricted by a lock
> need not be hard-wired into the protocol. We needn't invent a fixed
> set of lock types (write, etc.) with particular fixed semantics;
> an ACL rule could specify what the restrictions are. (And, as
> intimated earlier, a rich ACL proposal could probably do away
> with a distinguished lock property altogether.)
Please see my discussion in the first part of this response concerning why
the design choice of locking over ACLs was chosen.
> >7.4 Write Locks and Null Resources
>
> [CLARITY] I didn't understand null resources earlier, and I certainly
> don't understand "lock-null resources".
Without any further explanation, it's hard for me to divine why you're
having a hard time understanding this concept. To my eye, it is defined
pretty precisely.
The intent of a locking a URI is to reserve the name for use by that client.
The act of reserving the name by taking out a lock introduces properties, so
it is possible to perform lock discovery. This creates a resource which has
no body, but does have the lockdiscovery property defined on it.
That's it.
> >7.5 Write Locks and Collections
> >
> > A write lock on a collection, whether created by a "Depth: 0" or
> > "Depth: infinity" lock request, prevents the addition or removal of
> > members of the collection by non-lock owners.
>
> [CLARITY] This is the first mention of "Depth" in the draft.
> Some definition/introduction is merited.
This would be a helpful clarification -- it's too late to make changes to
the current draft, but we will make a note of this for future revisions.
>
> >7.5 Write Locks and Collections
>
> [OBJECTION] Again, I'd much prefer a proposal that didn't special case
> locks so much, and considered such issues as properties on collections
> as a general case.
There seems to be some misunderstanding here, since collections always do
support properties -- this is not a special case behavior.
> >7.6 Write Locks and the If Request Header
>
> [OBJECTION] As indicated above, I think this is overkill for the
> problem, if it even helps at all. Consider all the scenarios,
> *including* the case where the user *wants* Program B to take over
> the work.
It is certainly possible, in this example, for program B to take over the
work of program A. The important point is, program B can't *unwittingly*
take over the work of program A. But, if program B retrieves the lock token
created by program A, and submits it, along with valid authentication
credentials, then program B can take over the work of program A. It just
can't do this unless it has first retrieved the lock token.
> >7.7 Write Locks and COPY/MOVE
> >
> > A COPY method invocation MUST NOT duplicate any write locks active
> > on the source.
>
> [OBJECTION] COPY is a bit of an oddball, particularly in light of previous
> strictures concerning a lack of "duplicates" in the namespace. The actual
> semantics of a COPY might vary considerably: an SCM branch, an
> SCM snapshot,
> replication, backup, deployment, and so on. I'm not comfortable with
> a blanket statement on how locks behave until those possible semantics
> are fleshed out (which may have to await other drafts). This is
> true not just for locks but properties, links, pointers, and so on.
> (And again, I think locks deserve little or no special treatment as
> compared to properties generally).
The intent is that COPY duplicates the *resource*, and this new resource
available via a new URI. So, the requirements against duplicate URIs in the
namespace doesn't apply to duplicate resources.
The behavior of COPY w.r.t. versioning will be determined in the versioning
protocol specification.
> >7.8 Refreshing Write Locks
>
> [OBJECTION] Lock refreshes seem motivated by a desire to
> accommodate unstable
> or ephemeral clients (such as java applets), so that they are forced to
> maintain a "dead man switch". However, just because I've lost my work
> on my client doesn't mean I want all my server-side state wiped out
> as well. It should be possible for an unstable client to be brought back
> up and start up again where it left off. Furthermore, it is far from
> clear why this complication needs to be added to the protocol anyway,
> as compared to just allowing administrators to set up automatic sweeps
> on a periodic basis -- achieving the same end, if that end is in fact
> desirable.
Actually, the justification for lock refreshes is ensure that a client
doesn't ever have to momentarily lose a lock due to a timeout if it is still
actively performing editing operations. This applies equally to all
clients, ephemeral or not.
> >8.1 PROPFIND
>
> [OBJECTION] Again, I believe that the property proposal needs to be
> extracted and re-thought, addressing at least the issues raised earlier.
Please see my previous comments on this point.
>
> I'm not going to get into a detailed critique of the syntax and
> semantics of the property proposal here.
>
> > <D:propfind xmlns:D="DAV:">
>
> [CLARITY] There are a few places in the draft where "dav:" is used
> instead of "DAV:".
Thank you for pointing this out -- we have corrected these lowercase "dav:"
references in draft-ietf-webdav-protocol-10.
> [OBJECTION] It should probably be called "DA:" or "DAP:", since no
> versioning is provided, unless there actually is some (unspecified)
> conception for how this proposal will be extended to include versioning.
A consistent namespace for both distributed authoring, as well as
versioning, and DASL elements was felt to be a plus, and hence we are
continuing to use "DAV:".
>
> > >>Request
> >
> > PROPPATCH /bar.html HTTP/1.1
> > Host: www.foo.com
> > Content-Type: text/xml; charset="utf-8"
> > Content-Length: xxxx
> >
> > <?xml version="1.0" encoding="utf-8" ?>
> > <D:propertyupdate xmlns:D="DAV:"
> > xmlns:Z="http://www.w3.com/standards/z39.50/">
> > <D:set>
> > <D:prop>
> > <Z:authors>
> > <Z:Author>Jim Whitehead</Z:Author>
> > <Z:Author>Roy Fielding</Z:Author>
> > </Z:authors>
> > </D:prop>
> > </D:set>
> > <D:remove>
> > <D:prop><Z:Copyright-Owner/></D:prop>
> > </D:remove>
> > </D:propertyupdate>
> >
> > >>Response
> >
> > HTTP/1.1 207 Multi-Status
> > Content-Type: text/xml; charset="utf-8"
> > Content-Length: xxxxx
> >
> > <?xml version="1.0" encoding="utf-8" ?>
> > <D:multistatus xmlns:D="DAV:"
> > xmlns:Z="http://www.w3.com/standards/z39.50">
>
> [OBJECTION] I agree that some sort of structured response is
> required to express the result of methods with a Depth parameter.
> However, I do not see cause for the specific baroque 4-level
> multi-status structure.
Having spent considerable time thinking about how best to send back
multistatus responses, let me assure you that it is far from obvious how
best to design such a response format. The current response format has
sufficient expressiveness for our needs, and has been successfully
implemented by several applications. Unless there is a more serious problem
with the response format than an aesthetic judgement about it, it will stay
as-is.
> I also do not think that the existence of a multi-status response
> structure should open the door to piling in multiple unrelated
> operations into a single request, as is done here with "set" and
> "remove". If optimization of communication is desired, that
> should be left to lower layers (as in fact HTTP 1.1 begins to
> address). If transactions are desired -- and that is not the
> case here, since by definition the "multi-status" allows each to
> fail -- then that mechanism should be proposed as a separate
> draft, after due consideration of TIP.
Actually, our intent with PROPPATCH was to avoid having to specify
transactions in the protocol by allowing a client to specify a series of
"set" and "remove" operations which the server would have to perform
atomically. We also favored this approach because it allowed multiple
properties to be updated with a single network round trip. The combination
of atomicity and efficiency has, so far, been a good design choice.
>
> > A MKCOL request message may contain a message body. The behavior of
> > a MKCOL request when the body is present is limited to creating
> > collections, members of a collection, bodies of members and
> > properties on the collections or members. If the server receives a
> > MKCOL request entity type it does not support or understand it MUST
> > respond with a 415 (Unsupported Media Type) status code. The exact
> > behavior of MKCOL for various request media types is undefined in
> > this document, and will be specified in separate documents.
>
> [OBJECTION] Explain to me again why PUT won't work, perhaps extended
> as suggested by PEP, as an "M-PUT"? If it is possible to express
> what PUT does with a single resource, what is so difficult that prevents
> you from specifying how to provide multiple child resources as part
> of a MKCOL?
Please see my previous comments concerning the MKCOL vs. PUT design
decision, and the current dead status of the PEP proposal.
> >8.4 GET, HEAD for Collections
>
> [OBJECTION] While it might be possible to extend GET via M-GET on
> a collection to have a precise response format, I agree that
> refining GET behavior for collections is probably not a good idea.
> However, we need *some* way to easily and simply query
> about children.
PROPFIND is used to query a collection for its children.
> There is no discussion in the spec about what
> OPTIONS does with collections. I would suggest that OPTIONS
> take a Depth parameter. It is either that, or a new "DIR" method.
> I prefer extending OPTIONS.
OPTIONs with Depth is an interesting suggestion. It is too late to include
such a suggestion into the current specification, but I feel it is worth
considering.
> >8.6 DELETE
> >
> >8.6.1 DELETE for Non-Collection Resources
> >
> > If the DELETE method is issued to a non-collection resource which is
> > an internal member of a collection, then during DELETE processing a
> > server MUST remove the Request-URI from its parent collection.
>
> [CLARITY] Another "sense and reference" confusion, where URI's
> are somehow in collections.
This was corrected in draft-ietf-webdav-protocol-10.
>
> >8.6.2 DELETE for Collections
>
> [CLARITY] As with COPY (see above), some discussion is merited about
> the possible semantics of DELETE. For example, SCM systems sometimes offer
> both "delete" and "destroy". There should be some suggestion of how
> the capability of a server to carry out these different semantics
> should be detected and requested.
In previous revisions of the WebDAV protocol specification, there was a
DESTROY method. After discussion by the working group, this method was
removed. The versioning and variant authoring design team may decide to
reintroduce it.
> >8.7 PUT
>
> [CLARITY] The methods MKCOL (8.3), POST (8.5), and PUT (8.7) should
> all be discussed in succession.
It's not clear to me what advantage would be gained from this ordering.
> > A PUT that would result in the creation of a resource without an
> > appropriately scoped parent collection MUST fail with a 409
> > (Conflict).
>
> [CLARITY] I suggest that all these statement like "delete means
> delete" and "put means put", and how the methods are related to
> the URL hierarchy, be gathered together in a table, as described
> earlier.
Please see my previous comments concerning your table specification idea.
> I have no idea what an "appropriately scoped parent collection"
> is. Also, I have no idea in general what it means exactly to
> state that a resource does or does not exist. I *can* state what
> operations on a particular URL will fail.
By a resource "existing", we mean that there is no linkage of a given URI to
a resource.
> [CLARITY] It would be worthwhile to discuss the situations of PUT
> meaning "create", and PUT meaning "update". An extension which allows
> a client to restrict behavior is worth considering.
We were trying to restrict ourselves to just specifying the behavior of PUT
that was modified by WebDAV -- the HTTP specification is the proper place
for discussion of the two posible uses of PUT (update vs. create).
>
> >8.7.2 PUT for Collections
> >
> > As defined in the HTTP/1.1 specification [RFC2068], the "PUT method
> > requests that the enclosed entity be stored under the supplied
> > Request-URI." Since submission of an entity representing a
> > collection would implicitly encode creation and deletion of
> > resources, this specification intentionally does not define a
> > transmission format for creating a collection using PUT. Instead,
> > the MKCOL method is defined to create collections.
>
> [CLARITY] This paragraph seems redundant with the second paragraph
> of section 5.3. My comments above to that earlier paragraph
> apply here as well.
Good point -- one of the two could safely be removed. This change will be
noted for inclusion in a future draft.
> > When the PUT operation creates a new non-collection resource all
> > ancestors MUST already exist. If all ancestors do not exist, the
> > method MUST fail with a 409 (Conflict) status code. For example, if
> > resource /a/b/c/d.html is to be created and /a/b/c/ does not exist,
> > then the request must fail.
>
> [CLARITY] This should be moved into 8.7.1, or deleted as being redundant.
Good point. This change will be noted for inclusion in a future draft.
> >8.8 COPY Method
>
> [CLARITY] Section 7.7 should be merged in here. See my general comments
> regarding COPY at 7.7.
This is another document design decision. Do you discuss locking behavior
all in one place, or do you discuss the behavior of locks for COPY and MOVE
in the COPY and MOVE sections? We decided to keep the locking sections
together, so that all implications of locks could be more easily seen.
> > Live properties SHOULD be duplicated as identically behaving live
> > properties at the destination resource. If a property cannot be
> > copied live, then its value MUST be duplicated, octet-for-octet, in
> > an identically named, dead property on the destination resource
> > subject to the effects of the propertybehavior XML element.
>
> [CLARITY] This whole conception of "live" and "dead" properties escapes
> me. Maybe when the property proposal is fleshed out in its own
> document, it will become clearer.
Well, it's hard for me to understand your confusion without more specific
feedback. Section 4.1 is pretty clear when I read it.
> >8.8.3 COPY for Collections
>
> [CLARITY] There are a number of important issues this glosses over.
> What about treatment of resources that act like "symbolic links" (MKREF
> or whatever)? Should they be copied as resources, omitted, or copied
> as links? Can I specify my preference?
>
> What should happen if my request and destination URI's overlap in
> the URL hierarchy?
A separate specification ("Advanced Collections Protocol,
draft-ietf-webdav-collection-protocol-02) addresses these questions.
> How should the server treat simultaneous requests, for example if
> there is one COPY going into a tree that another request is COPY-ing
> out of? What about if two COPY requests go into the same tree, and
> then one of the requests fails? Must the server implement isolation?
> Similar questions apply to simultaneous combinations of MOVE, COPY,
> and DELETE.
We have been viewing this as a server implementation issue.
> If a request with Overwrite "T" fails, is full rollback mandatory?
No -- COPY and MOVE for collections are best-effort. If a single resource
cannot be copied/moved, the rest of the operation will still continue.
> There needs to be more discussion of errors that apply to the
> entire request and appear in the http header (501, etc.), and
> status responses in the body. If there is a 5xx error on
> some of the children, should the entire response have a 5xx
> status code in its http header? Or only if the entire operation
> was unsuccessful? The client needs some way, per failed child,
> to easily distinguish errors due to a server problem out of
> the user's control, and errors such as from an ACL. Would
> this mean a 4xx error vs. a 5xx error associated with each
> child in the response? How is the client to distinguish
> whether a status code in an http header is in reference
> to a request URI or a destination URI? (These are all general
> issues with the authoring methods, not specific to COPY.)
We had several discussions in our design over whether we needed to have a
success multistatus response, and a failure multistatus response -- kind of
a glass half full, or half empty discussion. In the end we decided that the
single 207 multistatus was sufficient unless all the responses are identical
(say every child fails with the same error response), in which case just
that response can be returned.
> [OBJECTION] Although I hesitate to ever add complexity, this does
> not seem powerful enough.
>
> "Depth" seems too impoverished; typically I will want to specify
> that the method should apply to resources with a particular
> property, or matching some pattern. But we have no facility for
> expressing such a scope, even as part of some other method.
>
> It is too rigid to specify a fixed error handling behavior.
> I should like to specify the behavior as "all-or-nothing"
> or "do-your-best".
>
> I might want to specify certain properties (access rights, certainly)
> that apply to the new destination resources. How that might
> be done awaits full proposals for properties and for ACL.
> I also may want richer control of the property copying semantics
> described in 8.8.2.
>
> I may want the resources to undergo some URL renaming during
> a COPY of a collection. I can do this when I COPY a simple resource;
> I may want the same capability for Depth > 0, so that the destination
> children get a URL name which is spelled differently than that
> of their matching source.
>
> I may want to specify what the server should do when it discovers
> that a destination resource exists already, or not (as with PUT,
> see above).
At first blush, this proposal appears to be *really* complex. Certainly
more complex than would be included in the draft at such a late date.
>
> > 502 (Bad Gateway) - This may occur when the destination is on
> > another server and the destination server refuses to accept the
> > resource.
>
> [OBJECTION] This request to another server is done with what
> proxy credentials? What user credentials? What protocol is used
> for this server-to-server operation? A MKCOL?
Answers to all of these questions are left undefined for now, since the base
WebDAV protocol is a client-server protocol, not a server-server protocol.
We just needed an error response to handle cases where the URI in the
Destination header is outside the control of the server.
> >8.9 MOVE Method
>
> [OBJECTION] Similar comments apply to MOVE as to COPY. Since MOVE
> is so similar to COPY, I wonder if we really need two methods
> (that is, add a parameter to a single method which indicates whether
> a following delete should occur).
Since COPY/MOVE do have different semantics, they might need to be
differentiated for access control. Having them be separate methods aids
separating the access control for MOVE and COPY.
> > If: (<opaquelocktoken:fe184f2e-6eec-41d0-c765-01adc56e6bb4>)
> > (<opaquelocktoken:e454f3f3-acdc-452a-56c7-00a5c91e4b77>)
>
> [CLARITY] Is one of these for the request URI, and the other one
> for the destination?
Yes.
> [OBJECTION] See above for my objections regarding this "cookie"
> approach to locking, and to the way HTTP header fields are
> added (Overwrite) or changed (If) without any acknowledgment of PEP.
Please see my response above to your previous objections concerning this
approach.
> >8.10 LOCK Method
>
> [OBJECTION] See above for my objections to treating locks
> so differently from other properties.
Please see my previous responses on the topic of locking.
>
> >8.10.3 Locking Replicated Resources
> >
> > A resource may be made available through more than one URI. However
> > locks apply to resources, not URIs. Therefore a LOCK request on a
> > resource MUST NOT succeed if can not be honored by all the URIs
> > through which the resource is addressable.
>
> [CLARITY] I'm not certain what it means for a URI to honor a request.
> There is a typo there, "succeed if can".
This doesn't say the URI honors the request, but rather that the resource,
when accessed via a URI, honors the request. And the text is correct as-is.
If the resource cannot honor the lock semantics for accesses via any of its
URIs, then the resource MUST NOT honor a request to create a lock in the
first place.
> [OBJECTION] See my comments on COPY -- there are a variety of
> reasons that resources may be duplicated. The semantics of those
> cases for properties and locks may vary. For example, if I want
> to carry out a snapshot, then I want it "disconnected" from later
> operations on the original resources.
I'm not sure I understand the meaning of this objection.
>
> [OBJECTION] Does this section imply that a server has to
> consult with other servers to check on locks?
> What protocol is that done with?
This specification does not specify any server-to-server protocol. It is a
server implementation decision if such a protocol exists, and is used by the
servers.
>
> >9.4 If Header
>
> [OBJECTION] See my comments above on the If header and
> opaquelocktoken. This all seems rather complicated for the
> scenarios it is apparently intended to address. Yet it still
> restricts itself to ETags and locks, and so is not sufficient for
> the kind of scoping that might be useful for COPY and other
> methods, as discussed above.
>
> In part, its complexity seems to arise from a desire to
> accomplish what really should be left to an ACL configuration
> ("it either has to have this kind of lock and a weak tag, or have
> a strong tag", etc.).
>
> > If: (Not <locktoken:write1> <locktoken:write2>)
Please see previous comments concerning your objections to the If header.
>
> [OBJECTION] As they say, if you leave academics alone long enough,
> they turn everything into Lisp :).
Actually, this section was written by a non-academic on the design team.
>
> >9.5 Lock-Token Header
>
> [CLARITY] Not that I agree with either header, but when are
> tokens used in If, and when in Lock-Token?
The lock token header is a request and response header. UNLOCK uses it as a
request header, while LOCK uses it as a response header. All other
state-modifying operations use the If header.
> >9.6 Overwrite Header
> >
> > Overwrite = "Overwrite" ":" ("T" | "F")
>
> [OBJECTION] "T" and "F" is needlessly English-specific, and needlessly
> introduces capitalization worries. Use 1 and 0.
So, "T" and "F" are needlessly English-specific, while "Overwrite" is
perfectly OK, right?
> As discussed above in COPY, the client needs to have richer
> control over the semantics of authoring methods than is allowed for
> here. In an alternative proposal, this lone boolean header may be
> supplanted,
> hence conveniently obviating the question of how to spell boolean values.
In our draft, additional parameters for MOVE and COPY are specified in the
message body (see section 8.9.6 for an example).
> >9.8 Timeout Request Header
>
> [OBJECTION] See discussion with section 7.8.
Please see my previous comments.
> >10.1 102 Processing
>
> [OBJECTION] This has a bit of the flavor of a congressional
> "continuing resolution". This is clearly orthogonal to anything
> else in the proposal.
>
> If it is worthwhile, it should be separately proposed, presumably
> with a full discussion of: consequences for proxies; whether there
> is a way for the server to know what the client's timeout is;
> how a client might indicate whether it wants any 102 responses,
> just one, or a periodic update; and how multiple and final
> notifications can be accomplished.
It wasn't until WebDAV that operations were proposed which might take
sufficiently long in their processing (I'm thinking of MOVE, COPY, DELETE
for large collections) that such a status code was necessary. Since these
methods created the need for this status code, it makes sense to me to
include it in this draft.
>
> >10.2 207 Multi-Status
> >
> > The 207 (Multi-Status) status code provides status for multiple
> > independent operations (see section 11 for more information).
>
> [CLARITY] See my discussion under COPY (8.8.3) concerning the
> interrelation
> between http status and response body status. This needs more
> explanation.
Please see my previous comments on this topic.
>
> >10.3 422 Unprocessable Entity
>
> [CLARITY] So would this include any case of an ACL violation,
> whereby a client attempts an operation that would not have been reported
> as allowed in a preceding OPTIONS response on that URI?
> Could you give some examples?
No, this error code is not intended for use with ACL violations.
> >10.4 423 Locked
>
> [OBJECTION] Again, I don't think locks should be so specially
> considered. Presumably the ACL proposal will supply a suitable
> set of errors, and even allow for custom error messages to be
> specified with ACL rules.
I agree this is a logical extension of your disagreement with locks.
>
> (Skipping ahead a bit past the details in sections 11-14....)
>
>
> >15 DAV Compliance Classes
>
> [OBJECTION] Again, this notion of "compliant resource" does not
> seem necessary. Servers may or may not implement an extension;
> that can be determined via PEP. A URL may or may not permit certain
> operations; that can be determined via an OPTIONS request and Allow
> (no need for a "DAV" http header for this).
>
> If you pull locking out of this proposal, then you don't even
> need to get into "class 1" and "class 2". It just devolves to
> the general question of discovering what of various extensions
> are implemented by a server (and at what version).
Please see my previous discussion on the need for compliance classes, and
why we only discuss compliance for individual resources.
>
> > Since interoperation of clients and servers does not require locale
> > information, this specification does not specify any mechanism for
> > transmission of this information.
>
> [CLARITY] If it isn't required, then don't make it a MUST. But presumably
> clients could benefit from a server knowing what their locale is?
> Not that this proposal is the place to put such a requirement.
Locale information didn't make sense to me in the context of WebDAV.
>
> ----------
>
> To summarize:
> - The property framework needs to be pulled out of this, and
> either abandoned in favor of another or proposed on its own.
In my opinion, you failed to make a convincing case for this, instead
repeatedly making this assertion.
> - Locking needs to be deferred to a full proposal for ACL
> (and possibly versioning), and may not need to be specially
> handled at all.
Your opinion on locking is different from the view of the members of the
working group.
> - That leaves a proposal for COPY, MOVE, and MKCOL --
> one which is both imprecise and ill-conceived.
In my opinion, you failed to make a convincing case that COPY, MOVE, and
MKCOL are imprecise. You may desire them to have additional functionality,
but that does not make them imprecise. Furthermore, unless I missed it,
there was no argument at all to justify your claim that COPY, MOVE, and
MKCOL are ill-conceived.
- Jim
Received on Tuesday, 24 November 1998 20:09:18 UTC