RE: MK* and lock-null (was: Re: Deleting versions)

OK, that's enough of a consensus for me (:-).

Unless anyone objects, I will add a sentence to
section 1.8 (Versioning Methods and Locks) explicitly
identifying MKRESOURCE and MKACTIVITY as additional
methods that can be applied to a lock null resource.

Cheers,
Geoff

-----Original Message-----
From: Tim Ellison [mailto:tim@peir.com]
Sent: Thursday, June 07, 2001 7:02 AM
To: DeltaV
Subject: RE: MK* and lock-null (was: Re: Deleting versions)


Greg wrote:

> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Greg Stein
> Sent: 07 June 2001 06:28
> To: DeltaV
> Cc: ejw@cse.ucsc.edu
> Subject: MK* and lock-null (was: Re: Deleting versions)
>
>
> On Wed, Jun 06, 2001 at 12:47:45PM -0400, Clemm, Geoff wrote:
> >...
> > So let's get some feedback from the working group:
> > Who thinks that the ability to apply MKWORKSPACE or MKACTIVITY
> > is a versioning/locking interaction that merits explicit
> > mention in the versioning protocol?  (I think we can take it
> > as given that Lisa thinks "yes" and I think "no").
>
> I think that we should explicitly specify that (contrary to RFC 2518), a
> MKWORKSPACE or MKACTIVITY can be applied to a locknull resource.

Given that DeltaV will be streaking through the standards process faster
than 2518 can get a revision out (:-), I think unfortunately this is
required.

> Since allowing them to apply is contrary to 2518, then we need to
> explicitly mention that fact. If we don't, then readers will
> assume that you cannot use those methods on a lock-null.

Agreed.

> And yes: this should raise an issue for 2518 to loosen that language in
> some way. (cc'ing Jim explicitly to ensure this is captured)

This is the real 'solution'.

Tim

Received on Thursday, 7 June 2001 09:22:45 UTC