Default Provisioning Implementation: OTA Provisioning


This chapter describes how application suites and LIBlets are provisioned if an implementation chooses OTA (Over the Air) Provisioning as an implementation of the Provisioning algorithm as generally described here.

As emphasized in the Provisioning chapter, there MUST be only one provisioning mechanism in a concrete implementation and it must remain unchanged. For OTA provisioning this means that, if OTA provisioning is implemented in a certain implementation, there MUST NOT be any other way to install, update or delete application suites and LIBlets in this implementation.

All statements made in the Provisioning chapter are also valid here. The following statements have to be additionally considered if an OTA Provisioning implementation is chosen.

Installation Mechanisms

The default installation mechanism for OTA provisioning as defined in the IMP-NG specification is the one via HTTP/HTTPS protocol. This installation mechanism is likely to be the most popular one for OTA Provisioning in MEEP 8 as well (chosing HTTP or HTTPS, whatever the respective MEEP 8 implementation supports).

On the other hand, other installation mechanisms (e.g. Bluetooth TM wireless technology, serial cable, IrDA TM, etc.) are mentioned to be possibly supported by devices, but stated as outside the scope of this specification. Here, we will speak of all these as "external triggers" to initiate OTA User Provisioning. Also "internal triggers" such as Timer events or requests from running Java applications are solutions one can think of.

Functional Requirements for OTA Provisioning

An OTA provisioning compliant device MUST be capable of:

Application Suite and LIBlet Lifecycle


Everything stated in the Discovery section of the Provisioning chapter applies, and in addition the following OTA Provisioning specific requirements MUST be fulfilled:

OTA Application Suite Provisioning

As mentioned before, the mechanism of discovery (if supported) is out of scope of this specification. If the location of an application suite or LIBlet refers to a JAR as described in the application specification, the JAR and its URL are passed to the AMS on the device to start the installation process. If the link refers to an Application Descriptor, as described in the this specification, the following steps are performed:

  1. Once the application suite or LIBlet has been located, the server MUST indicate in the response that the data being transferred (i.e., the Application Descriptor) has a MIME type of text/
  2. After completing this transfer, the Application Descriptor and its URL are passed to the AMS on the device to start the installation process. The Application Descriptor is used by the AMS to determine if the associated application suite or LIBlet can be successfully installed and executed on the device. This may involve transfer of Application Descriptors of any LIBlets the application suite or LIBlet depends on, if any LIBlet dependencies are specified by the application suite or LIBlet.

  3. If Application Descriptor is delivered in a transport format that is not the Unicode encoding that is specified by the specification it MUST be converted before it can be used. The default character set specified for the MIME type text/ is UTF-8. If the device supports other character sets, the appropriate Accept-Charset header SHOULD be included in the request, and the content MUST be converted based on the charset attribute returned on the Content-Type header. If charset is undefined, the encoding defaults to UTF-8, and it MUST be converted accordingly. It is expected that an implementation is able to recognize and convert the transport format used, otherwise the installation MUST fail.

    The attributes in the Application Descriptor MUST be formatted according to the syntax defined in Application Attributes; otherwise the provisioning MUST fail. All of the application attributes designated as mandatory by Appendix A MUST be present in the Application Descriptor; if this is not the case, the provisioning MUST fail. If the Application Descriptor contains any application attributes that are allowed only in the Jar manifest (see Appendix A), then the provisioning MUST fail.

Installation of Application Suites and LIBlets

