RE: bind draft issues

   From: Brian Korver [mailto:briank@xythos.com]

   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

Received on Saturday, 1 March 2003 09:28:01 UTC