Definitions

Abbreviations

In addition to the Abbreviations provided in Volume 1, the following abbreviations are used in this Volume.

Similarities between applications and traditional web pages

DAE applications are comprised of pages which are conceptually no different from traditional web pages. Both pages in a DAE application and traditional web pages can include the contents of other documents. These included documents can have a variety of types, including Cascading Style Sheets (CSS), JavaScript, SVG, JPEG, PNG and GIF.

A dynamic DOM, combined with XMLHttpRequest, permits AJAX-style changes to the current page in a DAE application or web page without necessarily replacing the entire document.

Differences between applications and traditional web pages

A DAE application provides shared context and state common to a number of pages — a concept which doesn't formally exist in the web. Loading and unloading pages within the context of a DAE application is the same as loading and unloading web pages.

The application context includes information about the state of an application from the platform's perspective — permissions, priority (for example, which to terminate first in the event of insufficient resources) and similar information that spans all documents within an application during the lifetime of that application.

An OITF MAY support the execution of more than one application simultaneously. Applications MAY share the same screen estate in a defined and controlled fashion. This differs from multiple web pages, which are typically handled through different browser “windows” or “tabs” and may not share the same screen estate concurrently (although the details of this behaviour are often browser-dependent). This also differs from the use of frames, which, apart from iframes, do not support overlapping screen estate. Where simultaneous execution of more than one application is supported, both foreground and background applications SHALL be supported simultaneously.

Where simultaneous execution of more than one application is supported, applications SHALL be recorded within a hierarchy of applications. Each object representing an application possesses an interface that provides access to methods and attributes that are uniquely available to applications. For example, facilities to create and destroy applications can be accessed through such methods.

The application tree

