Re: new proposed text for locking overview

On Thursday, 07/08/2004 at 08:28 ZE2, Julian Reschke wrote:
> Jason Crawford wrote:
> 
> >  > 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,
> > I don't understand how this is related.  As far as creation, typically
> > to create a resource you do PUT or MKCOL.  And the resource appears at
> > the URL you provide as an argument.   This is not the case for locks.
> 
> That's only "typical" for WebDAV. Outside WebDAV, new resources are
> created as an effect of POST every second (and in this case, it's the
> server that assigns the URL). I'd actually call that the typical case,
> for the simply reason that it happens so often.

We have different experience then.  For me PUT is only second to FTP.  And 
my web tools don't support authoring via POST. 

Besides.... We're working on or extending the WebDAV spec.  It doesn't 
make sense to treat our own spec(s) as exceptional.  We should be self 
consistant.   When we speak of resources, it has meant HTTP resources. 
This is not just coincidental.  The whole of 2518 is dedicated 
to defining these "resources".   To briefly use the term to refer to 
something that doesn't behave like the spec outlines doesn't make sense.

> >  > - a lock has a URI,
> > Are you referring to the lock-token?  It doesn't work the same way 
that
> > URI's for typical resources work.   For typical resources, the URI is 
a
> > URL.  This is not true for locks/locktokens.
> 
> What is a "typical" resource? And why is this relevant unless I say that
> a lock indeed is a "typical" resource?

An HTTP resource.


> As a matter of fact particular instances of WebDAV properties on a
> resource *are* resources on their own. We just don't have a common
> notation for their URLs. For instance we could have defined that the
> DAV:displayname property for a given WebDAV URL http://a/b has the
> following URL:
> 
> http://a/b;displayname
> 
> and then we could have allowed DELETE/PUT/GET on it. Many say that this
> is what WebDAV should have done, because it would have avoided the
> current situation where property values can not be addressed by the
> common WebDAV methods.

Right.  Properties are resources, but we don't call them resources.  That 
was my point.


> OK. Does "urn:ietf:rfc:2518" identify a resource? Does
> "mailto:w3c-dist-auth@w3c.org"? None of them can be addressed using HTTP
> directly. They are still resources, just not HTTP resources.

That's right.   In the context of a spec dedicate to HTTP resources it's 
not useful to call these or LOCKS  resources.  It actually is confusing 
because resources usually refers to HTTP resources.



> Again, unless you define what you understand with "typical" and how this
> is relevant here....

HTTP Resources.    One's that support simple namespace operations like 
GET/PUT/DELETE  or GET/MKCOL/DELETE... and our new operations in the 
binding spec.


> >  > and last but not least,
> >  > - it's pefectly ok to implement locks as HTTP resources (for 
instance
> >  > which would react to DELETE).
> > You can say that for just about anything in this world, but we don't.
> >  When we find reason to standardize what you just mentioned, we then
> > begin to have a reason to call locks resources, but right now they act
> > differently than what we typically think of as resources.  So although
> > they (and just about anything else in this universe) can be called
> > resources, it is not really helpful to do so... and because of the
> > context, it's actually confusing.
> 
> I'd like to understand *why* you find that confusing? Because you
> usually only use the term "resource" when talking about HTTP resources?

Because throughout the spec resources refer to 
HTTP resources.  Now it is being suggested to use the term briefly
for something that doesn't behave like an HTTP resource at all.  It
will draw the wrong picture because all the important operational
behaviors that the spec defines for resources don't apply.



> They technically *are* resources. If you're arguing with that statement,
> you should explain how this is incorrect according to RFC2396 (which is
> the relevant spec here).
> Whether we should *say* that they are resources is a different question.
> We don't need to say it, but my feeling was that it helps understanding
> how they work.
Right.  The disagreement is not whether they are resources are not.  The
rfc you mention clearly allows them and just about anything else in the
world to be a resource. 

The disagreement is over whether we should mention that they are
resources.

Down the road we might want to openly call them resources if we go 
ahead and have the lock-token be a URL that responds to 
GET/DELETE/PROPSTAT methods, but right now calling these things 
resources despite the fact that they don't have the behaviors that
our spec spends so much time defining for resources would be
confusing and not really helpful.