Subject: RE: MOVEs across file systems

From: "Clemm, Geoff" <[email-masked]>
Date: Tue, 11 Mar 2003 12:10:24 -0500

Yeah, I didn't think that Julian's suggestion would be popular (:-).

So I think realistically, we should focus on constraining the
behavior of MOVE/DELETE in the presence of multiple bindings
to the same resource, so that they don't violate the basic 
requirements of multiple bindings.

The current form of that proposal is:

----------------------------

Instead of saying:

  "DELETE SHOULD be UNBIND if UNBIND is supported"

we should say something like:

  "When DELETE is applied to a collection, it MUST NOT modify the
   membership of another collection, except when the collection
   being deleted is itself a member of that other collection.

   For example, suppose /a/b/.../x identifies a collection C, and there
   is a second binding to C in a collection that is not a member of
   /a/b, then "DELETE /a/b" MUST NOT delete the internal member
   named "y" from C.

And instead of saying:

   "MOVE SHOULD be REBIND if REBIND is supported"

we should say something like:

   "When MOVE is applied to a resource, the other bindings
    to that resource MUST be unaffected, and if the
    resource being moved is a collection, the bindings to any
    members of that collection MUST be unaffected.
    Also, if MOVE is used with Overwrite:T to delete an
    existing resource, the constraints specified for DELETE apply."

------------------

Cheers,
Geoff

-----Original Message-----
From: Lisa Dusseault [mailto:[email-masked]]
Sent: Tuesday, March 11, 2003 11:40 AM
To: 'Clemm, Geoff'; 'WebDAV'
Subject: RE: MOVEs across file systems

This is equivalent to the previous behavior as long as clients continue
to issue the same MOVE and DELETE requests they have in the past (which
they will for quite a while).  Therefore, I don't see how this is a
change, or how this could possibly be acceptable if the previous
behavior was unacceptable.

Servers must be able to support the binding specification, and to
support ordinary WebDAV clients, and to do what the server implementors
consider to be the most appropriate and best job they can of fulfilling
the request, and to report the results.  This proposed statement does
not meet that requirement because it forces all servers to do atomic
MOVE/DELETE in handling requests from ordinary WebDAV clients.

Lisa

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Clemm, Geoff
> Sent: Monday, March 10, 2003 12:18 PM
> To: 'WebDAV'
> Subject: RE: MOVEs across file systems
> 
> 
> 
> That would be fine with me as well.
> 
> Just to be clear, this means the binding spec would state:
> 
> A server that supports BIND MUST implement MOVE/DELETE with
> rebind/unbind semantics.  We will also define a parameter to
> MOVE/DELETE that allows a user to explicitly request the
> "best effort" style processing (that is OK because the user is
> explicitly stating that trashing multiple binding semantics is
> what they want).
> 
> Cheers,
> Geoff
> 
> -----Original Message-----
> From: Julian Reschke [mailto:[email-masked]]
> 
> > From: Clemm, Geoff
> > So I'm happy to limit the constraints on MOVE and DELETE to exactly
> > what is needed to preserve the semantics of multiple bindings, but
> > leaving them unconstrained makes the binding protocol pointless in
> > practice.
> 
> On the other hand, a system that allows a "weak" MOVE if and 
> only if there
> aren't any multiple bindings seems very weird to me. So maybe 
> we should
> consider make MOVE "strong" by default, and only allow the 
> old COPY/DELETE
> semantics upon specific request?
> 
>

---

From: "Lisa Dusseault" <[email-masked]>
Date: Tue, 11 Mar 2003 10:11:22 -0800

This is pretty good!  I look forward to seeing it in context of the
draft, when we can submit drafts again of course.

> Sent: Tuesday, March 11, 2003 9:10 AM
> To: 'WebDAV'

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 11 Mar 2003 19:58:18 +0100

Of course that doesn't require the ability to *submit* drafts, as long as
the current edits are published on the BIND home page (as they usually are)
:-)

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

> [mailto:[email-masked]]On Behalf Of Lisa Dusseault
> Sent: Tuesday, March 11, 2003 7:11 PM

---

From: "Lisa Dusseault" <[email-masked]>
Date: Tue, 18 Mar 2003 11:48:09 -0800

I've talked to a couple people about why the IETF has draft deadlines,
since we've slipped a couple times in how we meet the deadlines and what
we do about changes post-deadline. Basically the issue is fairness to
everyone.

1.  Participants need a chance to prepare. We all need about a week to
read a reasonable number of drafts to prepare properly for an IETF
meeting.

2.  There needs to be a clear understanding what version we're all
talking about. A version-number-less Web URL doesn't provide this
clarity. It's likely to result in arguments about what version something
appeared in.

3.  People who don't participate in the mailing list very closely still
ought to be able to catch up with the working group by reading drafts
before showing up in the meeting. They won't know about drafts submitted
after the deadline.

Please make a greater effort to meet the draft deadline.

We do deeply appreciate all the work that goes into drafts, and it is
hard to meet deadlines.  We also understand that the authors of the
drafts benefit from unofficial side channels like Web pages to discuss
work in progress, and that the draft authors may beneficially share
these URLs with the whole working group. However, anything discussed in
an official WG meeting ought to be submitted by the deadline.

Lisa and Jim