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

Jason Crawford wrote:
>  > 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 

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
> already.  I won't comment on that.

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?

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

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

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

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

Received on Friday, 12 May 2006 13:29:39 UTC