To install an application suite or LIBlet, the AMS performs the following series of steps and checks and MAY provide the user with feedback about the progress:

  1. The device initiates the download of the application suite or LIBlet. Every download of an application descriptor by the AMS for installation or update MUST supply the headers needed by UAProf for Device Identification. If an Application Descriptor was first downloaded as described in the Discovery section either without the UAProf headers or if it is unknown whether the headers were sent and the descriptor includes the MIDlet-Profile-Request: true attribute then the download of the descriptor must be repeated using the URL of the descriptor and including the headers required by UAProf. The new descriptor supersedes the original descriptor in the processing that follows. The requests for downloading descriptors and JARs in the application suite or LIBlet MUST be for exactly the URL specified in the descriptor; additional headers are unnecessary.
  2. If the server or proxy responds to the request for the application suite with a 401 (Unauthorized) or 407 (Proxy Authentication Required), the device MAY re-send the request with the appropriate credentials in an Authorization or Proxy-Authorization header field as specified in [RFC2617]. The device MUST be able to support at least the Basic Authentication Scheme as described in [RFC2617].
  3. If the OTA takes place via IP, and MIDlet-Required-IP-Version attribute is specified, and that IP version is not supported by the implementation, the installation MUST fail (see Status Codes for Status Reporting).

    In case the OTA does not take place via IP, the MIDlet-Required-IP-Version attribute, if specified, is ignored with respect to OTA.

  4. If the JAR is not available at the MIDlet-Jar-URL or LIBlet-Jar-URL attribute in the descriptor, the installation MUST fail. Similarly, if a dependency LIBlet is not already installed on the device and the JAR is not available at the LIBlet-Jar-URL, the installation of the dependent application suite or LIBlet MUST fail (see Status Codes for Status Reporting).

Automatic Application Update

If the provisioned application suite has the MIDlet-Update-URL attribute in the JAD file or the JAR manifest, the implementation MUST use it to configure the automatic update feature. The value of this attribute MUST either be empty or contain a valid URL. For details, see the description of the MIDlet-Update-URL attribute in Application Attributes.

Application Suite and LIBlet Update

If RMS is supported by the implementation, the handling of RMS record stores of an untrusted application suite or LIBlet when being updated is the following:

Status Reports

The operation status is reported by means of an HTTP POST request to the relevant URL specified. The server is expected to respond with a valid HTTP response. For an example of a status report, see Example: Install Status via HTTP Post Request. Status reports are only sent for application suites or LIBlets downloaded Over The Air (OTA).

The body of the POST request MUST include a status code and status message on its first line. See Provisioning Status Codes and Messages for a list of valid status codes and suggested status messages. The messages are informational only.

The implementation MUST transcode the request body into UTF-8, and MUST set the Content-Type entity-header field of the request as follows:

            Content-Type: text/plain; charset=utf-8

If the server receives the status report successfully, it MUST reply with a 2xx response code (typically 200 OK) and SHOULD NOT include a message body. Any content in the message body MUST be ignored by the implementation.

Since the body of the status report is short and simple, the implementation SHOULD NOT set the Expect: 100-continue header in the request, and MAY ignore any 100 Continue response sent by the server.

For other typical server responses, the implementation MUST maintain a retry count and attempt to retry the sending of the report as follows:

Device Identification and Request Headers

The process of discovering an application suite or LIBlet via the DA can be customized by the device sending information about itself to the server. The DA MAY provide the network server with information (e.g. the manufacturer and device model number) so that the server can determine the device's capabilities. In many cases, a DA will already have identified the device type to the server by means consistent with its network connection and markup language.

During the download of an application suite or LIBlet, a device SHOULD identify its characteristics and the type of the content being requested as completely as possible to the server. The HTTP request headers used to fetch the content MUST include User-Agent, Accept-Language, and Accept. Servers SHOULD use this additional information to select the appropriate Application Descriptor for the device.

UAProf for Device Identification

Provisioning servers require detailed information about the configuration of the device hardware, software, and installed middleware. However, the Discovery Agent, is not expected to provide detailed information because it does not have access to the detailed configuration of the Java Runtime.

The Open Mobile Alliance (OMA) has developed the UAProf Specification to communicate device and software configuration. See OMA User Agent Profile V2.0 for detailed specifications and schemas. UAProf is based on the Composite Capability/preference Profiles (CC/PP). The configuration schemas are extensible and the processing of profile instances is defined to allow static and difference profile instances to be merged to yield a complete description. The static configuration information is presented to the network using the URL of a profile that describes the device including hardware details and the software provisioned with the device. The client device can supply both the URL of a profile (by reference) and a difference profile (by value in a XML stream) in http headers using the UAProf specification.

The difference profile includes information that has changed relative to the static configuration due to installation of software, changes in the SIM card, etc.

