RE: DAV:modificationdate (was bindings-last-modified (was RE: DAV :getlastmodified of collections))

I've only seen a couple people express interest in this new proposed
property.  
I'd like to know more to see a clear consensus:
 - Should we add this property, yea or nay
 - Should it be protected or writable (a writable last modified value would
be very useful to 
clients doing backups or migrations)
 - Who will implement it, if it is added to 2518bis (ie within a year or two
of its addition)
 
Lisa

-----Original Message-----
From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] On
Behalf Of Nevermann, Dr., Peter
Sent: Monday, September 08, 2003 8:44 AM
To: 'w3c-dist-auth@w3c.org'
Subject: RE: DAV:modificationdate (was bindings-last-modified (was RE: DAV
:getlastmodified of collections))



I would prefer a more general new property, e.g. DAV:modificationdate as
proposed by Julian some days ago in another thread (I added a few words
about *bindings* of a collection to Julian's wording): 

    "A proper way to address this may be to define a new optional property 
    (if we make it optional, we may be able to get it into RFC52518bis), 
    for instance: 

    Name:        modificationdate 
    Namespace:   DAV: 
    Purpose:     Records the time and date the resource was modified. 
    Value:       date-time   
    Description: The creationdate property should be defined on all DAV 
            compliant resources.  If present, it contains a timestamp 
            of the moment when the resource was last modified (i.e., the 
            moment when content and/or properties last changed, 
            or, when the bindings of a collection last changed). 
            This property is live and protected. The Internet date-time 
            format is defined in [RFC3339], see the ABNF in section 5.6. 
    COPY/MOVE behavior: This property value SHOULD be kept during a 
            MOVE operation, but is re-initialized when a resource is 
            created with a COPY. It should not be set in a remote COPY. 
    
    <!ELEMENT modificationdate (#PCDATA) >" 

Probably, w.r.t. properties, we need to clarify whether: 
1) changes to *all* properties ought to be taken into account for setting
the modification date, 
or only 
2) changes to the *dead* properties plus some selected live properties (e.g.
non-protected properties). 

I would go for 2). 

Regards, 
Peter 

> -----Original Message----- 
> From: Geoffrey M Clemm [mailto:geoffrey.clemm@us.ibm.com] 
> Sent: Monday, September 08, 2003 17:19 
> To: w3c-dist-auth@w3c.org 
> Subject: DAV:bindings-last-modified (was RE: DAV:getlastmodified of 
> collections) 
> 
> 
> 
> I believe that we have concluded that DAV:getlastmodified depends on 
> what the server returns on a GET on a collection, and therefore is not 
> something we can define (since what the server returns on a GET on a 
> collection is not defined).  So what we are really talking about in 
> this thread is a new property (which without much thought, I've named 
> DAV:bindings-last-modified). 
> 
> This raises the key question: what will the client be using this new 
> property for.  I suggest it be used to keep the structure of a client 
> tree display synchronized with the names and resources on the server, 
> in which case the client doesn't care whether the version-controlled 
> state changes, as long as the named tree of resources is still valid. 
> 
> Cheers, 
> Geoff 
> 
> > > "Julian Reschke" <julian.reschke@gmx.de> wrote on 
> 09/05/2003 06:08:11 
> PM: 
> > > > But then we're missing the case of VERSION-CONTROL on a 
> versionable 
> but not 
> > > > yet version-controlled resource that lives inside a versioned 
> collection (in 
> > > > which case I'd say the state of the parent collection *does* 
> change). 
> 
> > > Geoffrey M Clemm 
> > > I suggest we keep the semantics very simple, and say that 
> DAV:getlastmodified 
> > > is changed only by adding a binding, removing a binding, 
> or changing a 
> binding 
> > > to new resource.  Putting an existing resource under 
> version control 
> does 
> > > none of these things, so it should not result in an update to 
> > > DAV:getlastmodified. 
> > > 
> > > Note that in general the "version-controlled state" of a 
> collection 
> will be 
> > > different from the "state" of a collection, i.e. adding 
> and removing a 
> binding 
> > > to a non-version-controlled resource does not change the 
> version-controlled 
> > > state of a collection, but does change the state of the 
> collection. 
>  
> "Julian Reschke" <julian.reschke@gmx.de> wrote on 09/08/2003 
> 09:45:20 AM: 
> > This seems to imply that the version-controlled state is 
> not a subset of 
> the 
> > state, or more precisely, that you can modify the 
> version-controlled 
> state 
> > without changing the state. This IMHO seems to be a weird 
> way to define 
> the 
> > state of a collection. 
> 
>