Subject: Re: Atomic MOVE vs BIND spec, was: Comments on the "new" 2518

From: Jason Crawford <[email-masked]>
Date: Fri, 12 May 2006 09:00:00 -0400

On Friday, 05/12/2006 at 01:42 ZE2, Julian Reschke 
<[email-masked]> wrote:
> Lisa Dusseault wrote:
> >
> >
> > Hoping I'm not going to beat a dead horse here, but instead offer
> > something a little different.
> >
> > Would it help everybody if the requirement wasn't made of servers at
> > all?  If the real purpose of the requirement on server behavior is to
> > set expectations for clients, well we can do that better with direct
> > requirements of clients:
> >
> >   "Clients MUST be prepared to handle complete or partial failure of a
> > MOVE request.  Partial failure could mean that some files remain at 
the
> > source while some are at the destination, or even that some files are
> > duplicated in both places.  Servers MUST NOT move partial files, a
> 
> I think that would be a change to what we say today and what RFC2518
> said. Partial failure is about member resources not being moved, not
> about individual resources being in both places. Unless you were talking
> about collection specifically, which may be true. As proposed I find
> this misleading.

I actually think what Lisa wrote is good.  It sounds to me that your issue 
is
with her saying that a resource might be left at both ends.  I don't know 
for sure
if there is a reason to say that.  If there is, I suspect you've discussed 
it
already.  I won't comment on that.

> Furthermore: what does "move partial files" mean here?

I interpret that to mean where the destination only contains the first 
block
of bytes of the file.  I'd hope that would be avoidable by writing to a
separate file and atomically renaming after the bytes are transfered.
That's why I think Lisa was willing to say MUST NOT.  (I am considering
inter-server MOVEs.) - If Lisa can confirm that I understood her
correctly, that means at least some people understand what she
means.

> > SHOULD NOT leave duplicate files in both places at the end of a MOVE
> > request."
> 
> If servers SHOULD NOT do that, why MUST clients expect and handle that?
> That doesn't seem to make sense from a spec language point of view.

It doesn't?  It says SHOULD NOT, not MUST NOT, so it's possible that it
can happen, right?  So the client should be prepared to deal with it, 
right?

---

From: Julian Reschke <[email-masked]>
Date: Fri, 12 May 2006 15:27:00 +0200

Jason Crawford wrote:
> I actually think what Lisa wrote is good.  It sounds to me that your 
> issue is
> with her saying that a resource might be left at both ends.  I don't 

Yes. That's certainly something I wouldn't expect when invoking MOVE.

> know for sure
> if there is a reason to say that.  If there is, I suspect you've 
> discussed it

As far as I can tell, it's a new thing that hasn't been discussed 
before. I'm also not sure whether it makes sense to spend too much time 
talking about what "partial success" means.

I didn't think about the aspect of collections being present in both 
source and destination namespace before, and we may want to say 
something about that. Lisa, is this what you though of when adding that 
text?

> correctly, that means at least some people understand what she

Well, if we make normative requirements here, we'll have to use proper 
terminology; "file" isn't in the context of WebDAV.

> can happen, right?  So the client should be prepared to deal with it, 

Maybe it's just me but I thought normative language should be used 
carefully (see RFC2119, Section 6). If we put in a MUST level client 
requirement to cope with a certain server behaviour, prohibiting exactly 
that server behaviour with a SHOULD NOT doesn't feel right to me.

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 12 May 2006 12:39:54 -0700

On May 12, 2006, at 6:27 AM, Julian Reschke wrote:
>
> I didn't think about the aspect of collections being present in  
> both source and destination namespace before, and we may want to  
> say something about that. Lisa, is this what you though of when  
> adding that text?

Yes, we didn't say anything about that before, and it only came to me  
when drafting possible text.  The idea of corrupted files also scared  
me.  Of course, we could remain silent about that, as RFC2518 was  
silent on it.

Another draft of suggested text would be welcome.

lisa