Where simultaneous execution of more than one application is supported, applications are organised into a tree structure. Using the createApplication() method as defined in section , applications can either be started as child nodes of the application or as a sibling of the application (i.e. added as an additional child of this application's parent). The root node of an application tree is created upon loading an initial application URI or by creating a sibling of an application tree's root node. An OITF MAY keep track of multiple application trees. Each of these individual application trees are connected to a hidden system root node maintained by the OITF that is not accessible by other applications.

Applications created while the DAE environment is running (e.g. as a result of an external notification) that are not created through createApplication() SHALL be created as children of the hidden system root node.

The application display model

Applications SHALL be displayed on the OITF in one of the application visualization modes as defined in section .

The mode used SHALL be determined prior to initialisation of the DAE execution environment and shall persist until termination or re-initialization of the DAE execution environment. The means by which this mode is chosen is outside the scope of this specification.

Each application has an associated DOM Window object and a DOM Document object that represents the document that is currently loaded for that application. Even “windowless” applications that are never made visible have an associated DOM Window object.

The security model

Each application has a set of permissions to perform various privileged operations within the OITF. The permissions that are granted to an application are defined by the intersection of three permission sets:

1. The permissions requested by the application, using the mechanism defined in section .
2. The permissions supported by the OITF. Some permissions may not be supported due to capability restrictions (e.g. the permission_pvr permission will never be granted on a receiver that does not support PVR capability).
3. The permissions that may be granted, as determined by user settings or configuration settings specified by the operator (e.g. blacklists or whitelists; see section for more information). This is a subset of (2), and may be different for different users.

Inheritance of permissions

Applications created by other applications (e.g. using the methods described in sections or ) SHALL NOT inherit the permissions issued to the parent application. The permissions granted to the new application will be defined by the mechanism specified in section .

When an application uses cross-document messaging (see the window.postMessage() method defined in HTML5 Web Messaging as referenced in [[.OIPF_WSTVP2]]) to communicate with another application, any action carried out in response to the message SHALL take place in the security context of the application to which the message was sent. Applications SHOULD take care to ensure that privileged actions are only taken in response to messages from an appropriate source.

Privileged application APIs

The privilege model implemented with applications is based upon requiring access to the Application object representing an application in order to access the privileged functionality related to application lifecycle management and inter-application communication.

Active applications list

Where simultaneous execution of more than one application is supported, the OITF SHALL maintain a list of application nodes ordered in a “most recently activated” order — the active applications list. This list is used by the cross-application event dispatch algorithm as defined in section and is not directly visible to applications.

An application is activated through calling the activateInput() method of the application node. This marks an application as active and SHALL insert the application at the start of the active application list (removing it from the list first if it is already present).

An application is deactivated through the deactivateInput() method of the application node. This marks an application inactive and SHALL remove it from the active application list.

The currently active application is the application at the start of the active application list.

This specification does not define any behaviour if more than one copy of the browser is executing.

Widgets

DAE Widgets are a specialization of DAE applications and share aspects with W3C Widgets.

W3C Widgets are standardized by the “Widgets 1.0 family of specifications” as described in section 1.4 of [[!Widgets-Packaging]]. Section of this document specifies which parts of W3C Widgets specifications are in supported by DAE Widgets. From here on, when using the word “Widget” we will refer to DAE Widgets as defined in this specification.

Widgets can be primarily seen as packaged DAE applications. Since they are packaged, it is possible to have a single download and installation on an OITF. Widgets may also be installed on an OITF via non-HTTP distribution channels and even over off-network channels (e.g. a USB thumb drive). Packaging also provides an easy way to deploy and/or update applications on the OITF when it is installed in the home. The packaging and configuration of a DAE Widget is described in section .

Since DAE Widgets are DAE Applications everything that is defined for a DAE Application is also applicable to a Widget unless specified. Furthermore Widgets have several specific features as defined in section .

Origin for Broadcast-delivered Documents

For documents that are delivered by an object carousel in a broadcast channel (as defined in section 4.1 of [[.OIPF_MEDIA2]], the following SHALL apply;

• For each broadcast channel, the OITF SHALL generate a unique origin as defined in [[!RFC6454]].
• These origins SHALL be of the form scheme/host/port tuple where the OITF does not use the same scheme for any documents other than those delivered by a broadcast object carousel.
• The origin SHALL be the one for the channel from which the document was loaded regardless of any subsequent channel changes

Specifically this origin SHALL be used with the Web Storage API as referenced in [[.OIPF_WSTVP2]].

Application lifecycle issues

Where simultaneous execution of more than one application is supported, if an application attempts to start and not enough resources are available, the application with the lowest priority MAY be terminated until sufficient resources are available for the new application to execute or until no applications with a lower priority are running. Applications without a priority associated with them (e.g. applications started by the DRM agent, see section ) SHALL be assumed to have a priority of 0x7F.

Applications may register a listener for ApplicationUnloaded events (see section ) to receive notification of the termination of a child application, where simultaneous execution of more than one application is supported.

Failure to load an asset (e.g. an image file) or CSS file due to a lack of memory SHALL have no effect on the lifecycle of an application, but may result in visual artefacts (e.g. images not being displayed). Failure to load an HTML file due to a lack of memory MAY cause the application to be terminated.

Caching of application files

Application files MAY be cached on the receiver in order to improve performance; this specification is silent about the use of any particular caching strategy.

Memory usage

Applications SHOULD use current industry best practises to avoid memory leaks and to free memory when it is no longer required. In particular, applications SHALL unregister all event listeners before termination, and SHOULD unregister them as soon as they are no longer required.

Where available, applications SHALL use explicit destructor functions to indicate to the platform that resources may be re-used by other applications.

Applications MAY use the gc() method on the application/oipfApplicationManager embedded object to provide hints to the OITF that a garbage collection cycle should be carried out. The OITF is not required to act on these hints.

The LowMemory event described in section SHALL be generated when the receiver is running low on memory. The amount of free memory that causes this event to be generated is implementation dependent. Applications may register a listener for these events in order to handle low-memory situations as they choose best.

Instantiating embedded objects and claiming scarce system resources

The objects defined in section of this specification are embedded objects. These are typically instantiated through the standard DOM 2 methods for creating HTML objects or the oipfObjectFactory as defined in section .

All embedded objects as defined in section SHALL NOT claim scarce system resources (such as a hybrid tuner) at the time of instantiation. Hence, instantiation SHALL NOT fail if the object type is supported (and sufficient memory is available).

For each embedded object for which scarce resource conflicts may be a problem, the state diagram and the accompanying text define how to deal with claiming (and releasing) scarce system resources.

Once an OIPF embedded object has been instantiated, dynamic change of its MIME type which could cause the properties and methods associated with the object to change SHALL be ignored.

For instance, it is possible to change the MIME type of an A/V Control embedded object from video/mpeg to video/mp4 but it is not possible to change the MIME type of an OIPF embedded object from “application/oipfApplicationManager” to “application/oipfConfiguration”.

Media control

If insufficient resources are available to present the media, the attempt to play the media SHALL fail. For the video/broadcast object, this shall be indicated by a ChannelChangeError event with a value of 11 for the error state. For an A/V Control object, the error property shall take the value 3.

When the video/broadcast or A/V Control object either is instantiated in the DYNAMIC_ALLOCATION model or transitions to the DYNAMIC_ALLOCATION model, scarce resources such as a media decoder SHALL only be claimed following a call to the bindToCurrentChannel(), setChannel(), nextChannel() or prevChannel() methods on a video/broadcast object or the play() method on an A/V Control object. By implication, instantiating a video/broadcast or A/V Control object does not cause the media referred to by the object's data attribute to start playing immediately. See section for details of when scarce resources are released by a video/broadcast object and section when scarce resources are released by an A/V Control object.

Scarce resources can be claimed by the video/broadcast or A/V Control object at instantiation time by specifying the requiredCapabilities parameter. In this case the STATIC_ALLOCATION method is used and the scarce resources are held by the object until it is either destroyed or the release() method is called.

This specification is intentionally silent about handling of resource use by embedded applications including scheduled recordings.

Use of the display

A compliant OITF SHALL support at least one of the following application visualization modes for managing the display of applications:

1. Multiple applications may be visible simultaneously, with each application having a full-screen window, with the OITF managing focus. Setting parts of an application to be transparent SHALL cause the following to be visible except where the application has drawn UI elements.
   • firstly any applications with a lower Z-index
   • secondly video (if the hardware supports overlay as per the <overlay*> elements defined in section for the capability profiles)

   In this mode, applications from the same service provider that are intended to run simultaneously SHOULD take care to co-ordinate their use of the display in order to ensure that important UI elements are not obscured.

2. Multiple applications may be visible simultaneously, with the OITF managing the size, position, visibility and focus between applications.
3. Only one application is visible at any time; switching to a different application either hides the currently-visible application (where simultaneous execution of more than one application is supported) or terminates the currently visible application (where simultaneous execution of more than one application is not supported). The mechanism for switching between applications is implementation-dependent. In this case, the show(), hide(), activateInput() and deactivateInput() methods of the Application object provide hints to the execution environment about whether the user should be notified that an application requires attention. The mechanism for notifying the user is outside the scope of this specification.

Applications SHALL be created with an associated DOM Window object, that covers the display area made available by the OITF to a DAE application. The size of the DOM Window can be retrieved through properties innerWidth and innerHeight of the DOM Window object.

Any areas of the browser area outside the DOM Window that become visible when it is resized SHALL be transparent — any video (if the hardware supports overlay as per the <overlay*> elements defined in section for the capability profiles) or applications (if multiple applications can be visible simultaneously) with a lower Z-index will be visible except where the application has drawn UI elements.

Broadcast-related and service provider related applications SHALL initially be created as invisible to avoid screen flicker during application start-up. Once loaded (as SHALL be indicated through an onload event handler), the application then typically calls the show() method of its parent Application object. Broadcast-independent applications SHALL initially be created as visible and need not call these methods.

If the application does not ever need to be visible, then its DOM Window object will never be shown. In that case, the application should take steps to avoid being formatted to reduce computation and memory overheads. This is typically accomplished by setting the default CSS style of the document's BODY element to visibility:hidden.

Because all applications have associated DOM Window objects, it is possible to make any application visible even if it is not normally intended to be visible. This is of particular benefit during debugging of hidden service type applications.

Application developers SHOULD explicitly set the background color of the application <body> and <html> elements.

Setting the background color to 'transparent' (e.g. using the CSS construct html, body { background-color: transparent; }) will allow the underlying video to be shown for those areas of the screen that are not obscured by overlapping non-transparent (i.e. opaque) children of the <body> element.

Changing the visibility of an application by calling method show() or hide() on the Application object SHALL NOT affect its use of resources. The application still keeps running and listens to events unless the application gets deactivated (see section ) or destroyed (see section ).

Cross-application event handling

As defined in the DOM Level 3 Events specification as referenced in [[!OIPF_WSTVP2]], standard DOM events are raised on a specific node within a single document. This specification extends the event capability of the OITF through cross-application events handling, but does not change the DOM2 event model for dispatching events within documents. Where simultaneous execution of more than one application is supported, an OITF SHALL implement the cross-application events and cross-application event handling model described in this section.

1. An OITF SHALL implement the following cross-application event handling model. Cancelling the propagation of an event in any phase SHALL abort further raising of the event in subsequent phases: If an event is eligible for cross-application event handling (see below for more information) and is targeted at a node in the most recently activated application, then dispatch the event to that node using the standard DOM bubbling/capturing of events. Default actions normally taken by the browser upon receipt of an event SHALL be carried out at the end of this step, unless overridden using the existing DOM methods (i.e. using method preventDefault()).
2. If the cross-application event is not prevented from being propagated beyond the document root node of the application by using the existing DOM methods, the event is dispatched to other active applications in the application hierarchy using the active applications list described in section . The OITF SHALL iterate over the applications in the active application list, from most recently activated to least recently activated, dispatching the event to the Application object of each application in turn. Note that the event SHALL NOT be dispatched to the document, and default browser action SHALL NOT be carried out during this phase. Cancelling the propagation of an event in this phase SHALL abort further raising of the event in subsequent applications.

Event listeners for cross-application events are registered and unregistered using the same mechanism as for DOM2 events. Listeners for cross-application events may be registered on the Application object as well as on nodes in the DOM tree.

The following events are valid instances of cross-application events and are applicable for cross application event handling:

The KeyPress, KeyUp and KeyDown events are all targeted cross-application events. The events are targeted at the node that has the input focus.

All events dispatched using the standard dispatchEvent() method are normal DOM events, not cross-application events. As defined in HTML5 Web Messaging as referenced in [[.OIPF_WSTVP2]], the OITF SHALL support the window.postMessage() method for cross-document messaging. The method takes two arguments; a message (of type String) to be dispatched and the targetOrigin, which defines the expected origin (i.e. domain) of the target window, or “*” if the message can be sent to the target regardless of its origin. The target of the event is the “window” of a specific application. Applications can use this method to send events to other applications. The receiving application MAY receive those events and interpret them, or MAY dispatch them in its DOM using standard DOM dispatchEvent() methods.

The visibility of an application SHALL NOT affect the cross-application event handling algorithm as defined above — an active application SHALL receive cross-application events even when it is not visible.

Incoming key events are dispatched using the cross-application event handling algorithm as defined above.

NOTE: This event dispatch model enables key events to be dispatched to multiple applications. Applications wishing to become the primary receiver for key events SHOULD call Application.activateInput(). Even though Application.activateInput() is called, another application may subsequently be activated. In order to ensure that sensitive key input (e.g. PINs or credit card details) is limited only to the application it is intended for, applications SHOULD check that they are the primary receiver of the key events (using the Application.isPrimaryReceiver property and/or the ApplicationPrimaryReceiver and ApplicationNotPrimaryReceiver events defined in section ) and SHOULD 'absorb' key events by calling the stopPropagation() method on the DOM2 key event.

Tuner resources

Tuners can be used for recording, scanning or watching broadcast channels (e.g. DVB-T). The priority relating to resource management is as follows. Recording have the highest priority, viewing a channel has the lowest priority. A record request SHALL not be automatically interrupted by a viewing a channel or a scan request. Note to free the tuner for viewing requires interrupting the recording first.

Download manager

An OITF SHALL support a native download manager (i.e. “Content Download” component) to perform the actual download and storage of the content, and which allows the user to manage (e.g. suspend/resume, cancel) and monitor the download, in a consistent manner across different service providers. The download manager SHALL continue downloading as a background process even if the browser does not have an active session with the server that originated the download request anymore (e.g. has switched to another DAE application), even after a device power-down or network failure, until it succeeds or the user has given permission to terminate the download. (see section on HTTP Range support to resume HTTP downloads after a power/network failure).

The native download manager SHALL be able to offer a visualization of its status through the application/oipfStatusView embedded object as defined in section .

If the attribute manageDownloads of the <download> element in the client capability description is unequal to “none”, the native download manager SHALL offer control over the active downloads through the JavaScript API defined by the application/oipfDownloadManager embedded object in section .

NOTE 1: Once sufficient data of the content has been downloaded, the content MAY be played back using a native application, and MAY be played back using an A/V Control object. In the latter case, see method setSource() in section for more information.

NOTE 2: Annex clarifies the content download usage scenario in more detail.

Content Access Download Descriptor

An OITF SHALL support parsing and interpretation of the Content Access Download Descriptor document format with the specified semantics, syntax and MIME type as specified in Annex .

Triggering a download

An OITF SHALL support a non-visual embedded object of type “application/oipfDownloadTrigger”, with the JavaScript API as defined in sections and to trigger a download.

The following subsections define some details about the different ways of triggering a download.

Download protocol(s)

The OITF SHALL support the HTTP protocol for download as specified in section 5.3.4 of [[!OIPF_PROT2]]. In addition, the OITF SHALL support the following requirements:

1. As specified in section 5.3.4 of [[.OIPF_PROT2]], if a server offers a content item for download using HTTP, the server SHALL make sure that HTTP Range requests as defined in [[!HTTP]] are supported for HTTP GET requests to the URI of that downloadable content item, in order to be able to resume downloads (e.g. after power or network failure).
2. If the OITF receives an HTTP 404 “File Not Found” status code, the OITF SHALL stop its attempts to resume the download, and go to a “Failed Download” state. The handling of other error codes is implementation dependent.
3. If after downloading a content item the size of the downloaded content item does not match the indicated size parameter or the value for the optional attribute “MD5Hash” of the given <ContentURL> does not match the hash of the downloaded content, the OITF SHOULD remove the downloaded content item.

Integration with download protocols other than HTTP are not specified in this document.

Unicast streaming

This specification defines 3 mechanisms by which a reference to content can be passed from a DAE application to the OITF.

1. By setting the data property of a A/V Control object as defined in section to the reference. The application SHALL set the type attribute to the MIME type of the content referred to by the value of the data attribute to provide a hint about the expected content type, in order for the browser to instantiate the proper object to play the content.
2. By setting the src attribute of a <video> element to the reference
3. By including the reference in the <ContentURL> element of a Content Access Streaming descriptor as defined in section and then setting the data property of an A/V Control object as defined in section to be a reference to that Content Access Streaming Descriptor. In this case the application SHALL set the type attribute to “application/vnd.oipf.ContentAccessStreaming+xml”.

   Example:
   <object id="d1" data=http://www.openiptv.org/fetch?contentID=25
  type="application/vnd.oipf.ContentAccessStreaming+xml" width="200" height="100"/>

This specification defines five different possible formats for a reference to unicast streaming content;

1. A Public Service Identifier (PSI) as defined in Protocol Specification [[.OIPF_PROT2]].
2. An HTTP URL directly referencing the content to be streamed.
3. An RTSP URL directly referencing the content to be streamed.
4. An HTTP or HTTPS URL referencing a HAS MPD
5. An HTTP or HTTPS URL referencing a MPEG DASH MPD

All of the mechanisms that an OITF supports SHALL be supported with all formats of a reference that an OITF supports.

Conveyance of channel list

To enable a service to control the tuner functionality on an OITF, the OITF needs to convey the channel list information that is managed by native code on the OITF device to the service (either the channel list information is provided locally on the OITF via JavaScript, or the channel list is communicated directly to a server). This information includes the list of uniquely identifiable channels that can be received by the physical tuner of a hybrid device, including information about how the channels are ordered and whether or not these channels are part of zero or more favourite lists. It also includes the channel line-up and the favourite lists that MAY be managed by an OITF for IP broadcast channels.

The API supports two methods of conveying the channel list information to a service:

1. Method 1: through JavaScript, by using the method “getChannelConfig()”, as defined in section .
2. Method 2: through an HTTP POST message that is sent upon the first connection to a service that requires tuner control, as defined in section .

An OITF SHALL support method 1, and SHOULD support method 2.

If an OITF conveys the channel list information using the HTTP POST message defined in method 2, then the server SHALL, if it supports method 2, receive the conveyed channel list information and SHOULD rely on this information for the purpose of exerting tuner control. If a service supports using the channel list information sent through the HTTP POST method to exert tuner control , the server SHALL indicate this compatibility with method 2 using the postList attribute specified in section (i.e., <video_broadcast postList="true">true</video_broadcast>), in the server capability description.

If the server does not support method 2, the service SHALL rely on the getChannelConfig() method defined in section to access the channel list information. If an OITF does not support method 2, the HTTP message of the first connection to the service that requires tuner control SHALL be an HTTP GET message with an empty payload and the service SHALL instead rely on the getChannelConfig() method defined in section to access the channel list information. If support for method 2 is indicated by both the OITF and the server (through respective capability exchanges), the OITF SHALL convey the channel list information using method 2.

If an OITF does not manage/maintain the channel line-up (i.e. does not have a locally stored channel line up), the getChannelConfig() method described in section SHALL return null, and the HTTP message described in section SHALL be an HTTP GET message with an empty payload. In that case, the application MAY use the createChannelObject() method as defined in section to create channel objects that can be used on subsequent setChannel() requests, and in this way can manage/maintain its own channel list.

NOTE: conveyance of the channel list SHALL adhere to the security model requirements as specified in sections and .

Conveyance of channel list and list of scheduled recordings

This section and the following sections SHALL apply to OITFs that have indicated <recording>true</recording> as defined in section in their capability profile.

To enable a service to schedule recordings of content that is to be broadcasted on specific channels, the OITF needs to convey the channel list information that is managed by the native code on the OITF. This information typically includes the channel line-up of the tuner of a hybrid device. The conveyance of channel list information and scheduled recordings is based on the same two methods of conveying the channel list information to a service as defined in section :

1. Method 1: through JavaScript, by using the method “getChannelConfig()”. To this end, the OITF SHALL support method “getChannelConfig()” as defined in section for the application/oipfRecordingScheduler object.
2. Method 2: through an HTTP POST message as defined in section that is sent upon the first connection to a service that has indicated that it requires control of the recording functionality and that has indicated compatibility with method 2 using the postList attribute specified in section (i.e., <recording postList="true">true</recording>), in the server capability description for a particular service.

An OITF SHALL support method 1, and SHOULD support method 2. If support for method 2 is indicated by both the OITF and the server (through respective capability exchanges), the OITF SHALL convey the channel list information using method 2. Otherwise, the HTTP message of the first connection to the service that requires tuner control SHALL be an HTTP GET message with an empty payload.

If a server has indicated that it requires control of both the tuner functionality and the recording functionality available to an OITF (i.e. by including both <video_broadcast> and <recording> with value true in the OITF's capability description), the body of the HTTP POST message SHALL contain a single instance of the Client Channel Listing whereby the <Recordable> element defined in Annex SHALL be used to indicate whether channels that can be received by the tuner of the OITF can be recorded or not.

If an OITF does not manage the channel line-up, the getChannelConfig() method described in section SHALL return null, and the HTTP message described in section SHALL be an HTTP GET message with an empty payload.

In addition, the OITF SHALL also support method getScheduledRecordings() as defined in . This method returns a ScheduledRecordingCollection object, which is defined in section .

Note that the conveyance of the channel listing and the scheduled recordings is subject to the security model requirements specified in section , and in particular the recording related security requirements in section .

Interfaces used by the DLNA RUI Remote Control Function

This section describes interfaces related to the DLNA RUI RCF. There are three entities (Remote Control Device, OITF and IPTV Applications server) that communicate with each other through the interfaces described in Figure .

Figure shows the entities in the OIPF Architecture involved in the DLNA RCF and the interfaces between them.

The dotted line “d)” between the RCF embedded object and the DLNA RUIS indicates that it is a local interface and hence not defined by this specification. The detailed behaviour of each interface is defined as follows:

1. Interface a)
   This interface is used to retrieve a Control UI from an IPTV Applications server by using XMLHttpRequest object (the Control UI retrieved through interface a) will be delivered to DLNA RUIC via interfaces c), d) and e), sequentially).