The UAProf specification defines the additional HTTP headers required to deliver configuration information to the server. The headers include x-wap-profile, and x-wap-profile-diff headers. These HTTP Request Headers MUST be supplied on the initial request by the AMS to retrieve a JAD.

MIDP Configuration Profile for UAProf

The predefined configuration schema is not adequate to describe the features of the runtime and the optional packages and shared libraries. The additional schema defined below addresses configuration of the Execution environment. The MIDP Configuration Profile builds on the established mobile profile. The specific RDF schema elements are defined below and are used incrementally as extensions to the existing schema.

The RDF elements are described Table 3-4 below.

Table 3-4 : MIDP RDF Elements

RDF Element

Domain of Element




A MIDP Shared Library property contains values for Name, Vendor, Version and JAR hash. The LIBlet Name, Vendor and Version are defined by LIBlet attributes.



Client provides values to describe the Client's name, certificate subject and certificate hash (Base64 encoded) for each Client.



For each certificate used for application authentication, the subject name as the key and the hash of the public key (Base64 encoded).



An RDF Bag containing, for each system property the name and the value.



An RDF Bag containing each of protocols supported for Push.

The RDF schema for the IMP / MEEP specific elements is:

<?xml version="1.0" encoding="UTF-8"?>
    <!ENTITY ns-rdf  ''>
    <!ENTITY ns-rdfs ''>
    <!ENTITY ns-prf  ''>
    <!ENTITY prf-dt  ''>
    <!ENTITY xsd     ''>
    <!ENTITY ns-midf ''>

  xmlns      = '&ns-rdf;'
  xmlns:rdf  = '&ns-rdf;'
  xmlns:rdfs = '&ns-rdfs;'
  xmlns:prf  = '&ns-prf;'
  xmlns:midf = '&ns-midf'>

    <rdf:Description rdf:ID='MIDProfile'>
        <rdf:type rdf:resource='&ns-rdfs;Class'/>
        <rdfs:subClassOf rdf:resource='&ns-prf;Component'/>
            Description: A platform based on IMP.

    <rdf:Description rdf:ID='MIDSharedLibrary'>
        <rdf:type rdf:resource='&ns-rdf;Property'/>
        <rdf:type rdf:resource='&ns-rdf;Bag'/>
        <rdfs:domain rdf:resource='#MIDProfile'/>
            Description: A MIDP Shared Library described by name, vendor, version,
                         and JAR hash.
                         The values are separated by ";" (semi-colon).
            Type: 	  Literal (Bag) String with multiple fields.
            Resolution:   Append
            Examples:     "QSort; BigCo; 1.1"

    <rdf:Description rdf:ID='MIDSystemProperty'>
        <rdf:type rdf:resource='&ns-rdf;Property'/>
        <rdf:type rdf:resource='&ns-rdf;Bag'/>
        <rdfs:domain rdf:resource='#MIDProfile'/>
             Description: A System property defined by the platform.
             Type:        Literal (Bag) String String
             Resolution:  Append
             Examples:    "microedition.locale fr-FR", "microedition.profiles MEEP-8.0"

    <rdf:Description rdf:ID='Client'>
        <rdf:type rdf:resource='&ns-rdf;Property'/>
        <rdf:type rdf:resource='&ns-rdf;Bag'/>
        <rdfs:domain rdf:resource='#MIDProfile'/>
            Description: A Client is a property with values for
                         Client Name, Certificate Subject and Certificate hash.
                         For each root certificate, a separate entry is required.
            Type:        Literal (Bag) String String String
            Resolution:  Append
            Examples:    "Operator XYZCorp,Inc.  a23438fd8e8a8a8a8a8a8aaaaaaa"

    <rdf:Description rdf:ID='Certificate'>
        <rdf:type rdf:resource='&ns-rdf;Property'/>
        <rdf:type rdf:resource='&ns-rdf;Bag'/>
        <rdfs:domain rdf:resource='#MIDProfile'/>
            Description: A certificate identified by an alias and its hash
                         used for access authorization.
                         For each certificate, a separate entry is required.
            Type:        Literal (Bag) String String
            Resolution:  Append
            Examples:    "XYZCorp  a23248fd8e8a8a929a8aaaaaaa"

    <rdf:Description rdf:ID='PushProtocols'>
        <rdf:type rdf:resource='&ns-rdf;Property'/>
        <rdf:type rdf:resource='&ns-rdf;Bag'/>
        <rdfs:domain rdf:resource='#MIDProfile' />
            Description: The list of push protocols supported by MIDP.
            Type:        Literal (Bag) String
            Resolution:  Append
            Examples:    "sms", "socket"

