drm developers guide for nokia devices v3 0 en

DRM Developer’s Guide for Nokia Devices

Version 3.0; October 20, 2006

DRM

F O R U M N O K I A

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:

Media object Rights object

Message format MIME multipart - 1 part (media object)

MIME multipart - 2 parts (rights object and

media object)

OMA specified DRM Content Format (DCF)

for media object

OMA specified Rights Expression Language (REL)

Rights object No

Rights delivered in single file with media

object (XML representation format)

Rights delivered separately

XML representation or WAP Binary XML (WBXML) content format (used for transmission over constrained bearers like WAP Push over SMS)

Forward lock (terminal) Yes Yes No Yes

Encryption (server) No No AES symmetric encryption

No, SMS used to provide safe delivery

Encryption (terminal) Yes, with terminal- specific key

Yes, with terminal-specific key

No (object encrypted on the server side) No

Encoding Media object encoded with Base64 or binary

Media object encoded with Base64 or binary - -

File extension .dm .dm .dcf .dr (XML representation) / .drc (WBXML)

Separate delivery Forward-lock Combined delivery

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.


http://www.forum.nokia.com/

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].


http://www.forum.nokia.com/info/sw.nokia.com/id/d9fb4771-43f0-48ab-a4d5-5bfa1734e8cd/NMIT4.1_User_Guide_v1_0.pdf.html


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.


http://www.forum.nokia.com/info/sw.nokia.com/id/44c00aa0-dd42-4258-989a-9dda6980cec3/Symbian_OTA_Whitepaper_v1_3_en.pdf.html


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 XHTML or WML page

OMA

Download Descriptor file

(.dd)

E.g.,

image content in DRM

wrapper (.dm)

2) Device fetches the descriptor file (.dd) and parses its contents

3) User accepts or cancels the content

4) If user accepts the download, device fetches the actual DRM-wrapped content (.dm)

page.xhtml: ... <a href=“desc_sample.dd”>link</a> ...

desc_sample.dd: ... <media xmlns="http://www.openmobilealliance.org/xmlns/dd">

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.


http://www.forum.nokia.com/drm

Forum.Nokia.com


Java

Application Descriptor file (.jad)

Java MIDlet

in DRM wrapper

(.dm)

2) Device fetches the descriptor file (.jad) and parses its content

3) User accepts or cancels the content download


desc_Test_MIDlet.jad: MIDlet-Jar-URL: Test_MIDlet.dm ...

page.xhtml: ... <a href=“desc_Test_MIDlet.jad”>link</a> ...

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.


http://java.sun.com/javame/

Forum.Nokia.com

Content Object

Descriptor file (.cod)

E.g.,


wrapper (.dm)

2) Device fetches the descriptor file (.cod) and parses its content

3) User accepts or cancels the content


page.xhtml: ... <a href=“desc_sample.cod”>link</a

desc_sample.cod: COD-URL: sample.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 DRM-wrapped content from the XHTML or WML page

E.g.,


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.

4) Rights object is sent to device via the Push Proxy Gateway and Short Message Service Center

OMA


(.dd)

E.g., image content in

encrypted DCF format (.dcf)

1) User browses on content provider’s XHTML page and selects the link of the content (the link of the .dd file of the content)

contents.xhtml: ... <a href src=”desc_xx.dd”>link</a> ...

3) DCF file is fetched to the device with X-Oma-Drm-Separate-Delivery HTTP header

Rights object of the DCF

content (.dr)

2) Descriptor file (.dd) is fetched to the device and user accepts the download

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


OMA


(.dd)

1) User browses on content provider’s XHTML page and selects the link of the content (the link of the .dd file of the content)

contents.xhtml: ... <a href 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 (no X-Oma-Drm-Separate-Delivery added)


content (.dr)

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

rights.xhtml: ... <a href src=”ro_xx_yy”>1 month</a> ...

E.g., image content in

encrypted DCF format (.dcf)

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)

1) The rights of the DCF content in the user’s device is expired


content (.dr)


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.


2) User B’s device initiates the browsing session to the Content Provider URL defined in the Rights-Issuer header of the DCF content. The server of the content provider responds to the request by sending the XHTML page to user


content (.dr)

3) User B selects the rights which (s)he is willing to buy by selecting the corresponding link from the XHTML page


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

(.dcf) User A User B

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

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

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—

HTTP-specific part

DRM forward-lock message part

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

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>

<o-dd:uid>cid:20141-9729@http://contentpro.com</o-dd:uid>

</o-ex:context>

<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 >


...jpeg image in binary format...


HTTP-specific part

Combined delivery message part 2: image content

Combined delivery message part 1: rights object

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;

Content-Length: xxx

X-OMA-DRM-SEPARATE-DELIVERY: 12

...DRM content in DCF file...

HTTP-specific part

Original content 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.


http://www.forum.nokia.com/info/sw.nokia.com/id/2767411d-e334-4874-b479-6fcf02d2fd55/Getting_Started_With_WAP_Push_v1_1_en.pdf.html


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

application/vnd.oma.drm.message The MIME type of the OMA forward-lock and OMA combined delivery message (file extension *.dm)

