| Application meta-data is data about an application. Application meta-data is often distributed across multiple layers and in a variety of formats. Some meta-data appears in the transport, whereas other data appears in application resources, e.g., XML files. 4.4.1 Universally Unique Application ID (UUID) Common to all standards is the assignment of a Universally Unique ID (UUID) to each and every application [UUID]. These are 128-bit numbers that are guaranteed to be unique. The mechanism used to guarantee their uniqueness is a combination of hardware addresses, time stamps, and random seeds . -
Hardware component of a UUID : There is a reference in the UUID to the hardware address of the first network card on the host which generated the UUID. This reference is intended to ensure the UUID will be unique as every network card is assigned by a single global authority and is guaranteed to be unique. -
Timestamp component of a UUID : The next component is a time stamp that will be unique in time as the clock always moves forward. -
Random component of a UUID : Just in case some part of the first two components goes wrong, there is a random component placed into the UUID as a catch-all for uniqueness. The network address of the ethernet adapter matches the last portion of the UUID. For example, the UUID 58f202ac-22cf-11d1-b12d-002035b29092 originates from a machine with the hardware address 002035B29092. The UUID almost always appears in the transport within some MPEG-2 section (e.g., the DST or AIT), and may sometimes appear in a file describing an application (e.g., XML file). 4.4.1.1 Application Boundary The application boundary defines the namespace of an application and all content files or resources within this namespace that are considered to be part of that application; files or resources outside that namespace are part of a different application. This namespace is used to determine to which application each piece of cached material belongs, to improve efficiency of execution, to enable pre-fetching of files, and to facilitate storing applications. The logical extent of an application could potentially be quite large, and for various reasons might not all be on the receiver at any given time. Part of it might be broadcast, part of it might be on local storage, part of it might be on the Internet, and some of it might even be generated on demand. The application boundary almost always appears in the transport within some MPEG-2 section, and may sometimes appear in a file. Preferably, if it appears in a file, it should be an XML file. 4.4.2 Application Compatibility and Expected Platform Capabilities MPEG allows the transport to include compatibility information. That indicates the type of application in terms of the identification of the organization or standard to which the application complies. This information is present to enable receivers detecting an unsupported application type to quietly ignore that application and avoid a disrupted viewer experience. In some cases, application meta-data may contain information about the capabilities that an application expects a receiver should have to execute it appropriately. This information may include compatibility information (e.g., which standards), CPU class, expected cache size, memory allocation needs, graphics resolution needed, color models needed, blending capability needed, number of pipeline video decoders needed, types of input devices needed (e.g., pointer device), number of tuners needed, whether a return channel is needed, and if so, access to which URLs may be needed. Application compatibility information is often viewed as the minimum requirements for a receiver to execute that application. It enables broadcasters to have limited control of the capabilities of the environment within which the application executes. In some cases, this information is usually implicitly encoded in, and can be inferred from, the transport. In many cases, it is organized in special purpose files (see Chapter 13). In general, however, unless broadcasters require this information as part of their contracts, it is often missing or hard to obtain. 4.4.3 Security Meta-data The security meta-data may be provided with three types of data: -
Cryptographic hash codes : This provides a summary of the data under consideration. -
Signatures : These deliver a master hash code (computed over all of the appropriate data) that has been signed by an authorizing organization. The signing process securely associates the master hash code with the signatory, ensuring that the data has not been tampered with since it was signed by the signatory. -
Certificates : These provide a chain of trust from the authorizing organization up to some trusted third party (the root certificate authority) that is well known to the receiver. Security meta-data attached to iTV applications enables performing the following tasks : -
Authentication of applications : The security framework that are successfully authenticated are often executed in trusted mode and may be granted access rights to privileged operations. -
Enforce security policies for applications : Broadcasters may specify their policy with regards to access rights to sensitive resources. For example, the ATSC A/94 has introduced a policy descriptor that enables broadcasters to prevent receivers from granting certain permissions to applications. The ultimate access rights that are granted to the applications are the intersection of the access rights requested by an application, access rights requested by the broadcaster , and the access rights granted by the user . -
Ensure privacy of communications : This includes cipher suites and possibly keys to be used by TLS [TLS] over a return channel. -
Certificate Management : Certificates may be revoked prior to their expiration time, e.g., if the broadcaster's private key is assumed to be compromised, or the broadcaster is no longer to be certified by the CA. Each CA publishes a list of revoked certificates, called a Certificate Revocation List (CRL) which contains the list of the serial numbers of revoked certificates. During the validation process of a certificate chain, the CRL of each CA on the certification path is checked. Security information is usually encapsulated within files (e.g., XML files) and rarely found in the transport signaling. Conditional access signaling used in the cable industry is delivered in the transport (not in files) and is different in nature and scope. 4.4.4 Availability versus Auto-launch Information Applications are available for execution only when they are signaled in the broadcast. Such signaling could be auto-launch indicating that they should be launched as soon as their resources are available to the receiver (for details see later discussion about launching condition). Nevertheless, it is possible for applications to be transmitted in the broadcast but not launched. At most, one application should be signaled for auto-launch; other applications could be launched as a result of viewer's interaction with the auto-launched application or through a GUI native to the receiver's implementation listing all available but non auto-launch applications. 4.4.5 Resource Meta-data In addition to meta-data associated with the entire application, much meta-data is associated with individual resources or groups of resources. Some resource meta-data may appear in the transport, and some may be encoded as part of the resource. The following meta-data is common: -
Naming information : This meta-data relates a file to one or more names that may be used to refer to that file. For example, names may be URI. In many cases, porting applications from an Internet environment to an iTV environment may require modifying the URL names of their files by changing their prefix effectively converting them into Locator ID (LID) URIs. This information is always found in the transport, but sometimes, in case archive (e.g., ZIP, JAR) formats are used, it may appear within a file. -
Modification time : This data may be used in conjunction with the name to unambiguously identify the file. It is useful when multiple versions of a file are delivered repeatedly, possibly using multiple networks. It enables, for example, updating an archived application by rendering an updated version of one of its files accessible over the Internet (without changing the content of the archive). This information is almost always encoded in the transport. -
Content type : The type of content a file contains, sometimes specified by its MIME type, is crucial to determine which decoders may be needed to render it. The two common cases in which a decoder is not available is when some hardware is needed to assist in the decoding (e.g., video decompression ) or the decoder is a plug-in (e.g., flash decoder). In the first case, the receiver should ensure the availability of the hardware resource prior to execution, and in the second case, the receiver should make an effort to allocate the plug-in and download it if necessary. This information is almost always encoded in the transport. In some cases, automatic sniffing heuristics may be able to derive the content type; when such heuristics are possible, the declared content type should be ignored and the discovered type should be used. -
Conditional access information : This meta-data is used to control the access to content. For example, content which requires payment should not be accessible to non-subscribing viewers . In another example, data associated with financial transaction should not be amenable to unauthorized use. This may include ciphers, keys, or other information needed to decode the resource and make use of its content. This information is almost always delivered in the transport. Exceptions are those cases in which the application itself is responsible for checking the access privileges of the viewer, in which case the information is implicit in the application's code. -
Pre-fetch and caching information : When it comes to the viewer's experience, iTV environment is less forgiving than a PC environment. Therefore, to ensure smooth execution, an application author may find it necessary not to launch applications until a minimum set of resources is loaded. Caching priority may also prove to be valuable . As an example, it is probably preferable that all resources required for the flash page of an application be loaded prior to launching that application. Resources referenced after any possible viewer's first selection should be cached thereafter as soon as possible. This information is usually present in the transport. In some cases, it may be present in a file (e.g., XML file). -
Transport configuration : This meta-data relates to the specific encapsulation of the resource within a transport. This may include information such as module number and other information that enables extraction of a file from an MPEG-2 transport (for details see Chapter 11). This meta-data may also include URLs from which the resource may be pulled. This information is almost always found in the transport only. Exceptions are in cases when the acquisition of files is performed by the applications that use APIs that enable direct access to the transport. |
