Re: Deleting an activity
Manfred Baedke <[email protected]> Tue, 30 May 2006 11:53:03 +0200
| Newsgroups | gmane.ietf.deltav |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --------------090309090801050804020503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Werner, since the current wording of section 3.13 does not do any harm and there=20 is no need to mention explicitly the possibility of rejecting a DELETE=20 request on an activity resource, I do not think that this is really an=20 issue. Again, a server may fail any request for whatever reason. Regards, Manfred Werner Donn=E9 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: > =20 >> Hi Werner, >> >> being a MAY requirement, the precondition definition in section 3.13 i= s >> 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=E9 wrote: >> =20 >>> 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: >>> =20 >>> =20 >>>> 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=E9 wrote: >>>> =20 >>>> =20 >>>>> 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 create= d >>>>> 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. >>>>> =20 >>>>> =20 >>>>> =20 >>>> =20 >>>> =20 >>> =20 >>> =20 > > =20 --------------090309090801050804020503 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Hi Werner,<br> <br> 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.<br> <br> Regards,<br> Manfred<br> <br> Werner Donné wrote: <blockquote cite="[email protected]" type="cite"> <pre wrap="">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: </pre> <blockquote type="cite"> <pre wrap="">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: </pre> <blockquote type="cite"> <pre wrap="">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: </pre> <blockquote type="cite"> <pre wrap="">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: </pre> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap=""> </pre> </blockquote> <pre wrap=""> </pre> </blockquote> </blockquote> <pre wrap=""><!----> </pre> </blockquote> </body> </html> --------------090309090801050804020503--