MHonArc v2.5.0b2 -->
office message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [office] DRM issues
I agree completely. This is a
FUD-fighting issue, and I don't think we need to change anything in the
spec. However, a statement from this TC that explains how ODF and
DRM would be expected to interoperate would probably be helpful to the
folks fighting the political battles. With luck, it won't be a huge
effort to produce such a statement. -- Nathaniel
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]