This chapter describes how application suites and LIBlets are provisioned; that is, how application suites and LIBlets are deployed to client devices, and the requirements imposed upon a client device to support these deployments. Following these recommendations will help ensure interoperability between clients and servers from all manufacturers, and will also provide guidance to mobile network operators deploying devices implementing this specification.
The ability of an implementation to support provisioning is optional in MEEP-1.0. If an implementation decides that is does not have to support provisioning (as all application suites are already pre-installed during the manufacturing of the target device and there is no need for updates), it can decide to skip it. Also the way of provisioning - if supported - can be freely chosen as it is out of scope of the specification (see later in this section for details).
Devices MAY provide mechanisms that allow the discovery of applications. Throughout this chapter, an application with this functionality will be referred to as the Discovery Application, or DA.
Other installation mechanisms (e.g. BluetoothTM wireless technology, serial cable, IrDATM, etc.) that MAY be supported by devices, are outside the scope of this version of the specification.
The term Application Management Software (AMS) is a generic term used to describe the software on the device that manages the downloading and lifecycle of applications. This term does not refer to any specific implementation and is used for convenience only. In some implementations, the term Java Application Manager (JAM) is used interchangeably.
This chapter describes the general functional requirements of the device and the functions supporting the application suite lifecycle and LIBlet provisioning. Descriptions are included for additional Application Attributes and mechanisms that identify the device type and characteristics to servers providing application suites and LIBlets.
An OTA provisioning compliant device MUST be capable of:
The lifecycle of an application suite consists of discovery, installation, update, invocation and deletion.
The lifecycle of a LIBlet consists only of discovery, installation, update, and deletion.
Application discovery is the process by which an application suite is discovered using the device. Discovery and installation of application suites, if supported, MUST follow the following high-level scheme:
When an application suite is provisioned, all files that comprise the application are downloaded to the device for installation. In addition to the application suite JAR file, one or more LIBlet JAR files could be downloaded.
This section describes how the Discovery Application (DA) and the Application Management System (AMS) handle the various components of the application suite.
As mentioned before, the mechanism of discovery is out of scope of this specification. If the discovered location of an application suite 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:
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 can be successfully installed and executed on the device. This may involve downloading of Application Descriptors of any LIBlets the application suite depends on, if any LIBlet dependencies are specified by the application suite.
The Application Descriptor MUST be converted from its
transport format to the Unicode encoding that is specified
by the specification 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 SHOULD 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 SHOULD
be converted accordingly.
The attributes in the Application Descriptor MUST be formatted according to the syntax defined in Application Attributes; otherwise the client MUST return Status Code 906 (Invalid Descriptor) in the status report. All of the application attributes designated as mandatory by Appendix A MUST be present in the Application Descriptor; if this is not the case, then the client MUST return Status Code 906 (Invalid Descriptor) in the status report. If the Application Descriptor contains any application attributes that are allowed only in the Jar manifest (see Appendix A), then the client MUST return Status Code 906 (Invalid Descriptor) in the status report.
LIBlet provisioning is performed as part of application provisioning.
The application suite JAD file lists its LIBlet dependencies. Each LIBlet may in turn have other LIBlet dependencies. The JAD files involved, for both application and LIBlets, MUST be downloaded first before any application suite or LIBlet JARs are downloaded. Based on the downloaded JAD files, the device SHOULD calculate the total static size required for installation. Also, any JAD only validation steps MAY be undertaken before the JARs are downloaded.
Figure 3-1 : LIBlet Provisioning Overview (needs to be updated to include the repeat fetch of the JAD to supply UAProf headers) |
---|
![]() |
Application installation is the process by which an application suite is downloaded onto the device and made available for running. Application installation is optional in MEEP-1.0.
If the application suite depends on one or more LIBlets, implementation MAY make the user aware of all LIBlets the application suite depends on. The means by which application dependencies are presented to the user are implementation specific.
LIBlet installation is done as part of the application suite installation process. Since other applications could depend on other versions of a LIBlet already installed in the device, a LIBlet is not simply replaced with a newer version. Instead, another (but typically newer) version of the LIBlet is installed. Any existing version of the LIBlet MUST NOT be deleted if there are other applications or LIBlets depending on it. It follows that multiple versions of the same LIBlet MAY reside on the device at the same time.
At installation of a signed application suite, the implementation MAY present to the user security information related to the application suite.
During installation, the user MAY be informed of progress. If the installation is interrupted by any reason, the device MUST be left in the state it was in before installation began.
If the application suite is already installed on the device, it SHOULD be treated as an update. See the Update section for additional information on how to handle an update.
To install an application suite, 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 MUST be for exactly the URL specified in the descriptor;
additional headers are unnecessary.
MIDlet-Jar-Size
+
Σ(LIBlet-Jar-Size
for distinct LIBlets)
MIDlet-Jar-URL
attribute
in the descriptor, the device MUST return
Status Code 907 (Invalid JAR)
in the Status Report.
Similarly, if a dependent LIBlet is not already installed on
the device and the JAR is not available at the
LIBlet-Jar-URL
, the device MUST
return Status Code 907 (Invalid JAR)
in the Status Report.
MIDlet-Name
,
MIDlet-Version
, and
MIDlet-Vendor
do not match those
in the JAR manifest, the device MUST return
Status Code 905 (Attribute mismatch)
in the Status Report. Similarly, if the mandatory attributes
in the LIBlet descriptor
LIBlet-Name
,
LIBlet-Version
, and
LIBlet-Vendor
do not match those
in the LIBlet JAR manifest, the device MUST return
Status Code 905 (Attribute mismatch)
in the Status Report.
MicroEdition-Profile
attribute equal to "IMP-1.0", or "IMP-NG".
If not identical, the device MUST return
Status Code 905 (Attribute mismatch)
in the Status Report.
For IMP 1.0, and IMP-NG application suites, refer to
Attribute Overrides in Application Descriptor.
LIBlet-Dependency-
<n>
attributes, or if any LIBlet Application Descriptor or
Manifest associated with the application suite contains any instances of
MIDlet-Dependency-
<n>
attributes, then the device MUST return
Status Code 906 (Invalid Descriptor)
in the Status Report.
MIDlet-Data-Size
+
Σ
(LIBlet-NonShared-Data-Size
for distinct LIBlets)
+ Σ
(LIBlet-Shared-Data-Size
for distinct LIBlets
if it is the first binding for the LIBlet on the device)
MIDlet-Dependency-Jar-SHA1-
<n> or
LIBlet-Dependency-Jar-SHA1-
<n>
of the dependent's application suite or LIBlet, or
if the computed hash of the downloaded LIBlet JAR does not
match the hash specified in the LIBlet JAD attribute
LIBlet-Jar-SHA1
,
then the implementation MUST reject the downloaded LIBlet and
MUST return
Status Code 914 (Application Integrity Failure)
in the Status Report. If the application suite installation
cannot proceed because of faults with the dependency LIBlets,
the user MAY be presented with an explanation of the cause
of the installation failure, if respective capabilities are
available.
LIBlet-Jar-SHA1
does not match
the hash value, if present, specified in the
MIDlet-Dependency-Jar-SHA1-
<n> or
LIBlet-Dependency-Jar-SHA1-
<n>
attribute, then the implementation MUST download the new LIBlet
JAR specified by the LIBlet-JAR-URL
attribute. Implementations MUST install the downloaded LIBlet
JAR as a unique LIBlet if the specified hash matches the value of the
MIDlet-Dependency-Jar-SHA1-
<n> or
LIBlet-Dependency-Jar-SHA1-
<n>
attribute.
MIDlet-Required-IP-Version
attribute
is specified, and that IP version is not supported by the implementation,
the installation MUST fail and return
Status Code 905 (Attribute mismatch)
in the Status Report.
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-Dependency-
<n> or
LIBlet-Dependency-
<n> attributes must be resolved.
Each installed LIBlet that exports one of the requested services in its
LIBlet-Services
attribute must be considered
a candidate service provider LIBlet.
LIBlet-Services
attribute does not contain valid service provider
information for the service as defined in the
Service Provider Packaging
then installation MUST fail and the device MUST return
Status Code 920 (Service Configuration Error)
in the Status Report.An application suite update is defined as the operation of installing a specific application suite when that same application suite (either the same version or a different version) is already installed on the device. Devices MAY support the updating of application suites. See Device Identification and Request Headers for the attributes that apply to updates.
If an application suite update does not result in binding to the same security domain as the original application suite, then installation MUST fail and the device MUST return Status Code 910 (Application authorization failure) in the Status Report. Additionally, if an application suite update and the already installed application suite do not have at least one common signer, then installation MUST fail and the device MUST return Status Code 910 (Application authorization failure) in the Status Report. Common signer is defined as matching the Organization field within the Subject field of the signing certificate of application suite update and the signing certificate of the original application suite, where the signing certificates are validated against the same Protection Domain Root Certificate.
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 the application suite dependencies change, the developer of the application suite needs to provide an updated JAD file containing the new LIBlet dependencies to be provisioned to the device. These dependencies MUST be resolved like in the initial installation of the application suite.
When updating a dependency declaration chain, the application suite declaring
the dependency MUST increase its own version number, regardless of
whether or not any code changes occurred to the application suite or LIBlet
itself declaring the dependency. Additionally, for all LIBlets in a dependency chain,
whenever a LIBlet version changes due to code change and/or
dependency declaration change, the attribute
LIBlet-Dependency-Jar-SHA1-
<n>,
if present, MUST contain the new hash value of the updated LIBlet JAR.
For the case where an application suite is being updated only because of new LIBlet dependencies, the application suite developer will need to check that the required Permissions for new LIBlet dependencies are reflected in application manifest and/or JAD. The application suite will also need to be correctly signed.
For a signed application suite update, the RMS record stores MUST be retained. For an unsigned application suite update, the RMS record stores MUST be managed as follows:
The format, contents and versioning of the record stores is the responsibility of the application suite. The permissions given to the original application suite SHOULD also be given to the new application suite, if they are in the security domain of the new application suite.
Under specific conditions a LIBlet installed for one application can be used to update other applications that use previous versions of the LIBlet. If allowed by the application and when the application is updated, the LIBlet will be included in the Execution Environment when the application is subsequently invoked.
The updated LIBlet can be rebound to an application by reevaluating all of the dependency information used during installation. Each dependency is evaluated and if the dependency expression has a version number that matches and there is no hash that must match exactly then the new LIBlet can be bound to the application. The entire Dependency Declaration Chain must be reprocessed including checking for circular dependency checking. The processing required is the same as re-installing the application but it should not require the download of the application JAD or JARs. If any errors are detected, then the update fails and the application must revert to the previously installed state.
The rebinding of LIBlets to applications can be performed immediately, can be deferred indefinitely or can be performed based on a profile setting in the implementation.
If the start of an application has been triggered, the device MUST invoke the application with the Execution Environment .
After an application suite is successfully installed on the device and
if the suite contains any application (that is, one or more
MIDlet-
<n>
attributes are found in the JAD file or JAR manifest), the implementation
MUST start an application. If the application suite contains only
one application, that specific application MUST be launched. If the
application suite contains several applications, the application specified
by the MIDlet-
<1> attribute
MUST be launched. These requirements apply only to applications that are
listed in the JAD file or in the JAR manifest by means of
MIDlet-
<n> attributes.
Devices MUST allow to delete application suites, with the exception of Persistent Application.
LIBlet deletion is usually done as part of the application suite deletion process, if a LIBlet has no other application suites depending on it. An implementation that has sufficient persistent storage MAY choose to retain LIBlets for possible later use, even after all application suites depending on the LIBlet have been deleted.
A LIBlet becomes unreferenced if there are no application suites installed on the device that specify a dependency on that particular LIBlet or if the LIBlet is not providing a service to or is not bound to any application. It is up to the implementation to determine when (if ever) it is appropriate to delete unreferenced LIBlets. For implementations that do retain unreferenced LIBlets, the AMS MAY provide a means to delete such LIBlets.
Some implementations MAY, according to policy, never allow unreferenced LIBlet automatic deletion, even if the LIBet's reference count drops to zero.
The success or failure of the installation, update, or deletion of an application suite is of interest to the service providing the application suite. The Application Descriptor MAY include relevant application attributes for provisioning that specify URLs for status reporting. Those URLs MUST be used for reporting as specified below.
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 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:
Unless an acknowledgement is requested with a MIDlet-Install-Notify
attribute whose value includes the ack
tag,
the sending of any status report MUST be retried until the retry
count reaches at least five (5), or it can be determined that there
is no server response (for example, due to the loss of network connectivity
or a network timeout). The implementation MAY continue to retry the sending of
the report.
The installed application suite MUST be made available for use
even if the sending of the installation status report fails,
unless an acknowledgement is requested with the ack
tag in
the MIDlet-Install-Notify
attribute. If the
ack
tag is present, the installation
of the application suite MUST fail if a server response other than
2xx or 3xx is received. When an application suite is updated,
any ack
tag SHOULD be ignored, and the updated application suite
be made available immediately.
If the application suite being installed has dependencies on some LIBlets,
an installation status report MUST be sent to any
LIBlet-Install-Notify
URL specified by
the LIBlet vendor.
Note that LIBlets are not deleted along with the application suite if there are other application suites that depend on them.
The following table contains the provisioning status codes and suggested status messages.
Table 3-2 : Install Status Codes and Messages |
|
---|---|
Status Code |
Status Message |
900 |
Success |
901 |
Insufficient Memory |
902 |
Cancelled |
903 |
Loss of Service |
904 |
JAR size mismatch |
905 |
Attribute mismatch |
906 |
Invalid Descriptor |
907 |
Invalid JAR |
908 |
Incompatible Configuration or Profile |
909 |
Application authentication failure |
910 |
Application authorization failure |
911 |
Push registration failure |
914 |
Application Integrity Failure |
915 |
One or more missing dependency |
916 |
Circular LIBlet dependency |
917 |
LIBlet namespace collision |
918 |
LIBlet dependencies limit exceeded |
919 |
General failure |
920 |
Service Configuration Error |
953 |
Non-Acceptable Content |
The process of discovering an application suite via the DA can be customized by the device sending information about itself to the server. The DA MUST 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, 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, normally a web browser 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 |
SecurityDomain provides values to describe the domain name, certificate subject and certificate hash (Base64 encoded) for each domain. |
|
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 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-1.0" </rdfs:comment> </rdf:Description> <rdf:Description rdf:ID='SecurityDomain'> <rdf:type rdf:resource='&ns-rdf;Property'/> <rdf:type rdf:resource='&ns-rdf;Bag'/> <rdfs:domain rdf:resource='#MIDProfile'/> <rdfs:label>SecurityDomain</rdfs:label> <rdfs:comment> Description: A security domain is a property with values for Domain 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> <!-- Security Domains and their root certificates --> <midf:SecurityDomain> <rdf:Bag> <rdf:li>Operator Alias1 hash1</rdf:li> <rdf:li>Manufacturer Alias2 hash2</rdf:li> <rdf:li>Identified Alias3 hash3</rdf:li> <rdf:li>Identified Alias4 hash4</rdf:li> </rdf:Bag> </midf:SecurityDomain> <!-- 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-1.0) are specified the CLDEC-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-1.0 Configuration/CLDC-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 |