Re: [office] DRM issues

[Michael Brauer - Sun Germany - ham02 - Hamburg <Michael.Brauer@Sun.COM>]

Hi,

I think we are in full agreement that specifying a DRM mechanism itself is 
ouside the scope of the TC, because the use of DRM is neither specific nor 
restricted to office documents.

I also think that a check whether OpenDocument works with a variety of 
possible DRM mechanisms might be useful, but is also outside the scope of the 
TC. To the best of my knowledge, there are no open standards for DRM right 
now. All DRM mechanisms that exist are vendor specific. While an 
interoperability check for an open DRM standards might be within the scope of 
the TC, I think interoperability checks with vendor specific DRM systems 
should be performed by the vendors of that systems, or by vendors that want 
to use a specifc DRM system together with OpenDocument in an application.

The results of such checks of course might be discussed by the TC, and it 
probably would be admissable to have them somewhere at the TC's web pages.

Best regards

Michael



Nathaniel S Borenstein wrote On 11/08/05 15:57,:
> 
> I like this basic approach.  We need to be able to say, definitively, 
> that ODF can work with a variety of possible DRM mechanisms, and outline 
> how it might be done.  That should be enough to prevent DRM from 
> becoming a leading FUD topic for our opponents, as well as to give some 
> guidance to the people who are actually going to try to make this work. 
>  -- Nathaniel
> 
> 
> 
> Patrick Durusau <patrick@durusau.net> wrote on 11/07/2005 01:28:31 PM:
> 
>  > Greetings!
>  >
>  > I think Gary's point about ODF being an open document format is well
>  > taken but do think some nod in the direction of DRM issues might be in
>  > order.
>  >
>  > Afterall, if I want to write an implementation that otherwise uses ODF
>  > and wish to layer a DRM solution on top of it, surely that is a
>  > legitimate use of the work product of this committee.
>  >
>  > Granted, it is possible to encrypt parts of an ODF document along the
>  > lines that is used by Adobe, but that does not address issues such as
>  > copy, print, modify, etc.
>  >
>  > The senario where government agencies will want to regulate access to
>  > certain parts of a document is a very real one in secure environments,
>  > which appear to be on the rise within the US government. I don't know of
>  > any reason why they could not use ODF, provided they layered an
>  > appropriate DRM/security system on top of the format.
>  >
>  > Suggestion: What if the various DRM technologies were reviewed and a
>  > report issued saying that ODF is compatible with DRM technologies that
>  > impose restrictions on addressable portions of a document, plus some
>  > statement about DRM being application specific?
>  >
>  > I would hesitate to go beyond such a report as the entire DRM question,
>  > particularly if it includes secure environments would take us far afield
>  > from what I think most of us would consider to be ODF questions.
>  > Security/DRM questions are very important but also involve
>  > network/application architectures, encryption, security protocols, and a
>  > host of other issues that are really beyond questions of an open
>  > document format.
>  >
>  > For example, in our telephone conference today the question of
>  > concealing an illustration was raised. Yes, most of us think about only
>  > concealing the illustration but there are use cases for concealing the
>  > fact that an illustration ever appeared in the document. Which would
>  > require suppressing appearance of the illustration in an illustration
>  > list, the illustration itself (and the fact it occurred at all), plus
>  > any references to the illustration. That is certainly doable, but not
>  > something I think we want to spend time specifying in an open document
>  > format TC.
>  >
>  > Hope everyone is having a great day!
>  >
>  > Patrick
>  >
>  > PS: I would be willing to volunteer to work with others who are
>  > interested in creating a ODF/DRM report for the TC to approve and issue.
>  >
>  > --
>  > Patrick Durusau
>  > Patrick@Durusau.net
>  > Chair, V1 - Text Processing: Office and Publishing Systems Interface
>  > Co-Editor, ISO 13250, Topic Maps -- Reference Model
>  > Member, Text Encoding Initiative Board of Directors, 2003-2005
>  >
>  > Topic Maps: Human, not artificial, intelligence at work!
>  >
>  >
>  >
>  > ---------------------------------------------------------------------
>  > To unsubscribe from this mail list, you must leave the OASIS TC that
>  > generates this mail.  You may a link to this group and all your TCs 
> in OASIS
>  > at:
>  > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>  >

-- 
Michael Brauer                                Phone:  +49 40 23646 500
Technical Architect Software Engineering      Fax:    +49 40 23646 550
StarOffice Development
Sun Microsystems GmbH
Sachsenfeld 4
D-20097 Hamburg, Germany                e-mail: michael.brauer@sun.com