W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2004

Re: new proposed text for locking overview

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 08 Jul 2004 19:04:31 +0200
Message-ID: <40ED7E9F.1060402@gmx.de>
To: Jason Crawford <ccjason@us.ibm.com>
Cc: Julian Reschke <nnjulian.reschke___at___gmx.de@smallcue.com>, WebDAV <nnw3c-dist-auth___at___w3.org@smallcue.com>

Jason Crawford wrote:

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

I'm not talking about authoring. I'm talking about HTML forms that allow 
user input and that perform a POST request that in many cases results in 
a new HTTP resource.

> 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.

I disagree here. When we usually mean "HTTP resource" when we say 
"resource" this is the case because it's clear from the context. There 
are other cases, such as in


Also, as a matter of fact, I *was* careful to say:

"Having a URI (the lock token URI) on it's own, a lock is a resource in 
the sense defined by [RFC2396]. In general, this resource does not have 
a HTTP URL, and thus can not be directly manipulated using HTTP methods."

So I claim there's no risk whatsoever of people misunderstanding this as 
meaning "HTTP resource".

> 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.

No, no. RFC2518 doesn't define resources at all. RFC2518 speaks about 
*HTTP* resources (which are defined in RFC2616), and what it means for a 
HTTP resource to be "WebDAV compliant".

>  > >  > - 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.

OK, and so why is this relevant when I explicitly say that generally 
it's not a HTTP resource?

> ...
>  > 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.

I'd agree if there was any risk of a misunderstanding. Looking at the 
text as proposed, there isn't. It says (a) "in the sense of RFC2396" and 
"generally not an HTTP URL".

 > ...
>  > >  > 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.

See above.

>  > 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.

A server may implement locks as HTTP resources, we don't need to change 
anything in RFC2518 to allow that.

Anyway, it seems that we just have different opinions how easily a 
reader can be confused by the statement in question.


<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Thursday, 8 July 2004 13:04:55 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:30 UTC