Re: Question on property behaviour descriptions in RFC2518bis

Hi Manfred,

I agree that the statement is not needed. Perhaps it stems from
what is written in section 8.8.2 about live properties.

Regards,

Werner.

Manfred Baedke wrote:
> 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
> 

-- 
Werner Donné  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: werner.donne@re.be

Received on Wednesday, 30 August 2006 17:09:00 UTC