DRM Developers Guide For Nokia Devices v3 0 en

F O R U M N O K I A
DRM Developer’s Guide for Nokia Devices
Version 3.0; October 20, 2006
DRM
Forum.Nokia.com
Contents
1 Introduction................................................................................................................................................ 6
1.1 OMA DRM 1.0 ..............................................................................................................................................6
1.2 OMA DRM 2.0 ..............................................................................................................................................7
2 Protecting content with OMA DRM 1.0 ................................................................................................. 8
2.1 How to protect media objects with OMA DRM 1.0.........................................................................8
2.1.1 Selecting message type .......................................................................................................9
2.1.2 Loading media content..................................................................................................... 10
2.1.3 Editing headers.................................................................................................................... 11
2.1.4 Specifying rights.................................................................................................................. 12
2.1.5 Saving message................................................................................................................... 13
2.2 How to protect executable content for S60 devices with OMA DRM 1.0 ............................. 14
2.2.1 Application packaging....................................................................................................... 14
2.2.2 Definition file format ......................................................................................................... 15
2.3 How to protect themes with OMA DRM 1.0................................................................................... 16
3 Delivering OMA DRM 1.0 content to mobile devices .......................................................................17
3.1 Forward-lock and combined delivery............................................................................................. 17
3.1.1 OMA Download..................................................................................................................... 17
3.1.2 Java Application Descriptor files .................................................................................... 18
3.1.3 Content Object Descriptor files (legacy solution) ..................................................... 19
3.1.4 Direct links............................................................................................................................. 21
3.1.5 Download descriptor files ................................................................................................ 21
3.2 Separate delivery and superdistribution....................................................................................... 22
3.2.1 The Rights-Issuer header ................................................................................................. 22
3.2.2 X-Oma-Drm-Separate-Delivery........................................................................................ 22
3.2.3 Content download .............................................................................................................. 23
3.2.4 Updating rights.................................................................................................................... 25
3.2.5 Superdistribution................................................................................................................ 26
3.3 HTTP messages....................................................................................................................................... 27
3.3.1 Forward-lock......................................................................................................................... 27
3.3.2 Combined delivery.............................................................................................................. 28
3.3.3 Separate delivery ................................................................................................................ 29
3.4 Rights object ........................................................................................................................................... 29
3.4.1 Rights object delivery ........................................................................................................ 29
3.4.2 Encoding of the rights object.......................................................................................... 29
3.5 MIME types and server configuration ............................................................................................. 31
4 Creating MMS messages with OMA DRM 1.0 content ......................................................................32
DRM Developer’s Guide for Nokia Devices 2

Forum.Nokia.com
4.1 MMS message format........................................................................................................................... 32

4.1.1 Forward-lock......................................................................................................................... 32
4.1.2 Combined delivery.............................................................................................................. 33
4.1.3 Separate delivery ................................................................................................................ 33
4.2 DRM-related headers............................................................................................................................ 34
4.2.1 Content-Type ........................................................................................................................ 34
4.2.2 Content-Transfer-Encoding.............................................................................................. 35
4.2.3 Content-ID and Content-Location.................................................................................. 36
4.2.4 X-Oma-Drm-Separate-Delivery........................................................................................ 36
4.2.5 Other headers....................................................................................................................... 36
4.3 Using Nokia tools for DRM MMS message content ..................................................................... 36
4.4 Examples of DRM objects in MMS messages ................................................................................. 37
4.4.1 DRM forward-lock object in MMS message without SMIL ...................................... 37
4.4.2 DRM forward-lock object in MMS message with SMIL............................................. 38
4.5 Tips for working with Series 40 MMS clients................................................................................ 40
4.6 Tips for working with S60 MMS clients .......................................................................................... 41
5 Creating and distributing OMA DRM 2.0 content .............................................................................42
6 OMA DRM support in Nokia devices.....................................................................................................43
7 Terms and abbreviations.......................................................................................................................44
8 References .................................................................................................................................................45
Appendix A ..........................................................................................................................................................47
A.1 Closed content list – how it works ......................................................................................................... 47
A.1.1 MIME types .................................................................................................................................... 47
A.2 Closed content list – versions.................................................................................................................... 48
A.2.1 Nokia Closed Content List 1.0.................................................................................................. 48
A.2.2 Nokia Closed Content List 2.0.................................................................................................. 49
APPENDIX B..........................................................................................................................................................50
B.1 DRM objects and cached content ............................................................................................................. 50
B.2 Example............................................................................................................................................................ 50
Evaluate this resource ......................................................................................................................................51

Forum.Nokia.com
Change history
15 August 2003 V1.0 Initial document release on Forum Nokia.
5 May 2004 V2.0 Replaces the Forum Nokia document ‘DRM

Forward-lock Developer's Guide for Nokia Mobile
Phones’.
October 22, 2004 V2.1 Nokia Mobile Internet Toolkit issues updated.
October 20, 2006 V3.0 Information about OMA DRM 2.0 and application
protection in OMA DRM 1.0 added.

Forum.Nokia.com
Copyright © 2003-2006 Nokia Corporation. All rights reserved.

Nokia and Forum Nokia are registered trademarks of Nokia Corporation. Java and all Java-based marks are
trademarks or registered trademarks of Sun Microsystems, Inc. Bluetooth is a registered trademark of Bluetooth
SIG, Inc. Other product and company names mentioned herein may be trademarks or trade names of their
respective owners.
Disclaimer
The information in this document is provided "as is," with no warranties whatsoever, including any warranty of
merchantability, fitness for any particular purpose, or any warranty otherwise arising out of any proposal,
specification, or sample. Furthermore, information provided in this document is preliminary, and may be changed
substantially prior to final release. This document is provided for informational purposes only.
Nokia Corporation disclaims all liability, including liability for infringement of any proprietary rights, relating to
implementation of information presented in this document. Nokia Corporation does not warrant or represent
that such use will not infringe such rights.
Nokia Corporation retains the right to make changes to this specification at any time, without notice.
License
A license is hereby granted to download and print a copy of this specification for personal use only. No other
license to any other intellectual property rights is granted herein.

Forum.Nokia.com
1 Introduction
This document describes how to protect content using OMA DRM 1.0 and 2.0 in Nokia devices. It also
explains how to deliver and consume media content and executable content using the different
delivery methods (OMA Download separate delivery and combined delivery) and rights objects.
Creating MMS messages with OMA DRM content is also discussed.
Digital Rights Management (DRM) allows owners and sellers of digital content to manage how their
content can be sold and used, and supports the development of commercial content services over the
Internet and mobile networks. The Open Mobile Alliance (OMA) created two DRM standards to enable
interoperable deployment of services that distribute DRM-protected content.
OMA DRM 1.0 [1] was designed for distribution of digital content in mobile networks. Content owners
and service providers can use tools available through Forum Nokia to protect their content using OMA
DRM 1.0, define usage rights for the content, and distribute the protected content to mobile devices.
The OMA DRM 2.0 specification [16] adds increased security to support distribution of higher-value
content, and increased flexibility to support mobile and non-mobile content services. The high security
level is based on a Public Key Infrastructure (PKI), backed by a trust model designed to satisfy
commercial music and video providers. The specification also supports more flexible business models,
including streaming and other packetized media, in addition to licenses for groups of content and
groups of devices.
1.1 OMA DRM 1.0
The OMA DRM 1.0 specifications [1] present three methods for DRM: forward-lock, combined delivery,
and separate delivery.
Forward-lock allows single purchase, single delivery of content that should not be forwarded to others.
It often applies to subscription-based services for the delivery of news, sports, information, and
images.
Combined delivery enables usage rules to be set for the media object. This method enables the
preview feature, for example.
Separate delivery protects higher-value media and enables rights refreshment as well as
superdistribution, which allows the device to forward the media, but not the rights. Superdistribution
is a method of separate delivery that enables distribution of media by allowing encrypted DRM
content to be freely distributed peer-to-peer, whereby superdistributed content gets its rightful
payment.
All three of these OMA DRM 1.0 methods are somewhat transport agnostic. They can be used to deliver
DRM-protected content over MMS, WAP (or TCP/IP) download, or even with streaming media. This
document will attempt to give technical insight for developers creating OMA DRM-protected content.
Additional guidance is also given on the use of available Forum Nokia tools to assist in this effort.
For more information on OMA DRM 1.0, please refer to the specification documents provided by the
OMA [1]. For information on DRM support in Nokia devices, refer to Chapter 6, “OMA DRM support in
Nokia devices.”
Note : One legacy DRM method currently available on all Nokia devices is use of the Close Content List
(CCL). A summary of Nokia CCL (sometimes referred to as Device Policy Forward-Lock solutions) is
provided in Appendix A.

Forum.Nokia.com
1.2 OMA DRM 2.0
OMA DRM 2.0 is an extension of the Separate Delivery mechanism of OMA DRM 1.0. As in the Separate
Delivery case, OMA DRM 2.0 content can be distributed by any means, including superdistribution. The
methods for obtaining rights for the files, however, are more restricted. For more information on OMA
DRM 2.0, please refer to the specification documents provided by the OMA [16].

Forum.Nokia.com
2 Protecting content with OMA DRM 1.0

