Re: Deleting an activity

Hi Werner,

since the current wording of section 3.13 does not do any harm and there 
is no need to mention explicitly the possibility of rejecting a DELETE 
request on an activity resource, I do not think that this is really an 
issue. Again, a server may fail any request for whatever reason.

Regards,
Manfred

Werner Donné wrote:
> Hi Manfred,
>
> Perhaps the pre-condition in section 3.13 could be replaced with a
> final paragraph in the section saying that the operation may be
> rejected. It is also formulated like that in other areas of the
> specification, such as when the update of some property may be
> rejected. Such a paragraph would in place for section 13.8 too.
>
> Regards,
>
> Werner.
>
> Manfred Baedke wrote:
>   
>> Hi Werner,
>>
>> being a MAY requirement, the precondition definition in section 3.13 is
>> nothing really normative. Maybe its only me, but I find the concept of a
>> precondition containing only MAY requirements rather strange.
>>
>> Regards,
>> Manfred
>>
>> Werner Donné wrote:
>>     
>>> Hi Manfred,
>>>
>>> Shouldn't then a pre-condition be added in section 13.8 of RFC 3253,
>>> analogous to the one in section 3.13?
>>>
>>> Regards,
>>>
>>> Werner.
>>>
>>> Manfred Baedke wrote:
>>>   
>>>       
>>>> Hi Werner,
>>>>
>>>> This is of course allowed, IMHO. More generally, a server is allowed to
>>>> reject the deletion of any resource for whatever reason.
>>>>
>>>> Regards,
>>>> Manfred
>>>>
>>>> Werner Donné wrote:
>>>>     
>>>>         
>>>>> Hi,
>>>>>
>>>>> When an activity is deleted all references to it should be removed.
>>>>> Versions that have the activity in their activity-set, for example,
>>>>> should have their activity-set updated. Versions, which were created
>>>>> on a branch represented by the activity, all of the sudden are not
>>>>> on that branch anymore and in an implicit way. This seems rather
>>>>> strange and dangerous. Would it be allowed to reject the deletion
>>>>> of the activity in this case?
>>>>>
>>>>> Regards,
>>>>>
>>>>> Werner.
>>>>>   
>>>>>       
>>>>>           
>>>>     
>>>>         
>>>   
>>>       
>
>   

Received on Tuesday, 30 May 2006 09:53:19 UTC