Re: new proposed text for locking overview

Of course a lock can be *modelled* as a resource. Of course, 
RFC2518(bis) can explicitly model a lock as a resource.  Of course 
implementations can model a lock as a resource.  Note however we could 
instead choose to model the lock token as a resource if we wanted.

To argue at least as devil's advocate, we can also simply say that a 
lock token is in the format of a URI and stop there.  The original 
RFC2518 text says that a lock token "is represented as" a URI, not that 
it is a URI, although it also says that the URI identifies a lock.

RFC2396 is clear that URIs identify resources, but since then, the 
format defined for URIs in RFC2396 has been used for many other 
identifiers.   It's natural for a well defined format to be used for 
things beyond what it was defined for.  Even HTTP URLs are used for 
things which are not HTTP resources -- for example, when an XML 
namespace begins with the "http" scheme.   When does a new URI indicate 
a new resource?  Does the addition of query parameters to a HTTP URL 
mean that it's now addressing a different resource?  Who cares?

Is an XML namespace a resource?  Each namespace has a URI.  How would 
it help or hinder XML Namespace definition if we were to insist that an 
XML namespace were a resource? Must we insist that every URI identifies 
a resource?  What implications would this have for other specifications 
and their models?  Does the "DAV:" URI point to a DAV resource?  Other 
examples:
  - CAP uses "CAP URLs" without defining calendars as "resources" 
(draft-ietf-calsch-cap-13.txt)
  - XMPP URIs and URLs (there are several kinds) don't worry about 
whether the things identified are strictly resources

Another way to look at this; is there some problem solved by modelling 
a lock as a resource?  I took a look at the proposed text and 
"resource" is only used to refer to a lock in the first paragraph, so I 
don't understand the argument that this makes the text clearer.  That 
argument ought to involve a claim that the original text is unclear in 
some way that matters to interoperability.

My concrete worry is that implementors will feel that there are 
implementation implications resulting from modelling a lock as a 
resource, and make implementation decisions that aren't necessary.  
That was the result of the wording that a MOVE is the "logical 
equivalent of" a COPY followed by a DELETE -- definitional or 
explanatory wording was seen as normative in that case by some 
implementors.  Philosophical, definitional or modeling changes do have 
an effect on implementors behavior.  What effect would you like that to 
be?

Lisa


On Jul 6, 2004, at 4:31 PM, Julian Reschke wrote:

>
> Jason Crawford wrote:
>> I'll try...
>> Because we tend to tend to think of words the way we've used them 
>> even if they technically have a more generic definition.   A lock 
>> seems to not behave like what we typically refer to as a resource.  
>> There doesn't seem to be a lot of overlap in their most important 
>> features and methods.
>
> Well, I'd say they do.
>
> - you can ask the server to create a new lock using LOCK, similar to 
> how servers frequently create new resources upon POST,
> - a lock has a URI,
> - a lock has state,
> - the state is observable indirectly through HTTP methods and last but 
> not least,
> - it's pefectly ok to implement locks as HTTP resources (for instance 
> which would react to DELETE).
>
>> You mentioned that a lock has a URI.   I think of the lock-token 
>> identifying the lock, but the fact that it uses URI-like syntax is 
>> only coincidental to me.
>
> That's fine.
>
>> If a lock is a resource, I'd expect to be able to substitute the word 
>> "resource" for "lock" and have it sound reasonable.  I'm comfortable 
>> saying that a lock acts on a resource, but I'd not be comfortable 
>> saying a  resource acts on a resource.  Similarly... 
>> "depth-resource", "exclusive resource", or "write resource".   I'd 
>> prefer to simply think of resources as something that locks act upon.
>
> If you substitute "lock" by "lock resource" things sound much better. 
> The concept is similar to the version history resource in DeltaV. It's 
> not strictly needed for many things, but making it an HTTP resource 
> gives you a lot of advantages (such as properties you can observe 
> *directly* though PROPFIND instead of indirectly through a specific 
> REPORT).
>
>> For me it feels better not to define a lock at all beyond it's 
>> behavior rather than to say it's a resource.
>
> The desire to define the *state* of a resource (what it must consist 
> of) in a single place IMHO is independant of whether we actually 
> *state* that it *is* a resource.  I just happen to think that things 
> become much clearer by seeing it this way.
>
> So far I've heard a resounding "of course" internally in our office, 
> yours and Elias' feedback. Let's see what others think...
>
> Julian
>
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>

Received on Wednesday, 7 July 2004 15:06:06 UTC