A partial example might look like:

<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf=""
    <rdf:Description rdf:ID="Profile">
            <rdf:Description rdf:ID="MIDProfile">
                <rdf:type rdf:resource=""/>

                <!-- System properties combined from all APIs  -->
                        <rdf:li> 1.2</rdf:li>
                        <rdf:li>audio.encodings encoding=pcm&rate=11025&bits=16&channels=1</rdf:li>
                        <rdf:li>microedition.deviceid imei:490154203237518</rdf:li>
                        <rdf:li>microedition.subscriberid imsi:310150123456789</rdf:li>
                        <rdf:li>microedition.locale zh-CN-Hans</rdf:li>
                        <rdf:li>microedition.profiles MIDP-3.0</rdf:li>

                <!-- Shared Libraries present on the device.  -->
                        <rdf:li>QSort MWV 1.1  hash8</rdf:li>

                <!-- Supported Push Protocols -->

                <!-- Clients and their root certificates -->
                        <rdf:li>A-Operator Alias1 hash1</rdf:li>
                        <rdf:li>B-Manufacturer Alias2 hash2</rdf:li>
                        <rdf:li>C-Identified Alias3 hash3</rdf:li>
                        <rdf:li>D-Identified Alias4 hash4</rdf:li>

                <!-- Certificates used for access authorization -->
                        <rdf:li>Alias5 hash5</rdf:li>
                        <rdf:li>Alias6 hash6</rdf:li>

User-Agent Product Tokens

The specification identifies HTTP User-Agent request headers to identify the client to the server. [RFC2616] specifies a format for product tokens such as:

"User-Agent" ":" 1*(product | comment)

The product tokens used to identify the device as supporting the underlying configuration (e.g. CLDC-8) and the used profile (e.g. MEEP-8.0) are specified the CLDC 8 specification. As in [RFC2616], the comment field is optional.

In addition, the device SHOULD further identify itself by adding a device-specific product token to the User-Agent header as defined by [RFC2616]. The device-identifying token SHOULD be the first token. The product-token and product-version values are specific to each device and are outside of the scope of this specification.

Accept-Language Header

The device MAY supply the Accept-Language request header as specified in [RFC2616] to indicate the language that is in use on the device.

Accept Header

The Accept HTTP header is used to indicate the type of content being requested. When requesting application suites, this header SHOULD include application/java-archive. For retrieving application descriptors, this header SHOULD include text/

Example: HTTP Request for Application Descriptor

When requesting the download of an Application Descriptor, the request headers might look as follows:

    GET HTTP/1.1
    Accept: text/
    User-Agent: CoolDevice/1.4 Profile/MEEP-8.0 Configuration/CLDC-1.8
    Accept-Language: en-US, fi, fr
    Accept-Charset: utf-8

The response headers from the server might look as follows:

    HTTP/1.1 200 OK
    Server: CoolServer/1.3.12
    Content-Length: 2345
    Content-Type: text/; charset=utf-8

Example: HTTP Request to Install/Update an Application Suite

When requesting the download of an application suite JAR, the request headers might look as follows:

    GET HTTP/1.1
    Accept: application/java, application/java-archive

The response headers from the server might look as follows:

    HTTP/1.1 200 OK
    Server: CoolServer/1.3.12
    Content-Length: 25432
    Content-Type: application/java-archive

Example: Install Status via HTTP Post Request

For example, installing an application suite with an application descriptor given below:


After a successful install of the application suite, the following would be posted:

    POST HTTP/1.1
    Content-Type: text/plain; charset=utf8
    Content-Length: 13
    900 Success


The response from the server might be:

    HTTP/1.1 200 OK
    Server: CoolServer/1.3.12

Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved.