JavaTM ME Embedded Profile Version 8.0.0
EG Working Draft
Java 8 Platform, Micro EditionTM
Copyright 2014, Oracle Inc, All Rights Reserved.
Portions Copyright 2003/2004,
Sun Microsystems, Inc. and Motorola, Inc., All Rights Reserved.
Portions Copyright 2005
Siemens AG & Nokia Corporation, All Rights Reserved.
Portions Copyright 2005-2009,
Motorola, Inc., All Rights Reserved.
Portions Copyright 2010-2012 GAIA Holdings Corporation, fka Aplix
Corporation, All Rights Reserved.
Preface
This document defines an EG Working Draft of the Embedded Profile for the Java Platform, Micro Edition (Java METM, version 8.0.0, aka MEEP 8.
This document and all associated documents are subject to the terms of the JCP and associated agreements (JSPA).
A profile of Java ME defines device-type-specific sets of APIs for a particular vertical market or industry.
Revision History
|
Date |
Version |
Description |
|---|---|---|
|
24-April-2012 |
MEEP 8 Speclead Draft |
Basis of EG work |
|
24-May-2013 |
MEEP 8 EDR Draft |
Result of EG work so far |
|
27-August-2013 |
MEEP 8 PR Draft |
Result of EG work so far |
|
22-November-2013 |
MEEP 8 Speclead Draft |
Incorporates results of PR into PR version |
Who Should Use This Specification
This document is targeted at the following audiences:- The Java Community Process (JCP) expert group defining this profile
- Implementers of the JavaTM ME Embedded Profile
- Application developers targeting JavaTM ME Embedded Profile
- Network operators deploying infrastructure to support JavaTM ME Embedded Profile devices
How This Specification Is Organized
This Specification includes the following important components:- Application Packaging
- Application Provisioning
- Default Provisioning Implementation: OTA Provisioning
- Optionality and Dependencies
- JavaTM ME Embedded Profile Platform version 8.0.0 (MEEP 8)
- Application Concurrency
- Security for Applications
- Security Authentication Providers
- Default Security Authentication Provider: Application Suites Trust Model Using X.509 PKI
- Security Policy Providers
- Default Security Policy Provider (certificate based)
- Legacy Compatibility for Previous Versions
- Application Attributes
- Example Client Policies
- System Properties Definitions
- JavaDoc API Documentation
Report and Contact
The preferred forum for comments will be JSR 361 project on java.net.
Alternatively, comments may be sent to jsr-361-comments@jcp.org.
Document Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
Code examples are formatted as follows :
DataInputStream inputStream2 = new DataInputStream(bais2);
try {
quote2 = inputStream2.readInt();
} catch (EOFException eofe) {
// ...
}
|
Glossary
|
Table 1-1 : Glossary |
|
|---|---|
|
Application |
An application is the entity that is launched by the Application Management Software (AMS). Each application consists of a class that extends the javax.microedition.midlet.MIDlet class and other classes and resources as may be needed by the application. |
|
Application Attributes |
Name-value pairs that represent application properties and configuration, are logically bound to an application suite, and are contained within an the suite's Manifest and/or JAD. |
|
Application Lifecycle |
Defines the protocol between an application and its execution environment through :
|
|
Application Management Software (AMS) |
Device system software that provides an environment in which Application suites are installed, started, stopped, and deleted. The AMS is responsible for handling any errors that may occur during the installation, execution, and removal of Application suites. The AMS is also responsible for providing the runtime execution environment that is required by the Application suite. It should be distinguished between the basic AMS functionality being an integral part of the MEEP 8 runtime environment on the one hand, and the extended SWM functionality as defined in the javax.microedition.swm package on the other hand. The extended SWM functionality defined in this package is optional for MEEP 8. |
|
Application Suite |
The fundamental device application packaging component, contains one or more applications to be executed. The elements of an application suite are: the execution environment, the Application Suite Packaging, the Application Descriptor, the Application lifecycle, and Service Providers. See the Packaging chapter for details. |
|
Application Suite Lifecycle |
Defines the protocol between an Application Suite and the Application Management Software, including :
|
|
Authentication Provider |
Authenticates Clients as well as Applications and assigns Applications to Clients based on a mechanism being configurable at the time of system level configuration. One possible implementation is the PKI x.509 certificate based authentication as known from MIDP 3.0. |
|
Auto Start Application |
Application that is automatically launched when the device is powered on, and restarted automatically upon exit of the application. |
|
Auxiliary Display |
Display hardware that is not an integral part of the device, and is not permanently connected to it. Not all devices implementing MEEP 8 have a display, and implementing graphical capabilities is not mandatory for MEEP 8. MEEP 8 devices MAY have one or several displays though. Auxiliary displays are transient, may not always be available for use by the device, and may be attached to the device by a wired or wireless connection. |
|
Blacklisting |
The possibility to prevent access to sensitive functionality for a particular Application or all applications assigned to a particular Client by removing the privileged Permissions of this application(s). This includes the immediate termination of the affected application, or of all applications assigned to the affected Client, respectively. This can happen using CRL or OCSP, but also using implementation-defined mechanisms such as ""push" blacklisting. |
|
Built-In Display |
Display hardware that is an integral part of and permanently connected to the device, such as the main or external display of a mobile phone. Not all devices implementing MEEP 8 have a display, and implementing graphical capabilities is not mandatory for MEEP 8. MEEP 8 devices MAY have one or several displays though. |
|
Certificate (Public Key Certificate) |
Also known as an identity certificate, an electronic document that incorporates a digital signature to bind together a public key with an identity - information such as the name of a person or an organization, their address, and so forth. The certificate can be used to verify that a public key belongs to an individual. |
|
Certificate Authority |
An entity that issues digital certificates on behalf of the certificate owner, as a trusted third party, as part of Application Suites Trust Model Using X.509 PKI. |
|
Client |
A security entity, authenticated by the Authentication Provider, with an associated Security Protection Domain. This domain can be specific for this Client or may be shared between more than one or all Clients. The principal purpose of the Client is to identify the Security Protection Domain to which all applications of that Client are bound. As a consequence, the assignment of a security protection domain to a Client cannot be changed. |
|
The concurrent execution of two or more applications; primarily this means that the running applications SHOULD behave as though they were running independently, in terms of runtime execution environment, data isolation, error handling, and scheduling. |
|
|
Dependency Declaration Chain |
The list of required, prerequisite components that an Application suite has expressed as required to be present for successful installation. This list must form a tree (an acyclic directed graph) in which each vertex in the graph represents a unique dependency. |
|
Dependency Expression |
The specification by an Application suite of a set of required, prerequisite components, including LIBlets, services, optional packages, standard APIs, and proprietary APIs, including allowed versions, necessary for successful installation. |
|
Discovery Application |
Software that enables the download of MEEP 8 applications, usually initiated by external or internal triggers. Installation mechanisms like Bluetooth™ wireless technology, serial cable, IrDA™, SMS etc. will be called "external triggers" to initiate provisioning here. Also "internal triggers" such as Timer events or requests from running Java applications are solutions one can think of. Which trigger is used by an implementation is outside the scope of this specification. The goal of such a generic solution is to ensure that an application suite can be downloaded by implementations of several manufacturers – not depending on what kind of trigger is used. For every kind of external trigger, security is an issue to keep in mind. Depending on security requirements it is strongly recommended to use security mechanisms such as passwords to avoid unauthorized triggering by external sources. |
|
Display Capabilities |
The set of user interface features that a Display supports and may be used by an application. These features include support for input events and other high level user interface components. As not all MEEP 8 devices own a display and/or user input devices, the existence of display capabilities is not mandatory in MEEP 8. |
|
Display State |
A Display object has one of the following three states : foreground, background, and visible. These states define the level of access the application has to the exclusive resources related to that Display hardware on the device. Applications running on MEEP 8 devices without a display do not have a Display object of course, and for these devices a Display state does not exist. |
|
Execution Environment |
|
|
IMlet |
See Application. The applications in the IMP profiles have been called IMlets. As MEEP 8 is backward compatible to IMP-NG, IMlets are applications in the sense of the definition to be found there. |
|
IMlet Lifecycle |
See Application Lifecycle. The applications in the IMP profiles have been called IMlets. As MEEP 8 is backward compatible to IMP-NG, IMlets are applications in the sense of the definition to be found there. |
|
IMlet Suite |
See Application Suite. The applications in the IMP profiles have been called IMlets. As MEEP 8 is backward compatible to IMP-NG, IMlets are applications in the sense of the definition to be found there. |
|
IMlet Suite Lifecycle |
See Application Suite Lifecycle. The applications in the IMP profiles have been called IMlets. As MEEP 8 is backward compatible to IMP-NG, IMlets are applications in the sense of the definition to be found there. |
|
JME Embedded Profile Execution Environment |
Within this specification often also referred to as just "Execution Environment". Each application is executed in a separate environment that includes the Application suite's classes, its shared libraries and the requested configuration, profile and optional APIs. |
|
JAD (Java Application Descriptor) |
A collection of attribute/value pairs used to describe an Application
suite or a LIBlet. The description includes the name of the Application
suite or a LIBlet, the location and size of the JAR, and
configuration, profile, and dependency requirements. JADs may contain
attributes defined by the profile (prefixed by |
|
JAR (Java Archive) |
An archive used to distribute an Application suite or a LIBlet, containing compiled Java classes and associated resources and metadata that constitute MEEP 8 applications or LIBlets. |
|
LIBlet |
A shareable software component that one or more Application suites may use at runtime. |
|
Licensee Open Classes |
Also known as OEM Specific Classes, proprietary packages that do not logically fall into the category of a Java ME configuration, profile, or optional package. |
|
Manifest |
Contains information that describes the contents of a JAR. Located at /META-INF/MANIFEST.MF within a JAR; same syntax as the JAD and may share the same attributes. |
|
Media Support |
Defined in javax.microedition.media, and javax.microedition.media.control packages, allows applications the handling of audio media. |
|
Collectively, the techniques and components used to prepare Application suites for distribution, including Java archive (JAR), Manifest, Java Application Descriptor (JAD), and resources. |
|
|
Permission |
Represents a specific access to a particular resource, such as an API or function, and the authorized use of that resource. |
|
Persistent Application Suite |
An Application Suite that cannot be deleted. |
|
The process of (optional) discovering, deploying, and maintaining content on an embedded device. Support of Provisioning is optional in MEEP 8. |
|
|
RMS |
Defined in javax.microedition.rms, Record Management System allows applications to persistently store and later retrieve data. |
|
RMS Record Tag |
An integer tag associated with a record in an RMS record store, specified at runtime by an application to either assign the tag to a record or to be used as a filter while searching a record store. |
|
Root Certificate |
A certificate or equivalent entity occupying the top-most position in a certificate chain and forming the root trust level that is inherited by all certificates below it in the certificate chain. A root certificate is trusted without validation as it is installed in the device's certificate store. It may be self signed, but does not have to. |
|
Security Policy |
Defines the mapping for a set of permissions that are available to applications assigned to a certain Client for a device. The Security Policy is assigned to this Client's protection Domain. |
|
Security Policy Provider |
Determines the per-application Permission set of an Application by determining the protection domain an application is bound to (identified by the Client the Application is assigned to) and then intersecting the permissions requested by the application. One possible implementation is policy file based mechanism as known from MIDP 3.0. |
|
Security Protection Domain |
Associates an application with a defined set of permissions that allow access to the functionality protected by the domain, based on the permissions granted. The mapping between Security Protection Domains and Clients is determined by the Security Service Provider. Every Client may have its own Security Protection Domain. It can be also decided that there is only one Security Protection Domain that fits all Clients. The assignment of the Client to a security protection domain cannot be changed. |
|
Service |
A service is a well-known set of Java interfaces and (usually
abstract) classes as defined by |
|
Service Provider |
A service provider is a specific implementation of a service. Service providers are packaged and distributed in LIBlets or in the application suite. |
|
Versioning |
A scheme to uniquely identify an Application suite, LIBlet, or API by major, minor, and micro version, to enable identification for provisioning (if supported) and dependency expression. |
|
X.509 Public Key Infrastructure |
A cryptography standard for that specifies standard formats for public key certificates and a certificate chain validation algorithm. |
Contributors
This specification was produced by the JSR XXX Expert Group, as a part of the Java Community Process. The following companies and individuals, listed in alphabetical order, are members of the Expert Group :
- Andreani, Stefano
- Aplix Corp.
- Gemalto M2M GmbH
- Keil, Werner
- North Sixty-One Ltd.
- Oracle Inc. (SpecLead)
Introduction
This document, produced as a result of Java Specification Request (JSR) 361, defines the Embedded Profile for the Java Platform, Micro Edition (Java METM). The goal of this specification is to define an enhanced architecture and the associated APIs required to enable an open, third-party, application development environment for information modules.
The JME Embedded Profile version 8.0 (MEEP 8) specification is based on the
IMP 1.0 and
IMP-NG specifications, and
many features are inspired by or have been adopted from
MIDP 3.0.
JME Embedded Profile (MEEP 8) claims to be binary backward compatible with
IMP-NG, any IMlets written for IMP-NG
can execute in MEEP 8 environments without changes, assuming that the
used packages that have been mandatory in IMP / IMP-NG, but being optional
in MEEP 8 have been chosen in this implementation.
The JME Embedded Profile version 8.0.0 (MEEP 8) is designed to operate on top of the Connected Limited Device Configuration (CLDC), version 8, aka CLDC 8. This means the full CLDC 8 specification, but NOT its compact version with limited functionality, CLDC 8 compact. MEEP 8 is not designed to operate on top of the compact version of CLDC 8!
Profile Identification
MEEP-8.0.0 profile is identified by the string "MEEP-8.0".
This string MUST be used to identify the JME Embedded Profile as the
recent one in the following contexts:
- The string
"MEEP-8.0"MUST appear in the value of themicroedition.profilessystem property as described in the system property chapter. - The string
"MEEP-8.0"MUST be the value of the application descriptor attribute for MEEP 8 applications as defined in Application Descriptor Attributes, Application Descriptor, and Operational Attributes and Applications. - The string
"MEEP-8.0"MUST be the value of the manifest attribute for MEEP 8 applications as defined in JAR Manifest.
New Features
MEEP 8 introduces a number of new features that build upon the previous success of IMP and IMP-NG. There are several reasons leading to the need of a new profile version of information modules :
- The range of embedded devices has become significantly broader during the last years, and include much more than just simple "information modules". (This is also the reason why this profile is called "Embedded Profile", although it can be seen as a successor of IMP-NG. While the devices using IMP-NG have been mainly simple wireless modules without a display and user input capabilities like keyboard or touchscreen, the area of information modules today embraces such simple devices, but also high-end modules with display and need for user interaction like water flow or electrical meters as well as medical monitors.
- The extended capabilities of embedded devices cause the need for a wider range of applications and services and new APIs are required for this.
- As many applications on embedded devices deal with personal or otherwise sensitive data, there have been requirements to improve the stability, security, and predictability of IMP implementations, that has been considered in MEEP 8.
As a consequence, MEEP 8 offers the following new features :
- Optional graphics support for those information modules owning
one or more displays and graphical capabilities. (Displays can be
built-in or auxiliary displays.) It can be chosen between:
- LUI, a simple library supporting line-oriented displays without canvas functionality (see LUI package).
- No graphics support (for information modules without a display).
- Optional support of key events (see Key package).
-
Optional media support. It can be chosen between:
- Audio-only MMAPI support as in IMP-NG, defined in the Media and the Media Control packages.
- No media support.
- Optional System and Application Events (see Event package)
- Optional Concurrency (see Application Concurrency)
- Optional Inter-Application Communication using the Inter-MIDlet Communication protocol IMC (for concurrency enabled implementations only, see IO package)
- Optional Shared Components (LIBlets)(see Application Suites and LIBlets)
- Services (see Service Providers)
- Application types like Auto Start Applications (see MIDlet package)
- Multiple Application Suite and LIBlet Clients (see Security Authentication Providers for details; if the default authentication provider is implemented, this means "multiple signers", see Application Suites Trust Model Using X.509 PKI for details)
- Optional Notifications (see Event package)
- Optional Java SE-like model for permissions (see Security for Applications).
- Optional extended SWM functionality (see SWM package).
- Optional record store system. It can be chosen between:
- Full RMS support as in IMP-NG (see RMS package).
- No record store system if not needed.
- GCF (Generic Connection Framework) has been moved into CLDC 8, the required underlying configuration for MEEP 8.
- Security related functionality like the PKI package has been moved into CLDC 8, the required underlying configuration for MEEP 8.
Scope
Embedded devices span a potentially wide set of capabilities. It is not the purpose of this specification to address all such capabilities, but rather to limit the set of APIs specified, addressing only those functional areas that were considered absolute requirements needed to achieve broad portability and successful deployments. The MEEP 8 Expert Group has agreed to continue and extend this philosophy to expand upon the existing IMP functionality in all areas, improve interoperability across implementations, and build upon the success of previous profile versions by enhancing the profile in the following areas :
- Platform : enable and specify proper application behavior on top of the CLDC 8 specification. CLDC 8 offers a row of enhancements against previous CLDC versions, and the MEEP 8 benefits from this. In ME-8 some functionality has been relocated from profiles to configurations. See the summaries of affected packages for details.
- Shared Components : enable statically shared libraries
- Application Lifecycle (i.e., defining the semantics of an application and how it is controlled) : clarify and extend to specify proper behavior of concurrently executing applications
- Optional Security Framework and Security Policy
- Optional Audio Media support
- Optional Networking support based on the GCF (being itself out of scope of this specification)
- Persistent storage : make persistent storage optional, and define for RMS API a secure binary interchange format for the provisioning of record stores
- Provide an optional line-oriented User interface (LUI) APIs for simple line-oriented displays. The support of bit-mapped graphics and UI instead, likely including Touch API, is allowed, but out of scope of this specification.
- Provide optional support of key events, also in case that no display is supported.
- Offer a higher degree of optionality in order to enable a better adaption of implementation footprints to the limitations of the target devices. See the section about optionality for details.
The above features are discussed in more depth in the associated Javadoc.
By the same reasoning, some areas of functionality were considered to be outside the scope of the MEEP 8. These areas include :
- System-level APIs: The emphasis on the APIs is, again, on enabling application programmers, rather than enabling system programming. Thus, low-level APIs that specify a system interface to, for example, voice CODECs are beyond the scope of this specification.
- Low-level security: This specification relies on the Configuration for the integrity of bytecode verification and execution.
- Service oriented architecture: No specific service oriented architecture is required, in which resources (local or remote) are made available via independent services. An inter-application communications architecture is specified, but the underlying implementation can be as simple or complex as the native platform allows.
Architecture
This section addresses issues that both implementers and developers will encounter when working with the MEEP 8. While not comprehensive, this section does reflect the most important issues raised during deliberations of the MEEP 8 Expert Group as well as experiences with previous versions.
As previously stated, the goal of the MEEP 8 is to create an open third-party application development environment for information modules. Ideally, this specification would only have to address functionality defined by the MEEP 8 specification itself. In reality, most devices that implement the MEEP 8 specification will incorporate features and components that exist in today's information module market. The High Level Architecture diagram (Figure 1-1) provides an overview of how MEEP 8 fits into an information module's software architecture. Note that not all devices that implement the MEEP 8 specification will incorporate all of the elements depicted in Figure 1-1, nor will every device necessarily implement a software stack precisely as depicted in this figure.
|
Figure 1-1 - MEEP 8 High Level Architecture |
|---|
|
In the MEEP 8 High Level Architecture, the lowest level block - labeled Embedded Device (ED) - represents the device hardware. Logically above this hardware is the native device system software; this layer includes the operating system and runtime libraries used by the device.
Logically above the native system software is the Java Virtual Machine and configuration layer. This block represents the Java Virtual Machine and associated libraries defined by the CLDC 8 specification. This block provides the underlying Java functionality upon which higher level Java APIs may be built, such as the MEEP 8 and optional packages.
Licensee Open Classes, sometimes also called OEM Specific Classes, are not JSRs, and are generally proprietary packages that do not logically fall into the category of a Java ME configuration, profile, or optional package.
OEM Specific Applications may make use of non-standard packages and APIs, and may be applications. Native Applications are non-Java applications that make use of the device system software, but may also interact and share data with MEEP 8 implementations.
Device Requirements
The requirements listed in this section are additional requirements above those found in into CLDC 8, the required underlying configuration for MEEP 8.
At a high level, the MEEP 8 specification assumes that the device is limited in its processing power, memory, connectivity, and display size.
Hardware
As previously stated, the main goal of the MEEP 8 is to establish an open, third-party application development environment for information modules. To achieve this goal, the MEEP 8 Expert group has defined the target device that SHOULD have the following minimum characteristics :
- Optional display. The user interface packages are optional in MEEP 8,
and so is the requirement of a display. The requirements depend on
the chosen UI option :
-
No user interface:
- No display.
-
LUI package :
- One or more built-in or auxiliary line-oriented displays.
- Screen size: suitable for at least one text line.
- Number of supported text lines: 1 or more.
- Number of supported characters per line: 1 or more.
-
Bit-mapped graphics and UI (out of scope of this specification):
- Screen-size : depends strongly on pixel size and resolution that can differ significantly between several kinds of embedded devices; that's why the specification won't mention a particular value here
- Display depth : 1-bit (or higher)
- Pixel shape (aspect ratio) : approximately 1:1
- touchscreen (if required by the chosen API)
-
No user interface:
- Optional Input Device (keyboard). The input device may exist as part of a display, but also independent of it.
- Memory: The minimal memory needed for a MEEP 8 implementation is
128 kB RAM and 1 MB Flash. This assumes this implementation to be
a combination of a single-function device without or with very few
optional packages.
Implementers should be aware that his is by far not enough for the implementation of all (or a higher number of) optional packages described in this specification.
The Profile Sets chapter describes a number of proposed and possible (but by far not all) possible combinations of optional packages being expected to become the most popular ones, called Profile sets. It includes also minimal and recommended memory amounts for those combinations.
- Optional Networking :
- Zero or more logical network interfaces
- Two-way, wireless connections, possibly intermittent, with limited bandwidth (if number of logical network interfaces is greater than zero)
- Optional Sound. Depending on whether the optional audio media package
is part of the implementation or not, the following requirement
is raised :
- The ability to play tones, either via dedicated hardware, or via software algorithm.
Examples of devices include (but are not restricted to) wireless modules, medical monitor devices, electrical or water meters, and cellular IP phones.
Software
For devices with the aforementioned hardware characteristics, there is still a broad range of possible system software capabilities. Unlike the consumer desktop computer model where there are large, dominant system software architectures, the space of information modules is characterized by a wide variety of system software. For example, some devices may have a full-featured operating system that supports multi-processing and hierarchical file systems, while other devices may have small, thread-based operating systems with no notion of a file system. Faced with such variety, this specification makes minimal assumptions about the system software. These requirements are as follows :
- A minimal kernel to manage the underlying hardware (i.e., handling of interrupts, exceptions, and minimal scheduling). This kernel must provide at least one schedulable entity to run the Java Virtual Machine (JVM). The kernel does not need to support separate address spaces (or processes) or make any guarantees about either real-time scheduling or latency behavior.
- Read and write access to the device's wireless networking to support the Networking APIs.
- A mechanism to provide a time base for use in time-stamping the records written to Persistent Storage and to provide the basis for the Timer APIs.
- A mechanism for managing the application life-cycle of the device.
In case a persistent storage option has been chosen, the following additional requirement has to be considered :
- A mechanism to read and write from non-volatile memory to support the requirements of the chosen record management API for persistent storage.
In case a UI option has been chosen, the following additional requirements have to be considered :
- A minimal capability to write to a bit-mapped graphics display in case a bit-mapped graphics and UI is used (outside the scope of this specification).
- A mechanism to capture user input from one (or more) of the input mechanisms previously discussed, if any.
Specification Requirements
This section lists some explicit requirements of this specification. Other requirements can be found in the associated API specifications. If any requirements listed here differ from requirements listed elsewhere in the specification, the requirements here take precedence and replace the conflicting requirements.
Compliant MEEP 8 implementations:
- MAY support IMP 1.0 and IMP-NG IMlets and IMlet suites. Packages used by those IMlets, that may have been mandatory in IMP 1.0 and/or IMP-NG, but being optional in MEEP 8 have to be chosen in the MEEP 8 implementation in order to let those applications run.
- MUST include all mandatory packages, classes, and interfaces described in this specification.
- MAY include any optional package, classes, and interfaces described in this specification as long as they are not mutually exclusive
- MAY implement provisioning as specified in the MEEP 8 Provisioning (OTA) specification.
- MAY implement another provisioning mechanism than the one covered by OTA Provisioning mechanism as specified in this specification.
- MAY incorporate zero or more supported protocols for PushRegistry.
- MAY give the user a visual indication of network usage generated when using the mechanisms indicated in this specification, but only IF the implementing device offers visual capabilities.
- MUST support Tone Generation in the media package, but only IFF audio media support as defined here has been chosen.
- MAY support 8-bit, 8 KHz, mono linear PCM wav format IF any sampled sound support is provided, but only IFF audio media support as defined here has been chosen.
- MAY include support for additional sampled sound formats, but only IFF audio media support as defined here has been chosen.
- MAY support Scalable Polyphony MIDI (SP-MIDI) and SP-MIDI Device 5-to-24 Note Profile, but only IFF audio media support as defined here has been chosen and any synthetic sound support is provided.
- MAY include support for additional MIDI formats, but only IFF audio media support as defined here has been chosen.
- MUST implement the mechanisms needed to support Untrusted Application Suites.
- MUST implement Trusted Application Suite security unless the device security policy does not permit or support trusted applications.
- MAY implement Application Suites Trust Model Using X.509 PKI to recognize signed Application suites as trusted unless PKI is not used by the device for signing applications.
- MAY implement another trust model to recognize trusted application suites than the one using PKI, while the definition of such an alternative model to recognize trusted applications is out of scope of this specification.
- MUST enforce the same security requirements for I/O access as from the Generic Connection framework, as specified in the underlying configuration, but only IFF audio media support as defined here has been chosen.
- MUST support at least the UTF-8 character encoding defined in [RFC2279] for APIs allowing to define character set names / encoding names.
- MAY support other character encodings IFF packages have been chosen that allow the application to define character encodings.
- SHOULD NOT allow copies to be made of any Application suite unless the device implements a copy protection mechanism and any resulting copies will be copy protected in a manner consistent with the implementation's policy.