Subject: RE: bind draft issues

From: "Clemm, Geoff" <[email-masked]>
Date: Sat, 1 Mar 2003 09:27:29 -0500

From: Brian Korver [mailto:[email-masked]]

   I like to bring up a couple of issues that I've found
   with the bind draft.  I'll post more comprehensive comments
   on the draft in a subsequent email.

   Define "Resource"

   The term "resource" should be defined in the draft.  I
   imagine the definition is something along the lines of
   "all content and all properties associated with that
   content (including live and dead properties), but which
   does not include properties associated with URIs."

As indicated in section 1.1, the bind draft inherits all
terminology from RFC2518, and therefore this section
only includes definitions that refine or extend those 
from RFC2518 (which in turn inherits definitions from
RFC2616).  The bind draft does not modify the definition
of resource inherited from RFC2518.

   Bindings and Locks

   The relationship between bindings and locks is missing
   from the draft.  I think the behavior of locks and the
   lock methods should be fully specified in this draft.

RFC2518bis is in the process of finalizing the behavior of
locks, and we do not want the bind draft to say anything that
conflicts with this.  Instead, we will make sure that the
locking model in RFC2518bis clearly defines locking behavior
in the presence of multiple bindings.

   URL Properties

   The behavior of other URL properties (in addition to
   locks) should be fully specified, for instance the
   display-name property.

I'm not aware of the binding protocol causing any change
to the behavior of the properties defined by 2518.  Also
note that a resource has properties, not a URL.

   Move and Delete

   The spec states that move and delete are merely operations
   on bindings.  At the very least, this is inconsistent with
   2518,

How is this inconsistent with 2518 (other than the use of
terminology not defined in 2518)?

   but I also think that the draft doesn't adequately
   address any of the issues that come up when the server
   goes to "reclaim system resources."  I would expect most
   servers to reclaim said resources during move and delete.

The protocol explicitly leaves those decisions up to the
server implementation, since different servers have made
(and need to make) different choices wrt how system resources
are reclaimed.  For example, a versioning server will
probably reclaim very few resources, since most of the
resources are being maintained as history.

   Operations not Atomic

   None of the operations specified should be required
   to be atomic.  I'd prefer SHOULD NOT myself.  This is
   especially true for any operation that involves deleting
   collections.

Atomic operations are one of the primary purposes of the
binding protocol.  A server that cannot maintain atomic
MOVE/DELETE/BIND operations is not capable of supporting
the bind protocol.

Cheers,
Geoff

---

From: Brian Korver <[email-masked]>
Date: Mon, 3 Mar 2003 10:57:08 -0800

> in the presence of multiple bindings.

It probably isn't a good idea to introduce a dependency
such as this, especially since 2518bis doesn't have any
notion of bindings.  I don't believe that the binding
document can move forward.

-brian
[email-masked]

---

From: Brian Korver <[email-masked]>
Date: Mon, 3 Mar 2003 11:11:54 -0800

> note that a resource has properties, not a URL.

Geoff,

URLs have properties to.  Think about how DAV:lockdiscovery
works in the face of COPY/MOVE, or DAV:displayname for that
matter.

Regarding this issue, I was not suggesting that the problem
is that the binding protocol changed the behavior of properties,
just that the behavior needs to be fully specified.  Do
you feel that 2518 does fully specify the behavior of
URL properties?

-brian
[email-masked]

---

From: Brian Korver <[email-masked]>
Date: Mon, 3 Mar 2003 11:28:32 -0800

> terminology not defined in 2518)?

2418 correctly states that MOVE (and COPY) also may involve
a DELETE with "Depth: infinity" operation in the case of
overwrite.

DELETE also operates on more than bindings.  Consider,
for instance, what happens to locks.

> resources are being maintained as history.

My reading of the document is different, so the language
should be cleaned up so that it doesn't sound like it is
prohibiting the semantics spelled out in 2518.  Would it
help if I provided that text?

-brian
[email-masked]

---

From: Brian Korver <[email-masked]>
Date: Mon, 3 Mar 2003 11:35:36 -0800

Geoff,

I disagree strongly.  Nothing should be stated to prohibit
atomic operations, but the spec should leave this decision
up to implementors.  There can be perfectly valid reasons
why a server vendor might want to provide normal filesystem
semantics to users.

-brian
[email-masked]

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 3 Mar 2003 23:09:08 +0100

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Brian Korver
> Sent: Monday, March 03, 2003 8:36 PM
> To: WebDAV
> Subject: Re: Operations not Atomic (was: bind draft issues)
>
>
>

Brian,

I can follow for DELETE (see separate mail), but I'm at a loss about how
MOVE and BIND can be non-atomic. Could you please explain?

Julian

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

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 3 Mar 2003 23:13:48 +0100

> Sent: Monday, March 03, 2003 8:12 PM
> To: WebDAV
> Subject: Re: bind draft issues
>
>
>

Brian,

properties are *never* on URLs, they are always on the resource. So if you
have multiple bindings to the same resource, a PROPFIND on each of these
bindings should yield the same results.

So DAV:lockdiscovery and DAV:displayname indeed do *not* depend on the
binding to which the PROPFIND is applied.