2. Interface b)
   This interface is used by the DAE browser to retrieve a DAE application containing an RCF object when the DLNA RUIC requests a DAE application to execute in the OITF.
3. Interface c)
   The DLNA RUI RCF APIs use this interface to enable a DAE application to get the request originating from the DLNA RUIC, through an event dispatched by the OITF, and send the corresponding response or any other information to the DLNA RUIC via the DLNA RUIS.
4. Interface d)
   This is a local interface that is used to pass messages between an RCF object in a DAE application and the DLNA RUIS.
5. Interface e)
   This is a DLNA RUI compatible interface which provides device discovery, sending/receiving HTTP messages and notifications.
   When the DLNA RUIC is activated by a user, the DLNA RUIC searches for a DLNA RUIS and does a capability exchange. Then, the DLNA RUIC retrieves the XML UI Listing from the DLNA RUIS and displays it to the user. When the user chooses one of the Control UIs, the DLNA RUIC retrieves the selected Control UI from the DLNA RUIS in the OITF.
   The Control UI may send an HTTP request to deliver a message (for example, plays an AV content) and receive a response from the DLNA RUIS.
   This interface is also used for the DLNA RUIS to send a 3^rd party notification defined in section 5.6.1 of [[!CEA-2014-A]].
6. Interface f)
   This interface is used by the selected Control UI (CE-HTML document) to retrieve resources (For example, images, CE-HTML documents, or css or JavaScript files) directly from the IPTV Applications server.

