[Requests] GeoDRM (RFPC 30) Response

Renato Iannella renato at nicta.com.au
Fri Apr 28 00:50:20 EDT 2006


  PART A
  ------
  1. Evaluator: Renato Iannella, National ICT Australia (NICTA)

  2. Submission: OGC Request 30: Geospatial Digital Rights Management  
Reference Model (GeoDRM RM): Request for Public Comments


  PART B
  ------
  1. Specification Section number: [3]

  2. Criticality: [MAJOR]

  3. Comments/justifications for changes:

The document is heavily influenced by the work of MPEG-21 (eg see  
footnote 1, page 18) and ignores the DRM work
from the Open Mobile Alliance (OMA) which covers content delivered to  
mobile devices. It would be good if some acknowledgment was made to  
this standard as well.

  ------
  1. Specification Section number: [4.13]

  2. Criticality: [EDITORIAL.]

  3. Comments/justifications for changes:

The text in the first "Note" should reference the original source of  
the definition:
    Iannella, R. Digital Rights Management (DRM) Architectures, D-Lib  
Magazine , June 2001, Volume 7 Number 6,
   <http://www.dlib.org/dlib/june01/iannella/06iannella.html>

  ------
  1. Specification Section number: [6.6]

  2. Criticality: [MAJOR]

  3. Comments/justifications for changes:

The License  Model (as described in Figure 5, 6 and Table 1) does not  
adequately represent the needs of the geoDRM community as there are a  
number of missing features. These include:
  - the need for "types" of rights expressions, such as "offer",  
"request" and "ticket" (for example, see the "request" in Figure 13  
section 8.1)
  - the need for inheritance of rights, to support a reusable  
hierarchy of rights expressions
  - the need for "duties" to be expressible. The use of "conditions"  
is too limiting and broad. Duties can be assigned
to *any* party and ensures that preconditions are met. "Conditions"  
on specific rights, eg print 5 times, should be named as  
"constraints" as the expression is not conditional.
- Principal is a poor choice of name, as it implies "one and only". A  
more generic name should be used (eg parties)
- The "principal" (parties) should allow for different roles - not  
just the licensee
- Explicit Prohibitions should be supported - these are the opposite  
to Rights - these are consistent in Creative Commons style licenses.
- It is not clear from the model what happens if a License is granted  
to a group of Principals.
- it is not clear from the model how downstream rights are issued
- The model only allows the Issuer to appear in the expression -  
other parties should be allowed (for example, see Figure 12 in  
Section 8.1)

It is important that these features be added and subsequently  
addressed throughout the document.

  ------
  1. Specification Section number: [9.5.3.2.1]

  2. Criticality: [MAJOR]

  3. Comments/justifications for changes:

It is not clear what "r:Rights" means. It would be better to define  
this independent from one specific REL.

  ------
  1. Specification Section number: [A.2]

  2. Criticality: [MAJOR]

  3. Comments/justifications for changes:

By definition, the conformance condition is dependent on ISO 21000-5.
This is not a good idea. Conformance should be independent from  
specific RELs
  ------

Cheers...  Renato Iannella
National ICT Australia (NICTA)



--------------------------------------------------------------------------
This email and any attachments may be confidential. They may contain legally
privileged information or copyright material. You should not read, copy,
use or disclose them without authorisation. If you are not an intended
recipient, please contact us at once by return email and then delete both
messages. We do not accept liability in connection with computer virus,
data corruption, delay, interruption, unauthorised access or unauthorised
amendment. This notice should not be removed.


More information about the Requests mailing list