Re: If: header and "parent" resource checking

   From: jamsden@us.ibm.com

   <geoff>
   The fact that they show up in a PROPFIND does not require that their
   addition and removal from a collection affect the lock state of that
   collection.  I'll appeal again to live properties here.  They are
   properties of a resource, but they can be changed without affecting
   the lock state of the resource.
   </geoff>

   <jra>
   But they're not live properties.

I didn't mean to imply that they were.  I was just using the way we handle
live properties as an analogy.  A live property appears to be part of the
state of a resource, but we allow it to be modified without modifying the
lock state of the resource.  Analogously, I propose that a lock null resource
should appear to be part of the state of a collection, but that we allow
them to be added and deleted without modifying the lock state of the resource.

   <jra>
   For example, lock-null resources can be
   the request-URL of PROPFIND and UNLOCK. The problem is that lock-null
   resources are only lock-null resources: a bunch of special cases that make
   sense when you look at them one way and not form another. I think they were
   a good idea that didn't semantically scale.
   </jra>

I agree that lock-null resources are just a bunch of special cases.
What I'd like to do is minimize their impact on the rest of the
protocol.  One way to do so is to say that only PROPFIND and UNLOCK
have to deal with them as a special case, i.e. all other methods do
not have to treat them as normal resources (in fact, according to
2518, most other methods are not *allowed* to treat them as normal
resources).

This then means that only the implementation of PROPFIND and UNLOCK
needs to treat a name lock as if it were a resource.  All the other
methods do not.  This I believe is the simplest and cleanest way of
handling lock null resources (and is consistent with what 2518
currently says).

Cheers,
Geoff

Received on Tuesday, 30 May 2000 08:45:09 UTC