OMA DRM 1.0 can be used to protect multimedia objects such as ring tones, images, and Java™ MIDlets.
Potentially, however, any type of media object that has a MIME content type defined for it can be DRM-
protected.
The requirements for protecting multimedia objects are defined in the OMA DRM 1.0 specifications [1].
Any encoding tools can be used to encode objects for forward-lock and combined delivery methods.
However, using the Nokia Mobile Internet Toolkit (NMIT) can help simplify the process because it will
attach the necessary DRM wrapper headers when encoding the media object. With NMIT, it is also
possible to create the DRM Content Format (DCF) files for separate delivery method. NMIT can be
downloaded for free from the Forum Nokia Web site (http://www.forum.nokia.com/).
The following table describes several features of the delivery methods and objects defined by the OMA
DRM 1.0:
Separate delivery
Forward-lock Combined delivery
Media object Rights object
MIME multipart - 2 OMA specified DRM
MIME multipart - 1 part OMA specified Rights
Message format parts (rights object and Content Format (DCF)
(media object) Expression Language (REL)
media object) for media object
XML representation or WAP
Rights delivered in
Binary XML (WBXML) content
single file with media Rights delivered
Rights object No format (used for transmission
object (XML separately
over constrained bearers like
representation format)
WAP Push over SMS)
Forward lock (terminal) Yes Yes No Yes
AES symmetric No, SMS used to provide safe
Encryption (server) No No
encryption delivery
Yes, with terminal- Yes, with terminal- No (object encrypted on
Encryption (terminal) No
specific key specific key the server side)
Media object encoded Media object encoded
Encoding - -
with Base64 or binary with Base64 or binary
.dr (XML representation) /
File extension .dm .dm .dcf
.drc (WBXML)
2.1 How to protect media objects with OMA DRM 1.0
NMIT can be used to protect any content type with OMA DRM 1.0. The process of publishing protected
content can be defined as follows:
1. Select the DRM message type.
2. Load the media content.
3. Edit headers.
4. Specify rights (only for combined delivery or separate delivery message types).
5. Save the message.
The DRM message window of the NMIT consists of different parts. The content of the DRM message
window varies depending on the type of the message selected. When combined delivery or separate
delivery message type is selected, the specify rights part appears on the right side of the window.

Forum.Nokia.com
When creating the OMA Download over the air (OTA) descriptor files with NMIT, refer to the Nokia
Mobile Internet Toolkit User Guide [2].
Figure 1: The DRM message window
2.1.1 Selecting message type
Figure 2: Selecting message type
The message type (forward-lock, combined delivery, separate delivery) can be selected from the Select
Message Type part of the DRM message window.
DRM Content Format (.dcf file), used with the separate delivery message type, is defined by the OMA
DRM 1.0 specifications. It is used to encrypt the media content for separate delivery method and
superdistribution. By selecting the separate delivery as a message type the NMIT automatically
performs DCF encryption and inserts the required headers to obtain a .dcf file. For details on the
encryption mechanisms and required parameters for DCF content, refer to the DRM Content Format
Specification [4].

Forum.Nokia.com
2.1.2 Loading media content
Figure 3: Loading media content
Media content can be selected by pressing the Load Content button from the Load Media Content part.
After the content is selected, the MIME type and the size of the selected media file can be seen on the
screen.
2.1.2.1 Content-ID
The URI in the Content-ID field specifies the unique content identifier for the combined delivery and
separate delivery contents. The Content-ID value in the Load Media Content part and the UID value of
the Specify Rights part are synchronized so that changing the Content-ID value also changes the value
of the UID.
The format used for the Content-ID value must conform to RFC 2396 [5].
2.1.2.2 Content-Transfer-Encoding
The content encoding type defines the type of the encoding to be used for the original content data
with forward-lock and combined delivery message types. The encoding type is selected from the drop-
down list of the Load Media Content part (see Figure 3). Possible encoding types are base64 and
binary. Nokia mobile devices support base64 DRM encoding, but the use of base64 encoding is not
recommended if interoperability is important: base64 encoding is not a mandatory OMA DRM 1.0
encoding type.
Encoding type is only available with the forward-lock and combined delivery message types; separate
delivery message type data is encrypted and not encoded. More information about encoding types can
be found in RFC 2045 [3].

Forum.Nokia.com
2.1.3 Editing headers
2.1.3.1 Required header
Figure 4: Required headers for forward-lock and combined delivery message types
Figure 5: Required headers for separate delivery message type
The ‘Required’ header is automatically updated according to the MIME type of the loaded media
content, the Content-ID, and Content-Transfer-Encoding defined in the Load Media Content part. For
the separate delivery content, the encryption method is shown on the required header.
2.1.3.1.1 MIME Type
NMIT automatically recognizes the MIME type from the selected media content but it is also possible to
edit the ‘Content-Type’ header value manually. The MIME type is a mandatory field and can be any
valid Content-Type header field value as defined in RFC 2045 [3].
2.1.3.2 Optional header
Figure 6: Optional headers for separate delivery message type
The parameters in the ‘Optional’ header are used only with the separate delivery message type and
are described in the following sections.

Forum.Nokia.com
2.1.3.3 Rights Issuer
The value of the Rights-Issuer field is used for the Rights-Issuer header of the DCF content. For more
information about the Rights-Issuer header, see Section 3.2.1, “The Rights-Issuer header.” The value of
the field must be according to RFC 2396 [5].
2.1.3.4 Content Name
The Content Name is the descriptive name of DRM-protected content.
2.1.3.5 Content Description
The Content Description describes the DRM-protected content.
2.1.3.6 Content Vendor
The Content Vendor is the name of the provider of the DRM-protected content.
2.1.3.7 Icon URI
The Icon-URI field can be used to define the Uniform Resource Identifier (URI) where an appropriate
icon for the content can be retrieved. The device may use this header to request the image object that
is used as an icon associated with the content.
2.1.4 Specifying rights
Figure 7: Specifying rights for the combined delivery or separate delivery content

Forum.Nokia.com
2.1.4.1 Permissions and constraints
The rights object will be created with any parameters that the user specifies with permissions ‘Play’,
‘Display’, ‘Execute’, or ‘Print’ and constraints ‘Count’, ‘Start Time – End Time’, and ‘Interval’. Using these,
the user can define the rules for access to the DRM-protected object. For example, if the DRM-
protected object is a MIDI file, setting “Count” to 3 in the ‘Play’ tab would allow the MIDI file to be
played only three times on the mobile device. After the limit has been exceeded, the MIDI file would
no longer be playable and the user would be notified (by the mobile device) that he or she has
exceeded the number of uses for this MIDI file. This means that this MIDI file would have expired.
Restrictions for specific date and time or time intervals can be defined instead of (or in addition to)
the “Count” restriction.
The rights object only defines the permissions for usage (execution of a game, playing of audio,
display of images, or printing of text) and does not regulate the distribution of the DRM-protected
content. The DRM-protected DCF files (separate delivery) may be forwarded to other devices; however,
a valid (unexpired) rights object would be needed to use the file.
2.1.4.2 Encryption key
The encryption key is a unique 16-bit key that is used to encrypt the associated content for the DCF
file. The key is automatically created by the NMIT when a separate delivery message type is selected.
The encryption key is linked to the UID of the content and generated to the rights object file (.dr or
.drc).
2.1.4.3 UID
This value is automatically updated according to the Content-ID value of the Load Media Content part.
UID is used to associate the rights object to the corresponding combined delivery or separate delivery
content on the device.
2.1.5 Saving message
The DRM output files are created by selecting ‘Save’ or ‘Save As’ from the File drop-down menu of the
DRM message window. The type of the output file is dependent on the selected protection method:
Forward-lock An output file with the extension .dm is created. File includes single media
object with forward-lock headers.
Combined delivery An output file with extension .dm is created. File includes the media object and
associated rights object.
Separate delivery An output file with extension .dcf is created. File includes the encrypted media
object. The rights object is saved as a separate file (.dr file extension).
Refer to the User's Guide for Nokia Mobile Internet Toolkit 4.1 [2] for details about the toolkit
functionality.
2.1.5.1 Encoding
The rights objects can be presented in two different ways: textual XML representation or compacted
WAP Binary XML (WBXML). For more detailed information about the encoding of the rights object, see
Section 3.4.2, “Encoding of the rights object.” With the NMIT the rights object can be saved as WAP
Binary XML (output file with .drc extension) by pressing the ‘Save Binary Rights…’ button.

Forum.Nokia.com
Note : Because the new DRM wrapped objects have a new file extension and MIME type, it will be
necessary to have all DRM MIME types mapped on the content server. The MIME types used with
different OMA DRM 1.0 files are described in Section 3.5, “MIME types and server configuration.”
2.2 How to protect executable content for S60 devices with OMA DRM 1.0
OMA DRM 1.0 can be used to protect C++ applications and other executable files intended for use on
devices based on S60 2nd Edition, Feature Pack 2 and later that support combined and separate
delivery, along with any application data that also needs to be protected. This protected data can be,
for example, files controlling the application logic, media files, or game levels. This section discusses
the technical aspects of the protection of executable content. Business opportunities and various ways
of implementing Symbian OTA application delivery are discussed in the white paper Native Symbian
OS Applications OTA: New Opportunities to Drive ARPU [20].
Note : From S60 3rd Edition onwards applications need DRM capability in order to, for example,
execute usage rights.
2.2.1 Application packaging
In order to protect an application using OMA DRM 1.0, the developer must create a Protected
Installation Package (PIP). A PIP file is a regular ZIP archive that includes the application installer (.SIS
file) plus any related application data. The application data must be available in files so that it can be
encrypted and protected properly. The size of the files must not be larger than what the application
can hold in memory, since the file data will be encrypted in memory. There are no restrictions
regarding the type of the data.
The PIP file can be created using regular ZIP packaging applications and must follow these rules:
• The files within the PIP file must not be stored with any path information.
• One, and only one, component of the PIP file must be the original application SIS file. Only
applications that are originally packaged in SIS files can be protected.
• One, and only one, component of the PIP file is the so-called definition file, which is named
datafiles.DEF. It defines which files need to be protected. Its format is described in Figure 4.1.
• The PIP file can contain a number of data files to be protected, and they must be listed in the
definition file.
• When storing a PIP file on a server for later download, the MIME type must be application/x-pip.
The file does not need to have a specific extension, but the use of the PIP extension can make the
server configuration simpler.
The PIP file itself is not a protected file. It can be protected by OMA DRM 1.0 by packaging it in an
appropriate DRM format as described in Section 2.1, “How to protect media objects with OMA DRM
1.0.” Superdistribution is not supported unless the original file is kept in the device after the
application is installed.
Note : In S60 2nd Edition, Feature Packs 2 and 3, there are some restrictions in the PIP support
preventing automated ordering of a new rights object (license) for the application. However, it is
possible for an application to manually check the rights to reject or limit the application usage.

Forum.Nokia.com
PIP File (DCF Format)
ZIP File
SIS File
Definition File
Data File
Data File
Figure 8: Overview of a PIP file
2.2.2 Definition file format
The definition file is used to specify the type of the package (either a protected application or a
protected theme) and the data files to be protected. The file is a regular text file consisting of one or
more lines. Each line ends with a carriage return and a line feed character (ASCII 13 and 10).
The first line of the definition file contains either the word “application” for protected applications or
“skin” for protected themes. Either word must be in lower case.
Each following line defines a data file to be protected. The lines contain at least one and up to three
elements, separated by a space character (ASCII 32). The first element is the name of the data file as it
is stored in the ZIP file. The second optional element is the MIME type for the encrypted data file that
will be used by the application recognizer in the device. The third optional element is the target file
name under which the encrypted data file will be stored. If it is omitted, the name will be the same
name as the first element; that is, the name of the file as it is stored in the ZIP file. The default
directory under which the file is stored is the same directory in which the application is stored. The file
name can, however, be an absolute path as well.
Below is an example of a definition file.
application
level1.dat
level2.dat
level3.dat
registry.dat text/plain c:\system\data\appregistry.dat
trailer.mpg video/mpeg

Forum.Nokia.com
The definition file above specifies a protected application. It will install the three files level1.dat,
level2.dat, and level3.dat with the MIME type application/binary and the file trailer.mpg with the MIME
type video/mpeg into the application directory. Also, the file registry.dat will be stored with the MIME
type text/plain under the name appregistry.dat in the directory \system\data\ on the C: drive.
Note : The SIS file in the PIP package must not be listed as one of the data files; otherwise, the
installation procedure will fail.
2.3 How to protect themes with OMA DRM 1.0
OMA DRM 1.0 protection can be applied to themes for Nokia devices, created with either the S60 or
Series 40 Theme Studio tools. Both are available from Forum Nokia. For S60 themes, Theme Studio will
generate a PIP file from a theme, which can then be protected with OMA DRM 1.0 using the NMIT, as
described in Section 2.1, “How to protect media objects with OMA DRM 1.0.” The NMIT can also be used
to protect Series 40 theme files (*.nth).

Forum.Nokia.com
3 Delivering OMA DRM 1.0 content to mobile devices

3.1 Forward-lock and combined delivery
Providing forward-lock or combined delivery downloadable content for devices consists of three steps:
1. DRM message creation from plain content, for example, GIF image (see Section 2.1, “How to
protect media objects with OMA DRM 1.0”).
2. DRM message (file extension .dm) deployment to the file system of the Web server.
3. XHTML or WML page design and implementation. The link in the XHTML or WML page is
addressed to the download description file or directly to the .dm file of the content.
Creating content download for forward-lock or combined delivery is a similar process. The only
difference is that the business logic can be more sophisticated with combined delivery content
because the rights object inside the message offers the possibility of defining usage rights for the
content (for example, preview or one-month usage right). A combined delivery message always
implements the forward-lock functionality as an addition to the other defined rights.
After the content is protected, as described in Section 2.1, it can be deployed to the content server.
There are different technologies for providing the download of protected content depending on, for
example, the content type to deliver. The download technologies are:
1. OMA Download Over the Air (OMA DL OTA)
2. Java Application Descriptor (JAD)
3. Content Object Description (COD; Nokia proprietary method)
4. Direct links
3.1.1 OMA Download
OMA Download [6] provides reliable download functionality for generic content types, such as MIDI
ring tones, wallpapers, and screensavers in media types such as JPEG, GIF, and PNG, either in still or
animated form. With OMA Download, any content can be downloaded as long as the receiving device
understands it. In addition, it is possible to download SIS application packages via OMA Download to
S60 2nd Edition, Feature Pack 2 and later devices that support combined or separate delivery.
OMA Download is based on a descriptor file. The Download Descriptor (DD) file contains information
about the media object that is going to be downloaded in XML format. During the download
transaction, the download descriptor is fetched first and then parsed by the device. In this phase the
device checks, for example, the MIME type of the content indicated in the descriptor. According to the
results of this check, the media object is finally downloaded from the URI defined in the download
descriptor.

Forum.Nokia.com
1) User selects the link addressing the

