Subject: RE: Proposal on MOVE and locks

From: "Yaron Goland (Exchange)" <[email-masked]>
Date: Wed, 15 Sep 1999 16:33:43 -0700

This exact same question, regarding moves and locks, came up in the past and
the group consensus was that we should not allow locks to MOVE with
resources. To revoke this decision is to pull the rug out of implementers
who took WebDAV in good faith. This is exactly the sort of behavior which
makes some many companies wary of dealing with the IETF. The rules change
too often.

There is an alternative route which I believe meets everyone's needs. We
define a new header, which can optionally be used with mandatory, that
specifies that the move is only to succeed if the lock (if any) is moved
with it. If the header is absent the server MUST NOT move the lock. The
benefit of this system is that existing clients will continue to properly
interoperate with both existing WebDAV servers and future WebDAV servers. In
addition existing WebDAV servers will be able to properly interoperate with
both existing WebDAV clients and future WebDAV clients.

			Yaron

> -----Original Message-----
> From: Slein, Judith A [mailto:[email-masked]]
> Sent: Wed, September 15, 1999 1:02 PM
> To: 'WebDAV'
> Subject: Proposal on MOVE and locks
> 
> 
> As a result of the discussions on the mailing list over the 
> past week, the
> design team would like to make some changes in its proposal 
> about MOVE and
> locks.
> 
> We agree that we should not be specifying any different behavior for
> cross-server MOVEs than for MOVEs on the same server.  So we 
> plan to take
> out all normative language related to cross-server MOVEs.
> 
> We do want to stand by our basic position that locks MOVE 
> with a resource,
> since that is consistent with the underlying semantic model 
> of bindings.  A
> MOVE has no effect on the resource, but only involves 
> creating a new binding
> between the final segment of the Destination URI in its 
> collection and the
> resource, and removing the binding between the final segment of the
> Request-URI in its collection and the resource.  The state of 
> the resource
> itself -- including its lock state -- is unchanged.
> 
> That leaves us with the following:
> 
> For MOVE (assuming that the principal performing the MOVE 
> owns all locks
> involved):
> 
> 1. If there is a lock on the source resource that is rooted 
> at the source
> resource (that is, the lock is not inherited from a parent 
> collection), the
> lock moves with the resource to the destination.  
> 
> 2. If there is a lock on the destination resource that is 
> rooted at the
> destination resource (that is, the lock is not inherited from a parent
> collection), its lock is gone after the MOVE.
> 
> 3. If the source resource inherits a lock from a parent 
> collection, and the
> resource is moved out of the tree affected by that lock, the 
> lock no longer
> applies to the resource after the MOVE.
> 
> 4. If the destination resource inherits a lock from a parent 
> collection, the
> MOVEd resource inherits that lock after the MOVE.
> 
> 5. If there is a lock on the source resource that is rooted 
> at the source
> resource, and the destination resource inherits a lock from a parent
> collection, the MOVE fails due to a conflict between rules 1 and 4.
> 
> 6. If a collection is MOVEd, and there are some locked 
> resources in that
> collection, the locks on those resources move with the resources.
> 
> For COPY: 
> 
> After the COPY, there will be no locks at the destination 
> except what is
> inherited from above.
> 
> Judith A. Slein
> XR&T/Xerox Architecture Center
> [email-masked]
> 8*222-5169
>

---

From: Greg Stein <[email-masked]>
Date: Wed, 15 Sep 1999 17:21:26 -0700

Yaron Goland (Exchange) wrote:
>...

Why a new header? MOVE has a defined body. Add a new XML element in
there.

Cheers,
-g

--
Greg Stein, http://www.lyra.org/

---

From: "Larry Masinter" <[email-masked]>
Date: Fri, 17 Sep 1999 19:08:53 PDT

> makes some many companies wary of dealing with the IETF. The rules change

I suppose it's necessary to repeat this in every working group.
The IETF rules for "Proposed Standard" are very clear and explicit. The
rule hasn't changed. From RFC 2026:

   Implementors should treat Proposed Standards as immature
   specifications. It is desirable to implement them in order to gain
   experience and to validate, test, and clarify the specification.
   However, since the content of Proposed Standards may be changed if
   problems are found or better solutions are identified, deploying
   implementations of such standards into a disruption-sensitive
   environment is not recommended.

Those who choose to implement and ship product based on Proposed Standard
do so to gain the advantage of early market entry, against the risk
that product changes might be necessary. I don't believe that changes
from Proposed Standard should be made lightly or without good reason,
but it is not "bad faith" to consider changes based on experience with
the protocol.

The ability to update protocols between Proposed and Draft Standard
based on experience is a strength, not a weakness, of the IETF process.
WebDAV is at an early stage of development and deployment, compared
to what we will see in the future.

Don't avoid doing the right thing just because some early implementors
want to avoid shipping an update to their beta customers.

Larry
-- 
http://www.parc.xerox.com/masinter