Subject: Re: new proposed text for locking overview

From: Elias Sinderson <[email-masked]>
Date: Tue, 06 Jul 2004 13:21:26 -0700

>  Jason Crawford:
>
>> ...  I don't like us calling a lock a resource.
>
Julian Reshke:

> I expected pushback on that wording; but I think it really makes 
> things clearer. Anything that has a URI *is* a resource (as per 
> RFC2396 definition). Saying that it is a resource with internal state 
> makes talking about it a lot simpler. So can you explain *why* you 
> don't like that terminology? 

Elias Sinderson:

Initially I also had a negative reaction to calling a lock a resource, 
since I generally use that word to refer to something that one can GET, 
PUT, PROPPATCH, etc. However, after reviewing RFC2396 to refresh my 
conceptual understanding of URIs vs. URLs, I have less of a reservation 
on using the term as Julian has for locks. A significant turning point 
in my feeling on this was in reading the explicitly referenced 
definition of a resource in section 1.1 of RFC2396:

      Resource
         A resource can be anything that has identity.  Familiar
         examples include an electronic document, an image, a service
         (e.g., "today's weather report for Los Angeles"), and a
         collection of other resources.  Not all resources are network
         "retrievable" [...]

In short, while my initial reaction was on par with Jasons', I'm okay 
with the wording - especially since it seems to make things clearer and 
a clearer specification will only lead to better implementations in the 
long run (even if the implementors have to reference RFC2396 themselves)...

Cheers,
Elias

---

From: Geoffrey M Clemm <[email-masked]>
Date: Thu, 8 Jul 2004 00:29:41 +0200

I agree with Elias (and Julian).  In particular, I agree
that Julian's usage of the term resource exactly follows the
definition and recommended usage in RFC 2396. 

In general, I strongly support the proposed text for the locking
overview as it is currently written (it is a very significant
improvement over what appears in 2518 or 2518bis).

Cheers,
Geoff