View source for Media APIs/HNReq Comparison

= Comparison of "Media APIs" and "Home Networking" requirements =

This document is a basis for discussion. Its aim is to compare the [http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements requirements list] currently (as of September 2013) being worked on by the Media APIs Task Force of the web and TV IG and the [http://www.w3.org/TR/hnreq/ requirements published at the end of 2011] by the now-disbanded Home Networking Task Force (HNTF).


== Service Discovery ==

http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Service_Discovery_Mechanism

=== Current Draft ===

There SHALL be a Service Discovery mechanism for a device to look for and pair with local networked services including contents provided by home appliances including set-top boxes.

=== in HNReq ===

There is an equivalent section: http://www.w3.org/TR/hnreq/#service-discovery

Conforming specifications should provide a means for applications to discover services advertised by devices and applications in the home network. Details of the advertising protocols are out of scope for this document and the type and number of supported discovery protocols is user agent dependent. Nevertheless conforming specifications should provide a means for application search for specific services and to be able to determine the means by which it should communicate with that service.

== Device Discovery ==

http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Device_Discovery_Mechanism

=== Current Draft === 
There SHALL be a Device Discovery mechanism for an application to look for and pair with local networked services including contents provided by home appliances including set-top boxes.

=== In HNReq === 

There is no exact match, but the requirement for Content Discovery states:

Conforming specifications should provide a means for applications to _discover devices_ in the home network capable of serving content (content servers). In addition, conforming specifications should provide a mechanism to retrieve a list of the available content, provide additional information (metadata) about the content and to support negotiation of a supported content format between content servers and content players.


== Service Aggregation Mechanism ==

http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Service_Aggregation_Mechanism

=== Current Draft === 

There SHALL be a Service Aggregation mechanism for local networked services including contents discovered by a device to be aggregated and bundled together so that the device can present a subscriber with the bundled services.

=== In HNReq === 

There does not appear to be such a requirement in HNReq. The use cases are covered, however, by a mix of requirements for service discovery and standard metadata. 

Whether the combination of service discovery and Metadata makes the need for a standard Service Aggregation mechanism moot is to be discussed.

== Service Synchronisation Mechanism == 

http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Service_Synchronisation_Mechanism

=== Current Draft === 
There SHALL be a Service Synchronization mechanism between the device that interacts with a subscriber and the sources of local networked services, including the content in the services.

=== In HNReq ===

The question if synchronisation is covered by two distinct sections in HNReq:

4.3.6 Time-synchronization 

Conforming specifications should provide a means for applications to co-time the presentation of their own content (audio, video or other) with the timeline of a programme being played back on another device, including programmes being received via broadcast. Conforming specifications should provide applications with a means to be aware of the progress (time within the programme) of the playback of media content on a remote device/service, including programmes being received via broadcast.

4.3.7 Accurate Time-synchronization

Conforming specifications should support any protocols or optional protocol features that enable applications to be aware of the progress (time within the programme) of the playback of a programme on a remote device to within frame accuracy (1/25th or 1/30th second) or better. Conforming specifications should support the ability to determine an estimate of the level of accuracy with which timing information about media playback on a remove device/service is conveyed to applications.


== Service Expiry Mechanism ==

http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Service_Expiry_Mechanism

=== Current Draft ===
There SHALL be a mechanism to specify the validity period of the local networked services including contents delivered to the devices.

=== In HNReq ===

There does not seem to be any requirement for service expiry in HNReq. This is a requirement the Media APIs TF should focus on and develop accordingly.

== Device Authentication Mechanism ==

http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Device_Authentication_Mechanism

=== Current Draft ===

There SHALL be a mechanism to authenticate the device, the application and the subscriber for security purpose.

=== In HNReq ===

There appears to be no requirement exactly at this level, but there are several high-level requirements addressing similar concerns:

4.5.1 Application Trust Level

Conforming specifications should provide a means to define the trust level of an application. Determining the trust level may involve interaction with the user and the use of security mechanisms such as password, PIN etc.

4.5.2 Access to Home Network Services

Conforming specifications should allow access to home network devices and services only to trusted applications.

4.5.3 Prevent Leaking of Information:
http://www.w3.org/TR/hnreq/#prevent-leaking-of-information

Conforming specifications should prevent unauthorized transfer of information outside the home network.

The group should determine whether these two requirement meet the same needs, or if both are complementary.

== Local Access Control ==
http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Local_Access_Control

=== Current Draft ===

There SHALL be a mechanism to authorize a subscriber to access the local networked services including contents that are appropriate to the subscriber’s profile, such as age, subscription status, etc.


== Local Network Service Protection Mechanism ==
http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Local_Network_Service_Protection_Mechanism

=== Current Draft ===

There SHALL be a mechanism to protect the local networked services including contents from unauthorized access.



== Context-based and targeted Service Aggregation ==
http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Context-based_and_targeted_Service_Aggregation

=== Current Draft ===

There SHALL be a mechanism to support the Context-based and targeted Service Aggregation and Content Delivery in order to provide subscriber with more suggested and relevant service and content. The context information includes but is not limited to:

* Subscriber’s context such as profile information and related tradition and culture information, current timestamp / day / season, etc.
* Device context, such as current geo-location / country / region, application and environment, OS and platform, etc.
* Network context, such as bandwidth and other measurement etc.
* Service context, such as provider’s profile, EPG information etc.
* Content context, such as current content information, current background information, view history, etc.


== Wake-up Mechanism ==
http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Wake-up_Mechanism

=== Current Draft ===
There SHALL be a Wake-up mechanism for the local network services to push a notification to the device and wake up a proper application to serve the subscriber.



== Service Information in Push Notifications ==
http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Service_Information_in_Push_Notifications

=== Current Draft ===
The Push notification in the Wake-up mechanism SHALL carry all necessary information related to services and contents so that the appropriate application will be able to present the subscriber with content services WITHOUT extra handshaking steps.


== Offline Mode for Services and Content ==
http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Offline_Mode_for_Services_and_Content

=== Current Draft ===
There SHALL be a mechanism for subscriber to save the suggested service and/or content for watching later.



== Device-to-device content transfer ==
http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Device-to-device_content_transfer

Current Draft:
There SHALL be a mechanism for content to be transferred among the devices, and between the device and original sources of local networked services.



== Payment Mechanism ==
http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Payment_Mechanism

=== Current Draft ===
A standard Payment mechanism SHALL be supported for a subscriber to purchase additional services including contents.


== Search ==
http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Search

=== Current Draft ===
There SHALL be a mechanism to integrate search functions with the local networked services including contents.



== Operating Modes ==
http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Operating_Modes

=== Current Draft ===
Subscribers SHALL be allowed for different operating mode, such as DVR mode, Life Goes On mode, etc.



== Tuner Control ==
http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Tuner_Control

=== Current Draft ===
There SHALL be a mechanism for the application on set-top box to control TV’s tuner.



== Channel Identification ==
http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Channel_Identification

=== Current Draft ===
There SHALL be a mechanism to support channel identification.



== Content Streaming ==
http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Content_Streaming

=== Current Draft ===
There SHALL be a mechanism to stream TV’s content to HTML player in set-top box.

=== In HNReq ===

There is a similar (but not exactly equivalent) requirement in HNReq.

4.3.4 Playback of Live Content

Conforming specifications should provide a means to play back live content advertised by a home network content server.



== Content Download ==
http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Content_Download

=== Current Draft ===
There SHALL be a method of referencing video sources for download, e.g. using anchor elements with the download attribute.

== Media Content Protection ==
http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Media_Content_Protection

=== Current Draft ===

There SHALL be an ability to:

* store video content in a protected format, as applicable.
* store content licenses of protected video contents for offline playback.
* view previously stored protected video content, e.g. via the HTML5 Encrypted Media Extensions.
* transfer media in a single operation (not copy-then-delete).
* account & verify the number of coexisting instances of the media.


=== In HNReq ===

There is a similar requirement in HNReq.

4.3.10 Content Protection

“Conforming specifications should support the content protection mechanism for a content item used by a content server in order to play back that content item. Conforming specifications must provide a graceful failure model when a content protection mechanism is not supported.”

The draft requirement by the Media APIs TF is both more precise and covers additional cases. Notably, it adds a case where content protection would also work with offline playback.


== Content Storage ==
http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Content_Storage

=== Current Draft ===

* There SHALL be an adequately-sized storage medium; at least enough to store several full movies, e.g. 32GB
* There SHALL be a method of accessing the storage medium to save videos, e.g.
** For local filesystem storage, [http://dev.w3.org/2009/dap/file-system/file-writer.html the File Writer API]
** For browser-internal storage, [http://www.w3.org/TR/IndexedDB/ the IndexedDB API]
* There SHALL be a method of specifying the validity duration of the content in offline storage
* There SHALL be a method of clearing the content in offline storage when its validity period has expired 

=== In HNReq ===

None?

== Content Playback ==
http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Content_Playback

Current Draft:
* There SHALL be a method of accessing the storage medium for video playback, e.g.
** [http://www.w3.org/TR/FileAPI/ The File API]
** [http://www.w3.org/TR/IndexedDB/ The IndexedDB API]
* There SHALL be an ability to view previously stored video content, e.g. via
** The [http://www.w3.org/TR/html5/single-page.html#the-video-element HTML5 video element] using a reference to a locally-stored file, provided through [http://www.w3.org/TR/FileAPI/ the File API]
** The [http://www.w3.org/TR/html5/single-page.html#the-video-element HTML5 video element] using a reference to a video stored in browser-internal storage, and accessed via [http://www.w3.org/TR/IndexedDB/ the IndexedDB API]
* There SHALL be an ability to view previously stored protected video content, e.g. via the [https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html HTML5 Encrypted Media Extensions]

=== In HNReq ===

There are several relevant requirements in HNReq, notably:

4.3.3 Playback of Content

Conforming specifications should provide a means to play back content advertised by a home network content server.


== Content Recording while Watching ==
http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Content_Recording_while_Watching

Current Draft:
* There SHALL be an ability to store video content accessed via the [http://www.w3.org/TR/html5/single-page.html#the-video-element HTML5 video element], while the video is being presented in the browser.