[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [cmis] Fwd: [cmis-comment] Question on the proposed CMIS Retention/Hold Extension
Hi Stephane, welcome to the TC from my side as well and thank you for your comments. The Client Managed Retentions allow you to apply a retention type without setting a concrete expiration date. In this case the document cannot be deleted until a concrete date is set. In your scenario the client would just apply a Client Managed Retention Type without a concrete expiration date. As soon as the corresponding event occurs, the client can set the expiration date. Nevertheless, setting a fixed Expiration Date is required for other scenarios which can’t be supported with just setting documents to immutable. The Client Managed Retentions are intended to be used in long term archiving or end-of-live system scenarios. In such scenarios the client must be able to set a concrete expiration date, as the client may not exist anymore at the time the expiration date is reached. Hence the client has to set the retention time in advance. In general the Repository Managed Retentions are more suitable for such “rule based” scenarios, assuming that the repository has means to create such rules. In this case the client would just apply the Repository Managed Retention Type which corresponds to the rule and the repository would manage all the rest. Best regards, Martin From: cmis@lists.oasis-open.org [mailto:cmis@lists.oasis-open.org] On Behalf Of David Choy Hello Stephane, ---------- Forwarded message ---------- Hello, I was going through the new CMIS Retention and Hold Management and have a question about Client Managed Retention: As mentioned on the Repository Managed Retention part or on the JIRA CMIS-714, retention and disposition rules might rapidly become much more complex than just setting a fixed retention/disposition schedule. Rules can be event-based (e.g: “if an employee leaves the company, dispose of his records one year after this event else dispose after 10 yrs” or “keep forever until a certain event occurs”). Such federated RM mechanisms will then be difficult to implement only with the current cmis:rm:expirationDate and cmis:rm:startOfRetention. In the second case scenario the CMIS client will either try to assign a huge retention value to ensure proper long term retention (but will not be able to properly dispose of the content when the event occurs which might then cause some legal risk for the organization) or may see the object deleted because it did not properly set the cmis:rm:expirationDate and another client or the Repository itself will set such an expiration date afterwards. The CMIS client will then try to bypass these obstacles by assigning an Hold on all concerned object to enforce proper immutability. Wouldn’t it be more easy, at least in a first phase, to only implement a “cmis:rm:declareAsRecord” and a “cmis:rm:unDeclareAsRecord” interface (or a “cmis:rm:setImmutability” and a “cmis:rm:releaseImmutability” in order to freeze a given content item and let the client decides when this content item should be released independently of any retention and disposition rule? Best Regards, Stéphane Croisier __________________________________ Stéphane Croisier RSD SA Email: s.croisier@rsd.com Twitter: @scroisier |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]