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.
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.
An OTA provisioning compliant device MUST be capable of:
Everything stated in the Discovery section of the Provisioning chapter applies, and in addition the following OTA Provisioning specific requirements MUST be fulfilled:
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:
text/vnd.sun.j2me.app-descriptor.
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.
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/vnd.sun.j2me.app-descriptor 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.
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:
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.
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.
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).
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.
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:
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:
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.
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.
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 |
Description |
|
|
MIDProfile |
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. |
|
|
MIDProfile |
Client provides values to describe the Client's name, certificate subject and certificate hash (Base64 encoded) for each Client. |
|
|
MIDProfile |
For each certificate used for application authentication, the subject name as the key and the hash of the public key (Base64 encoded). |
|
|
MIDProfile |
An RDF Bag containing, for each system property the name and the value. |
|
|
MIDProfile |
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"?>
<!DOCTYPE rdf:RDF [
<!ENTITY ns-rdf 'http://www.w3.org/1999/02/22-rdf-syntax-ns#'>
<!ENTITY ns-rdfs 'http://www.w3.org/2000/01/rdf-schema#'>
<!ENTITY ns-prf 'http://www.openmobilealliance.org/tech/profiles/UAPROF/ccppschema-20070511#'>
<!ENTITY prf-dt 'http://www.openmobilealliance.org/tech/profiles/UAPROF/xmlschema-20030226#'>
<!ENTITY xsd 'http://www.w3.org/2001/XMLSchema#'>
<!ENTITY ns-midf 'http://opensource.motorola.com/midp3/midprofile#'>
]>
<rdf:RDF
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'/>
<rdfs:label>MIDProfile</rdfs:label>
<rdfs:comment>
Description: A platform based on IMP.
</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID='MIDSharedLibrary'>
<rdf:type rdf:resource='&ns-rdf;Property'/>
<rdf:type rdf:resource='&ns-rdf;Bag'/>
<rdfs:domain rdf:resource='#MIDProfile'/>
<rdfs:label>MIDShareLibrary</rdfs:label>
<rdfs:comment>
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"
</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID='MIDSystemProperty'>
<rdf:type rdf:resource='&ns-rdf;Property'/>
<rdf:type rdf:resource='&ns-rdf;Bag'/>
<rdfs:domain rdf:resource='#MIDProfile'/>
<rdfs:label>MIDSystemProperty</rdfs:label>
<rdfs:comment>
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"
</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID='Client'>
<rdf:type rdf:resource='&ns-rdf;Property'/>
<rdf:type rdf:resource='&ns-rdf;Bag'/>
<rdfs:domain rdf:resource='#MIDProfile'/>
<rdfs:label>Client</rdfs:label>
<rdfs:comment>
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"
</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID='Certificate'>
<rdf:type rdf:resource='&ns-rdf;Property'/>
<rdf:type rdf:resource='&ns-rdf;Bag'/>
<rdfs:domain rdf:resource='#MIDProfile'/>
<rdfs:label>Certificate</rdfs:label>
<rdfs:comment>
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"
</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID='PushProtocols'>
<rdf:type rdf:resource='&ns-rdf;Property'/>
<rdf:type rdf:resource='&ns-rdf;Bag'/>
<rdfs:domain rdf:resource='#MIDProfile' />
<rdfs:label>PushProtocols</rdfs:label>
<rdfs:comment>
Description: The list of push protocols supported by MIDP.
Type: Literal (Bag) String
Resolution: Append
Examples: "sms", "socket"
</rdfs:comment>
</rdf:Description>
</rdf:RDF>
|
A partial example might look like:
<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:prf="http://www.openmobilealliance.org/tech/profiles/UAPROF/ccppschema-20021212#"
xmlns:midf="http://opensource.motorola.com/midp3/midprofile#">
<rdf:Description rdf:ID="Profile">
<prf:component>
<rdf:Description rdf:ID="MIDProfile">
<rdf:type rdf:resource="http://opensource.motorola.com/midp3/midprofile#MIDProfile"/>
<!-- System properties combined from all APIs -->
<midf:SystemProperty>
<rdf:Bag>
<rdf:li>microedition.media.version 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>
</rdf:Bag>
</midf:SystemProperty>
<!-- Shared Libraries present on the device. -->
<midf:MIDSharedLibrary>
<rdf:Bag>
<rdf:li>QSort MWV 1.1 hash8</rdf:li>
</rdf:Bag>
</midf:MIDSharedLibrary>
<!-- Supported Push Protocols -->
<midf:PushProtocols>
<rdf:Bag>
<rdf:li>sms</rdf:li>
<rdf:li>socket</rdf:li>
<rdf:li>datagram</rdf:li>
</rdf:Bag>
</midf:PushProtocols>
<!-- Clients and their root certificates -->
<midf:Client>
<rdf:Bag>
<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>
</rdf:Bag>
</midf:Client>
<!-- Certificates used for access authorization -->
<midf:Certificates>
<rdf:Bag>
<rdf:li>Alias5 hash5</rdf:li>
<rdf:li>Alias6 hash6</rdf:li>
</rdf:Bag>
</midf:Certificates>
</rdf:Description>
</prf:component>
</rdf:Description>
</rdf:RDF>
|
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.
The device MAY supply the Accept-Language request header as specified in [RFC2616] to indicate the language that is in use on the device.
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/vnd.sun.j2me.app-descriptor.
When requesting the download of an Application Descriptor, the request headers might look as follows:
GET http://host.foo.bar/app-dir/comm.jad HTTP/1.1
Host: host.foo.bar
Accept: text/vnd.sun.j2me.app-descriptor
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/vnd.sun.j2me.app-descriptor; charset=utf-8
|
When requesting the download of an application suite JAR, the request headers might look as follows:
GET http://host.foo.bar/app-dir/comm.jar HTTP/1.1
Host: host.foo.bar
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
|
For example, installing an application suite with an application descriptor given below:
...
MIDlet-Install-Notify: http://foo.bar.com/status
...
|
After a successful install of the application suite, the following would be posted:
POST http://foo.bar.com/status HTTP/1.1
Host: foo.bar.com
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.