DAE application wake-up support

The OITF MAY support wake-up requests from a “passive standby” state. There are two types of wake-up requests, one on an individual DAE application and one on the OITF. The supported wakeup is indicated in the power consumption capability information.

OITF hibernate support

The OITF MAY support a hibernate mode which allows DAE applications and their state to be stored in memory when in a “passive standby” state. The support of a hibernate mode greatly reduces the start-up time for DAE applications (for example, start-up times of 3 seconds may be reached).

When the OITF resumes from the hibernate mode, it SHALL restore all of the previous DAE applications with their previous state and SHOULD assign the same resources to the DAE applications as they had prior to the hibernate mode. If this is not possible, the regular callback functions SHALL be used to inform the affected DAE application.

If hibernate mode is supported the event ApplicationHibernateRequest is generated instead of ApplicationDestroyRequest when the OITF enters a “passive standby” state.

If the OITF supports hibernate mode only the OITF wake-up request is supported. The single DAE application wake-up SHALL NOT be supported. The reason for this limitation is due to the difficulty to support both options.

A wake-up support SHALL NOT make the OITF resume from the hibernate mode. The wake-up support SHALL be supported independently.

The OITF SHALL indicate support for hibernate mode through the <hibernateMode> capability defined in section .

State diagram for the power state

The following state machine provides an overview of the power state changes that may occur relating to power consumption. The transitions in the state machine due to setPowerState() may be also be triggered by user generated events handled natively by the OITF.

NOTE 1: The transition from the OFF state to the PASSIVE_STANDBY or ON states is manufacturer dependent

Creating a new application

// Assumes that the application/oipfApplicationManager object has the ID 
// “applicationmanager”
var appMgr = document.getElementById("applicationmanager");
var self = appMgr.getOwnerApplication(Window.document);

// create the application as a child of the current application
var child = self.createApplication( url_of_application, true );

Stopping an application

The destroyApplication() method (as specified in section ) SHALL terminate the application. An application may register a listener on the ApplicationDestroyRequest event in order to perform any clean-up before being destroyed completely. After the destroyApplication() method returns, further execution of the specified application SHALL NOT occur.

When an application is terminated, all associated resources SHALL be freed (or marked available for garbage collection). Any active network-related sessions will be terminated. Any media content being presented by the application is stopped, although recordings or content downloads initiated by the application will not be affected.

Note that terminating an application does not imply any effect on the state of the DAE environment.

Additional requirements are defined for stopping selected service provider applications and applications part of scheduled content services in sections and respectively.

Application Boundaries

All of the pages that make up an application are contained within its application boundary. This is the “fully qualified domain name” (FQDN) of the initial page of the application in the absence of an application_boundary_descriptor.

If an applicationBoundary element is present in the SD&S signalling for an application as defined in [[!TS102809]], the application boundary SHALL also include the FQDNs listed in the applicationBoundary element. If this element is not present, then the application boundary SHALL consist of the FQDN of the initial page of the application.

For files requested with XMLHttpRequest, the same origin policy SHALL be extended using the application domain; i.e. any domain in the application domain SHALL be considered of same origin.

The OITF SHALL remove any IP address in the application boundary which is within the private address space as defined in [[!RFC1918]], before launching the application.

Extending the origin of XMLHttpRequest is potentially dangerous, and may lead to undesired leaking of private information. To make sure that the integrity of the user is not compromised, the OITF SHOULD include a mechanism which allows the user to exclude domains from application boundaries of applications.

Introduction

This specification defines 3 basic types of application;

• Applications related to one or more broadcast TV or radio channels. These MAY run while one of the channels which they are related to is being presented by the OITF. These are signalled through the SD&S broadcast or package discovery records or included in an application discovery record which is referenced from the broadcast or package discovery record.
• Applications related to the service provider selected through the service selection process. These MAY run at any time until the service provider selection process is repeated and a different service provider selected. These are signalled through the SD&S service provider discovery record or included in an application discovery record which is referenced from the service provider discovery record.
• Applications independent of either of the above. These MAY run at any time. These are started by other applications and are not signalled anywhere.

Each of these types is described in more detail below.

General

Section of this specification describes how one application may start another application either as a sibling or as a child. All applications started via SD&S signalling as described in this section SHALL be started as children of the hidden system root node, as described in section .

Any application may be signalled as AUTOSTART or PRESENT (see “Table : ” below and section 5.2.4.3 of [[!TS102809]]). Applications signalled as AUTOSTART are intended to be automatically started by the OITF. Applications signalled as PRESENT are intended to be started only by other applications. Broadcast related applications may alternatively be signalled as KILL (see below) or PREFETCH.

It is up to the OITF manufacturer to ensure a good quality of experience concerning;

• Navigation within a DAE application.
• Accessing the available DAE applications, both available for launch, and those already running.
• Managing the life cycles of all DAE applications able to be used concurrently.

It is outside the scope of this specification whether there are dedicated keys on a remote control (e.g. the "menu", "home" or "guide" key), there is an entry in an on-screen menu or there are some other mechanism.

It is OPTIONAL for the OITF to support an exit mechanism directly accessible by the end-user. If one is supported, it is outside the scope of this specification whether this mechanism is a button on a remote control, an item in an on-screen menu or something else. If such a mechanism is supported then it SHALL only stop the application the end-user is currently interacting with and any child applications of that application. The parent application and any siblings SHALL NOT be stopped.

