RE: bind draft issues

In case there remains any question about whether HTTP supports
multiple URIs being mapped to the same resource, the following quote
appears in section 9.6 of RFC-2616:

"A single resource MAY be identified by many different URIs. For
 example, an article might have a URI for identifying "the current
 version" which is separate from the URI identifying each
 particular version. In this case, a PUT request on a general URI
 might result in several other URIs being defined by the origin
 server."

The binding protocol does two things: 

- it provides terminology for us to unambiguously discuss concepts
that already exist in HTTP (and therefore are inherited by WebDAV).

- it provides a new method to allow a client to explicitly
creating multiple mappings to a resource.

It is important to distinguish the new terminology for existing
concepts (e.g. "bindings") from new functionality (e.g. BIND).

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Tuesday, March 04, 2003 4:36 PM
To: Lisa Dusseault; 'Julian Reschke'; 'Clemm, Geoff'; 'WebDAV'
Subject: 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).

Received on Tuesday, 4 March 2003 16:56:38 UTC