Re: new proposed text for locking overview

Lisa Dusseault wrote:

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

According to RFC2396, anything that has a URI is a resource. There's a 
one-to-one relationship between a lock token and the lock. However, the 
lock token *is* the URI, so saying it is a resource doesn't really make 
sense.

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

Anything that is identified by a URI is a resource. This by *by definition*.

RFC2518 says:

"A lock token is a type of state token, represented as a URI, which 
identifies a particular lock."

So we have a URI and an object identified by a URI. It's unclear to me 
why saying that object is a resource would be saying something new...

> 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 

Example, please?

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

A URI always identifies a resource. Whether a "new" URI identifies a 
"new" resource depends on URI scheme, implementation and intent.

> 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 

Yes, because that's what the relevant RFCs say.

> and their models?  Does the "DAV:" URI point to a DAV resource?  Other 
> examples:

Strictly speaking, "DAV:" isn't a URI (as defined by RFC2396). However, 
for instance, "DAV:displayname" is a resource.

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

I don't follow. What do you mean by "not being strictly a resource"? 
What's the definition of that? Do you have another definition for 
URI/resource than the one appearing in RFC2396?

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

I think it helps understanding that a lock is an object that indeed has 
identity, a defined lifetime and observable properties.

> 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 

Under the definition of RFC2396, there's no way to implement a WebDAV 
lock but as a resource. You may want to re-read RFC2396 
(<http://greenbytes.de/tech/webdav/rfc2396.html#rfc.section.1.1.p.3>) or 
RFC2396bis 
(<http://cvs.apache.org/viewcvs.cgi/*checkout*/ietf-uri/rev-2002/rfc2396bis.html#rfc.section.1.1.p.3>) 
to understand why this is correct.

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

The intent is to better explain what a lock indeed *is*.

Could you elaborate in which way people could possibly misunderstand the 
new text?

Julian

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

Received on Wednesday, 7 July 2004 15:35:19 UTC