Re: Bind issues

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:35:14 UTC