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

 


Help: OASIS Mailing Lists Help | MarkMail Help

rights message

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


Subject: Re: [rights] Digital Rights at OASIS?


Dear Members of the Board and Members of the RLTC,

The core facts I presented in my post were:

1. It was represented to the OASIS Board that XrML 2.0 would be 
contributed to OASIS for further work.

2. XrML 2.1 was contributed, which lacks Part IV of XrML 2.0, which has 
the mechanisms necessary along with the core and standard extensions to 
make a working DRM system.

3. A working DRM system will need standards based on or the equivalent 
of, Part IV of XrML 2.0.

To which we can now add:

4. The post by Hari Reddy below does not address #1-3 above.

I asked the OASIS Board to take steps to insure that standards based on 
what is know as Part IV of XrML would be developed at OASIS. Which would 
be consistent with fact #1 above.

FYI: TC conference calls (RLTC or any other) are not the place to argue 
about requests to the OASIS Board and I will be following that rule.

The rest of Hari's post reminds me of the advice an older lawyer gave a 
younger one: "When the law is on your side, pound on the law. When the 
facts are on your side, pound on the facts." To which the young lawyer 
asked: "What do I do when the law and facts are against me?" To which 
the older lawyer replied: "Pound on the table!" Hari's post is just a 
lot of table pounding, "full of sound and fury, signifying nothing."

Patrick



Reddy, Hari wrote:

> Dear Members of the Board and Members of the RLTC:
> I think it is important to clear up the misunderstanding that is 
> demonstrated by this email by Patrick Durusau.
>
> I am disturbed that this was never discussed at any RLTC meeting prior 
> to its presentation as an issue to the Board. This adds little to 
> promote a harmonious and positive TC process.
>
>
> I would like to make a few points:
> 1. After a full discussion, the submission of ContentGuard of XrML 2.1 
> was accepted without dissent at the first meeting of the RLTC on May 
> 21, 2002. Patrick Durusau was not at this meeting and only joined the 
> RLTC on August 6, 2002. I have also had communiqués describing the 
> work of the RLTC to Patrick before he joined the RLTC trying to 
> further illustrate the intent and address any questions. (see mailnote 
> below sent on July 9, 2002)
>
> I have clipped the results here from the May 21st Meeting Minutes ( 
> http://www.oasis-open.org/committees/rights/documents/rltc/minutes/RLTC%20Minutes%2020020521.doc 
> ) for your review:
>
> "Content Guard submitted XrML 2.1 to serves as a starting point for 
> the work of the TC.
>
> Vote was held to accept the submission from ContentGuard:
> 11 Yeas
> 1 Abstention
> 2 Phone votes unknown"
>
> This submission was in complete conformance with the statement of 
> intent to submit XrML to the TC which was made in conjunction with the 
> TC Charter distributed with the announcement of the TC.  As 
> ContentGuard had already developed a more advanced version of the 
> Specification, version 2.1, it made sense to submit that instead.  The 
> RLTC has always made it clear that the intent of this TC was to 
> develop a Core architecture, agnostic to any given domain, based on 
> XrML.  If Version 2.1 had not been developed, ContentGuard would have 
> submitted the Core and Standard Extension of Version 2.0 to the RLTC.  
> ContentGuard had already submitted and pursued further development of 
> the Content Extension within MPEG. 
>
> This was discussed at length during the May 21st face to face meeting. 
> During the meeting, Thomas DeMartini provided a technical review of 
> XrML 2.1. Brad Gandee and others also discussed the important role of 
> the core and standard extension in linking with domain specific 
> standards efforts already proceeding.  There was also other 
> documentation explaining the technology which was provided to the 
> participants and sent to the email list.
>
>
> 2. The statement that the Core and Standard Extension eliminates any 
> significant role for OASIS in the development of meaningful rights 
> language is incorrect. The mission has always been to provide a 
> central Core and Standard Extension such that domains that are have 
> experts in their relative areas build upon this foundation. The intent 
> from the very inception was to have MPEG build upon this foundation. 
> The intent was NEVER to build specific extensions. While this is 
> important work, the RLTC looks to other TCs or organizations to build 
> their respective extensions.
>
> More than just reflecting the intent in the Charter, the RLTC has 
> built an entire organization around this basic principle. For example, 
> the Subcommittee ("SC") structure reflects how this is internalized 
> and worked on by the entire RLTC:
>
> -the Core and Standard Extension Specification SC which is responsible 
> for the development of the Core and Standard Extension
>
> -the Extensions Process and Models SC which is responsible for 
> providing guidelines on the development of extensions.
> -the Governance and Liaison SC which is responsible for developing the 
> governance procedures on managing the core and developing liaisons 
> with standards organizations such as MPEG, TV-Anytime and OASIS Web 
> Services Security.
>
> -the Requirements SC which has been developing requirements for the 
> Core and Standard Extension.
>
> 3. Finally, Patrick's proposal to the Board to force this substantial 
> change to the RLTC Charter seems to be inconsistent with OASIS TC 
> Process which is very clear on that a TC can only clarify its 
> statement of purpose.
>
>
> The concept of having MPEG and other standards bodies develop domain 
> specific extensions based on a Core language, managed by OASIS was 
> clearly articulated and discussed within the TC on May 21, 2002 and 
> many times since then.  Frankly this lack of understanding and 
> acceptance on the part of Patrick Durusau and, possibly others, has 
> been a constant source of tension within the TC and has blocked any 
> substantive progress to delivering to those constituents that would 
> like to build upon the work product of the RLTC. The RLTC is presently 
> without a schedule that would facilitate these linkages. While these 
> other agendas may be interesting, the RLTC was not chartered to 
> address these.
>
>
> If you require any more information, please feel free to contact me.
>
> Regards,
> Hari Reddy
> Chairperson
> Rights Language Technical Committee
>
> Office: 240-694-1246
>
>
> Email sent to Partick Durusau and the digital-copyright list on July 
> 9, 2002
> ------------------------------------------------------------------------------------------------------------------------
>
> Hello Patrick:
> A colleague of mine forwarded to me your email below that was sent to 
> the digital-copyright list regarding the OASIS Rights Language 
> Technical Committee ("RLTC") request for DRM Requirements. I am the 
> Chairperson of this committee and would like to take the opportunity 
> to respond.
>
> For a long time, we have recognized that a Digital Rights standard 
> must enable the wide variety of uses of digital rights management, 
> only one of which is the sale of media and entertainment content to 
> consumers. The standard must also respect all of the entities within 
> the workflows. This is central to our charter ( 
> http://www.oasis-open.org/committees/rights/#charter ).
>
> Accordingly, we agree with your view that a DRM standard should not 
> attempt a one size fits all solution. The basis of the RLTC work stems 
> from many years of research and development resulting from numerous 
> engagements with communities and standards bodies. With regards to the 
> technology, the domain agnostic architecture of the RLTC work supports 
> a wide array of uses of digital rights management including fair use. 
> Through the development of extensions, various communities can also 
> build upon the work to extend functionality further. We also have one 
> Subcommittee that is developing models on how to do this easily to 
> facilitate adoption across many different domains. This extensibility 
> is fundamental to the architecture and to the mission of the RLTC.
>
> Although the RLTC did not initially receive members from the classical 
> academic community during our open call for participation, this does 
> not imply at all that we intend to ignore its needs. On the contrary, 
> the charter specifically includes the need to solicit requirements 
> from "user communities" which includes academia. In fact, a number of 
> us came from the academic community. To support the RLTC charter, we 
> have identified certain communities and organizations and have 
> assigned RLTC representatives to each to act as the initial conduit 
> for requirements. Robin Cover has volunteered to collect some of these 
> requirements from the academic community. I invite input to be sent to 
> Robin (robin@isogen.com) who will present the material to the 
> Requirements Subcommittee.
>
> The RLTC also invites liaisons with various academic organizations to 
> develop a closer relationship with our work. I would also like to 
> invite individuals to join the RLTC. Per OASIS guidelines, all 
> technical committee members need to be OASIS members. There are many 
> ways that one may become an OASIS member (< 
> http://www.oasis-open.org/join/ >) including joining as an Individual 
> which is relatively inexpensive (250 USD/year). I also invite people 
> to review our work going forward by going to the RLTC Website (< 
> http://www.oasis-open.org/committees/rights/ >). OASIS is an open 
> standards process in that all of the work is open for public review.
>
> Finally, let me emphasize that this is not a one-time opportunity to 
> determine academic requirements. As noted above, since the 
> architecture supports the development of future extensions and 
> profiles, the needs of academia (or for that matter, any other 
> community) can be accommodated either today or at anytime in the 
> future. This approach has the benefit of enabling efficient 
> specification development today for areas that have defined 
> requirements, without stranding future needs.
>
> On behalf of the RLTC, I look forward to your input and support. If 
> you have any questions with regards to the RLTC, please feel free to 
> contact me.
>
> Regards,
> Hari Reddy
> Chairperson
> OASIS Rights Language Technical Committee
>
> ------------------------------------------------------------------------------------------------------------------------
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> -----Original Message-----
> From: Patrick Durusau [ mailto:pdurusau@emory.edu ]
> Sent: Sunday, October 20, 2002 7:12 PM
> To: edward.cobb@oasis-open.org; colin.evans@oasis-open.org;
> patrick.gannon@oasis-open.org; jim.hughes@oasis-open.org;
> chris.kurt@oasis-open.org; simon.nicholson@oasis-open.org;
> laura.walker@oasis-open.org; michael.weiner@oasis-open.org;
> karl.best@oasis-open.org
> Cc: ecobb@bea.com; colin.evans@intel.com; jim_hughes@hp.com;
> ckurt@microsoft.com; simon.nicholson@eng.sun.com;
> laurawalker@laurawalker.com; mweiner@us.ibm.com;
> rights@lists.oasis-open.org
> Subject: [rights] Digital Rights at OASIS?
>
>
> To:
>
> Edward Cobb (edward.cobb@oasis-open.org, cc: ecobb@bea.com)
> Colin Evans (colin.evans@oasis-open.org, cc: colin.evans@intel.com)
> Patrick J. Gannon (patrick.gannon@oasis-open.org)
> Jim Hughes (jim.hughes@oasis-open.org, cc: jim_hughes@hp.com),
> Christopher Kurt (chris.kurt@oasis-open.org, cc: ckurt@microsoft.com)
> Simon Nicholson (simon.nicholson@oasis-open.org, cc:
> simon.nicholson@eng.sun.com)
> Laura Walker (laura.walker@oasis-open.org, cc: 
> laurawalker@laurawalker.com)
> Michael Weiner (michael.weiner@oasis-open.org, cc: mweiner@us.ibm.com)
> Karl Best, Director Technical Operations (karl.best@oasis-open.org)
> cc: Rights TC (rights@oasis-open.org)
>
> Dear OASIS Board Members and Karl Best,
>  
> The Society of Biblical Literature (SBL) joined OASIS to participate in
> standards efforts on behalf of its members (primarily academics).
> Academic interests are sometimes not represented in standards efforts
> and we saw OASIS as a place where application standards, which have
> immediate impact on our members, would be likely to develop.
>
> The area of digital rights concerns the SBL and its members, since all
> have the dual roles of producers and consumers of digital resources. We
> joined the Rights TC with the expectation that the Rights TC and OASIS
> more generally, would be locus of an effort to define useful standards
> for digital rights.
>
> As a partial result of very productive email exchanges with Thomas
> Demartini (also a member of the Rights TC), there has been a move to
> more precisely define the scope of issues to be addressed by the TC. It
> appears that the TC is now considering that it will deal with a core
> permission expressions language, plus standard extensions and has no
> intent to address the broader issue of digital rights.
>
> As a member of OASIS but one without unlimited funds for standards
> participation, the SBL finds the limiting of the role of OASIS in the
> development of a digital rights standards more than a little disturbing.
> Not only does it diminish the role of OASIS to providing a permissions
> component on which other organizations can develop standards, but it
> increases the expense of effective participation in development of
> digital rights standards elsewhere by members of OASIS.
>
> It is significant to note that the Rights TC was originally formed on
> the basis of an agreement that ContentGuard would contribute XrML 2.0 to
> OASIS for development of a digital rights standard.
> http://lists.oasis-open.org/archives/tc-announce/200203/msg00001.html (A
> message from Karl Best representing that the TC had been approved by the
> OASIS Board.)
>
> Despite the OASIS board approving formation of the TC on the
> representation that XrML 2.0 would be submitted by ContentGuard, in
> fact, XrML 2.1, was submitted and accepted without review at the first
> meeting of the TC. XrML 2.1 appeared at the first TC meeting, and
> reports from the attendees differ on what was represented about the
> content of XrML 2.1. The record of the meeting does not reflect any
> notice to the attendees that a portion of XrML 2.0, the portion
> essential for any XrML application had been removed.
>
> However, it is not necessary for the OASIS Board to address who said
> what to who, etc., and similar disputes relying on personal accounts.
> The document record is clear that it was represented to the OASIS Board
> that XrML 2.0, which could be the basis for a set of meaningful digital
> rights standards, was offered as the basis for the OASIS Board approving
> the formation of this TC. What attendees of the TC did or did not know
> or accept at the first meeting is largely irrelevant since what offered
> to the OASIS Board as the basis for formation of this TC in fact has not
> been tendered by ContentGuard.
>
> A comparison of XrML 2.0 as promised with XrML 2.1 as submitted
> demonstrates how the submission eliminates any significant role for
> OASIS in the development of a meaningful rights language. The TC was
> established with the rationale that XrML would be handed over to OASIS
> "for long-term development and governance of the rights language"
> http://www.contentguard.com/press_040302.asp
> http://www.xrml.org/press_040302.asp The central concern of the SBL is
> that the actual submission by ContentGuard, contrary to prior
> representations for the formation of the TC, deprives OASIS of any
> meaningful role in the development of a digital rights language.
>
> You will note that the critical Part IV Content Extension Schema was
> removed from XrML 2.0 in when XrML 2.1 was presented to Rights TC at its
> first meeting. That removal effectively prevents OASIS from having a
> principal role in the development of the most important aspect of
> digital rights, that is the development of standards for digital rights
> in applications.(Part IV was as well-developed as any other part of XrML
> 2.0 so I see no technical reason for its omission.) There are serious
> disagreements within the TC which are the direct result of the removal
> of Part IV, which defines key functions like "copy, loan, read, write,
> backup, etc."
>
> Not wanting to point out a problem without suggesting a solution, I
> would propose the following:
>
> 1. That the OASIS Board call upon ContentGuard to honor its original
> committment to contribute XrML 2.0 to OASIS.
>
> 2. That the OASIS Board approve re-formulation of the charter of the
> Rights TC to properly focus its work on the permissions language portion
> of XrML 2.0.
>
> 3. That the OASIS Board give public notice that it is seeking proposals
> to form new TC's to address domain specific standards based on the
> Content Extension Schema of XrML 2.0.
>
> I would note that such steps would put OASIS at the center of
> development of digital rights standards and could well attract industry
> participants who would otherwise not seek OASIS membership. In the
> interest of full disclosure, such steps would also make it easier for
> the SBL to participate in such standards and enhance the value of its
> OASIS membership.
>
> I can be reached most easily by email: pdurusau@emory.edu or by phone:
> 404-727-2337 if I can contribute to your resolution of this request.
>
> Aside to Karl Best: Please acknowledge receipt of this request and its
> submission to the OASIS Board. I am unaware of the proper procedure for
> direct submission of requests to the OASIS Board so I have addressed
> this message to all the board members. If there is some other procedure
> that I should follow with this request, please advise and I will resubmit.
>
> Patrick
>
> (Due to the vagaries of email service experienced by TC members I have
> taken the liberty of addressing this post to the OASIS email addresses
> for members of the OASIS Board and their more customary email addresses.
> So that other members of the Rights TC will be aware of this request, I
> have also posted it to the main Rights TC mailing list.)
>
> -- 
> Patrick Durusau
> Director of Research and Development
> Society of Biblical Literature
> pdurusau@emory.edu
>
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: < http://lists.oasis-open.org/ob/adm.pl >
>

-- 
Patrick Durusau
Director of Research and Development
Society of Biblical Literature
pdurusau@emory.edu





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


Powered by eList eXpress LLC