Application Provisioning

Overview and Goals

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.

Functional Requirements for OTA Provisioning

An OTA provisioning compliant device MUST be capable of:

Application Suite Lifecycle

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.

Discovery

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:

Provisioning

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.

Application Suite Provisioning

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:

  1. Once the application 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/vnd.sun.j2me.app-descriptor.
  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 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.

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

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)

LIBlet Provisioning Overview

Installation

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:

  1. The device initiates the download of the application suite. 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 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. The application suite and the headers that are received MUST be checked to verify that the retrieved application suite is valid and can be installed on the device. The following problems may occur:
    1. If there is insufficient memory to store the application suite on the device, the device MUST return Status Code 901 (Insufficient Memory) in the Status Report. In case a LIBlet dependency is specified, the device MUST first verify there is sufficient persistent storage space by summing the JAR size specified in the JADs of the application suite and all of the LIBlets that the application suite declares dependency on, directly or indirectly, using the following formula:
      MIDlet-Jar-Size + Σ(LIBlet-Jar-Size for distinct LIBlets)
      The associated JARs will only be downloaded if there is sufficient persistent storage space. If a LIBlet already exists on the device, its size will be omitted from this total size.
    2. If the JAR is not available at the 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.
    3. If the received JAR size does not match the size specified in the Application Descriptor, the device MUST return Status Code 904 (JAR size mismatch) in the Status Report.
    4. If the manifest or any other file can not be extracted from the JAR, the device MUST return Status Code 907 (Invalid JAR) in the Status Report.
    5. If the JAR manifest is not in the correct syntax, or if any of the required application attributes are missing in the JAR manifest, or if the JAR manifest contains any application attributes that are allowed only in the JAD (see Appendix A), then the device MUST return Status Code 907 (Invalid JAR) in the Status Report.
    6. If the mandatory attributes in the descriptor 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.
    7. The value of each attribute that appears in both the Manifest and Application Descriptor MUST have the identical value, with the exception of application suites with the 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.
    8. If an Application Descriptor or Manifest contains any instances of 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.
    9. At installation time, the device MUST first verify there is sufficient disk space for persistent data using the data size specified in the JADs of the application suite and the LIBlets, computed as:
      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)
      The associated JARs will only be downloaded if there is sufficient persistent storage space. In case of insufficient memory, the device MUST return Status Code 901 (Insufficient Memory) in the Status Report.
    10. If the application failed to be authenticated, the device MUST return Status Code 909 (Application authentication failure) in the Status Report.
    11. If circular dependencies are detected in the LIBlets that an application suite depends on, the device MUST reject the installation of such a binding and MUST return Status Code 916 (Circular LIBlet dependency) in the Status Report.
    12. If a device imposes an upper limit on the number of LIBlet dependencies allowed for a single application suite, and if that upper limit is exceeded, the device MUST reject the installation of the application suite and MUST return Status Code 918 (LIBlet dependencies limit exceeded) in the Status Report.
    13. If the computed hash of downloaded LIBlet JAR does not match the hash, if present, from the attribute 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.
    14. If the dependent LIBlet specified in the dependency expression of an application suite/LIBlet matches the attribute values of name, vendor, and version of a LIBlet that already exists on the device, but the hash value specified in the existing LIBlet JAD attribute 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.
    15. If the application is not authorized for a permission as defined by the Requesting Permissions for an Application Suites section then installation must fail and the device MUST return Status Code 910 (Application authorization failure) in the Status Report. The JARs of the application suite and the LIBlets it depends on MUST NOT be downloaded.
    16. If a static push registration fails for a reason other than not being authorized, the device MUST return Status Code 911 (Push registration failure) in the Status Report.
    17. If the network service is lost during installation, Status Code 903 (Loss of Service) SHOULD be used in a Status Report if possible (it may be impossible to deliver the status report due to the network-service outage).
    18. If the device detects a namespace collision between classes in the application suite and classes in the LIBlets it depends on, the device MUST fail the installation of such a binding and return Status Code 917 (LIBlet namespace collision) in the Status Report.
    19. If installation of a valid application suite fails due to an unexpected internal error in the device, or if installation of an application suite fails due an error that cannot be reflected by one of the defined Status Codes, then the device MUST fail the installation and return Status Code 919 (General failure) in the Status Report.
  4. 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 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.

  5. If the application is protected by OMA DRM and the device can not parse it, then Status Code 953 (Non-Acceptable Content) MUST be sent as described in [OMADRM-MIDP].
  6. Each service requested by the application and its LIBlets in 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.
  7. The dependent LIBlets found during installation or update MUST be bound to the application for use in the Execution Environment. The set of LIBlets remains bound to the application until it is explicitly updated. See Updating Applications to use Updated LIBlets for details.
  8. If a LIBlet that exports a service with a 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.
    LIBlets that export a service must be enabled when installed.
  9. Provided there are no problems that prevent installation, the applications contained in the application suite MUST be installed and made available for execution.
  10. The installation is complete when the application suite has been made available on the device, or an unrecoverable failure has occurred. In either case, the status MUST be reported as described in the Status Reports section.

Update

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.

Updating Applications to Use Updated LIBlets

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.

Invocation

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.

Deletion

Application Suite Deletion

Devices MUST allow to delete application suites, with the exception of Persistent Application.

LIBlet Deletion

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.

Status Reports

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

Device Identification and Request Headers

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.

UAProf for Device Identification

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.

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

Description

MIDSharedLibrary

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.

SecurityDomain

MIDProfile

SecurityDomain provides values to describe the domain name, certificate subject and certificate hash (Base64 encoded) for each domain.

Certificate

MIDProfile

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

SystemProperty

MIDProfile

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

PushProtocols

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>

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

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

Example: HTTP Request for Application 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
    

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

Example: Install Status via HTTP Post Request

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