download descriptor file of the content from the OMA
XHTML or WML page Download
Descriptor file
page.xhtml: (.dd)
...
<a href=“desc_sample.dd”>link</a>
... 2) Device fetches the descriptor file
(.dd) and parses its contents
desc_sample.dd:
...
<media
xmlns="http://www.openmobilealliance.org/xml
ns/dd">
3) User accepts or cancels the content
4) If user accepts the download,

device fetches the actual DRM- E.g.,
wrapped content (.dm) image content
in DRM
wrapper (.dm)
Figure 9: Downloading DRM objects using OMA Download Descriptor files
Note : The <objectURI> element of the OMA Download Descriptor file must address the created DRM
message file (file extension .dm).
For more information about OMA Download, see the Forum Nokia DRM and Download section at
http://www.forum.nokia.com/drm.
3.1.2 Java Application Descriptor files
Each MIDlet suite Java Archive (JAR) file may have an associated application descriptor to describe its
contents. The application descriptor MIME type is text/vnd.sun.j2me.app-descriptor. The file extension
of an application descriptor file must be .jad. The application management software uses the
descriptor to manage each MIDlet — that is, to verify that a MIDlet is suited to execution on the mobile
information device before loading the MIDlet suite JAR file.
In Nokia devices, the following information, at a minimum, must be found in the JAD file: MIDlet-name,
MIDlet-vendor, MIDlet-version, MIDlet-Jar-Size, and MIDlet-Jar-URL. If the JAR file is located in the same
directory as JAD, the URL address can be simply the name of the JAR file. Other optional parameters can
also be used. MIDlet-name, MIDlet-vendor, and MIDlet-version must match with the manifest.mf file,
which is located inside the JAR file. Other attributes may be different in the JAD and JAR manifest, in
which case the JAD attribute is used.

Forum.Nokia.com
1) User selects the link addressing the Java

download descriptor file of the content Application
from the XHTML or WML page Descriptor
file (.jad)
page.xhtml:
2) Device fetches the
... descriptor file (.jad) and
<a parses its content
href=“desc_Test_MIDlet.jad
”>link</a> desc_Test_MIDlet.ja
... d:
MIDlet-Jar-URL:
Test_MIDlet.dm
...
3) User accepts or cancels the

content download
4) If user accepts the Java MIDlet

download, device fetches the in DRM
actual DRM-wrapped content wrapper
(.dm) (.dm)
Figure 10: Downloading DRM-encoded MIDlets using JAD files
Note : The MIDlet-Jar-Size parameter inside the JAD file should be set as the size of the original plain
JAR file.
For more information about the JAD file, see http://java.sun.com/javame/.
3.1.3 Content Object Descriptor files (legacy solution)
In general, the benefits and download process for the Content Object Descriptor (COD) are very similar
to OMA Download. The main difference is that COD is a Nokia proprietary solution and cannot be used
with other manufacturers' devices.

Forum.Nokia.com
1) User selects the link addressing the Content

download descriptor file of the content from Object
the XHTML or WML page Descriptor file
(.cod)
2) Device fetches the descriptor file

(.cod) and parses its content
desc_sample.cod:
page.xhtml:
COD-URL: sample.dm
... ...
<a
href=“desc_sample.cod”>link</a
3) User accepts or cancels the content
4) If user accepts the download,

device fetches the actual DRM- E.g.,
wrapped content (.dm) image content
in DRM
wrapper (.dm)
Figure 11: Downloading DRM objects using COD
Note : The COD-URL attribute of the Nokia COD descriptor file must address the created DRM message
file (file extension .dm).
For information about COD support in Nokia devices, see the document Browser Characteristics in Nokia
GSM Devices [17] at http://www.forum.nokia.com.

Forum.Nokia.com
3.1.4 Direct links
A direct link to protected content is the most basic way to provide the download.
...
<a href=“http://www.server.com/drm/xxx.dm”>DRM content link</a>
...
The code above provides a link to the xxx.dm DRM-protected content for the end user browsing on
that XHTML or WML page.
1) User selects the link addressing the E.g.,

DRM-wrapped content from the image content
XHTML or WML page in DRM
wrapper (.dm)
page.xhtml:
...
<a
href=“sample.dm”>link</a>
... 2) Device fetches the DRM-
wrapped content (.dm)
Figure 12: Downloading DRM objects using a direct link
Note : It is recommended to use COD, JAD, or OMA Download technologies instead of direct links to
provide a better end-user experience (for example, for transaction handling).
3.1.5 Download descriptor files
The descriptor files for OMA Download can also be created with NMIT. For more details, refer to the
User's Guide for Nokia Mobile Internet Toolkit [2]. The descriptor file for the Nokia proprietary solution,
COD, can be created with the Nokia Content Publishing Toolkit (NCPT). For more information about the
NCPT, see http://www.forum.nokia.com/.

