Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC

From: "Clemm, Geoff" <[email-masked]>
Date: Wed, 1 Aug 2001 23:48:36 -0400

I strongly support all of Ilya's and Allan's points.

Remember that the point of the current process is to address any
issues that have arisen during the implementation of 2518, and
a feature that has negligible value and has demonstrated
implementation and interoperability problems is a prime
candidate for revision or removal.

Cheers,
Geoff

-----Original Message-----
From: Ilya Kirnos [mailto:[email-masked]]
Sent: Wednesday, August 01, 2001 10:53 PM
To: Hall, Shaun
Cc: [email-masked]
Subject: Re: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC

>
> I don't think LNRs should be changed at all.
>
> You could use a file to track the lock if you wish and you won't be
> deviating from the RFC.
>
> The RFC doesn't place restrictions on implementation (in this case LNRs) -
> you can basically use whatever you want, so why are you suggesting that
the
> semantics should be changed ?
>
> Its an implementation problem, not a protocol problem.
>

As I recall, there are some restrictions on the behavior of a lock-null
resource that make it difficult to track with an honest-to-goodness file.
For
example:

As I recall an LNR is supposed to show up as a member of its parent
collection,
but return 404 when you try to do a GET on it.  This means you have to keep
some metadata about that file to know that it's 'special'.  You can keep it
in
the DAV server, but nobody else would know or care about it, so even another
DAV server (forget other protocols) working against the same filesystem
wouldn't know about the 'specialness'.  Why would you want to limit DAV
locking
in this way if you have a filesystem that supports locking natively, for
example?

I think there were other examples as well.  Generally, IMHO, LNRs have
unusual
behavior, and perhaps we can solve the problems LNRs are intended to solve
and
make them a little easier to implement on many existing systems.

Like I said, I'd be up for keeping LNRs if things like this were amended.  I
know these are all implementation details, but if the implementation becomes
one hack after another, as I think LNRs would have to be as currently
defined,
maybe it's time to step back and revisit the spec.

-ilya

From:	Alan Kent [[email-masked]]
Sent:	Wednesday, August 01, 2001 8:14 PM
To:	[email-masked]
Subject:	Re: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC

I am discussing only for the sake of discussing - not because I actually
have a strong opinion on this.

On Wed, Aug 01, 2001 at 10:30:22AM +0100, Hall, Shaun wrote:
> I think you are taking WebDAV out of its intended context (see below).

I would be interested to know what the intended context for other WebDAV
implementors are.

> You don't need race conditions because your WebDAV layer in the above
> example can be circumvented full stop. For example, there's nothing to
stop
> another non-WebDAV application creating a directory with the same name as
> the LNR even though your WebDAV server has created a LNR.

If the LOCK requests are passed down to the underlying system and
supported by the underlying system, then it *is* possible to stop
another non-WebDAV application doing things. My understanding is
this is exactly (one of) the reasons why it was being proposed that
LNR be changed. For example, I thought it would be a real issue with
Oracle iFS. I might have misunderstood.

I agree that not all possible implementations of the underlying system
will be able to support WebDAV. But if (for example) a LNR request
did create a file and lock it in the underlying file system, then
other applications *would* be stopped from creating a directory with
that name concurrently. This is the whole point.

> Unless the heart of your "back end" (in this case a OS's file system)
> supports WebDAV, its going to be a "best effort" approach.

I agree with this. The question is it worth changing WebDAV to use
a model closer to what the majority of file systems do support, to
allow more implementations do locking properly (that is, at the file
system level, not the WebDAV level). In other words, is it worth
minimizing the impedience between protocols/systems?

> > (2) Locking is only to protect against other WebDAV clients and not
> >     against anything else

> Actually 2) is correct as well:

I agree - this is a valid position to take (which is why I included it).
I *personally* dislike it, but it is a completely valid position to take.

> Remember that WebDAV is a set of extensions to HTTP, which suffers similar
> problems. WebDAV is about WWW functionality, not a "be all and end all"
> access mechanism for everything - see section 1 of RFC 2518, read RFC
2291.
> This is what I mean when I say you've taken WebDAV out of intended
context.

I think this weakens WebDAV when there is no real reason to weaken it.

> Your example of other applications accessing your Web/WebDAV Server's data
> area is not WWW functionality and therefore WebDAV does not apply IMHO.
> People have to live with it.

Philosophically I think we disagree here. I am interested in WebDAV as
a means to maximize integration of systems. To maximize integration it
is common to have to support multiple protocols accessing the same
information. I think Oracle iFS is a good example of this need in real
life. I think Microsoft users using Web Folders want WebDAV to act as
much like other file systems as possible and integrate with them as
safely as possible.

> Is WebDAV going to stop admins/root formatting
> the hard disk which contains the data ?

Yes. If a lock is held in the underlying file system, it cannot be
unmounted (for UNIX anyway), and so cannot be reformatted. You would
have to shut down the machine to circumvent this.

> In your file system example, there is nothing to stop another application
> deleting a file (that is not a LNR) that your WebDAV Server has locked.

There is *if* the LOCK is mapped down to something the underlying file
system can understand.

> Therefore the locking mechanism has failed.

If this is truely the case, I would almost consider arguing that locking
serves

> What mechanism can you invent
> that would solve all these multiple protocol problems?

