Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC

From: "Jason Crawford" <[email-masked]>
Date: Mon, 23 Jul 2001 13:12:05 -0400

I'd like to conclude this issue, but I've not heard any anything to suggest
that we have agreement.  Discussion has been light.

Stefan and Lisa, do you have a response to Geoff's response to your
postings?  Has anyone decided they agree with each another position?
Would someone else like to speak up and take/defend a position?

J.

------------------------------------------
Phone: 914-784-7569,   [email-masked]

---

From: "Lisa Dusseault" <[email-masked]>
Date: Mon, 23 Jul 2001 18:42:25 -0700

My sense of the room at the Interop was that clients already relied on the
ability to LOCK resources which don't previously exist, then do PUT.

The only functionality which is under question, IMHO, is:
 - whether clients can do LOCK then MKCOL (or MKACTIVITY, etc)
 - whether the null or empty resource goes away when unlocked

I'm happy with the current behaviour as specified by RFC2518 -- after all,
we implemented it that way.  I'm not totally attached to the ability to turn
a lock-null resource into a collection, or make it disappear when unlocked.

lisa

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jason Crawford
> Sent: Monday, July 23, 2001 10:12 AM
> To: Clemm, Geoff
> Cc: WebDAV
> Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC
>
>
>
>
>

---

From: "Stefan Eissing" <[email-masked]>
Date: Tue, 24 Jul 2001 10:15:48 +0200

> [mailto:[email-masked]]On Behalf Of Lisa Dusseault
>

This summarizes also my ideas. WebDAV should stick to the LOCK behaviour
of null-resources, when followed by a PUT. I think there are no interop
problems when LOCK->MKCOL is discontinued or when the resource, created
by a LOCK on a null-resource, stays after lock timeout.

In fact, changing RFC2518 in this way, will make live for server
implementors much easier and probably result in more compliant
implementations.

//Stefan