Additionally any application MAY be stopped under the following circumstances;

• The application itself exits.
• Its parent application exits.
• It is stopped by the application which started it or another application which has a reference to its application object.
• In response to changes in the application signalling as defined below for broadcast related applications and service provider related applications.

In all these above cases except the first (when an application itself exits) when an application is stopped by the OITF, an ApplicationDestroyRequest event (as defined in section ) SHALL be raised on the application. In the following error conditions, an application being stopped SHOULD have an ApplicationDestroyRequest event raised if this is possible.

• The OITF runs out of resources for applications and has to stop some of them in order to keep operating correctly.
• The OITF has determined that an application is non-responsive or has crashed.

Broadcast related applications

Procedure for starting and stopping broadcast related applications on channel change

When a scheduled content service is selected, the following SHALL apply;

• The OITF shall determine if there are any applications signalled as part of the service as defined by sections 3.2.3.1 and 3.2.3.2 of [[.OIPF_META2]].
• Applications which are related to that scheduled content service and which are signalled with a control code of AUTOSTART SHALL be started if not still running from any previously presented linear TV service. They SHALL be started commencing with the highest priority application working downwards in priority while resources in the OITF permit.
• Applications which are related to that scheduled content service, which are signalled with a control code of AUTOSTART and which are already running from a previously presented scheduled content service SHALL:
  1. continue to run uninterrupted if the serviceBound element of the ApplicationDescriptor in their signalling has value false
  2. be stopped and re-started if the serviceBound element of the ApplicationDescriptor in their signalling has value true
• Applications which are related to that scheduled content service and which are signalled with a control code of PRESENT SHALL continue to run if already running but SHALL NOT be started if not already running.
• Running applications from any previously presented scheduled content service which are not part of the new scheduled content service SHALL be stopped as part of the change of presented service.

The following flowchart shows the behaviour that SHALL apply when the selected channel changes:

Procedure for starting and stopping broadcast related applications when signalling is updated

When the application signalling for a scheduled content service is updated, the following apply;

• Applications which are added to the service with a control code of AUTOSTART SHALL be automatically started when their addition is detected by the OITF. They SHALL be started commencing with the highest priority application working downwards in priority while resources in the OITF permit. Applications added to the service with any other control code SHALL NOT be automatically started.
• Applications which are part of the service whose control code changes to AUTOSTART from some other value SHALL be automatically started unless already running.
• An application which is removed from the service or whose control code changes to KILL SHALL be stopped.

If application signalling is removed from a service, all running broadcast-related applications SHALL be stopped (i.e. the same behaviour as signalling an empty AIT).

The following flowchart shows the behaviour that SHALL apply when the application signalling for the currently selected service changes, or when a running broadcast-related application exits:

Service provider related applications

Broadcast independent applications

Switching between applications

Two cases of switching between applications are relevant in this specification;

• Switching between visible applications and invisible ones.

  NOTE: Switching between a visible application and an invisible one is conceptually a little like changing between tabs in a PC browser however without any implication of a particular user interface.

• Switching between simultaneously visible applications where this OPTIONAL feature is supported.

A number of possible mechanisms exist for switching between visible applications and invisible ones. Some examples include the following;

• Hard coded mechanisms in the terminal for switching to a specific application (e.g. to the service discovery application, the content guide, the communication service application).
• An OPTIONAL terminal specific UI showing available DAE applications which the user can switch to.

Signalling format

Widgets lifecycle

As Widgets are packaged as ZIP archives, they only require a single download and installation on an OITF before being executed. Widgets can also be downloaded over non-HTTP distribution channels and even over off-network channels (USB drives, CD/DVD, etc.).

The Widget lifecycle has 3 main steps:

1. Installation: The Widget is installed on the OITF
2. Execution: The Widget is executed (end eventually stopped)
3. Removal: The Widget is uninstalled from the OITF

Step 1, installation, is only needed before the first execution of the Widget or if its version is obsolete and the user or the OITF want to update it (see section ).

Step 2, execution, may be performed at any time after the Widget has been installed. It can be triggered by an action from the user, or it may be done automatically by the OITF either through a DAE application or a native application in the OITF. Note that it is not possible to have two running instances of a single Widget simultaneously.

Step 3, removal, is performed if the user wants to uninstall the Widget from the OITF. An uninstalled Widget needs to be reinstalled by a user to be executed again.

Detail descriptions of each step above are provided in the following sections.

Event notification framework based on CEA 2014

An OITF must be capable of displaying various event notifications from both Internet domain and home network domain. Event notification can be conveyed through active UI interaction's channel or out of session. As described in the diagram below, in-session notification is associated with a running DAE application, whereas a 3^rd party event notification is delivered through an independent communication channel. If an OITF receives a 3^rd party event after subscribing to a certain internet url or the OITF receives a multicasted event notification message, the OITF needs to perform 3^rd party event notification and display its information inside a new DAE application.

The diagram below describes a general overview of Event Notification architecture.

In-Session notifications are performed to update partial or whole DAE application UI through the NotifSocket object and/or the XMLHttpRequest object as defined by [[!CEA-2014-A]]. The NotifSocket object creates a persistent TCP connection between a DAE application and Remote UI server in order to support burst event notifications. In addition, a DAE application can create an XMLHttpRequest object to make asynchronous HTTP requests to a web server on the internet domain. This establishes an independent HTTP connection channel to support XML updates between the DAE application and the Remote UI server. On the other hand, if the OITF receives an incoming notification outside of an active interaction (i.e. session) with the server, a 3^rd Party Event Notification must be executed to invoke a DAE application to fetch and render the UI content using the url contained within the notification message. This allows servers to “broadcast” important messages, such as Emergency alert messages, to an OITF at any time, even when the DAE application would currently not be running. This should be done through a push-method with multicast message for the home network domain. and a pull-method for the internet case. The next two subsections describe the requirements for the event mechanisms in more detail.

IMS event notification framework

This section covers the DAE interactions needed to drive the message exchanges on the HNI-IGI interface in the case where the Service Provider offers an IMS application.

The HNI-IGI framework defines how an OITF interacts with an IMS Gateway (IG) via the HNI-IGI interface ([[!OIPF_PROT2]] section 5.2).

Every message on the HNI-IGI interface SHALL be carried in a HTTP transaction where the OITF sends the HTTP request and the IG responds to the request. The HNI-IGI In-session framework, in the case of a DAE application, uses the XMLHttpRequest Script Object, as defined in the XMLHttpRequest specification as referenced in [[!OIPF_WSTVP2]].

There are two message directions on the HNI-IGI interface, corresponding to outgoing and incoming messages from and to the OITF.

HNI-IGI transactions for in-session out-going request messages

This message direction applies to outgoing messages from the OITF on the HNI-IGI interface. The OITF sends a request and the IG responds to the request. The following figure illustrates the sequences for in-session transactions for outgoing requests from DAE application to the IG.

0. Prepare the Call-ID for a SIP request. The Call-ID SHALL be generated by the DAE application for an outgoing SIP request. This Call-ID SHALL be locally unique across all OITFs in a residential network.
   NOTE: How uniqueness is achieved is currently not defined.
1. The DAE application SHALL create a new XMLHttpRequest object using the constructor “new XMLHttpRequest()”.
2. The DAE application SHALL invoke the open() method to specify the HTTP method and Request-URI for the request. In this case, the HTTP POST method with the Request-URI of <IG_URL>/SIP SHALL be used as specified in [[.OIPF_PROT2]].
3. The DAE application SHALL invoke the setRequestHeader() method to specify the required HTTP headers as specified in [[.OIPF_PROT2]]. This method SHALL be invoked for each required HTTP header. For example, the X-OITF-Request-Line HTTP header specifies the SIP request line for the SIP request. The Call-ID is specified in the X-OITF-Call-ID header.
4. The DAE application SHALL invoke the send() method to send the HTTP request. The SIP Message Request body is specified in a parameter of this method.
5. When the HTTP response is received, the onreadystatechange callback function SHALL be invoked on the DAE application.
6. The DAE application SHALL invoke the getRequestHeader() method to retrieve each HTTP header. The SIP Response Line is specified in the X-OITF-Response-Line header.
7. If the readyState property of the XMLHttpRequest object has the value 4, the HTTP response body SHALL be retrieved via the responseXML or responseText properties of the XMLHttpRequest object. The SIP response body is specified in the HTTP response body.

