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

 


Help: OASIS Mailing Lists Help | MarkMail Help

rights-requirements message

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


Subject: RE: [rights-requirements] General permissions expressions in XrML


I agree that the expressiveness of XrML is being mixed with issues related to architecting trust-based systems. I also wonder about arguments which dismiss something by subjectively declaring it a "market failure" or "absurd".
 
However, it was a different observation that really struck me about the example that Aaron provided. It seems to me that the only solution that will be found satisfactory in this argument about sound recording is the one where A is free to "self-issue" any rights to him/herself without any restrictions. B can't be trusted. The Government (or any other third party) can't be trusted due to "burdens of cost, delay and loss of privacy on A". The notion that some set of obligatory "fair" permissions can be enclosed with the content (and other permissions - going beyond typical use - can be requested from B, the Government or a 3rd party) is dismissed as "absurd".
 
Correct me if I am wrong but the only logical conclusion that I can come up with by following Aaron's argument is that only the solution where A is fully trusted to do whatever A chooses and B and 3rd parties can't restrict use of content (and must pursue other means against "unfair uses") will be found satisfactory. I think that in the age of electronic content with perfect, unlimited, low-cost duplication and distribution available to everyone such a solution is - to quote Aaron - "both politically and practically untenable".
 
Moreover, while we do want to make sure that practical DRM-based systems can be designed using the Rights Language from RLTC, the goal of RLTC is not to actually design and standardize such systems. That would represent much much greater scope than the rights language. Most practical designs involve compromises. Such approaches were in principal suggested on this reflector - where a set of basic user rights (or permissions, whatever term is preferable) for a given industry context are mandated and probably will automatically satisfy 99% of the cases, while the 1% of the cases where a different "fair use" set is required can be addressed via a trusted 3rd party, role-based permissions, etc. If there exists a fair set of permissions for reasonable and customary usage, the burden of getting permissions for doing things outside of that set does not seem to be that unreasonable and the cost of such a system seems reasonable as well because the vast majority of uses are automated.
 
There are certainly interesting and debatable issues on what are reasonable "fair use" sets of rights in different countries, industries and for different roles of the participants. But the role of XrML (or any rights language for that matter) is to provide a mechanism for expressing these rights, not to mandate a particular architectural solution inherent in the language structure.
 
Dmitry Radbel
Universal Music Group

-----Original Message-----
From: Bob Atkinson [mailto:bobatk@Exchange.Microsoft.com]
Sent: Wednesday, October 16, 2002 8:25 AM
To: burstein@boalthall.berkeley.edu; rights-requirements@lists.oasis-open.org
Cc: drowan@boalthall.berkeley.edu
Subject: RE: [rights-requirements] General permissions expressions in XrML



Hmmm.

 

One question was asked, but a rather different one was answered.

 

You are confusing and mixing the issue of the ability to express an intended semantic in the syntax of XrML with the issue of how such syntactic entities are reasonably distributed and disseminated. Both are important questions, but are separate and distinct issues.

 

With respect to the latter of these issues, while you bring up many problematic dissemination mechanisms, and articulate well why they are problematic, you miss other important possibilities and choices, among them the inclusion, pre-canned, in systems using XrML to control the execution of certain actions of certain useful and / or obligatory Grants or Licenses.

 

Are we agreed, then, that there are no expressiveness issues in XrML, only dissemination ones? I, for one, would certainly agree that more discussion about the dissemination issue would be useful and productive.

 

      Bob

 

-----Original Message-----
From: Aaron Burstein [mailto:burstein@boalthall.berkeley.edu] 
Sent: Wednesday, October 16, 2002 12:41 AM
To: rights-requirements@lists.oasis-open.org
Cc: burstein@boalthall.berkeley.edu; drowan@boalthall.berkeley.edu
Subject: [rights-requirements] General permissions expressions in XrML

 

Here are some thoughts on an issue that we discussed in the last two 

calls.

 

1. We have been asked by the SC to answer the question: "What do we need 

that we cannot express today in the syntax" of XrML?

 

2. Example:

         a. A purchases a sound recording from B.

         b. A wants to excerpt parts of the sound recording for use in a 

published review of the recording.

This example requires that A be able to (1) take the excerpt, (2) 

incorporate it into his review document, and (3) publish the review. 

A's readers then require permission to listen to the excerpt.

 

3. Conversations in the SC, in related contexts, have suggested that 

XrML can express the permissions that A's use requires AS FOLLOWS

  a. A may obtain these rights either by direct grant from B, the rule 

maker; or,

  b. A may "self-issue" a set of rules that permit the relevant 

exercises; or,

  c. A may obtain the permissions he requires from a trusted third 

party, such as the United States government.

 

These options may be theoretically available, but assuming they

are, using XrML in this way is practically and politically  impossible.

The reasons for this are as follows:

 

  d.      (Regarding 4(a).) One way to characterize A's predicament is 

that of a market failure.  Relying on B's willingness to grant 

permissions to cure a market failure, when B is the cause of that 

market failure, is absurd.

  e.      (Regarding 4(b).) A's ability to express the required 

permissions is separate from A's ability to exercise those permissions.  

A cannot exercise the permissions that A issues to himself unless A is 

trusted by B to issue these permissions.  In effect, this alternative 

reduces to the preceding one.

  f.      (Regarding 4(c).) Once again, this alternative requires the 

 trust of B, the rule maker and it requires, in this particular 

instance, the government to craft REL rule sets about particular 

copyrighted works arguably in particular contexts. Sending A to any 

third party for permissions imposes burdens of cost, delay, and loss of 

privacy on A.  The notion that the Government could or would express 

REL's granting the relevant permissions in this context is absurd.  

Involving the Government in this way is both politically and 

practically untenable.

 

4. Thus this question and example highlight the distinction between what 

is theoretically expressible and what is practically expressible.  We 

find XrML wanting in its practical ability to support rights associated 

with the use and exploration of copyrighted works.

 

5. To the extent XrML is offered as an all purpose rights expression 

language itmust provide practical not purely theoretical support for 

the expression of rights in domains it intends to support. If XrML's 

authorization algorithm allowed expressions of context to enter the 

authorization decision, this kind of problem could likely be solved, or 

at least alleviated. If context is ignored in authorization 

evaluations, however, a class of rights (expressed as permissions), 

similar to the case described above, is practically impossible to 

express.

 

Aaron Burstein

Dean Rowan

 

----------------------------------------------------------------

To subscribe or unsubscribe from this elist use the subscription

manager: <http://lists.oasis-open.org/ob/adm.pl>



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


Powered by eList eXpress LLC