Re: [Bug 2] Bindings needs to completely describe how bindings interact with locks.

Geoffrey M Clemm wrote:
> 
> Hi Neal,
> 
> It's great to have someone other than usual culprits (:-) contribute
> to the discussion!

+1.

> Although the 2518 does not provide a standard method for mapping a
> resource to more than one URL, it does explicitly state that in the
> WebDAV model, multiple URLs may identify the same resource.
> In particular, section 5.1 of RFC2518 states:
> 
> "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."
> 
> So since having multiple URLs identify the same resource is part of
> the 2518 model, how locks behave when multiple URLs identify the same
> resource must be defined by the locking model for 2518.
> 
> On the other hand, the BIND specification must specify the locking
> semantics of anything new that it introduces, which is the BIND, REBIND,
> and UNBIND methods.  And the locking behavior of those methods is
> defined in the BIND specification.
> 
> Cheers,
> Geoff

I'd also like to add that

- RFC2616 (the base protocol that we extend) also includes this concept,

- RFC3253 (versioning) speaks of bindings and some RFC3253 operations 
indeed can create additional bindings to a resource, thus it's really 
time to actually get the BIND spec out of the door :-), and

- that just because you don't have a specific WebDAV method to 
explicitly create bindings that doesn't mean that you can't create them 
at all (for instance, a server that maps directly to an underlying POSIX 
filesystem would naturally expose file system hard links as WebDAV 
bindings). (That's similar to although only the unfinished REDIRECTREF 
spec defines an explicit method to create a redirect resource, you 
already see lots of HTTP resources that answer with 301/302 status 
codes, right...?).

Best regards, Julian



-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Friday, 14 January 2005 08:44:32 UTC