HNI-IGI transaction for in-session incoming request messages

This message direction applies to incoming messages to the OITF on the HNI-IGI interface which are related to an existing IMS session. An example of this is a SIP NOTIFY message received from the network in response to a previous SIP SUBSCRIBE sent from the IG. The OITF sends a HTTP request and the IG responds to the request when it receives an incoming message from the network related to an existing session. The following figure illustrates the sequences for in-session transactions for incoming requests from the IG to the DAE application.

0. Prepare the Call-ID for this SIP session for which a message is expected. The Call ID SHALL be the same as the one created initially for this session.
1. The DAE application SHALL create a new XMLHttpRequest object using the constructor “new XMLHttpRequest()”.
2. The DAE application SHALL invoke the open() method to specify the HTTP method and the Request-URI for the request. In this case, the POST method with a Request-URI of <IG_URL>/PENDING_IG SHALL be used as specified in [[.OIPF_PROT2]].
3. The DAE application SHALL invoke the setRequestHeader() method to specify the required HTTP headers, as specified in [[.OIPF_PROT2]]. This method is invoked for each HTTP header that is required. In this case, the X-OITF-Request-Line, which specifies the SIP request line for the SIP request, is set to the value null. The SIP Call-ID is specified in the X-OITF-Call-ID header.
4. The DAE application SHALL invoke the send() method to send the HTTP request. For the HTTP request that sets up the initial long poll, no X-OITF headers are allowed for the HTTP request to the PENDING_IG Request-URI.
5. When the HTTP response is received, the specified onreadystatechange() callback function is invoked.
6. The DAE application SHALL invoke the getResponseHeader() method to retrieve each HTTP header. The SIP Request Line is specified in the X-OITF-Request-Line HTTP header.
7. If the readyState property of the XMLHttpRequest object has the value 4, the HTTP response body SHALL be retrieved via the responseXML or responseText properties of the XMLHttpRequest object. The SIP response body is specified in the HTTP response body.
8. The DAE application SHALL create a new XMLHttpRequest object using the constructor “new XMLHttpRequest()”.
9. The DAE application SHALL invoke the open() method to specify the HTTP method and the Request-URI for the request. In this case, the POST method with a Request-URI of <IG_URL>/PENDING_IG SHALL be used as specified in [[.OIPF_PROT2]].
10. The DAE application SHALL invoke the setRequestHeader() method to populate each HTTP header as specified in [[.OIPF_PROT2]]. This method SHALL be invoked for each required HTTP header. For example, the X-OITF-Response-Line specifies the SIP response line for the SIP response. The Call-ID is specified in the X-OITF-Call-ID header.
11. The DAE application SHALL invoke the send() method to send the HTTP request. If there is a SIP response body, it is included as a parameter to the send() method. The SIP response body message is carried in the HTTP body for the HTTP request to the PENDING_IG Request-URI.

In the case where the OITF does not need to receive any further incoming in-session SIP requests, the HTTP POST in step 11 SHALL be directed to the <IG_URL>/SIP Request-URI.

HNI-IGI transaction for out of session incoming request messages

This message direction applies to incoming messages on the HNI-IGI interface which are not related to an existing session. An example of this is a SIP MESSAGE message received from the network, coming e.g. from an IPTV application or from another user. The following figure illustrates the sequences of out-of-session transactions for in-coming requests from the IG to OITF.

Figure describes what happens when the OITF is first turned on.

1. When the OITF is turned on the OITF SHALL send a HNI_IGI IG registration message to register the default user.
2. The IG Registers the default user in the IMS network.
3. The IMS network returns 200 OK.
4. a 200 OK message SHALL be returned on the HNI_IGI.
5. If there are native IMS applications that may receive unsolicited messages the OITF SHALL send a PENDING_IG message to the IG, for the default user and with the call_id set to null. The steps to send PENDING_IG are the same as steps 8-11 from section “”.
6. The OITF performs service selection and discovery and loads the initial DAE page.
7. DAE IMS applications that desires to receive unsolicited notifications SHALL issue a subscribeNotification() method (as defined in section ).
8. When applicable the OITF SHALL send a HNI_IGI IG registration message to re-register the default user, including new applications.
9. The IG re-registers the default user in the IMS network.
10. The IMS network returns 200 OK.
11. A 200 OK message SHALL be returned on the HNI_IGI.

Figure describes what happens when a specific user logs in using the DAE interface.

1. When the user desires to login the DAE SHALL call the registerUser() method to register the user.
2. The OITF SHALL send a HNI_IGI IG registration message to register the user.
3. The IG Registers the user in the IMS network.
4. The IMS network returns 200 OK.
5. A 200 OK message SHALL be returned on the HNI_IGI.
6. If there are native IMS applications that may receive unsolicited messages the OITF SHALL send a PENDING_IG message to the IG, for the default user and with the call_id set to null. The steps to send PENDING_IG are the same as steps 8-11 from section “”
7. DAE IMS applications for the user that desires to receive unsolicited notifications SHALL issue a subscribeNotification(icsi) method (as defined in section ).
8. When applicable the OITF SHALL send a HNI_IGI IG registration message to re-register the user, including new applications.
9. The IG re-registers the default user in the IMS network.
10. The IMS network returns 200 OK.
11. a 200 OK message SHALL be returned on the HNI_IGI.

Figure describes what happens when an unsolicited message arrives from the network. The precondition is that a DAE application is already running and subscribed to the IMS notifications (refer to previous sequence when user logs in).

1. A SIP message arrives from the network.
2. The IG responds to the PENDING_IG request.
3. The OITF SHALL immediately issue a new PENDING_IG request after receiving a response on a PENDING_IG request. The steps to send PENDING_IG are the same as steps 8-11 from section “”.
4. The OITF SHALL call the callback function onNotification for the corresponding application. This includes the IMS message.
5. The OITF MAY respond to the network with a new outgoing message. The steps to send PENDING_IG are the same as steps 8-11 from section “”.
6. If the OITF sends a message the IG SHALL forward it to the network.

Additional restrictions and requirements

• The following properties and methods SHALL be supported on the window object as defined in section “The window Object” of the HTML5 specification as referenced in [[.OIPF_WSTVP2]] with additional requirements relating to integration with APIs and mechanisms defined in this document:
  • close(): calling this method on the Window object of a DAE application SHALL be equivalent to calling method destroyApplication() of the DAE application (as defined in section ).
  • blur(): calling this method on the Window object of a DAE application SHALL not deactivate the application as defined in section .
• Window scripting object support for the additional methods defined in Annex is indicated by the <pollingNotifications> element in the device capabilities as defined in section .
• An OITF SHALL offer a means to set focus to the following elements in a HTML document by using key-based input: <a>, <area>, all form elements, <iframe>, and <object> elements of type “video”. These elements SHALL have the tabindex focus flag set (see section 7.4.1 of the HTML5 specification as referenced by [[.OIPF_WSTVP2]]).
• An OITF SHALL allow the user to manually trigger elements that have an activation behaviour, for instance using keyboard input.

  NOTE: Section 3.2.5.1.7 ("Interactive content") of the HTML5 specification as referenced by [[.OIPF_WSTVP2]] includes similar requirements however using "SHOULD" not "SHALL".

Media format of A/V media except for audio from memory

This section describes the format and usage of the A/V media codec except for audio from memory.

