Re: new proposed text for locking overview

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

<http://greenbytes.de/tech/webdav/rfc3744.html#rfc.section.4.1>

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.  

Thanks.

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

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Thursday, 8 July 2004 13:04:55 UTC