Re: Question on property behaviour descriptions in RFC2518bis

Hi Werner,

Werner Donné wrote:
> Hi Julian,
>
> Julian Reschke wrote:
>   
>> Hi,
>>
>> as a follow up to BugZilla issue 247
>> (http://ietf.osafoundation.org:8080/bugzilla/show_bug.cgi?id=247>) which
>> I opened a few days ago (but which was originally raised during Last
>> Call) I'm currently confused by statements like:
>>
>>    COPY/MOVE behaviour:  This property value SHOULD be kept during a
>>       MOVE operation, but is normally re-initialized when a resource is
>>       created with a COPY.  It should not be set in a COPY.
>>
>> (see
>> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-15.html#rfc.section.15.1>).
>>
>>
>> Questions:
>>
>> 1) When a resource is being created, shouldn't DAV:creationdate *always*
>> be set (by definition?)
>>     
>
> My understanding of this is that the property is indeed set when a new
> resource is created during a COPY.
>
>   
Yes, but as Julian pointed out, there is nothing special about a 
resource created by a COPY (compared to resources created by any other 
method). So what is the statement good for?

>> 2) What does "should not be set in a COPY" mean? What does "in a COPY"
>> refer to?
>>     
>
> I think this refers to the case when an existing resource is overwritten.
> The creationdate shouldn't be updated because the resource is merely
> being updated. The getlastmodified property on the other hand would be
> set, but to the value corresponding to the time of the COPY operation.
>
>   
It is indeed possible that this meaning is intended. If so, one should 
at least change the wording in a way that this meaning is clear, but I'd 
prefer to remove the statement. Either a resource is created during the 
COPY or not, and this property behaves accordingly. I think this is 
pretty clear.

>> There are similar problems with other COPY/MOVE behaviour statements,
>> but maybe we can focus on this one first...
>>
>> Best regards, Julian
>>
>>
>>
>>     
>
> Best regards,
>
> Werner.
>   

Regards,
Manfred