• Format and usage of video codecs SHALL adhere to section 5 of [[!OIPF_MEDIA2]].
• The format and usage of subtitle streams SHALL adhere to section 6 of [[!OIPF_MEDIA2]].
• The format and usage of teletext information SHALL adhere to section 7 of [[!OIPF_MEDIA2]].
• The format and usage of audio codecs SHALL adhere to section 8 of [[!OIPF_MEDIA2]], except for sections 8.1.1.2, 8.1.5 and 8.2.1 which are covered in section .

Media format of A/V media for audio from memory

This section describes the format and usage of the A/V media codec for audio from memory. Usage of corresponding A/V media object is described in section of this specification.

For the audio from memory format, HE-AAC SHALL be supported by the OITF and WAVE MAY be supported by the OITF.

• The format and usage of HE-AAC audio from memory SHALL adhere to sections 8.1.1.2 and 8.2.1 of [[!OIPF_MEDIA2]].
• The format and usage of WAVE audio from memory SHALL adhere to sections 8.1.5 and 8.2.1 of [[!OIPF_MEDIA2]].

Media transport

The format and usage of media transports referred to by DAE applications SHALL adhere to section 4 of [[!OIPF_MEDIA2]].

Methods

Examples

This section provides examples of the usage of the methods.

The first example shows how to query whether an instance of the A/V Control object for a specified MIME type can be created without the application having to attempt to instantiate the object.

var videoPlayer;
if (window.oipfObjectFactory.isObjectSupported("video/mpeg")) {
  videoPlayer = window.oipfObjectFactory.createVideoMpegObject();
  // append object to document
  document.getElementById('playerDiv').appendChild(videoPlayer);
  videoPlayer.data = "rtsp://server/barker_channel";
}

If the OITF does not support the created object the OITF SHALL throw an error with the error.name set to the value "TypeError". The example below shows how this can be used by applications:

try {
  configuration = window.oipfObjectFactory.createConfigurationObject();
}
catch (error) {
  alert("application/oipfConfiguration object could not be created - error name: " 
        + error.name + " - error message: " + error.message);
}

The application/oipfApplicationManager embedded object

An OITF SHALL support a non-visual embedded object of type "application/oipfApplicationManager", with the following JavaScript API, to enable applications to access the privileged functionality related to application lifecycle and management that is provided by the application model defined in this section.

If one of the methods on the application/oipfApplicationManager is called by a webpage that is not a privileged DAE application, the OITF SHALL throw an error as defined in section .

The Application class

The Application class is used to implement the characteristics of a DAE application.

If the document of an application is modified (or even replaced entirely), the Application object SHALL be retained. This means that the permission set granted when the application is created applies to all “edits” of the document or other pages in the application, until the application is destroyed.

The ApplicationCollection class

typedef Collection<Application> ApplicationCollection

The ApplicationCollection class represents a collection of Application objects. See Annex for the definition of the collection template.

The ApplicationPrivateData class

var app = appman.getOwnerApplication(window.document);
debug("[APP] free mem = " + app.privateData.getFreeMem() + "\n");

The Keyset class

The Keyset object permits applications to define which key events they request to receive. There are two means of defining this. Common key events are represented by constants defined in this class which are combined in a bit-wise mask to identify a set of key events. Less common key events are not included in one of the defined constants and form part of an array.

The supported key events indicated through the capability mechanism in section SHALL be the same as the maximum set of key events available to the browser as indicated through this object.

The default set of key events available to broadcast-related applications shall be none. The default set of key events available to broadcast-independent or service provider related applications which do not call Keyset.setValue() SHALL be all those indicated by the constants in this class which are supported by the OITF excluding those indicated by OTHER.

myKeyset = myApplication.privateData.keyset;

myKeyset.setValue(0x00000013);
myKeyset.setValue(myKeyset.INFO | myKeyset.NUMERIC);

New DOM events for application support

New events have been created that are raised on the Application objects in the application tree. These are normal events, not cross-application events, and are used to indicate changes in the state of an application.

These events do not bubble and cannot be cancelled. Each of these events has a corresponding DOM 0 event handler property on the Application object.

Examples (informative)

The examples below illustrate some aspects of the application model.

 
// Assumes that the application/oipfApplicationManager object has the ID 
// “applicationmanager”
var appMgr = document.getElementById( "applicationmanager" );
var self = appMgr.getOwnerApplication( Window.document );

// Assumes that the application/oipfApplicationManager object has the ID 
// “applicationmanager”
var appMgr = document.getElementById( "applicationmanager" );
var self = appMgr.getOwnerApplication( Window.document );
var child = self.createApplication( url_of_application, true );

<script>
function loaded() {

    var screen = document.defaultView.screen;
    var clock = document.getElementById( 'clock' );

    setup_clock( clock.width, clock.height );

    // Assumes that the application/oipfApplicationManager object has the ID 
    // “applicationmanager”
    var appMgr = document.getElementById( "applicationmanager" );
    var self = appMgr.getOwnerApplication( Window.document );
    self.show();
}
</script>

<style> * { margin: 0cm } </style>

<body onload="loaded()">
   <img id="clock" src="clockbackground.png" style="position: absolute; 
     top: 0px; left=0px">
</body>

Widget APIs

This section defines APIs an author can use to interact with Widgets installed on the OITF. Note that the Widget lifecycle is managed through the application manager as defined in the previous sections.

typedef Collection<WidgetDescriptor> WidgetDescriptorCollection

The application/oipfConfiguration embedded object

The OITF SHALL implement the “application/oipfConfiguration” object as defined below. This object provides an interface to the configuration and user settings facilities within the OITF.

The Configuration class

The Configuration object allows configuration items within the system to be read and modified. This includes settings such as audio and subtitle languages, display aspect ratios and other similar settings. Unlike the LocalSystem object, this is concerned with software- and application-related settings rather than hardware configuration and control.

The LocalSystem class

The LocalSystem object allows hardware settings related to the local device to be read and modified.

Note: The standbyState property has been removed from this class.

The NetworkInterface class

The NetworkInterface class represents a physical or logical network interface in the receiver.

The AVOutput class

The AVOutput class represents an audio or video output on the local platform.

The NetworkInterfaceCollection class

typedef Collection<NetworkInterface> NetworkInterfaceCollection

The AVOutputCollection class

typedef Collection<AVOutput> AVOutputCollection

The TunerCollection class

typedef Collection<Tuner> TunerCollection

The Tuner class

A Tuner object represents the source of broadcast content provided through a physical tuner in the OITF. Each Tuner object is represented by a <video_broadcast> element in the capability description as defined in section .

A Tuner object that is capable of tuning at the same time to multiple transponders SHALL have the nrstreams attribute of the <video_broadcast> element set to a value equal to the number of transponders.

A Tuner object that is capable of tuning to transponders of different types SHALL include all those types in the types attribute of the <video_broadcast> element.

NOTE: An OITF may contain a physical tuner that has its capabilities split into multiple Tuner objects to fit the restrictions on the <video_broadcast> element outlined above and in section .

The SignalInfo class

The LNBInfo class

The StartupInformation class

The application/oipfDownloadTrigger embedded object

An OITF SHALL support a non-visual embedded object of type application/oipfDownloadTrigger, with the following JavaScript API to enable passing a content-access descriptor to an underlying download manager using JavaScript.

The functionality as described in this section is subject to the security model of section .

Extensions to application/oipfDownloadTrigger

If an OITF has indicated support for both BCG metadata (i.e. by giving element <clientMetadata> value “true” and a “type” attribute with value “bcg”), and the download management APIs defined in section (i.e. by giving attribute “manageDownloads” of the <download> element a value unequal to “none”) in the client capability description, then the following additional method SHALL be supported by the application/oipfDownloadTrigger object defined in section .

The functionality as described in this section is subject to the security model of section

The application/oipfDownloadManager embedded object

In a managed deployment, privileged applications may need access to the download management functionality in a CoD system. This access may be required to implement a UI to the download manager, to queue a download or to display the progress of a specific download. OITFs SHOULD support an “application/oipfDownloadManager” object with the following interface.

