Re: Issues remaining with Bind draft

On Mar 18, 2004, at 12:47 PM, Geoffrey M Clemm wrote:

>
> 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.
>
We don't necessarily have to restrict implementations when we add 
clarifying text.  For example, we could say that "A VCR is more than 
just a binding to a VHR -- it has different properties and state.  
Likewise, two VCRs pointing to the same VHR don't always behave as two 
bindings to the same underlying VCR resource, again because of 
different properties and state in certain circumstances, such as when 
one VCR is checked out."

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

Why couldn't the source ETag be preserved in a REBIND, even if the 
destination resource is being overwritten?  At the least, the spec 
should say that the source ETag MAY be preserved, so that clients know 
they have to handle both cases.

The getlastmodified is a little more contentious.  Does it mean that 
the underlying resource body changed?  If so, then the spec should say 
that this property SHOULD NOT (or MUST NOT) change only because of a 
REBIND operation.

Lisa

Received on Thursday, 18 March 2004 16:44:51 UTC