application/vnd.oma.drm.content The MIME type of the OMA DRM 1.0 Content Format (file extension *.dcf)

application/vnd.oma.drm.rights+xml

or

application/vnd.oma.drm.rights+wbxml

The MIME type of the OMA rights object (textual XML representation and WBXML) (file extension *.dr for textual or *.drc for WBXML)

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

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

text/x-co-desc The MIME type of the Nokia COD method (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.

.

Content-Type: application/vnd.mms.message

Header

Content

..

Content-Type: application/vnd.mms.message

Header

Content

MMS Message Body

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

MMS Message Body


…

Header of MMS Object 1

Encoded_Image1.dmDRM Forward-lock Wrapped Object

MMS Message Header

Encoded_Image2.dmDRM Forward-lock Wrapped Object

. . . Content-Type: application/vnd.oma.drm.message; boundary=“testboundary1”Content-ID:<CID1>

--testboundary1Content-Transfer-Encoding: base64Content-Type: image/jpeg… contents of encoded Image1…--testboundary1--


--testboundary1Content-Transfer-Encoding: base64Content-Type: image/jpeg… contents of encoded Image1…--testboundary1--


--testboundary2Content-Transfer-Encoding: binaryContent-Type: image/gif… contents of encoded Image2…--testboundary2--


--testboundary2Content-Transfer-Encoding: binaryContent-Type: image/gif… contents of encoded Image2…--testboundary2--

Header of theDRM Wrapper

. . .Content-Type: text/plainContent-ID:<CID0>

…text file …


…text file … Sample_text.txtMessage Text



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.

.

Content-Type: application/vnd.mms.messageHeader

Content

..


Content

MMS Message Body


MMS Message Body


Header MMS Object 1

Encoded_Image.dmDRM Combined Delivery Wrapped Object

MMS Message Header

. . . Content-Type: application/vnd.oma.drm.message; boundary=“atestboundary”Content-ID:<CID1>



…text file … Sample_text.txtAttached plain text file

--atestboundary

--atestboundary

--atestboundary--

Rights Object

Content-Transfer-Encoding: binaryContent-ID: <959816597@http://www.forum.nokia.com>Content-Type: image/gif… contents of binary encoded Image…

Content-Transfer-Encoding: binaryContent-ID: <959816597@http://www.forum.nokia.com>Content-Type: image/gif… contents of binary encoded Image…

Media Object

Content-Type: application/vnd.oma.drm.rights+xmlContent-Transfer-Encoding: binary… contents of XML rights file…

Content-Type: application/vnd.oma.drm.rights+xmlContent-Transfer-Encoding: binary… contents of XML rights file…

Header MMS Object 0

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.

.


Content

..


Content

MMS Message Body



Encrypted_Image.dcfDRM Content FormatEncrypted Object

MMS Message Header

. . . Content-Type: application/vnd.oma.drm.content;Content-ID:<CID1>X-Oma-DRM-Separate-Delivery: 18


…text file … Sample_text.txtAttached plain text file

…contents of DCF file…


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


http://www.forum.nokia.com/info/sw.nokia.com/id/3c587a80-262d-43eb-bcc4-530e10d4b353/Getting_Started_with_Nokia_MMS_Tools_v1_0.pdf.html

http://www.forum.nokia.com/info/sw.nokia.com/id/a57a4f20-b7f2-475b-b426-19eff18a5afb/How_To_Create_MMS_Services_v4_0_en2.pdf.html


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: [email protected] 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.


http://www.forum.nokia.com/info/sw.nokia.com/id/7c3c318d-f20f-4dcb-91ae-4463dae3226b/Messaging_Characteristics_In_Nokia_GSM_Devices_v2_0_en.pdf.html





http://www.forum.nokia.com/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.


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.




http://forum.nokia.com/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)


http://www.openmobilealliance.org/



http://www.ietf.org/rfc/rfc2045.txt




http://www.forum.nokia.com/info/sw.nokia.com/id/2767411d-e334-4874-b479-6fcf02d2fd55/Getting_Started_With_WAP_Push_v1_1_en.pdf.html



http://www.w3.org/TR/wbxml/








http://www.ietf.org/


http://www.forum.nokia.com/info/sw.nokia.com/id/bb61897c-ef67-4879-9c35-1aca20745f45/Browser_Characteristics_in_Nokia_GSM_Devices_v1_9_en.pdf.html




http://www.forum.nokia.com/info/sw.nokia.com/id/a57a4f20-b7f2-475b-b426-19eff18a5afb/How_To_Create_MMS_Services_v4_0_en2.pdf.html





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


http://forum.nokia.com/devices

http://www.nokia.com/phones

http://www.forum.nokia.com/messaging

http://www.forum.nokia.com/browsing

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 text/vnd.sun.j2me.app-descriptor

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 text/vnd.sun.j2me.app-descriptor

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.


http://www.forum.nokia.com/main/1%2C%2C90%2C00.html?surveyId=f269e8db-bb9b-4de8-9009-bb9c2ec810f2/DRM_Developers_Guide_for_Nokia_Devices_v3_0_en.pdf

drm developers guide for nokia devices v3 0 en

Documents