Clients supporting the download management APIs as specified in this section SHALL indicate this by adding the attribute “manageDownloads” to the <download> element with a value unequal to “none” in the client capability description as defined in section .

The functionality as described in this section is subject to the security model of section .

State diagram of the application/oipfDownloadManager object

The following state machine provides an overview of the state changes that are possible in the download manager. The states reflect the changes signalled to applications via the onDownloadStateChange event handler.

Note that newly-registered downloads may pre-empt downloads which are currently in progress, if they have a higher priority than in-progress downloads. This may cause downloads to be paused or resumed without application intervention.

The Download class

A Download object being made available by the application/oipfDownloadManager embedded object represents a content item that has either been downloaded from a remote server or is in the process of being downloaded.

If the ID of a download is a TV-Anytime CRID, then the values of the name, description and parentalRatings properties SHALL be set by the OITF based on the metadata provided for the item matching that CRID.

In order to preserve backwards compatibility with already existing DAE content the JavaScript toString() method SHALL return the Download.id for Download objects.

The DownloadCollection class

typedef Collection<Download> DownloadCollection

The DRMControlInformation class

The DRMControlInfoCollection class

typedef Collection<DRMControlInformation> DRMControlInfoCollection

The application/oipfCodManager embedded object

OITFs that have indicated <clientMetadata> with value “true” and a “type” attribute with value “bcg” SHALL implement an “application/oipfCodManager” embedded object with the following interface.

Content is organised into catalogues, where each catalogue contains a hierarchy of folders that are used to organise individual content items. The structure of the catalogue SHALL be determined by the server managing that catalogue and SHALL be reflected in the structure of the metadata passed to the OITF.

The three types of content in a CoD catalogue are:

• Assets, represented by the CODAsset class. A CODAsset is a user-level description of a piece of CoD content, and so it is more concerned with information such as the price, rental period, description and parental rating rather than detailed technical information about the asset such as encoding format. A CoD asset MAY represent a single movie, or a bundle of movies offered for a single price.
• Folders, represented by the CODFolder class.
• Services represented by the CODService class. CODService objects are a specific type of container representing subscription VoD (SVOD) services, where users purchase a group of assets which may change over time rather than a single movie or TV show.

The CODAsset, CODFolder and CODService classes define a type property that allows these classes to be distinguished by applications. For each class, this property SHALL take the value defined below:

This specification defines the mapping between the CoD API and BCG metadata. Mappings between the CoD API and other CoD metadata sources are not specified in this document.

The ContentCatalogueCollection class

typedef Collection<ContentCatalogue> ContentCatalogueCollection

The ContentCatalogue class

A ContentCatalogue represents a content catalogue for a content on demand service.

To receive events relating to operations on items in a catalogue, applications MAY add listeners for “ContentAction” events to the application/oipfCodManager object.

The ContentCatalogueEvent class

The CODFolder class

CODFolder represents a folder in a CoD catalogue. Folders may contain other folders, and an asset may be present in more than one folder.

Because a content list may contain a large number of items, the contents of the list are made available on demand using a paging model. Applications MAY request the contents of the list in 'pages' of an arbitrary size. The data SHALL be fetched from the appropriate source, and application SHALL be notified when the data is available.

Each folder is described by a GroupInformation element in the BCG Group Information Table.

The CODAsset class

The CODAsset represents a piece of CoD content that can be purchased and played. A CODAsset object MAY refer to a bundle of content items that are purchased together but which can only be played individually.

Some fields of a CODAsset object MAY not be populated until an application requests them; in this case the data MAY be fetched asynchronously from a server. Fields where the data has not been fetched from the server SHALL have a value of undefined. Fields for which data is not available on the server SHALL have a value of null.

Note: The lookupMetadata() method has been removed from this class.

<Price currency="JPY">500</Price>

The CODService class

The CODService class is a subclass of CODFolder that represents a subscription CoD service. A subscription CoD service is similar to a folder, except that:

• The service SHALL be purchased in its entirety, rather than purchasing individual items from the service.
• Business rules may prevent browsing of the content within a service unless the service has already been purchased.

A CODService MAY contain a number of assets, folders and services.

Note: The lookupMetadata() method and uid property has been removed from this class.

The application/oipfDrmAgent embedded object

An OITF SHALL support a non-visual embedded object of type “application/oipfDrmAgent”, with the following JavaScript API, to enable in-session message exchange from the web page with an underlying DRM agent.

Access to the functionality of the application/oipfDrmAgent embedded object SHALL adhere to the security requirements as defined in section .

Note: Annex provides a clarification to the browser interaction model when dealing with protected content.

 application/vnd.marlin.drm.actiontoken+xml 

The application/oipfGatewayInfo embedded object

The application/oipfCommunicationServices embedded object

Extensions to application/oipfCommunicationServices for presence and messaging services

If a client has indicated support for the control of its presence and messaging functionality by a server by stating <presenceMessaging>true</presenceMessaging> as defined in section in its capability description, the client SHALL support Communication Services through the use of the following non-visual embedded object:

<object type="application/oipfCommunicationServices"/>

The presence and messaging API provides for instant messaging, presence and contact list services. The messages can either be in a chat session using MSRP (see [[.OIPF_PROT2]]) or page mode messages sent without a session. The support of presence and messaging SHALL follow the OMA specification [[!PRES]], [[!IM]].

The Communication Services API SHALL be supported in combined OITF and IG deployment cases. It MAY be supported in other deployment cases. The use of the HNI-IGI interface is OPTIONAL between the OITF and IG when these are co-deployed.

The UserData class

The UserDataCollection class

typedef Collection<UserData> UserDataCollection

The FeatureTag class

The FeatureTagCollection class

typedef Collection<FeatureTag> FeatureTagCollection

The Contact class

The ContactCollection class

typedef Collection<Contact> ContactCollection

The ContactCollection class represents a collection of Contact objects. See Annex for the definition of the collection template.

In addition to the methods and properties defined for generic collections, the ContactCollection class supports the additional methods defined below.

Extensions to application/oipfCommunicationServices for voice telephony services

If an OITF has indicated support for full-duplex Voice Telephony Services functionality by a server by stating <telephony_services>true</telephony_services>, or <telephony_services video=“false”>true</telephony_services>, or <telephony_services video=“true”>true</telephony_services> as defined in section in its capability description, the OITF SHALL support IMS through the use of the following non-visual embedded object:

<object type="application/oipfCommunicationServices"/>

The full-duplex Voice Telephony Services API provides support for managing the setup and life-cycle of a telephony call session. It also provides the methods to manage the capture devices and the list of preferred codecs to be used.

The full-duplex Voice Telephony Services API MAY be supported in the combined OITF and IG deployment cases as well as the separated OITF and IG case. It MAY be supported in other deployment cases. The use of the HNI-IGI interface is OPTIONAL between the OITF and IG when these are co-deployed.

Extensions to application/oipfCommunicationServices for video telephony services

If an OITF has indicated support for full-duplex Video Telephony Services functionality by a server by stating <telephony_services video="true">true</telephony_services> as defined in section 9.3.9 in its capability description, the OITF SHALL support communication services through the use of the following non-visual embedded object:

<object type="application/oipfCommunicationServices"/>

The extensions for telephony services provide support for:

• Parameters and values related to video (identified by (*) in previous sections).
• Methods to manage the rendering of local and remote video streams through CEA-2014 A/V Control or HTML5 video element.
• Methods to send a session update request and to accept or refuse it. A session update is typically invoked when users want to add video to their currently ongoing voice-only call session.

When a remote or local video is activated on a target CEA-2014 A/V Control or HTML5 video element, any currently displayed video content on that object is stopped and released. The activated stream is automatically played.

The full-duplex Video Telephony Services API MAY be supported in the combined OITF and IG deployment cases as well as the separated OITF and IG case. It MAY be supported in other deployment cases. The use of the HNI-IGI interface is OPTIONAL between the OITF and IG when these are co-deployed.

The DeviceInfo class