> you feel that 2518 does fully specify the behavior of

:-)

If we agree on that there are no "URL properties", there's nothing that
needs to be defined.

Julian

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 3 Mar 2003 23:14:35 +0100

> Sent: Monday, March 03, 2003 7:57 PM
> To: WebDAV
> Subject: Re: Bindings and Locks (was: bind draft issues)
>
>
>

Of course does RFC2518 have a notion of bindings. What it doesn't have is a
method to *create* multiple bindings, and the live properties to inspect
them.

Bindings always have been there implicitly. All the BIND spec adds is the
machinery to create them, and to discover some more information about them.

Julian

---

From: "Lisa Dusseault" <[email-masked]>
Date: Mon, 3 Mar 2003 19:40:14 -0800

> in the presence of multiple bindings.

I don't think that's a reasonable expectation of RFC2518bis.  The
bindings draft has to be clear in how it deals with locks -- RFC2518bis
will not discuss bindings.  

Lisa

---

From: "Lisa Dusseault" <[email-masked]>
Date: Mon, 3 Mar 2003 20:09:20 -0800

> machinery to create them, and to discover some more 

You can say that RFC2518 supports bindings, but only if you cover one
eye when you look at it.  RFC2518 contains definitions for operations
that apply to resources and operations that apply to URLs.  RFC2518 is
in fact very ambiguous on this kind of thing, without a fixed model of
how implementors must represent everything under the covers. A lot of
the text is descriptive. 

For example, the definition of DELETE for a non-collection talks as if
it applies to a binding:

"If the DELETE method is issued to a non-collection resource whose URIs
are an internal member of one or more collections, then during DELETE
processing a server MUST remove any URI for the resource identified by
the Request-URI from collections which contain it as a member."

However, the definition of DELETE for a collection talks as if it
applies to a set of underlying resources:

"DELETE instructs that the collection specified in the Request-URI and
all resources identified by its internal member URIs are to be deleted.
"

Locks apply more to URLs than to resources, yet property operations
apply more to resources than to URLs, and neither locks nor properties
are 100% pure.

Really, what this means is that implementors of several kinds of systems
can support RFC2518 simply by supporting a consistent behavior.  For
example, systems that model URLs as links to underlying resources, as
well as systems that model URLs as properties of resources. There may be
other kinds too.

Lisa

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 4 Mar 2003 09:45:32 +0100

> [mailto:[email-masked]]On Behalf Of Lisa Dusseault
> Sent: Tuesday, March 04, 2003 4:40 AM
> To: '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:

<http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/0064.html>

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 4 Mar 2003 15:55:11 +0100

> From: Lisa Dusseault [mailto:[email-masked]]
> Sent: Tuesday, March 04, 2003 5:09 AM
> To: 'Julian Reschke'; 'Brian Korver'; 'WebDAV'
> Subject: RE: Bindings and Locks (was: bind draft issues)
>
>

RFC2518 extends HTTP, and HTTP allows multiple URLs to be mapped to the same
resource.

> how implementors must represent everything under the covers. A lot of

Well, yes. The RFCs should describe server behaviour, not their internals.

> the text is descriptive.

Correct.

> apply more to resources than to URLs, and neither locks nor properties

Locks apply both to resources and URLs (as clarified by GULP), and always
did.

Property operations *always* apply to resources, and there really is no
exception to that rule.

> well as systems that model URLs as properties of resources. There may be

The URL can only be a property of a resource if the system explicitly
restricts itself to only single bindings. You can't have both multiple
bindings, and also treat the URL as a property of the resource at the same
time.

Julian

---

From: "Lisa Dusseault" <[email-masked]>
Date: Tue, 4 Mar 2003 12:33:29 -0800

> and therefore either should be added to RFC2518bis, or be the 

GULP should not cover bindings.  That's the problem.  It causes a
problem because some RFC2518 servers just don't work that way.  There's
no need to say whether operations apply always to URLs, bindings or
resources in RFC2518, because when you have 1:1 mappings between URLs
and resources it just doesn't matter 95% of the time, and lets
implementations expose their existing repository.

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

Lisa

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 4 Mar 2003 22:35:49 +0100

> Sent: Tuesday, March 04, 2003 9:33 PM
> To: 'Julian Reschke'; 'Clemm, Geoff'; 'WebDAV'

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.

> 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.

> 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

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

---

From: Brian Korver <[email-masked]>
Date: Tue, 4 Mar 2003 17:02:59 -0800

> MOVE and BIND can be non-atomic. Could you please explain?

Julian,

Oops, I typed "BIND" when I meant "COPY".

For MOVE, I mostly mean the DELETE that occurs when the MOVE causes
an overwrite, although I could be convinced that ending up with 2
bindings to the collection in the event of an interrupted MOVE,
while inadvisable, shouldn't be prohibited.

-brian
[email-masked]

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 5 Mar 2003 09:42:23 +0100

> Sent: Wednesday, March 05, 2003 2:03 AM
> To: WebDAV

That's indeed a problem. All "overwrite" operations require a DELETE (this
also applies to BIND (!)), so having them atomic when the target is a
collection has the same problems has the collection DELETE itself.

Julian