Re: Issues remaining with Bind draft

Julian wrote on 03/18/2004 01:50:55 PM:

> Lisa Dusseault wrote:
> 
> > On Mar 18, 2004, at 5:29 AM, Julian Reschke wrote:
> > 
> >> Lisa Dusseault wrote:

> >>> 2. Clarify that a VCR isn't just another binding (because different 
> >>> VCRs pointing to the same VHR have different live properties, not 
> >>> the  same ones)
> >>> etc...
> >>
> >> As DeltaV doesn't say that, I'm not sure why we would need to clarify 
 
> >> that.
> >>
> > I had to do a fair bit of thinking and logical deductions to figure 
> > that out, and I'm fairly experienced in this area.  Let's save 
> > implementors that work and the risk of making an incorrect assumption. 
 
> > A bindings section on the relationship of binding to the 
> > resources/properties defined in DeltaV isn't too hard to write.
> 
> I'm still not sure which part of DeltaV is supposed to be unclear here. 
> But if there is one, this should be fixed as an RFC3253 erratum.

This is deliberately left as an implementation choices.  For example, on 
one
of our servers, we do use multiple bindings to a shared resource for 
checked-in VCR's, and then automatically create a new resource on
checkout.  As long as we satisfy the versioning pre and post conditions,
we are free to make that choice.  If the spec made the kind of statement
Lisa is asking for, it would be limiting the implementation choices of
a provider for no good reason.

In general, an implementor will have to do a fair bit of thinking and
logical deductions, because the spec is the basis for interoperation of
a wide range of implementations, not an implementation guide.

> >>> Section 6 -- REBIND method
> >>> One precondition is " (DAV:binding-allowed): The resource identified 
 
> >>> by the DAV:href supports multiple bindings to it." How can this 
> >>> error  possibly occur?

> OK, now I see. This precondition also exists on BIND (where it makes a 
> lot of sense), however I'm not sure why we would need it for REBIND. 
> Geoff, do you remember why it appears here?

I think it is just an error (resulting from copying all of the BIND
preconditions to the REBIND method).

So I think deleting the precondition would be the right thing to do.

> >>> Does REBIND destroy locks, as MOVE does? It shouldn't, unless 
> >>> there's  a compelling reason for backward compatibility.
> >>
> >> No, it should. REBIND is a "strong" MOVE (that will never attempt a 
> >> "weak" resource move using COPY/DELETE). That's the only semantical 
> >> difference to MOVE, and thus locks behave just like they do with 
MOVE.
> > 
> > I disagree, but in either case, the spec needs to say this one way or 
> > another.
> 
> OK, we may have to add this piece of information, because it's not 
obvious.

I agree with Julian that locking semantics require this behavior, and I
agree that it would be reasonable to add this as an explicit 
post-condition
of the REBIND method.  We would then need to add a similar post-condition 
to
the UNBIND method.

> >>> Does REBIND change the ETag of a resource? Does it change the 
> >>> getlastmodified value of the resource?
> >>
> >> Same as MOVE (which means: usually not).
> > 
> > Can't we be more specific about this?
> 
> No, we can't. It *will* be the same as for MOVE, and for MOVE there's no 

> guarantee whatsoever.

That is correct.  If the etags on the rebound (or moved) resources
satisfy etag semantics, the etags can stay the same.  But they might have
to be changed (in case there previously was a resource at the destination
of the REBIND MOVE with that etag but with different content), so you 
can't
infer whether or not the etag changes as the result of a MOVE.

Cheers,
Geoff

Received on Thursday, 18 March 2004 15:48:08 UTC