Forum.Nokia.com
Figure 13: NCPT Download functionality
3.2 Separate delivery and superdistribution
In separate delivery, the download of the DRM Content Format file can be implemented in a similar
way as downloading forward-lock or combined delivery messages. The difference is that the rights
object is sent to the device separately by using unconfirmed Push (WAP Push) over Short Message
Service (SMS). The actual content in the DCF file is encrypted so that it cannot be used without a
Content Encryption Key (CEK). The CEK is delivered to the consuming device as a part of the rights
object.
3.2.1 The Rights-Issuer header
The Rights-Issuer header defines the URL of the content provider’s HTTP server. This can be used by
the device making a request (HTTP GET) to get the rights object for the encrypted DCF content. In one
example scenario, the server could respond to the request by posting the XHTML page to the
requesting device. From the XHTML page, the end user can select the needed rights: preview, buy, etc.
The corresponding rights object is then delivered to the end user's device via WAP Push.
The Rights-Issuer URL is defined as one of the headers in the DCF file.
Figure 14: DCF message: Rights-Issuer header
3.2.2 X-Oma-Drm-Separate-Delivery
The X-Oma-Drm-Separate-Delivery header is used to indicate that the rights object will be pushed to
the device after the device has received the DCF file (see Figure 13). The X-Oma-Drm-Separate-Delivery
header is added to the HTTP response containing the DCF file. It is also possible to specify in the
header the estimated time that it will take for the rights object to arrive at the device.
The usage of the X-Oma-Drm-Separate-Delivery header can be seen in the HTTP message in Figure 20.
The following section provides a few separate delivery use cases.

Forum.Nokia.com
3.2.3 Content download
DCF content can be downloaded to the device with the X-Oma-Drm-Separate-Delivery HTTP header. It
is recommended that you use this header to improve the user experience of the protected content
download. In practice, using the header provides a download process that does not differ from the
traditional download process from the end user point of view. Figures 14 and 15 show use cases for
download with and without the X-Oma-Drm-Separate-Delivery header.
1) User browses on content

contents.xhtml: provider’s XHTML page and OMA
selects the link of the content Download
... (the link of the .dd file of the Descriptor file
<a href content) (.dd)
src=”desc_xx.dd”>link</a>
...
2) Descriptor file (.dd) is fetched to

the device and user accepts the
download
3) DCF file is fetched to the device with X-

Oma-Drm-Separate-Delivery HTTP header
4) Rights object is sent to device via the

Push Proxy Gateway and Short Message
Service Center
E.g., image
content in
encrypted DCF
format (.dcf)
Rights object
of the DCF
content
(.dr)
Figure 15: DCF download with X-Oma-Drm-Separate-Delivery HTTP header
After step 4, the DRM-protected content can be used in the device according to the permissions and
constraints defined in the sent rights object.

Forum.Nokia.com
1) User browses on content

provider’s XHTML page and OMA
selects the link of the content Download
contents.xhtml: (the link of the .dd file of the Descriptor file
content) (.dd)
...
<a href
src=”desc_xx.dd”>link</a>
... 2) Descriptor file (.dd) is fetched to the device
and user accepts the download
5) Rights object is sent to device via the

Push Proxy Gateway and Short Message
Service Center
3) DCF file is fetched to the device (no X-
Oma-Drm-Separate-Delivery added)
Rights object E.g., image

of the DCF content in
content rights.xhtml:
encrypted DCF
(.dr) format (.dcf)
...
<a href src=”ro_xx_yy”>1
month</a>
...
4) User selects Update rights from the device, and browsing

session to the content provider’s XHTML page is initialized by the
device. User selects the rights which (s)he is willing to buy by
selecting the corresponding link from the XHTML page
Figure 16: DCF download without X-Oma-Drm-Separate-Delivery HTTP header
Note : The browsing session in step 4 is established to the URL defined in the Rights-Issuer header of
the DCF file.

Forum.Nokia.com
3.2.4 Updating rights
Updating “rights” is a very similar process to content download without the X-Oma-Drm-Separate-
Delivery header (steps 4 and 5 in Figure 16).
E.g.,
image content
in encrypted
DCF format
(.dcf)
3) Rights object is sent to device via the Push 1) The rights of the DCF content in the user’s
Proxy Gateway and Short Message Service device is expired
Center
Rights object
of the DCF
content rights.xhtml:
(.dr)
...
<a href src=”ro_xx_yy”>1
month</a>
...
2) User selects Update rights from the device, and browsing session
to the content provider’s XHTML page is initialized by the device.
User selects the rights which (s)he is willing to buy by selecting the
corresponding link from the XHTML page
Figure 17: Updating the expired rights of the DCF content
Note : The browsing session in step 2 is established to the URL defined in the Rights-Issuer header of
the DCF file.

Forum.Nokia.com
3.2.5 Superdistribution
The superdistribution case makes it possible to pass the content object (DCF object) from mobile
device to mobile device through any channel. The DCF object is encrypted and cannot be consumed on
the receiving mobile device without the rights object including a content encryption key. The rights
object for the DCF object can be requested by the end user from the Rights-Issuer URL defined in the
DCF object. The end user can renew the rights part of the content without additional download of the
content object.
1) User A sends a DRM-protected content

(DCF) to user B, e.g., via IrDA, BT, or MMS.
E.g.,
image content
in encrypted
DCF format
User A (.dcf) User B
2) User B’s device initiates the browsing

session to the Content Provider URL defined
4) Rights object is sent to device via the in the Rights-Issuer header of the DCF
Push Proxy Gateway and Short Message content. The server of the content provider
Service Center responds to the request by sending the
XHTML page to user
Rights object
of the DCF rights.xhtml:
content ...
(.dr) <a href src=”ro_xx_yy”>1
month</a>
...
3) User B selects the rights which (s)he is willing to buy by

selecting the corresponding link from the XHTML page
Figure 18: Superdistribution of the DCF image content
After step 4, the DRM-protected content can be used in the device of user B according to the
permissions and constraints defined in the sent rights object.

