Re: Bind issues

I agree with all of Julian's points.  Another example of where
multiple bindings are explicitly created by RFC3253 operations are
when a version-controlled collection is updated to a different
version of a collection.  If a member of the specified collection
version is a version history for a resource that is already
present in the workspace of that collection, the server MUST
create a second binding to that resource. (RFC-3253, Section 14.11).

Cheers,
Geoff

Julian wrote on 12/02/2003 03:31:43 PM:

> Lisa Dusseault wrote:
> 
> >>BIND does *not* introduce the concept on bindings (multiple 
> >>URIs mapped 
> >>to the same resource). This concept already exists implicitly in 
> >>RFC2616, RFC2518 and RFC3253. In RFC3253, some operations even 
> >>implicitly create possibly multiple bindings.
> > 
> > 
> > How so?
> 
> RFC2518: section 5.1:
> 
> "Although implicit in [RFC2068] and [RFC2396], any resource, including 
> collection resources, MAY be identified by more than one URI. For 
> example, a resource could be identified by multiple HTTP URLs."
> 
> RFC3253: section 14:
> 
> "Unlike a version-controlled collection, which contains bindings to 
> version-controlled resources and non-version-controlled resources, a 
> working collection contains bindings to version history resources and 
> non-version-controlled resources."
> 
> >>So if RFC2518bis doesn't already fully explain how locking 
> >>and multiple 
> >>URI mappings interact, it's RFC2518bis that is incomplete.
> > 
> > 
> > RFC2518bis implicitly included the concept that files had previous
> > versions (that you just couldn't happen to know about or view).
> > Still, when DeltaV added versions, it was reasonable and right
> > to add requirements on how servers supporting DeltaV had to MOVE
> > and COPY resources with versions.
> 
> I agree, but I don't understand how that compares to the issue we're 
> discussing....
> 
> > The difference is that before the bindings work, bindings could
> > exist but weren't standardized.  One major goal of standardizing
> > a feature ought to be to ensure that it works the same in different
> > implementations.
> 
> Agreed. I think we're just discussing the best way to ensure this. As 
> multiple bindings (multiple internal member URIs...) to the same 
> resource already appear in RFC2518 and RFC3253, I don't see why it must 
> be the BIND spec that clarifies their locking semantics. *If* it's going 

> to do that, we *must* ensure that it's consistent with what RFC2518bis 
> says. In which case, using the identical description is the easiest way 
> to achieve this.
> 
> > So, if the bindings draft leaves it optional to servers how to 
> > apply LOCK to multiple bindings, then it's my opinion that the
> 
> No, it doesn't leave it optional. It just (currently) doesn't say 
> something that really should be said somewhere else.
> 
> > bindings draft needs to be fixed.  Even if we believe that the
> > required behavior is implicit in GULP, I'd like to see it spelled
> > out in the bindings proposal to minimize confusion and implementation
> > differences.
> 
> If there is anything that actually needs to be clarified, I think it's 
> up to you to point to it. Geoff and others have tried to make GULP as 
> precise as possible. If you think that it doesn't do that well enough 
> yet, please tell us where you think it needs to be improved.
> 
> Julian
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>

Received on Tuesday, 2 December 2003 15:55:01 UTC