If (and it is *if*) all the protocols can map locking requests down to
the base level, then there is no problem. In terms of WebDAV my question
is "should WebDAV be changed to be a better protocol citizen to make it
easier to share an underlying file system with other protocols". No,
there is no guarantee. But using more standard semantics would make it
much more likely.

> In the real world, the end users system in question should be configured
so
> only HTTP/WebDAV clients can access the data area that the WebDAV Server
> interacts with.

I would be interested in other implementors feeling on this one.
Its certainly not true for our system. Its certainly not true
for Oracle iFS. I am pretty sure its not true for Apache mod_dav
(its not unreasonable for web site administrators to go to the file
system directly). I suspect the same holds for IIS.

I have probably said enough on this topic. I am interested in the outcome
because it makes a difference to our locking implementation. I am not
really stressed which way it goes. I agree that changing the LNR
semantics will not solve *all* problems. But I dont think this alone
is a reason not to try to reduce implementation/compatibility problems
when used in systems with other protocols/systems etc.

Alan

---

From: Alan Kent <[email-masked]>
Date: Thu, 2 Aug 2001 16:27:01 +1000

Here is a proposal I think someone else posted a while back.

- LOCK on existing resource stays as is

- LOCK on unmapped URI should (must? can?) create a non-collection resource

- UNLOCK on the same URI without a PUT should (can?) delete the resource

- MKCOL on a LOCKed unmapped URI will fail (pity, but too bad).

This allows implementations to create a file in the underlying file
system if they want to.

In order to completely remove the concept of LNR, PROPFIND must be
cleaned up too. Here are some alternatives:

(1) I would say a LOCK on a unmapped URI MUST create a resource and lock it.
    That way it will appear in PROPFIND's. A PUT on the resource would then
    say 200, not 201.

(2) If a LOCK creates a temporary file, PROPFIND returns it. If a LOCK does
    not create a temporary file, PROPFIND does not return it.

(3) Keep more of the current semantics. PROPFIND returns info about LNR
    resources.  If your implementation creates a temporary file, then your
    implementation does not have to worry about LNR (but it stays in
    the standard as a concept).

I was actually going to propose a new optional flag to say for locks
that the intent is to create a non-collection resource or a collection
resource (where non-collection is the default for backwards
compatibility). The idea is in order to be able to create a temporary
placeholder resource in the underlying file system, get the client to
say in advance whether it is going to PUT or MKCOL. Have a default
value of PUT means MS Word will probably be conformant as is (or pretty
close) for example.

The problem with this however was a sequence of LOCK /a, MKCOL /a
would probably have troubles (MKCOL would not like the fact that
/a already existed). The implementation would have to remember that
the collection created was temporary (which is probably fine actually)
so the MKCOL just clears the 'temporary' status of it.

Another variation (which could always be added later) is to add new
variations of LOCK which has an additional mode/flag/header field to
'create collection resource' and 'create non-collection resource' so
you can create and lock in an atomic operation.

One question then. If LOCK on an unmapped URI creates a resource,
should the resource be marked with a WebDAV property of being 'temporary'.
That way a PUT or MKCOL on an existing resource marked as 'temporary'
could behave as if the resource did not exist before (and return 201).
The implementation however would simply clear the 'temporary' flag.
A PROPFIND on the resource would also clearly identify it as being
temporary.

There are lots of variations possible. One could even go full circle
and say "well, temporary resources are really just LNR's". The only
difference is that LOCK on a unmapped URL should be able to determine
in advance if its going to be a non-collection or collection resource.
That way an implementation can send things down to the lower level
file system if needed. (ie, it can create a temporary file or directory
which other applications see as a file or directory - not as a LNR).

Also in the new proposal, an UNLOCK does not have to remove the LNR
(it should, but its not mandatory). To be clean, I would say it really
should be a MUST not a SHOULD, but some existing implementations don't
do it correctly. I guess backwards compatibility with currently
implementaions is not a requirement.

Oh dear, I seem to be arguing against myself. In this last bit I guess
I am really saying maybe the problem with LNR's is that they dont have
a resource type (collection/non-collection) when they are created.
If they did have a resource type, then they could be immediately
created as such a resource in the underlying file system. The WebDAV
layer could remember that they are 'temporary' (LNR) resources and
so remove them later, or make PUT on them return 201 etc.

Alan

---

From: "Stefan Eissing" <[email-masked]>
Date: Thu, 2 Aug 2001 10:18:22 +0200

> [mailto:[email-masked]]On Behalf Of Alan Kent
>

> - LOCK on unmapped URI should (must? can?) create a

MUST if the namespace is kept consistent.

> - UNLOCK on the same URI without a PUT should (can?) delete the resource

Same holds true for LOCK timeout. should or can is the question.

>     That way it will appear in PROPFIND's. A PUT on the resource

That's what I would expect.

>     the standard as a concept).

That makes life of clients unnecessary difficult.

> [removed neuronal interference patterns]

The question is what to do with such resources when they are unlocked
or the lock times out. Possibilities:

1. If the resource disappears, WebDAV still has the concepts of LNRs and
servers have to track resources created by a LOCK.

2. If the resource stays as an empty file, the concept of LNRs can be
removed
completely from the spec. Additionally, servers would have no need to
track resources created by LOCK.

I favour the second approach. It gives most bang for less bugs.

//Stefan