Forum.Nokia.com
3.3 HTTP messages
3.3.1 Forward-lock
The following example presents the HTTP response from the Web server when a user selects the link
addressed to the forward-lock message. The device receiving the forward-locked image is allowed to
view and save the object but is not allowed to forward it to other devices.
HTTP/1.1 200 OK
Content-type: application/vnd.oma.drm.message;
boundary=random78o6bP%[GB6b/8&/45&%*^'?vS HTTP-specific part
Content-Length: xxx
--random78o6bP%[GB6b/8&/45&%*^'?vS
Content-type: image/jpeg
Content-Transfer-Encoding: binary
51 67 4b 44 42 51 4e 44 41 73 4c 44 42 6b 53 0d DRM forward-lock
message part
0a 45 77 38 55 48 52 6f 66 48 68 30 61 48 42 77
67 4a 43 34 6e 49 43 49 73 49 78 77 63 4b 44 63
70 4c 44 41 78 4e 44 51 30 48 79 63 35 50 54 67
--random78o6bP%[GB6b/8&/45&%*^'?vS—
Figure 19: Sample of an HTTP message containing a forward-lock wrapped object
The "DRM forward-lock message part" is the content of the forward-lock message file with a .dm
extension.

Forum.Nokia.com
3.3.2 Combined delivery
In combined delivery, the message structure is very similar to forward-lock — only "part 1: rights
object" is added. Rights are always in textual XML representation with a combined delivery message.
HTTP/1.1 200 OK
Content-type: application/vnd.oma.drm.message;
boundary=random78o6bP%[GB6b/8&/45&%*^'?vS HTTP-specific part
Content-Length: xxx
Content-type: application/vnd.oma.drm.rights+xml
<o-ex:rights
xmlns:o-ex="http://odrl.net/1.1/ODRL-EX"
xmlns:o-dd="http://odrl.net/1.1/ODRL-DD"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#/">
<o-ex:context>
<o-dd:version>1.0</o-dd:version>
</o-ex:context>
<o-ex:agreement>
<o-ex:asset>
<o-ex:context>
Combined delivery
<o-dd:uid>cid:20141-9729@http://contentpro.com</o-dd:uid> message part 1:
</o-ex:context> rights object
<ds:KeyInfo>
<ds:KeyValue>PkerZ9f5g0a37UC2u/G+QA==</ds:KeyValue>
</ds:KeyInfo>
</o-ex:asset>
<o-ex:permission>
<o-dd:display>
<o-ex:constraint>
<o-dd:count>3</o-dd:count>
</o-ex:constraint>
</o-dd:display>
</o-ex:permission>
</o-ex:agreement>
</o-ex:rights>
Content-type: image/jpeg
Content-ID: <20141-9729@http://contentpro.com > Combined delivery
message part 2:
image content
...jpeg image in binary format...

Figure 20: Sample of an HTTP message containing a combined delivery-wrapped object
If the DRM forward-lock or combined delivery message is created with NMIT, the boundaries of the
DRM part are created by the toolkit. The “Combined delivery message parts 1 and 2” are the content of
the combined delivery message file with .dm extension.

Forum.Nokia.com
3.3.3 Separate delivery
The X-Oma-Drm-Separate-Delivery HTTP header is used to indicate to the device that the rights object
will be delivered in 12 seconds to the device.
HTTP/1.1 200 OK
Content-type: application/vnd.oma.drm.content;
HTTP-specific part
Content-Length: xxx
X-OMA-DRM-SEPARATE-DELIVERY: 12
Original content
...DRM content in DCF file...
encrypted in DCF
format
Figure 21: Sample of an HTTP message containing a separate delivery object
The "Original content encrypted in DCF format" is the content of the separate delivery message file
with a .dcf extension. For the structure of the DCF message, see the OMA DRM 1.0 Content Format
specification [4].
3.4 Rights object
3.4.1 Rights object delivery
The rights object is pushed to the user by using unconfirmed push over a connectionless session
service (like GSM Short Message Service). In the case of separate delivery, when the rights object is sent
to the device with WAP Push over SMS, the rights object can be compacted using WBXML to provide
more efficient delivery. For more information about encoding the rights object, see Section 3.4.2. With
the combined delivery method, the textual XML representation of the rights object is used.
Note : When pushing rights objects in binary-encoded format via the SMS, the MIME type must be set
to application/vnd.oma.drm.rights+wbxml.
For more information about WAP Push, see the document Getting Started With WAP Push [7] available
at www.forum.nokia.com.
Note : The Mobile Subscriber Integrated Services Digital Network (MSISDN) number or other alias of
the end user is needed to provide the rights objects via WAP Push.
3.4.2 Encoding of the rights object
When the rights object is delivered to the device as a WAP Push via SMS, it is recommended to use the
WBXML-encoded version because it uses significantly less space than the same rights object in a
textual XML representation.

Forum.Nokia.com
Example of rights object in textual XML representation:
<o-ex:rights
xmlns:o-ex="http://odrl.net/1.1/ODRL-EX"
xmlns:o-dd="http://odrl.net/1.1/ODRL-DD"
>
<o-ex:context>
<o-dd:version>1.0</o-dd:version>
</o-ex:context>
<o-ex:agreement>
.
.
.
Example of rights object in WBXML:
Hex Description
03 WBXML version number – WBXML version 1.3
0E Public identifier (-//OMA//DTD DRMREL 1.0//EN)
6A Charset = UTF-8
00 String table length = 00 (empty string table)
C5 <o-ex:rights
05 xmlns:o-ex=
85 “http://odrl.net/1.1/ODRL-EX” (attribute value)
06 xmlns:o-dd=
86 “http://odrl.net/1.1/ODRL-DD” (attribute value)
07 xmlns:ds=
87 http://www.w3.org/2000/09/xmldsig#/” (attribute value)
01 >
46 <o-ex:context>
47 <o-dd:version>
03 STR_I (inline string follows with a terminator)
“1.0”, 00 “1.0” + string terminator
01 </o-dd:version>
01 </o-ex:context>
49 <o-ex:agreement>
… …
More information about rights object encoding can be found in the OMA Rights Expression Language
specification [8]. More information about the rules of encoding XML in general can be found in the
W3C specification, WAP Binary XML Content Format [9].

Forum.Nokia.com
3.5 MIME types and server configuration
In cases where content download is used for distributing protected content to devices, the download
method and OMA DRM 1.0-specific MIME types with associated file extensions must be configured to
the Web server, which is used as content storage. The MIME types needed are:
MIME Type Description
The MIME type of the OMA forward-lock and

application/vnd.oma.drm.message OMA combined delivery message
(file extension *.dm)
The MIME type of the OMA DRM 1.0 Content

application/vnd.oma.drm.content Format
(file extension *.dcf)
application/vnd.oma.drm.rights+xml The MIME type of the OMA rights object
(textual XML representation and WBXML)
or
(file extension *.dr for textual or *.drc for
application/vnd.oma.drm.rights+wbxml
WBXML)
The MIME type of the OMA Download method

application/vnd.oma.dd+xml
(file extension *.dd)
The MIME type of the JAD method

text/vnd.sun.j2me.app-descriptor
(file extension *.jad)
The MIME type of the Nokia COD method

text/x-co-desc
(file extension *.cod)
When uploading the files to the Web server, make sure to check the MIME configuration of your server.
It may be necessary to add a new MIME type to the Web server, which would map to the file
extensions shown above.
Note : Check with your operator to ensure that its WAP gateway accepts the OMA DRM 1.0 MIME type.
If you are using your own WAP gateway, remember to check your configuration for the allowed MIME
types. Otherwise, it could reject the message or change the MIME type when transferring, for example,
Java downloads.

Forum.Nokia.com
4 Creating MMS messages with OMA DRM 1.0 content

Multimedia Messaging Service (MMS) enables content providers and mobile device users to exchange
and share audio, images, and other rich content, in addition to traditional text messages. MMS is also
sometimes known as “picture messaging” or “video messages.” It provides an enhanced experience
for mobile device users to share personal media via their mobile devices. However, content providers
may have concerns about protecting branded media from unauthorized redistribution. Wrapping
content (like images, ring tones, and Java applications) in DRM forward-lock encoding before attaching
it to MMS messages ensures that only the original receiver will be able to use the media object.
4.1 MMS message format
The procedure for attaching content objects to MMS messages is always the same. Attaching DRM
encoded/encrypted multimedia objects is not different. The objects are simply appended to the MMS
message body preceded by any necessary MMS object headers (for example, the DRM header).
4.1.1 Forward-lock
Figure 21 is an example of an MMS message containing multiple DRM forward-locked media objects.
Header
Content-Type: application/vnd.mms.message
Content
MMS Message Header MMS
… Message Header
Content-Type: application/vnd.wap.multipart.mixed
MMS Message Body

...
Content-ID:<CID0>
.
Content-Type: text/plain Header of MMS Object 0
…text file … Sample_text.txt

Message Text
...
Content-Type: application/vnd.oma.drm.message; boundary=“testboundary1”
Header of MMS Object 1
Content-ID:<CID1>
--testboundary1
Content-Transfer-Encoding: base64 Encoded_Image1.dm
Content-Type: image/jpeg DRM Forward-lock
… contents of encoded Image1… Wrapped Object
--testboundary1--
…
...
Content-Type: application/vnd.oma.drm.message; boundary=“testboundary2”
Header of MMS Object 2
Content-ID:<CID2>
--testboundary2
Content-Transfer-Encoding: binary Header of the Encoded_Image2.dm
Content-Type: image/gif DRM Wrapper DRM Forward-lock
… contents of encoded Image2… Wrapped Object
--testboundary2--
Figure 22: MMS message containing forward-lock wrapped content

Forum.Nokia.com
4.1.2 Combined delivery
Figure 22 shows the architecture of an OMA DRM 1.0 combined delivery object within a simple MMS
message.
Header
Content
MMS Message Header MMS

… Message Header
Content-Type: application/vnd.wap.multipart.mixed
MMS Message Body

...
.
Content-Type: text/plain Header MMS Object 0
Content-ID:<CID0>
Sample_text.txt
…text file …
Attached plain text file
...
Content-Type: application/vnd.oma.drm.message; boundary=“atestboundary” Header MMS Object 1
Content-ID:<CID1>
--atestboundary
Content-Type: application/vnd.oma.drm.rights+xml
Content-Transfer-Encoding: binary Rights
… contents of XML rights file… Object
--atestboundary Encoded_Image.dm
DRM Combined Delivery
Content-Transfer-Encoding: binary Wrapped Object
Content-ID: <959816597@http://www.forum.nokia.com> Media
Content-Type: image/gif Object
… contents of binary encoded Image…
--atestboundary--
Figure 23: MMS message containing combined delivery-wrapped content
As shown in Figure 22, for combined delivery, the rights object and multimedia object are both
contained inside the DRM wrapper and delivered in the same MMS message. The rights object not only
contains the key for access to the multimedia object, it may also contain permissions information for
the number of times (or the time period) that the object is allowed to be played, printed, displayed, or
executed on the receiving device. For more information on creating rights permissions, see Section
2.1.4, “Specifying rights.”
In OMA DRM 1.0 combined delivery, the rights object and multimedia object are both stored to the
mobile device and cannot be forwarded from that mobile device. They are associated with each other
via a unique content identification when stored onto a mobile device, allowing the rights object to
continue governing the access permissions of the multimedia object even after the actual MMS
message has been deleted.
4.1.3 Separate delivery
For OMA DRM 1.0 separate delivery, the multimedia content is encrypted and stored as a DCF file (DRM
Content Format). For more information about DCF format and encoding for separate delivery, see the
OMA DRM 1.0 specifications. See Chapter 2, “Protecting content with OMA DRM 1.0” for instructions on
creating the DCF file and the rights object using NMIT.

Forum.Nokia.com
Remember that with DRM separate delivery, the DRM content is delivered to the mobile device without
the rights object. The rights object is delivered separately in a WAP Push message. This is the same
procedure as separate delivery using OMA Download for transport of the DRM content file.
Separate delivery wrapped content (the DCF file) is allowed to be forwarded from the mobile device
(via MMS, infrared, Bluetooth, etc.), but the DRM-wrapped content cannot be rendered or played
without the key from the rights object. However, rights objects can never be forwarded from the
mobile device. For more information on DCF files and rights object usage, see Sections 3.2, “Separate
delivery and superdistribution” and 3.4, “Rights object.”
Figure 23 shows the architecture of an OMA DRM 1.0 separate delivery object within an MMS message.
Header
Content
MMS Message Header

… MMS
Content-Type: application/vnd.wap.multipart.mixed Message Header
.
MMS Message Body
...
Content-Type: text/plain Header of MMS Object 0
Content-ID:<CID0>
…text file … Sample_text.txt
Attached plain text file
...
Content-Type: application/vnd.oma.drm.content; Header of MMS Object 1
Content-ID:<CID1>
X-Oma-DRM-Separate-Delivery: 18
…contents of DCF file… Encrypted_Image.dcf

DRM Content Format
Encrypted Object
Figure 24: MMS message when using separate delivery DRM
4.2 DRM-related headers
4.2.1 Content-Type
When sending MMS messages containing an OMA DRM 1.0 forward-locked or OMA DRM 1.0 combined
delivery multimedia object, the following MIME media type is used in the headers of the DRM-wrapped
MMS objects:
Content-Type: application/vnd.oma.drm.message; boundary=”<boundary>”

When delivering a DCF-formatted media object (as used with OMA DRM 1.0 separate delivery or OMA
DRM 1.0 superdistribution), the following MIME media type is used in the header of the DCF MMS
object:
Content-Type: application/vnd.oma.drm.content
Notice in Figure 23 that there are four levels of Content-Type headers in MMS messages. Each level of
headers describes the body of data following that set of headers.

Forum.Nokia.com
(1) The MMS message header “Content-Type” has a value of application/vnd.wap.multipart.mixed. DRM
forward-locked objects can be delivered in either multipart-mixed or multipart-related MMS messages.
However, if the MMS message is multipart-related, the DRM object must be referenced in the
Synchronized Multimedia Integration Language (SMIL) presentation file delivered with that MMS
message. See Section 4.4.2, “DRM forward-lock object in MMS message with SMIL,” for details on using
DRM objects with SMIL.
(2) The second level of Content-Type header is contained within the body of the MMS message and is
referred to in this document as MMS Object Headers. When attaching a DRM forward-locked object to
an MMS message, the object header must always have a value of application/vnd.oma.drm.message,
regardless of the actual type of media inside the DRM wrapper.
(3) When unwrapping the DRM object, the mobile device will then attempt to determine the original
media type of the object. Therefore, in addition to the headers for normal MMS messages, this third
Content-Type header is included within the DRM wrapper as an indication of the object’s media type.
(4) The Content-Type used within the DRM object is defined by the OMA DRM 1.0 specification and is
not a required part of the MMS implementation. For more information on appropriate header values,
refer to the MIME Types table in Section 3.5, “MIME types and server configuration.” This header is
automatically created within the .dm file when using NMIT to create your forward-locked and
combined delivery-wrapped content and rights objects.
Also notice in Figure 22 that the DRM-wrapped objects (for forward-lock and combined delivery) are
properly formatted by starting and ending with a “boundary” that begins and ends within “--” (double
dashes). A properly defined OMA DRM 1.0 wrapper begins with double dashes, followed by the
boundary value, and then ends with the boundary value, followed by the double dashes. The
boundary value must be unique within the message so that it is not confused with boundaries of
other objects included in the same message. NMIT will automatically generate a random boundary
value for its DRM wrappers. This parameter is further defined in the OMA DRM 1.0 specifications [1].
According to the OMA DRM 1.0 specifications, “If HTTP or MIME compliant protocol is used to transport
the DRM message, the boundary delimiter must be included as a parameter in the media type
definition.” Nokia devices will accept MMS and DRM content with or without the “boundary=”
parameter; however, for interoperability purposes, it is recommended to use the “boundary=”
parameter for DRM MMS messages. For more information on the Content-Type header field, see RFC
1521 [10].
4.2.2 Content-Transfer-Encoding
All devices compliant with OMA DRM 1.0 will support 7bit, 8bit, and binary transfer encodings. Using
one of these encodings for creating your DRM object is recommended. However, Nokia devices will
also support base64 transfer encoding. Base64 encoding may be the preferred transfer encoding
method in some environments such as legacy e-mail server systems.
The mobile device will expect all DRM objects to be encoded. If no transfer encoding is defined in the
headers (that is, if the Content-Transfer-Encoding header is missing), then the default encoding is
assumed to be:
Content-Transfer-Encoding: 7bit
Note : This header is used for OMA DRM 1.0 forward-lock and combined delivery methods, and is not
relevant for separate delivery or superdistribution DRM methods.

Forum.Nokia.com
4.2.3 Content-ID and Content-Location
As with all MMS messages, Nokia mobile devices support the use of either Content-ID or Content-
Location to identify and reference DRM objects in an MMS message. Only one header (either Content-ID
or Content-Location) is used to reference each MMS object in a SMIL presentation, so defining both
headers for each object is not necessary. The Content-ID header is required by OMA DRM 1.0 standards
to implement future DRM methods, such as combined and separate delivery. Therefore, for forward
compatibility, use of Content-ID is recommended.
Note : For more information on referencing MMS objects with Content-ID and Content-Location, see
Getting Started with MMS Tools [18] or How to Create MMS Services [19] available at
http://www.forum.nokia.com/.
4.2.4 X-Oma-Drm-Separate-Delivery
The X-Oma-Drm-Separate-Delivery header is only used for OMA DRM 1.0 separate delivery.
The header provides a way for the service provider to hint at the approximate wait time until rights
object delivery to the receiving device. This header indicates to the mobile device that the rights
object will be delivered separately from the MMS message. In the case of superdistribution, the user
may need to obtain “rights” by making a request using the DCF object. See Sections 3.2, “Separate
delivery and superdistribution,” and 3.4, “Rights object,” for more details on “rights” handling.
As shown in Figure 23, the following is added to the MMS object header of the DCF object:
X-Oma-DRM-Separate-Delivery: 18
The example above indicates that a WAP Push containing rights to this DCF object should arrive in
approximately 18 seconds (this is only an example value). The header value is defined in increments
of seconds. For more information on this header, please see the OMA DRM 1.0 specification.
When working with Nokia devices, the absence of this header will not affect the acceptance and
consumption of the rights object. The messaging client will accept the rights object whenever it is
delivered. Still, use of this header is recommended to maintain interoperability with other mobile
devices.
4.2.5 Other headers
The headers outlined in this document are the mandatory MIME headers needed to form a valid MMS
message. There are a large number of MIME headers that are not mentioned here. In general, Nokia
mobile devices will ignore all other MIME headers that they do not need for MMS message processing.
The Content-Disposition header is an example of this. This is a valid MIME header that can be used in
conjunction with the Content-Type header. Existing Nokia MMS clients simply ignore the Content-
Disposition header. However, see Section 3.4, “Rights object,” for a note about this header.
4.3 Using Nokia tools for DRM MMS message content
There are a variety of ways to create MMS messages (as long as the message format conforms to the
OMA and 3GPP specifications). Most content providers will create service applications that will
dynamically create, encode, and send out MMS messages. However, for learning and testing purposes,
NMIT (versions 4.0 and newer) can also be used to create MMS messages.
NMIT can be used to DRM-wrap the media object (see Chapter 2, “Protecting content with OMA DRM
1.0,” for tips on using NMIT) and then insert the DRM media object into any MMS message. This can be

Forum.Nokia.com
done with the NMIT MMS creation wizard or in the MMS message window by using the Add Part button
(see Figure 24). For more information, please refer to the user’s guide of the toolkit.
This document addresses DRM issues for MMS and assumes that the reader understands basic MMS
concepts related to MMS service creation. For more tools and emulators for MMS application
development, see the document Getting Started with MMS Tools [11] available at
www.forum.nokia.com.
4.4 Examples of DRM objects in MMS messages
4.4.1 DRM forward-lock object in MMS message without SMIL
NMIT can be used to create, analyze, and test MMS messages. The Part0 of Figure 24 is a DRM object
attached to an MMS message. The Part Properties lists all MMS object headers (associated with the DRM
object), followed by a blank line, then the DRM wrapped object.
Figure 25: MMS message containing one DRM media object
Notice that in Figure 24 there is a blank line at the end of the Multipart Headers of the MMS message
and again at the end of each set of object headers (Part Properties). This blank line (a sequence of CRLF
CRLF) marks the boundary between the headers and the body data. These CRLFs are automatically
inserted by NMIT when it creates MMS messages. As defined in RFC 2822 [12]:

Forum.Nokia.com
“Messages are divided into lines of characters. A line is a series of characters that is delimited with the
two characters carriage-return and line-feed; that is, the carriage return (CR) character (ASCII value 13)
followed immediately by the line feed (LF) character (ASCII value 10). (The carriage-return/line-feed
pair is usually written in this document as 'CRLF'.)
A message consists of header fields (collectively called "the header of the message") followed,
optionally, by a body. The header is a sequence of lines of characters with special syntax as defined in
this standard. The body is simply a sequence of characters that follows the header and is separated
from the header by an empty line (i.e., a line with nothing preceding the CRLF).”
Therefore, a blank line (or two sets of CRLF) is used to show the end of a set of headers and the
beginning of body data. The absence of a CRLF can cause the message to be deformed or interpreted
incorrectly.
The following sample is a hex dump of the same message that is displayed above. In hexadecimal,
CRLF is displayed as 0x0D and 0x0A. This is a sample taken from the mobile device (MM1 Interface), so
the MMS message headers have been Wireless Session Protocol (WSP) binary encoded.
. . . . . . . . .
Figure 26: MMS message example in hex mode
4.4.2 DRM forward-lock object in MMS message with SMIL
DRM objects are not different from any other object when used in SMIL. The .dm object is referenced in
the SMIL file by using Content-ID or Content-Location methods. Then, the DRM object is attached to the
MMS message.
Therefore, a SMIL file referencing an image that has been DRM wrapped in DRM (in a file named
sample_image.dm) might look like this:

Forum.Nokia.com
<?xml version="1.0"?>
<!DOCTYPE smil PUBLIC "-//W3C//DTD SMIL 1.0//EN" "http://www.w3.org/TR/REC-
smil/SMIL10.dtd">
<smil xmlns="http://www.w3.org/2000/SMIL20/CR/Language">
<head>
<layout>
<root-layout width="160" height="140"/>
<region id="Image" height="120" width="160" left="0" top="0"/>
<region id="Text" height="20" width="160" left="0" top="120"/>
</layout>
</head>
<body>
<par>
<img region="Text" src="cid:CID2" />
<img region="Image" src="cid:CID1"/>
</par>
</body>
</smil>
The full MMS message for this sample SMIL is shown in Figure 27.
Figure 27: MMS message containing SMIL and DRM object
NMIT does not only create MMS messages, but using the MMS creation wizard, it can also automatically
create an associated SMIL file for presentation. Afterwards, NMIT can be used in conjunction with a
variety of Nokia mobile device emulators to test and view created MMS messages.
The message sample in Figure 27 was taken from a packet sniffer on the MM1 interface (between the
WAP gateway and the mobile device) after the message had left the Multimedia Messaging Service
(MMSC). The MMS message consists of a SMIL presentation with one image and one text object.

Forum.Nokia.com
--------------------------------------------------------------
Wireless Session Protocol

PDU Type: Reply (0x04)
Status: OK (0x20)
Headers Length: 40
Content Type: application/vnd.wap.mms-message
Headers
Date: May 1, 2003 11:18:49.000000000
Accept-Ranges: None (0x00)
Data --------------------------------------------------------------
MMS Message Encapsulation
Message-Type: m-retrieve-conf (0x84)
Transaction-ID: PrFImENBX8QAADAPAAAAAQAAAAUAAAAA
MMS-Version: 1.0
Date: May 1, 2003 11:20:07.000000000
From: sampleMMS@forum.nokia.drm.com
Subject: Here is a DRM object in SMIL
To: +12125551212/TYPE=PLMN
Message-Class: Personal (0x80)
Delivery-Report: No (0x81)
Content Type: application/vnd.wap.multipart.related (0x33)
Type: application/smil
Start: <0000>
Data (Post) --------------------------------------------------------
Multipart body
Part: 1
Content Type: application/vnd.oma.drm.message;
boundary=”random78o6bP%[GB6b/8&/45&%*^'?vS”
Content-ID: <GoldFish.dm>
Data ---------------------------------------------------
00e0 8e 47 6f 6c 64 46 69 73 68 2e 64 6d 00 2d 2d 72 .GoldFish.dm.--r
00f0 61 6e 64 6f 6d 37 38 6f 36 62 50 25 5b 47 42 36 andom78o6bP%[GB6
0100 62 2f 38 26 2f 34 35 26 25 2a 5e 27 3f 76 53 0d b/8&/45&%*^'?vS.
0110 0a 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 69 .Content-Type: i
0120 6d 61 67 65 2f 67 69 66 0d 0a 43 6f 6e 74 65 6e mage/gif..Conten
0130 74 2d 54 72 61 6e 73 66 65 72 2d 45 6e 63 6f 64 t-Transfer-Encod
0140 69 6e 67 3a 20 62 61 73 65 36 34 0d 0a 0d 0a 2f ing: base64..../
0150 39 6a 2f 34 41 41 51 53 6b 5a 4a 52 67 41 42 41 9j/4AAQSkZJRgABA
0160 51 45 41 53 41 42 49 41 41 44 2f 32 77 42 44 41 QEASABIAAD/2wBDA
. . . . . .
0d70 58 4b 34 4a 46 5a 4a 51 63 45 2b 47 5a 4b 59 6a XK4JFZJQcE+GZKYj
0d80 43 41 49 41 67 43 41 49 41 67 43 41 49 44 2f 2f CAIAgCAIAgCAID//
0d90 5a 0d 0a 2d 2d 72 61 6e 64 6f 6d 37 38 6f 36 62 Z..--random78o6b
0da0 50 25 5b 47 42 36 62 2f 38 26 2f 34 35 26 25 2a P%[GB6b/8&/45&%*
0db0 5e 27 3f 76 53 2d 2d 1d 84 3b 13 61 70 70 6c 69 ^'?vS--
Part: 2
Content Type: application/smil
Charset: us-ascii (0x0003)
Headers
Content-ID: <0000>
Data ---------------------------------------------------
. . . . . .
Part: 3
Content Type: text/plain (0x03)
Charset: us-ascii (0x0003)
Headers
Content-ID: <TestText.txt>
Data ---------------------------------------------------
. . . . . .
Figure 28: Example of MMS message from the MM1 interface
4.5 Tips for working with Series 40 MMS clients
Messaging developers have the ability to use MMS (with the addition of SMIL support, supported from
Series 40 2nd Edition onwards). The MMS client will display the multipart/related MMS messages as
defined in the SMIL presentation, for example, as animated slide shows. This will not affect DRM
objects, and all Series 40 mobile devices that have OMA DRM 1.0 functionality will decode and protect
media objects regardless of the presence of a SMIL presentation.

Forum.Nokia.com
Note that most Nokia Series 40 1st Edition devices do not have a SMIL player. In these platforms, the
MMS client will accept the MMS message, and objects (including DRM objects) will be displayed as if the
message is a multipart/mixed message.
When creating MMS messages and attaching DRM objects, it is important to follow the industry-
defined format as outlined in OMA [1] and IETF [15] specifications. Any oddities (such as an extra
semicolon or the absence of a carriage return) may cause errors in interpreting the MMS message or
the DRM object. Review the examples given in Section 3.3, “HTTP messages,” for details about MMS
message formats.
For more information about device support for MMS messages, see the document Messaging
Characteristics In Nokia GSM Devices [13] available at www.forum.nokia.com.
4.6 Tips for working with S60 MMS clients
S60 devices provide more functionality than Series 40 devices, and therefore support a larger list of
file formats and content types. However, not all content types supported on the device are also
supported in DRM functionality. For more information about acceptable content types for MMS
messages, please see the document Messaging Characteristics in Nokia GSM Devices [13] available at
www.forum.nokia.com. The S60 MMS client will search the MMS headers and the SMIL tags for any
instructions for displaying the MMS objects; however, if there is no standard reference from the SMIL
to the MMS objects, then the message may not be displayed as intended. Remember that either
Content-ID or Content-Location should always be used to reference MMS objects to SMIL.
It is possible that some mobile devices may have support for DRM forward-lock support for browser
downloads, but not for MMS objects. Please check the Device Specifications table at
http://www.forum.nokia.com/devices for details about DRM support for individual mobile devices.

Forum.Nokia.com
5 Creating and distributing OMA DRM 2.0 content

The Nokia implementation of OMA DRM 2.0 complies with the robustness and compliance
requirements of the Content Management License Administrator (CMLA), which maintains and
enforces the trust model for the PKI specified by the standard. CMLA defines compliance and
robustness rules for both providers and consumers of OMA DRM 2.0 content. This means that it is not
possible to use the OMA DRM 1.0 tools from Forum Nokia to package and distribute OMA DRM 2.0
content. Packaging and distribution may only be done by entities that meet the requirements of CMLA
licensing.
More information about CMLA and its requirements is available at http://www.cm-la.com.

Forum.Nokia.com
6 OMA DRM support in Nokia devices

Forward-lock is supported by all Series 40 and S60 devices (forward-lock for SIS files was introduced in
S60 2nd Edition). Full OMA DRM 1.0 (that is, forward-lock, combined delivery, and separate delivery) is
supported from Series 40 2nd Edition onwards. In the S60 platform, combined delivery and separate
delivery were introduced as optional features in S60 2nd Edition, Feature Pack 2. Newer Nokia
devices, for example, devices based on S60 3rd Edition, support full OMA DRM 1.0, except for Nokia
Eseries devices, which support only forward-lock.
From Series 40 3rd Edition and S60 3rd Edition onwards, some devices may also support DRM 2.0.
For futher information on DRM support in different Nokia devices, see the DRM table at the Forum
Nokia DRM Technology section [21] or Forum Nokia Device Specifications [22]. The device
specifications are updated regularly with information about new mobile devices.

Forum.Nokia.com
7 Terms and abbreviations
Term or abbreviation Description

CCL Closed Content List
CEK Content Encryption Key
CMLA Content Management License Administrator
COD Content Object Descriptor
DCF DRM Content Format
DRM Digital Rights Management
ETSI European Telecommunication Standardization Institute
GIF Graphical Interchange Format
HTTP Hypertext Transfer Protocol
IETF Internet Engineering Task Force
IP Internet Protocol
JPEG Joint Photographic Experts Group
MIME Multipurpose Internet Mail Extensions
MSISDN Mobile Subscriber Integrated Services Digital Network
(telephone number of device)
MMS Multimedia Messaging Service
MMSC Multimedia Messaging Service Center
NCPT Nokia Content Publishing Toolkit
NMIT Nokia Mobile Internet Toolkit
OMA Open Mobile Alliance
OTA Over the Air
REL Rights Expression Language
RFC Request for Comments
SMIL Synchronized Multimedia Interface Language
SMS Short Message Service
SMSC Short Message Service Center
TCP/IP Transmission Control Protocol/Internet Protocol
TIA Telecommunication Industry Association
WAP Wireless Application Protocol
WDP Wireless Datagram Protocol
WSP Wireless Session Protocol

Forum.Nokia.com
8 References
[1] OMA Digital Rights Management version 1.0, OMA (http://www.openmobilealliance.org/)
[2] User's Guide for Nokia Mobile Internet Toolkit 4.1, Forum Nokia (http://www.forum.nokia.com/)
[3] RFC 2045; Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message
Bodies, The Internet Engineering Task Force (http://www.ietf.org/rfc/rfc2045.txt)
[4] OMA Digital Rights Management version 1.0; DRM Content Format, OMA (OMA-Download-DRMCF-
V1_0-20031113-C) (http://www.openmobilealliance.org/)
[5] RFC 2396; Uniform Resource Identifiers (URI): Generic Syntax, The Internet Engineering Task
Force (http://www.ietf.org/rfc/rfc2396.txt)
[6] OMA Digital Rights Management version 1.0; OMA Download OTA, OMA (OMA-Download-OTA-
v1_0-20030221-C) (http://www.openmobilealliance.org/)
[7] Getting Started With WAP Push, Forum Nokia (http://www.forum.nokia.com/)
[8] OMA Digital Rights Management version 1.0; Rights Expression Language, OMA (OMA-Download-
DRMREL-V1_0-20031031-C) (http://www.openmobilealliance.org/)
[9] WAP Binary XML Content Format, World Wide Web Consortium (W3C)
(http://www.w3.org/TR/wbxml/)
[10] RFC 1521; MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying
and Describing the Format of Internet Message Bodies, The Internet Engineering Task Force
(http://www.ietf.org/rfc/rfc1521.txt)
[11] Getting Started with MMS Tools, Forum Nokia (http://www.forum.nokia.com/)
[12] RFC 2822; Internet Message Format, The Internet Engineering Task Force
(http://www.ietf.org/rfc/rfc2822.txt)
[13] Messaging Characteristics In Nokia GSM Devices, Forum Nokia (http://www.forum.nokia.com/)
[14] RFC 1522; MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for
Non-ASCII Text, The Internet Engineering Task Force (http://www.ietf.org/rfc/rfc1522.txt)
[15] The Internet Engineering Task Force (http://www.ietf.org/)
[16] OMA Digital Rights Management Version 2.0, OMA (http://www.openmobilealliance.org)
[17] Browser Characteristics in Nokia GSM Devices (www.forum.nokia.com)
[18] Getting Started with MMS Tools (www.forum.nokia.com)
[19] How to Create MMS Services (www.forum.nokia.com)
[20] Native Symbian OS Applications OTA: New Opportunities to Drive ARPU

(www.forum.nokia.com)
[21] Nokia DRM and Download Technologies section (http://www.forum.nokia.com/drm)

Forum.Nokia.com
[22] Forum Nokia Device Specification (http://forum.nokia.com/devices)
Further reading:
Nokia Devices Technical Specification

http://www.nokia.com/phones
Introduction to Nokia Messaging Technologies

http://www.forum.nokia.com/messaging
Introduction to Nokia Browsing Technologies

http://www.forum.nokia.com/browsing
Forum Nokia Discussion Board

http://discussion.forum.nokia.com/forum

Forum.Nokia.com
Appendix A
A.1 Closed content list – how it works
Nokia is currently supporting a forward-lock solution called the Nokia Closed Content List (CCL) in all
devices. With the introduction of OMA DRM 1.0 technology, the existing solution will be modified to
ensure a flexible transition period for content providers to adapt to OMA DRM 1.0. The solution will
eventually be removed from Nokia devices when OMA DRM 1.0 is widely adopted.
Nokia CCL is a so-called Device Policy forward-lock solution, which means the device is hard coded
from the factory not to forward certain content. The implemented solution works based on MIME type
recognition and allows the device to register content as copy protected based on this information.
To understand how Nokia CCL works, a little background information on MIME types is needed.
A.1.1 MIME types
MIME types are specified in the Internet RFCs 1521 [10] and 1522 [14]; they allow the transmission of
various types of content over a network.
MIME types work by allowing a server to add MIME type information to any network transmission. The
receiving client can use this information to forward the content to the appropriate “player.”
To ensure a common interpretation of MIME types, these are registered with the Internet Assigned
Numbers Authority (IANA). MIME types can be of different types. Some are deemed as being of general
interest to the Internet community, while others can be vendor-specific.
Example:
Audio/AMR (IETF tree)
Application/vnd.Nokia.ringing-tone (Vendor tree)
The Nokia CCL solution uses MIME types to ensure that content is delivered to the appropriate
application, as well as to register in the file system whether a specific piece of content should be
forward-locked or not.
Example:
MIME: image/jpeg Content type: jpeg Can be forwarded
MIME: image/vnd.nok-wallpaper Content type: jpeg Is blocked from forwarding
The above example shows how applying a specific MIME type during the distribution phase can
protect a piece of content. In this case, the MIME type is vendor-specific (Nokia wallpaper). In the case
of MIDI ring tones, no such vendor-specific MIME type exists for Nokia devices. For MIDI ring tones, the
standard MIDI MIME types are used for copy protection depending on the version of the CCL. However,
the SP-MIDI MIME type is always forward-locked.
As all ring tone MIME types are handed off to the same “player” in Nokia devices, any kind of ring tone
can be distributed as any kind of MIDI MIME type. The actual player recognizes the content type based

Forum.Nokia.com
on the content itself, not the MIME type, and will render the content appropriately. This is what allows
the different MIDI MIME types and content types to be matched in order to achieve the desired
forwarding scenario.
Example for CCL Version 2.0
MIME: audio/midi Content type: midi Can be forwarded
MIME: audio/midi Content type: sp-midi Can be forwarded
MIME: audio/sp-midi Content type: midi Is blocked from forwarding
A.2 Closed content list – versions
A.2.1 Nokia Closed Content List 1.0
Content Type Name File Extension MIME Type

DRM Message .dm application/vnd.oma.drm.message
OMA rights .dr application/vnd.oma.drm.rights+xml

OMA rights, binary .drc application/vnd.oma.drm.rights+wbxml
MRV .mrv application/x-mrv.xml
application/x-mrv.wbxml
MRM .mm application/x-mrm-text
Ringing tone .ott application/vnd.nokia.ringing-tone
AMR-WB (SAAT) .awb audio/amr-wb
MIDI .mid audio/sp-midi
audio/midi
audio/mid
audio/x-midi
audio/rmf
audio/x-rmf
3D screensaver .c3d image/vnd.nok-3Dscreensaver
Wallpaper .gif/.jpg/.jpeg/.png image/vnd.nok-wallpaper
Operator logo .opl image/vnd.nok-oplogo
Operator logo color .gif/.jpg/.jpeg image/vnd.nok-oplogo-color
Nokia game pack .ngd application/x-NokiaGameData
Java archive .jar application/java
application/java-archive
application/x-java-archive
Symbian game pack .ngd application/x-NokiaGameData
Symbian installation package .sis application/vnd.symbian.install

Forum.Nokia.com
A.2.2 Nokia Closed Content List 2.0
Content Type Name File Extension MIME Type

DRM message .dm application/vnd.oma.drm.message
OMA rights .dr application/vnd.oma.drm.rights+xml

OMA rights, binary .drc application/vnd.oma.drm.rights+wbxml
Ringing tone .ott application/vnd.nokia.ringing-tone
AMR-WB (SAAT) .awb audio/amr-wb
MIDI .mid audio/sp-midi
3D screensaver .c3d image/vnd.nok-3Dscreensaver
Wallpaper .gif/.jpg/.jpeg/.png image/vnd.nok-wallpaper
Operator Logo .opl image/vnd.nok-oplogo
Operator Logo Colour .gif/.jpg/.jpeg image/vnd.nok-oplogo-color
JAVA Archive .jar application/java
application/java-archive
application/x-java-archive
Symbian Game Pack .ngd application/x-NokiaGameData

Symbian installation package .sis application/vnd.symbian.install

Forum.Nokia.com
APPENDIX B
B.1 DRM objects and cached content
One additional concern with the download of DRM content may be the cached content on mobile
browsers or any proxy caches between the server and the client browser. This could allow for multiple
copies of data that should only be allowed to be downloaded and installed once.
Although this data is very difficult to copy from a mobile client browser’s cached memory, it is a
simple and safe precaution to use HTTP Cache-Control headers when delivering server-side. From the
download server, when delivering your DRM object in an HTTP message, make sure to include the
Cache-Control header with “no-cache” values as shown here:
Cache-Control: no-store, no-cache, must-revalidate
B.2 Example
For example, PHP scripts are often used to generate dynamic content. When using DRM, this content
should not be allowed to be cached by the client browser or any proxy servers. Many proxies and
clients can be forced to disable caching with the following addition to the PHP script:
<?php
header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");
// Date in the past
header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");
// always modified
header("Cache-Control: no-store, no-cache, must-revalidate");
// HTTP/1.1
header("Cache-Control: post-check=0, pre-check=0", false);
header("Pragma: no-cache");
// HTTP/1.0
?>
You may find that pages are not cached even if you don't output all of the headers above. There are a
number of options that users may be able to set for their browser that change its default caching
behavior. By sending the headers above, you should override any settings that may otherwise cause
the output of your script to be cached.

Forum.Nokia.com
Evaluate this resource

Please spare a moment to help us improve documentation quality and recognize the resources you
find most valuable, by rating this resource.

DRM Developers Guide For Nokia Devices v3 0 en

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

DRM Developers Guide For Nokia Devices v3 0 en

Hochgeladen von

Copyright:

Verfügbare Formate

F O R U M N O K I A

DRM Developer’s Guide for Nokia Devices

Version 3.0; October 20, 2006

DRM Developer’s Guide for Nokia Devices 2

4.1 MMS message format........................................................................................................................... 32

DRM Developer’s Guide for Nokia Devices 3

5 May 2004 V2.0 Replaces the Forum Nokia document ‘DRM

DRM Developer’s Guide for Nokia Devices 4

Copyright © 2003-2006 Nokia Corporation. All rights reserved.

DRM Developer’s Guide for Nokia Devices 5

1.1 OMA DRM 1.0

DRM Developer’s Guide for Nokia Devices 6

1.2 OMA DRM 2.0

DRM Developer’s Guide for Nokia Devices 7

2 Protecting content with OMA DRM 1.0

2.1 How to protect media objects with OMA DRM 1.0

1. Select the DRM message type.

2. Load the media content.

5. Save the message.

DRM Developer’s Guide for Nokia Devices 8

Figure 1: The DRM message window

2.1.1 Selecting message type

Figure 2: Selecting message type

DRM Developer’s Guide for Nokia Devices 9

2.1.2 Loading media content

Figure 3: Loading media content

DRM Developer’s Guide for Nokia Devices 10

2.1.3 Editing headers

2.1.3.1 Required header

Figure 5: Required headers for separate delivery message type

2.1.3.1.1 MIME Type

2.1.3.2 Optional header

Figure 6: Optional headers for separate delivery message type

DRM Developer’s Guide for Nokia Devices 11

2.1.3.3 Rights Issuer

2.1.3.4 Content Name

The Content Name is the descriptive name of DRM-protected content.

2.1.3.5 Content Description

The Content Description describes the DRM-protected content.

2.1.3.6 Content Vendor

2.1.3.7 Icon URI

2.1.4 Specifying rights

DRM Developer’s Guide for Nokia Devices 12

2.1.4.1 Permissions and constraints

2.1.4.2 Encryption key

2.1.5 Saving message

DRM Developer’s Guide for Nokia Devices 13

2.2.1 Application packaging

DRM Developer’s Guide for Nokia Devices 14

PIP File (DCF Format)

Figure 8: Overview of a PIP file

2.2.2 Definition file format

Below is an example of a definition file.

DRM Developer’s Guide for Nokia Devices 15

2.3 How to protect themes with OMA DRM 1.0

DRM Developer’s Guide for Nokia Devices 16

3 Delivering OMA DRM 1.0 content to mobile devices

1. OMA Download Over the Air (OMA DL OTA)

2. Java Application Descriptor (JAD)

3. Content Object Description (COD; Nokia proprietary method)

3.1.1 OMA Download

DRM Developer’s Guide for Nokia Devices 17

1) User selects the link addressing the