RE: bind draft issues

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: Tuesday, March 04, 2003 9:33 PM
> To: 'Julian Reschke'; 'Clemm, Geoff'; 'WebDAV'
> Subject: RE: bind draft issues
>
>
>
>
> > I thought we had agreement that GULP is the currently best approach of
> > explaining the WebDAV locking model. GULP also covers binds
(implicitly!)
> > and therefore either should be added to RFC2518bis, or be the basis for
a
> > rewrite:
> >
>
> GULP should not cover bindings.  That's the problem.  It causes a

I don't understand this statement. How is the fact that GULP indeed handles
the effects of multiple bindings (internal member URIs) to the same resource
affecting it's usability for servers that do not need to consider this
case??? Maybe it's really time to re-read it:

---
Grand Unified Lock Proposal (V5.2)

- A lock either directly or indirectly locks a resource.

- A LOCK request creates a new lock, and the resource identified
  by the request-URL is directly locked by that lock.  The
  "lock-root" of the new lock is the request-URL. If at the time of
  the request, the request-URL is not mapped to a resource, a new
  resource with no content MUST be created by the request.

- If a collection is directly locked by a depth:infinity lock, all
  members of that collection (other than the collection itself) are
  indirectly locked by that lock.  In particular, if a binding to a
  resource is added to a collection that is locked by a depth:infinity
  lock, and if the resource is not locked by that lock, then the
  resource becomes indirectly locked by that lock.  Conversely, if a
  resource is indirectly locked with a depth:infinity lock, and if the
  result of removing a binding to the resource is that the resource is
  no longer a member of the collection that is directly locked by that
  lock, then the resource is no longer locked by that lock.

- An UNLOCK request deletes the lock with the specified lock token.
  The request-URL of the request MUST identify a resource that
  is either directly or indirectly locked by that lock.
  After a lock is deleted, no resource is locked by that lock.

- A lock token is "submitted" in a request when it appears in an If
  header tagged-list whose tag is the lock-root of the lock.

- If a request would modify the content for a locked resource, a dead
  property of a locked resource, a live property that is defined to be
  lockable for a locked resource, or a binding of a locked collection,
  the request MUST fail unless the lock-token for that lock is
  submitted in the request.

- If a request causes a directly locked resource to no longer be
  mapped to the lock-root of that lock, then the request MUST
  fail unless the lock-token for that lock is submitted in the
  request.  If the request succeeds, then that lock MUST have been
  deleted by that request.

- If a request would cause a resource to be locked by two different
  exclusive locks, the request MUST fail.
---

I really doubt that you make the description significantly simpler by
removing this case.

> problem because some RFC2518 servers just don't work that way.  There's

Could you explain? Are you saying that there are RFC2518-compliant servers
that do not comply to the GULP lock model? In which case there's simply a
problem in the model that needs to be fixed. Actually, Geoff and I have been
asking for this kind of feedback for several months now.

> no need to say whether operations apply always to URLs, bindings or
> resources in RFC2518, because when you have 1:1 mappings between URLs

No. You don't. Just because RFC2518 doesn't have a BIND method doesn't mean
that multiple bindings do not exist.

In fact, RFC2518bis talks about redirect resources, although it doesn't
define a method to create them. This is a very similar issue.

> and resources it just doesn't matter 95% of the time, and lets
> implementations expose their existing repository.

So how precisely have these implementations problems with GULP? Please
explain!

> Otherwise, I think there is a lot of useful specification language in
> GULP.

OK.

So *please* specify in which way GULP is inconsistent with RFC2518. Things I
don't like to hear are:

- it contains the term "binding"

- RFC2518 defines a 1:1 mapping between URL and resource (this is clearly
wrong, because RFC2518 extends HTTP, and there's no such restriction in
HTTP).

Julian

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

Received on Tuesday, 4 March 2003 16:36:23 UTC