OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cmis message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Fwd: [cmis-comment] Question on the proposed CMIS Retention/Hold Extension


Hello Stephane,

Welcome to the CMIS TC.
Please use cmis@lists.oasis-open.org for TC discussion, or append retention comments to JIRA #714.
Thanks.

Best Regards,
David

---------- Forwarded message ----------
From: CROISIER Stéphane <S.CROISIER@rsd.com>
Date: 2011/11/25
Subject: [cmis-comment] Question on the proposed CMIS Retention/Hold Extension
To: "cmis-comment@lists.oasis-open.org" <cmis-comment@lists.oasis-open.org>


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
Senior Product Manager

 

RSD SA

Email: s.croisier@rsd.com

Twitter: @scroisier

 




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]