Requirements for Home Networking Scenarios

4.1 General

4.2 Discovery and Advertising

4.3 Control and Communication

4.4 Migration

4.5 Security and Privacy

5.1 U1. Service User Interface

Description

An application as an interface to a service: the application provides a remote user interface for a device (light switch, HiFi volume control, radio station chooser, etc.) or a service on a device (remote control on the media player software on a computer).

Possible implementation:

• the application discovers services with a discovery protocol, selects one service of a certain expected type, e.g. a media renderer service.
• the application binds to it and provides a UI for it.
• on user interaction, the application sends the messages to set the content url to play then play, pause, ... to the media renderer service, with appropriate parameters.

Motivation

There is no standard interface to discovery protocols in existing standards implemented in connected devices. There is no standard interface to service communication protocols in existing standards implemented in connected devices. What should be standardized is:

• an interface to get a list of discovered services;
• an interface to get the list of messages exposed by a discovered service;
• an interface to send a message to a discovered service;
• an interface to set a listener for messages from a discovered service.

Dependencies

In order to interface with a service, the application first needs to discover the service (or the device, then the service on the device).

Requirements

Low Level	High Level
Determine list of discovered services	section 4.2.1 Service Discovery
Determine list of discovered services	section 4.2.1 Service Discovery
Send a message to a discovered service	section 4.3.8 Service Communication
Listen to messages (possibly unsolicited) from a discovered service	section 4.3.8 Service Communication

5.2 U2. Discovered Content Host

Description

A document as host for discovered content: e.g. the document describe content provided by a local, discovered device or service.

Motivation

Rendering a media on another device than the one hosting is the basic step to enable more complex use cases.

Requirements

Low Level	High Level
Support a document which displays discovered content	section 4.3.3 Playback of Content

5.3 U3. Service Migration

Description

An application moving across HNTF user agents in a decentralized situation (local application, without a server).

A radio service is split into a radio application which resides typically on a HiFi, TV, personal music player or computer, and a radio controller application which resides on a device with intuitive interaction capability such as a phone, computer or tablet. The radio application is implemented as a document exposing a service interface on the network, and has a state that needs preserving if the document is migrated. The radio controller application is a pure interface, and does not have its own state.

The radio application does not have a visual interface. The radio application exposes a service of type JCDsRadioApp with seven possible messages:

• setURI(radioStationURI, radioName),
• play(),
• stop(),
• setVolume(n),
• getURI(),
• getRadioName(),
• getPlayState(),
• getVolume().

The radio application is running on a TV set.

The radio controller application has a visual interface, comprising:

• a button to choose the radio station.
• a play button.
• a stop button.
• a label for the current radio station name.
• a volume bar to display the current volume.
• two buttons to increase and decrease the volume.

The radio controller application is running on a smartphone. The radio controller application looks for a service called JCDsRadioApp by using the HNTF discovery mechanism, then establishes a connection with the above application. The radio controller application gets the radio name, volume, play state of the radio application and displays that information.

The stage is now set.

The user wants to move from the TV in the main room to the computer in her office:

• In the HNTF user agent on the TV, the user requests to migrate the radio application.
• The TV HNTF UA looks for other HNTF UAs on the network, by discovering service "HNTFUserAgentv1.0".
• The result of the discovery is a list of HNTF UAs: the one on the phone, the one on the computer, possibly other ones.
• The user selects the HNTF UA running on the computer.
• The TV HNTF UA sends the message migrate(appURI, contextURI) to the computer HNTF UA.
• The computer HNTF UA requests the appURI to get the radio application, then requests the contextURI, which contains all the information needed to place the radio application in the same state it was in on the TV.
• The computer HNTF UA loads the radio application, then the context. Loading the context first sets the volume to half and the station to "Jazz".
• Then the computer HNTF UA exposes a service of type JCDsRadioApp.
• Then the smartphone HNTF UA understands that its connection to the radio application in the TV is down, so it starts again a discovery of service type JCDsRadioApp. It finds one on the computer HNTF UA, and sends a connection request.
• The computer HNTF UA receives a connection request from the device mentioned in the migration context as formerly connected. It accepts the connection without requiring a user validation.

End of migration.

When moving the radio document, the following needs to be preserved:

• the service needs to be restarted and exposed on the new device
• the connection to the (same) radio controller needs to be reestablished
• the radio needs to be playing the same station, with the same volume, etc.

Another possible example is a multi-user game, e.g. with lots of players sending location and activity information about their character/cars. Upon migration, the game state needs to be transferred to the new device, and the connections to other players need to be reestablished.

Motivation

• no way to discover a service from an application
• no way to expose a service from an application
• no way to move an application to another device and restart it while keeping an execution context

Dependencies

This use case depends on discovery. This is a refinement of ISSUE-15, where the migrated document uses a service rather than exposes a service.

Requirements

Low Level	High Level
User-Agents support a service to transfer a running Application to different User-Agent.	section 4.4.1 Push Migration
Applications support the ability to save their current state and provide this information via a contextURI.	section 4.4.1 Push Migration
Applications support the ability to restore their state on a different User-Agent using state information provided by a contextURI.	section 4.4.1 Push Migration

5.4 U4. Service Distribution

Description

An application spawning other applications on other devices and communicating with them: e.g. the TV set receives and renders an application implementing some voting; the application discovers multiple phones in the home, proposes to activate voting interfaces on each of the viewers' phones, communicates with the voting interfaces, collates votes and sends them back to the channel's voting service.

Possible implementation:

• The TV receives a connected TV application for voting, which starts automatically.
• The application exposes a service on the HN to collect votes and forward them to the TV channel.
• The application discovers personal interactive devices (phones and tablets for our case) running the HNTF document UA which exposes a recognizable service.
• The application sends a suggest message with a URL to a voting interface.
• Willing users accept the suggested migration and their UA loads the voting interface.
• The voting interface document loads and discovers and binds to the vote collecting service.
• The user votes
• The voting interface document sends a vote message to the vote collecting service.
• The vote collecting service exposed by the TV application receives the vote message and forwards them for a certain voting period.
• At the end of the show (or of the voting period), the application is killed by the TV system, so the voting collection service disappears.
• Seeing the voting collection service disappear, the voting interfaces may shut down.

This use case does not require new technology, but reuses technology required by other use cases. Technologies required by other use cases are:

• the ability to discover
• the ability to expose a service

This use case requires:

• the HNTF UAs to implement a service which could be called "HNTF service", so that documents can discover other "HNTF UAs"
• the HNTF service to include a "suggest" message telling the UA to please render a document given by URL
• maybe the HNTF service to include a message allowing a document to determine its capabilities, to be able to segregate between devices appropriate for voting or not.

A few sketches for clarification:

Motivation

This is the generic version of a crucial "second screen" usage scenario.

As there are more devices in the home, some generic and some task-specific, and with varying capabilities (including different UI methods), there is a growing need to spread an application across different devices to achieve service distribution. But the service usually "enters" the home network through one particular device. The service running entirely on the initial device, as part of other use cases, can discover its environment and determine that other devices could meaningfully contribute to the quality of experience. From then on, the service needs to send part of "itself" to other devices.

Dependencies

• section 5.1 U1. Service User Interface
• section 5.6 U6. Application Exposing a Service
• section 5.7 U7. Application Discovering a Service

Requirements

Low Level	High Level
A document exposes an interface to a service	section 4.2.1 Service Discovery section 4.3.8 Service Communication

5.5 U5. 3-Box Model

Description

A document as an interface coordinating action between other services. In the most obvious example, a document discovers media content sources and media players. The document allows the user to select a source and a player, then control playback (Play, pause, rewind, etc.) of the content to the player.

Motivation

Assets offered by one service (on one device) can be consumed by another service (on another device) and controlled by a separate controlling document (on a third device). Vendors can offer control services to manage services across the whole home.

Dependencies

This is similar to Service User Interface (see section 5.1 U1. Service User Interface) but it explicitly manages services between independent devices, multiple simultaneous

Requirements

Low Level	High Level
An application may invoke services to control devices on other User-Agents separate from the User-Agent issuing the service requests	section 4.3.5 3 Box Model

5.6 U6. Application Exposing a Service

Description

An application exposes a service on the home network. In order to allow this with some technologies, it may be necessary for the HNTF user agent to advertise itself on the HN as a device. For example, an application rendered on a connected TV has access to the connected TV API for EPG information. Other devices on the HN do not have access to this information. The application implements a service exposing the EPG information and makes it discoverable by other devices.

Possible implementation:

• the application A is a TV-broadcast-related application, which is allowed to call the function returning the description of the next program.
• the application A exposes a service with one message getNextProgramDescription.
• application B on another device discovers the service (not knowing that it is an application, it is just another service to application B).

Neither application A or B know the actual nature of the other. They may have an IP address, and they share a service type.

Motivation

Allowing sharing resources other than content, such as a capability (a large screen, a sensor) or an "authorization" (permission to use a restricted API).

Dependencies

This is a prerequisite to applications discovering each other without a "middle man": one of the two applications exposes a service that the other application may discover.

Requirements

Low Level	High Level
An application can cause a User-Agent to act as a device which exposes services	section 4.2.5 Services Advertisement

5.7 U7. Application Discovering a Service

Description

An application discovers a service. Discovery means that after discovery, the application has:

• an identification of a device (maybe) and a service;
• a means to know the messages that can be exchanged, possibly with their parameters;
• a means to send messages to the service, if the service may receive messages;
• a means to receive messages from the service, if the service may send messages.

Motivation

Very basic use case, on which all other use cases depend. There is no existing way for an application to discover services and communicate with them, if the author did not have the address of the service.

Requirements

Low Level	High Level
An application can determine allowable messages and parameters provided by a service	section 4.2.1 Service Discovery
An application can send messages to a service	section 4.3.8 Service Communication
An application can receive messages from a service	section 4.3.8 Service Communication

5.8 U8. Application Push-Migration

Description

An application moving across devices in a decentralized situation (local application, without a server).

I start using my phone for the user interface to a device and then my tablet becomes available, so I move the interface application to the tablet. The application in question is an HNTF application, which means it has discovered services and has connections to some services and a history of execution. Just restarting the application on another device would lose the execution state, the existing connections, etc...

• I start using my phone as a UI of a service on my TV, e.g. EPG, but the screen is small.
• My tablet finally becomes available.
• I request the migration of the current application: this is a user agent function.
• The user agent discovers its peers on the network, i.e. other user agents capable of running the current document.
• The user agent proposes to me a list of suitable user agents, including the one running on the tablet.
• I choose the user agent running on the tablet.
• The UA on the phone binds to the UA on the tablet, and sends a migration message with the URL of the document, and the URL of the execution state.
• The UA on the tablet receives the migration message, fetches the application and the execution state and loads both.
• The UA on the tablet signals to the UA on the phone that migration is complete, by replying "success" to the migration message.
• The UA on the phone stops rendering the migrated application.
• I pick up the tablet and go on with the service at the point I left it on the phone.

Motivation

There is no way with current standards and in the absence of a central server to achieve the saving and transfer of the execution state of a widget, so there is no way to start an application on a device, switch devices and restart the application on the new device, keeping the exact same execution state.

Dependencies

This use case depends on discovery.

Requirements

Low Level	High Level
User-Agents support a service to transfer a runningapplication from another User-Agent to itself	section 4.4.1 Push Migration
Applications support the ability to save their current state and provide this information via a contextURI	section 4.4.1 Push Migration

5.9 U9. Application Pull-Migration

Description

An application moving across devices in a decentralized situation (local application, without a server), the migration being initiated on the target device.

I start using my phone for the user interface to a device and then my tablet becomes available, so I move the interface application to the tablet by interacting with the tablet. The application in question is an HNTF application, which means it has discovered services and has connections to some services and a history of execution. Just restarting the application on another device would lose the execution state, the existing connections, etc...

• I start using my phone as a UI of a service on my TV, e.g. EPG, but the screen is small.
• My tablet finally becomes available.
• I drop my phone.
• I take the tablet, start the HNTFUA and request a list of discoverable HNTFUAs on the tablet: this is a user agent function.
• I start the HNTFUA of the phone and request from it a list of pullable applications and I choose one in the list.
• The UA on the tablet sends a pull-migration message with the identifier of the wanted application chosen from the above list.
• The UA on the tablet receives the response to the pull-migration message, i.e. the url of the application and the url of the execution state, fetches the application and the execution state and loads both.
• The UA on the tablet signals to the UA on the phone that migration is complete.
• The UA on the phone stops rendering the migrated application.

Motivation

Same as ISSUE-15, with the additional twist of triggering the migration from the target device rather than the source device.

Requirements

Low Level	High Level
User-Agents support a service to notify a running application of a request to transfer itself to another User-Agent	section 4.4.2 Pull Migration
Applications support the ability to save their current state and provide this information via a contextURI	section 4.4.2 Pull Migration

5.10 U10. Media Identification

Description

Where available, applications should be able to determine and refer to programmes using a unique and consistent identifier. If the same programme is available from multiple devices or services, the programme should have the same identifier associated with it across all devices or services.

Scenario: An application, wants to present more information associated with a particular programme that the user is currently viewing on their television, without the television acting as an intermediary that serves that additional information.

1. The application discovers an appropriate service
2. The application sends a request to the service to return an identifier for the programme currently playing on the television
3. The application discovers a service that can return metadata for an identified programme
4. The application sends a request to the service to retrieve a unique identifier for the programme that was assigned by the original broadcaster, content publisher or content creator
5. The application contacts an internet service that can resolve identifiers to additional programme metadata
6. The internet service returns additional metadata for the programme

Motivation

• Allows anyone (not just the original content creator or distributor) to create an application that can associate programmes with metadata and web based content; without that metadata or content having to be delivered, or referenced by data served from services on the television or set top box.
• Recommendations to be fed to any groups defining home network protocols to add global content identifier support where not present
• Areas for standardization: (Application specific API/protocols)
  • Requirement for any high level media playback API abstractions (see issue-20) should include the ability to:
    • expose such identifiers as part of programme metadata
    • search for programmes using such identifiers
    • request playback of a programme using such an identifier
  • This use case does not suggest mandating a particular identifier format.

Dependencies

section 5.11 U11. TV Control (for outlined user scenario)

Requirements

Low Level	High Level
Provide consistent program identifiers which are meaningful across multiple devices	section 4.2.6 Media Identification
Provide a means to obtain metadata corresponding to program identifiers	section 4.2.6 Media Identification

5.11 U11. TV Control

Description

An API, or service, for simplified control of key functionality of television devices, including those with integrated broadcast receivers and limited or no media streaming capabilities. The application defines its own user interface, independent of the user interface of the television device.

Application developers would benefit from a simplified API or services that provide:

• A single unified directory of programmes that a given rendering device (e.g. television display) is able to obtain and play. The application does not have to check, for itself, across multiple sources of content and for any issues of codec, container format, and transport protocol compatibility.
• A single simple method for requesting a programme or channel to be presented by a rendering device, irrespective of the above factors.

It is also desirable to be able to control other common aspects of television functionality through the same API.

The target of the API would be a processing engine on the home network. For a Javascript API this processing engine could be incorporated into the user agent. Alternatively, it could be implemented by any other device on the home network, including the television device itself. For the latter case, the user agent must be able to discover and communicate with the processing engine in order to execute the functions of the API.

The processing engine may, when appropriate, utilize existing home networking protocols to perform its function. For example: it may use UPnP AV services to discover and stream content.

Scenario 1: Basic programme guide application: The application uses the API to perform the following tasks:

• The application sends a request to discover television devices on the home network
• The application sends a request to ask for the identity of the programme currently being presented on the television, and the source (e.g. television channel)
• The application sends a request to retrieve basic programme metadata (title, description, start and end times) and displays this for the user
• The application sends a request to retrieve a list of sources (e.g. channels) of programmes that can be displayed on the television
• The application sends a request to retrieve a list of programmes, and their basic metadata for those sources for presentation to the user
• The application sends a request to cause a given channel or programme be played on the television.

Extension to scenario 1: Control of other television functions:

• The application can send a request to change the volume of the television
• The application can enable or disable accessibility features such as subtitles or audio-description
• The application can request to seek (jump to a different time point) within the programme being played

Scenario 2: A web site with material supporting a particular programme wants to be able to offer to play the programme on a television if it is available. A possible interaction (via the API):

• The application sends a request to discover television devices on the home network
• The application makes a request to query if a specific programme is available to the television. If it is available, the application offers the choice to the user to display it.
• If the user accepts, the application requests that programme be played on the television.

Each of the interactions described should be ideally achievable a single call to an API or service method.

Motivation

• Simplify creation of applications that will work with a range of devices and variety of means by which a given programme might played on the television.
• Standardization could facilitate a new ecosystem of interfaces.
• Existing standards for home network communication are not commonly available from the browser context and expose functionality at a lower level.
• What could be standardized:
  • Type of use case: Application specific services / protocols / APIs
  • A Javascript API
  • Service(s) for television type devices on the home network

Dependencies

• section 5.7 U7. Application Discovering a Service
• Scenario 2 requires section 5.10 U10. Media Identification

Requirements

Low Level	High Level
Provide a directory of programs a rendering device can play	section 4.3.1 Control of Content Players
Provide a service to select a program on a rendering device to play	section 4.3.1 Control of Content Players
Provide services to control other aspects of a rendering device such as Seek, Volume, etc.	section 4.3.1 Control of Content Players

5.12 U12. Time Synchronization

Description

Applications should be able to time synchronize their activity with the time-line of a programme being played on a television or other home media rendering device.

Application developers will benefit from having a single simple API that provides a unified interface to this functionality, irrespective of the means by which the programme is being delivered to, or played by, the television device.

The application is running on a different device from where the programme is being played. This could be a laptop, mobile phone, tablet, etc. Both devices are on the same home network. The device playing the programme may be a television or other media rendering device. The programme being played may be being obtained by a variety of different means:

• from a live broadcast via an integrated tuner
• playback from local storage (e.g. a Personal Video Recorder device)
• streaming from another device on the home network
• streaming from an on-demand internet service

The target of the API would be a processing engine on the home network. For a Javascript API this processing engine could be incorporated into the user agent. Alternatively, it could be implemented by any other device on the home network, including the television device itself. For the latter case, the user agent must be able to discover and communicate with the processing engine in order to execute the functions of the API.

The processing engine may, when appropriate, utilize existing home networking protocols to perform its function. For example: it may use UPnP AV services to query and set the playback time index.

An API meeting these requirements may enable an application to:

• request the current playback time index of the programme being played on a given device
• command the device to jump to a different playback time index
• request notification when programme playback reaches a particular moment or time interval in the programme timeline.

Scenario: An application wants to present a slideshow of content relating to the programme the user is watching on their television. As the programme progresses, the slideshow automatically moves onto the correct slide for any given point in the programme. If it is possible to seek within the programme timeline (because the programme is not being watched from a live broadcast), the user can use the application to jump to a different point in the presentation and the television will also seek to the corresponding segment of the programme.

Motivation

• Simplify creation of applications that will work with a range of devices and variety of means by which a given programme might played on the television.
• Enable the creation of added-value viewing experience for the user where additional information is available in a timely fashion without interrupting the TV viewing experience or increasing on screen 'clutter'.
• What could be standardized:
  • Type of use case: Application specific services / protocols / APIs
  • A Javascript API
  • Services or protocols implemented by devices on the home network

Dependencies

• section 5.7 U7. Application Discovering a Service
• section 5.10 U10. Media Identification required for an application to know which content to provide for the programme being watched in the described scenario.
• This use case could be considered an extension of section 5.11 U11. TV Control

Requirements

Low Level	High Level
Provide ability to generate notification to application when a particular playback time is reached	section 4.3.6 Time-synchronization
Provide the ability to position playback to a specified time-index	section 4.3.6 Time-synchronization
Obtain the current playback time-index	section 4.3.6 Time-synchronization

5.13 U13. Lip Sync Time Synchronization

Description

This use case is a specialization of the use case Time Synchronisation (see section 5.12 U12. Time Synchronization)

An application should be able to synchronize the presentation of its own content with a high degree of accuracy to the timeline of a programme being played on a television or other home media rendering device. The level of accuracy should be sufficient to achieve 'lip-sync' between audio and video (typically within 1 to 2 video frames or tens of milliseconds).

In addition to the functions described in the Time Synchronisation use case; the API used by the application should be able to:

• report an estimate of the timing synchronism accuracy that is achievable
• provide synchronization to within lip-sync accuracy if all devices involved support it

The processing engine that implements the API may utilize existing home networking protocols to achieve the required accuracy. A likely necessary component will be the synchronization of clocks between the television or media rendering device and the device on which the application is running. Possible protocols that might be used to achieve this include: Precision Time Protocol (IEEE 1588-2002) [IEEE1588], IEEE 802.1AS [IEEE802-1AS], UPnP Precision Time Synchronization [UPNP-AVT3].

Applications will benefit if the API presents a simple unified set of functions such that the application does not need know which protocols are being used.

Scenario: An application plays alternative audio that is time synchronized to a programme that the user is watching. The synchronization is sufficiently accurate to maintain 'lip-sync' between the alternative audio and the programme video. The alternative audio may be delivered to the application independently of the television device - such as via a direct stream from a broadcaster's internet based server.

Motivation

• Simplify creation of applications requiring lip-sync accurate time synchronization that will work with a range of devices and variety of means by which a given programme might be played on the television.
• What could be standardized:
  • Type of use case: Application specific services / protocols / APIs
  • A Javascript API
  • Services or protocols implemented by devices on the home network

Dependencies

This use case is a specialization of the Time Synchronization use case (see section 5.12 U12. Time Synchronization)

Requirements

Low Level	High Level
Determine the time synchronization capabilities of home-network devices	section 4.3.7 Accurate Time-synchronization
Provide the capability for applications to synchronize with playback content to approximately frame resolution	section 4.3.7 Accurate Time-synchronization
Provide the capability to precisely synchronize multiple content streams	section 4.3.7 Accurate Time-synchronization

5.14 U14. Local Link of Web Applications

Description

This use case is about the bi-directional communication between web applications via the local IP network e.g. Home IP network.

Assumptions:

• User devices are connected to the same local IP network
• The applications on user devices know each other and can exchange messages for communications
• Note that the applications may not necessarily be provided by the same distributor or service provider
• A user uses the IR remote controller to operate the HTML5 browser on the TV device (10 feet UI)
• A user uses the touch screen to operate the HTML5 browser on the tablet device or smart phone (Touch UI)
• Note that the application may not necessarily to be a web application as long as it communicates by the same network protocols as the user-agent does.

User Scenario A - Single User:

• Bob operates the TV device to watch movies on an online video service
• Bob also operates the tablet device to access a social network service about movies
• Bob views web pages of the social network service and find a favorite movie
• Bob clicks the “your device” button on the web page of the social network service
• The application on the TV device show the web page of the video service about the movie, then Bob starts to watch the movie

User Scenario B - Multiple Users:

• Bob operates his smart phone to use an application for a picture service
• Alice operates her smart phone to access another picture application
• Bob selects his favorite picture and clicks the “Sharing photo with other device” on the application
• The application on Bob’s device shows the device name list and he selects the Alice’s device
• The picture file is transferred from the Bob’s device to the Alice’s device while each application shows the progress bar of file transfer
• After the transfer is completed, the application on the Alice’s device shows the Bob’s favorite picture

User Scenario - Interactive Quiz:

• Alice and Bob operates the TV device to watch a quiz programme, from live broadcast
• Alice and Bob also operate their smart phones to access a quiz application
• Note: The smart phone quiz application knows that the quiz programme is being watched on the TV and establishes communication with an interactive application on the TV that is active during the quiz programme)
• The TV application overlays on-screen information informing Alice and Bob that they are now taking part in the quiz.
• As a question is asked in the quiz programme, the interactive TV application instructs Alice and Bob's smart phone quiz applications to ask Alice and Bob the same questions. Alice and Bob enter answers to the questions using their smart phones, which are relayed back to the interactive TV application.
• Between quiz rounds, Alice and Bob's scores are displayed on their smart phones and overlayed on screen by the TV interactive application. Scores are compared to those of the contestants featuring in the programme.
• Note: Regarding need/justification: Using local-link communication to an interactive application provided as part of a broadcast stream provides a way around scalability concerns if participation is substantial for a particularly popular programme.

Use case (System Interactions):

• A User-Agent discovers other Users agent on the same IP-sub network
• Via API, the User-Agent provides the discovered application list which contains the applications which are running on other user-agent, e.g. application id, the URL for message exchange, physical device name(for user selection)
• The application establishes the bi-directional communication for message exchanges with the application on the other user-agent via API

Implementation examples:

• For the local discovery, the HTML5 browser implements UPnP Discovery to provide the generic discovery API to find applications on the same IP sub-network
• For the message exchange, the HTML5 browser implements the extended WebSocket protocol and APIs for bi-directional communications
• The HTML5 browser should implement some mechanism to confirm the user consensus to permit the device discovery and message exchanges for the applications

Additional comments:

• The above user scenarios are examples. As long as the message exchange API is service/application agnostic, many rich user experience can be realized as the open web platform does

Motivation

The “Local Link” enables applications to exchange message, e.g. String, Blob, via the local network directly. Without the “local Link”, the applications which are running on different devices can in-directly communicate via a service on the Internet. But, the “Local Link” has the following benefits:

• Adhoc: Without any syndication of services, the applications provided by different services can communicate each other's in ad-hoc. Also, all devices are not required to be bound to the same service. This is a kind of service mash-up using multiple devices
• Efficient: A large size of files can be transferred between devices via high bandwidth local network connection.
• Off-line: Even if the Internet access is not available, the applications can still communicate
• User-centric: Users can easily recognize which devices communicate. Only devices on the same network are listed and the communications of different user device are based on the user consent

There are some standards of local discovery, e.g. UPnP, Bonjour, WS-Discovery, but there is no standard of the JavaScript API which enables communications between Web applications in the manner of application/service agnostic.

What needs to be standardized:

• Type of use case: Generic APIs
• General service discovery and messaging APIs should be standardized
• Network protocols for the APIs should be specified

Dependencies

Any other use cases related to the local IP network discovery since the discovery is also application/service agnostic

Requirements

Low Level	High Level
Support applications communicating with each-other via ad-hoc messages	section 4.3.9 Application Communication section 4.2.2 Application Discovery

5.15 U15. Home Network Enabled User-Agent - Network Media Player

Description

Enable a User-Agent to act as a Home Network Media Player

The User-Agent acts as a Home Network Media Player device. For example (steps further detailed below):

1. List available Home Network Media Server devices.
2. List available content on a Home Network Media Server.
3. List available content on a Home Network Media Server matching specified metadata criterion.
4. Determine capabilities of User-Agent playback facilities provided to Home Network Media Player. Ex: supported content formats, number of streams, supported resolution(s).
5. Play content from a Home Network Media Server.
6. View EPG data from a Home Network Media Server.
7. Tune and play live programs from a Home Network Media Server capable of streaming live content.
8. Select and play recorded content from a Home Network Recording device.
9. Select and play time-shifted content.

Detailed steps for "List available Home Network Media Server devices":

1. Web page issues a method to discover home network devices
2. User-Agent gets an event indicating the list is ready.
3. User-Agent retrieves a list of handles representing the discovered devices
4. Web page issues a method to get information about each discovered device
5. Web page retains handles for devices of the appropriate type.
6. Web page displays available devices to end-user.
7. End-User selects one of the displayed devices.
8. Web page issues method to access the device.
9. User-Agent responds that a password is required.
10. Web page obtains the password from the end-user (or secure password store) and issues method to provide the password to the User-Agent
11. Web page can now access the device.

Detailed steps for "List available content on a Home Network Media Server":

1. Web page formats an action request to browse the Home Network device metadata containers for EPG Items matching desired channel/time ranges.
2. Web page issues method to send action request to selected Home Network device
3. User-Agent sends request to Home Network Media Server device.
4. User-Agent generates event when Home Network device responds (or times-out)
5. Web page gets response (XML document) from Home Network Media Server device.
6. Web page displays containers and items as indicated in XML document
   This depends on the data representation of Home Network Media Server content metadata.
7. Web page displays the information in the Home Media Server response.

Detailed steps for "List available content on a Home Network Media Server matching specified metadata criterion":

1. Web page formats an action request to determine searchable metadata on the selected Home Network device metadata store.
2. Web page issues method to send action request to selected Home Network device.
3. Web page formats an action request to search the Home Network device metadata store.
4. Web page issues method to send action request to selected Home Network device
5. User-Agent sends request to Home Network Media Server device.
6. User-Agent generates event when Home Network device responds (or times-out)
7. Web page gets response (XML document) from Home Network Media Server device.
8. Web page displays containers and items as indicated in XML document

Detailed steps for "Play content from a Home Network Media Server":

1. End-user select displayed Home Network Media Server item for playback.
2. Web page formats an action request to browse metadata for selected item.
3. User-Agent sends request to Home Network Media Server device.
4. User-Agent generates event when Home Network device responds (or times-out)
5. Web page gets response (XML document) from Home Network Media Server device.
6. Web page selects media binary format that is compatible with User-Agent.
7. Web page displays Media Player using HTML5 <video> element.
8. Web page transfers item URL to <video> element @src (or creates <source> element as child element)

Detailed steps for "View EPG data from a Home Network Media Server":

1. Web page formats an action request to determine root container(s) for EPG data on the selected Home Network device metadata store.
2. Web page issues method to send action request to selected Home Network device.
3. Web page formats an action request to search the Home Network device metadata store.
4. Web page issues method to send action request to selected Home Network device
5. User-Agent sends request to Home Network Media Server device.
6. User-Agent generates event when Home Network device responds (or times-out)
7. Web page gets response (XML document) from Home Network Media Server device.
8. Web page displays EPG containers and EPG items as indicated in XML document

Detailed steps for "Tune and play live programs from a Home Network Media Server capable of streaming live content":

1. Web page formats an action request to determine root container(s) for Channel Lineup metadata on the selected Home Network device.
   Notes:
   • Multiple Channel Lineup containers may represent either an aggregate of multiple channel sources (Broadcast, Cable, Satellite) or selected channel sources (“Favorite Channels” for instance).
   • Channel Lineup containers contain Channel Items which are metadata bundles of channel related properties. Some example of channel properties are: Channel Name, Channel Number, Channel Icon, Channel Preview Stream.
   • A Channel Item contains metadata describing one or more URLs which stream the channel's binary content. Access to one of these URL implies any tuning operations necessary to make the requested channel source available.
2. Web page formats a channel listing based on Channel Items found. In addition the Web page may construct a subset of available Channel Items based previously stored end-user selections.
3. Web page may support a Channel Up/Down notion based on an ordering of channels selected by the end-user of by using metadata properties of the Channel Items (Channel Number, Channel Name, etc.)
4. Web page will typically offer the end-user the ability to select a channel for playback. The Web page will generate a <video> element referencing the channel's streaming URL provided by the Channel Item metadata.

Detailed steps for "Select and play recorded content from a Home Network Recording device":

1. Web page formats an action request to determine root container(s) for Recorded Content metadata on the selected Home Network device.
   Notes:
   • Recorded Content Items are similar to stored Content Items. However, Recorded Content Items may contain metadata containing the ID of the Recording Service request that resulted in the creation of this item.
2. Web page display information about recorded content item.
3. Web page offers end-user the ability to play recorded item.
4. Web page offers end-user the ability to manipulate the Recording request which created the item.

Notes for "Select and play Time-Shift recorded content from a Home Network Recording device":

• Time-shift recording is an important variant of Network Recording. For Time-Shift recording no explicit request is required to record content; instead, the recording device automatically records the currently tuned channel (or favorite channel) in a circular buffer. Recorded content may be organized as one of more blocks of continuous content or as a list of separate captured programs.
• Time-shift recording generates temporary Content Items (bundles of content metadata). These content items are typically pointed to by the Channel Item that the content was captured from. For Time-shift Content Items some additional metadata properties are defined to indicate that the recording of an item may not be complete, and/or that a Content Item may represent a partial recording the original content.

Detailed steps for "Select and play Time-Shift recorded content from a Home Network Recording device":

1. Web page access Channel Items (as described in prior use-case)
2. Web page detects Channel Item lists to one or more Content Items as preserved content.
3. Web page displays preserved Content Items which is available for the channel.
4. Web page offers user ability to play preserved content by accessing URL in preserved Content Item.
5. Web page offers user ability to convert preserved content to permanently recorded content by offering preserved Content Item(s) to the Network Recording service.

Motivation

• Existing Home Network interfaces do not (by scope/tradition) standardize user interface control. However, the combination of HTML markup and Javascript allow both access to Home Network devices functions and access to very capable user interface resources.
• Why were you not able to use only existing standards to accomplish this?
  • HTML User-Agents do not provided the abstractions necessary for Javascript to issue discover and issue commands to home network devices.
  • Basic access methods to home network devices need to be standardized so that developers can implement pages to control Home Network devices using Javascript/HTML.
• What might you suggest could be standardized?
  • Provide generic access methods to enable a User-Agent to discover and command home network devices.
  • Provide a means for applications to control some of the parameters that may need to be exposed to support well-established home network protocols. A more detailed analysis is needed to identify such parameters and a way to specify them in a transport agnostic way
  • Provide access and privacy controls for untrusted pages accessing home network devices.
  • Allow pages to discover functional differences (optional functionality) that may be implemented in some but not all Home Network ecosystem devices.

Dependencies

This use-case provides the basic framework for generic access to home network devices. It is "agnostic" towards the underlying functionality of the devices being controlled.

Requirements

Low Level	High Level
Application can obtain and display descriptive metadata for playback content	section 4.2.1 Service Discovery section 4.2.3 Content Discovery
Application can obtain and display other descriptive metadata such as Electronic Programming Guides	section 4.2.1 Service Discovery section 4.2.3 Content Discovery
Application can select content binary formats which match the User-Agent’s supported playback formats	section 4.3.3 Playback of Content
Application can play content from Home Network stored content sources	section 4.3.3 Playback of Content
Applications can play live content from Home Network streaming sources	section 4.3.4 Playback of Live Content
Applications can play content from Home Network recording sources	section 4.3.3 Playback of Content

5.16 U16. Home Network Enabled User-Agent - Network Media Server

Description

Enable a User-Agent to act as a Home Network Media Server.

Scenario: The User-Agent acts as a Home Network Media Server device. For example:

• Create a discoverable Home Network Media Server device.
• List available content that the User-Agent chooses to make available on the Home Network.
• Provide descriptive metadata (title, description) for this content.
• Provide multiple binary formats for this content.
• Provide functionality to allow other User-Agents to search for content matching specified metadata criteria.
• Provide capability for Home Network Media Server to notify clients when list of available content changes.

Detailed steps for "Create a discoverable Home Network Media Server device":

1. Web page provides User-Agent descriptive metadata for the device to be created.
2. Web page provides User-Agent access to programs to service requests made to Home Network Media Server.
3. Web page requests User-Agent to make device visible on Home Network

Detailed steps for "List available content that the User-Agent chooses to make available on the Home Network":

1. Created Media Server device receives request to list Media Server content.
2. User-Agent invokes previously registered program (php?) to service request.
3. User-Agent forwards results of registered program to requesting end-point providing identifiers for (Content Items) describing available content.

Detailed steps for "Provide descriptive metadata (title, description) for this content":

1. Created Media Server device receives a request to provide metadata for a Content Item.
2. User-Agent invokes a previously registered program (php?) to provide metadata corresponding to a Content Item.
3. User-Agent forwards results of registered program to requesting end-point.

Detailed steps for "Provide multiple binary formats for this content":

1. Content Items contain metadata providing one or more alternative formats for content represented by a content item. This metadata consists of a URL which serves the content item and additional descriptive metadata for the content binary served by the corresponding URL.

Detailed steps for "Provide functionality to allow other User-Agents to search for content matching specified metadata criteria":

1. Created Media Server device receives a request to provide Content Item identifiers whose metadata matches criteria provided by the end-point.
2. User-Agent invokes a previously registered program (php?) to provide identifiers of Content Items which match the search criteria provided.
3. User-Agent forwards results of registered program to requesting end-point.

Detailed steps for "Notify User-Agents of changes to available content":

1. User-Agent receives request from end-point(s) to report changes to available content.
2. User-Agent receives notification that available content has changed.
3. User-Agent forwards notification to end-point(s) which have registered for this notification.

Motivation

Existing Home Network interfaces do not (by scope/tradition) standardize user interface control. However, the combination of HTML markup and Javascript allow both access to Home Network devices functions and access to very capable user interface resources.

Why were you not able to use only existing standards to accomplish this?

• HTML User-Agents do not provided the abstractions necessary for Javascript to issue discover and issue commands to home network devices.
• Basic access methods to home network devices need to be standardized so that developers can implement pages to control Home Network devices using Javascript/HTML.

What might you suggest could be standardized?

• Provide generic access methods to enable a User-Agent to discover and command home network devices.
• Provide a mean for applications to control some of the parameters that may need to be exposed to support well-established home network protocols. A more detailed analysis is needed to identify such parameters and a way to specify them in a transport agnostic way
• Provide access and privacy controls for untrusted pages accessing home network devices.
• Allow pages to discover functional differences (optional functionality) that may be implemented in some but not all Home Network ecosystem devices.

Dependencies

This use-case provides the basic framework for generic access to home network devices. It is "agnostic" towards the underlying functionality of the devices being controlled.

Requirements

Low Level	High Level
Applications can cause a User-Agent to act as a Home Network media server	section 4.2.4 Content Advertisement
Applications support services which provide metadata describing available content	section 4.2.4 Content Advertisement
Application supports services which allow searching for content metadata matching specified criteria	section 4.2.4 Content Advertisement
Application supports services which notify clients of changes in available content or content metadata	section 4.2.4 Content Advertisement
Content descriptions support offering content in multiple binary formats	section 4.2.4 Content Advertisement

5.17 U17. Home Network Enabled User-Agent

Description

Enable a User-Agent to control other media oriented Home Network Devices (3-box model).

Scenario: The User-Agent commands other media oriented home network devices. For example:

• Determine the playback capabilities of a Home Network Media Rendering device. For example: supported content formats, number of streams, supported resolution(s).
• Direct a Home Network Media Rendering device to play compatible content stored on a Home Network Media Server.
• Direct a Home Network Media Rendering device to play live content from a Home Network Media Server capable of streaming content.
• Control Home Network Media Renderer attributes: Brightness, Contrast, Volume, etc.
• Control Home Network Media Renderer multiplex stream selection: Closed Captioning, Language, Subtitling and Camera Angles.

Detailed steps for "Direct a Home Network Media Rendering device to play content stored from a Home Network Media Server":

1. Web page requests User-Agent discover Media Rendering devices on Home Network
2. Web page allows end-user to select a Media Rendering device
3. Web page issues request to Media Rendering device to determine content formats it supports
4. Web page requests User-Agent discover Media Server devices on Home Network
5. Web page allows end-user to select a Media Server device
6. Web page obtains list of Content Items available on Media Server
7. Web page removes items from list which do not have formats compatible with selected Media Renderer device
8. Web page allows end-user to select from remaining Content Items
9. Web page selects Content Item URL that provides "best" playback experience on Media Renderer
10. Web page sends selected Content Item URL to Media Renderer device
11. Web page sends command to Media Renderer device to begin playback

Detailed steps for "Direct a Home Network Media Rendering device to play live content from a Home Network Media Server capable of streaming content":

• Steps are similar to above use-case. However, Media Rendering device needs to modify buffer sizes to account for content being served at playback rate.

Detailed steps for "Control Home Network Media Renderer attributes: Brightness, Contrast, Volume, etc.":

1. Web page issues request to Media Renderer device to get default settings
2. Web page issues request to Media Renderer device to modify default settings
3. Web page issues request to Media Renderer device to modify settings for current Content Item (if any)

Detailed steps for "Control Home Network Media Renderer multiplex stream selection: Closed Captioning, Language, Subtitling and Camera Angles":

1. Steps are followed to the point where Media Render is provided the Content Item URL.
2. Web page issues request to Media Renderer to determine what playback attributes can be modified for the selected Content Item.
3. Web page may request to Media Renderer device to select desired playback settings for the selected Content Item if user wishes to override default settings.

Motivation

Existing Home Network interfaces do not (by scope/tradition) standardize user interface control. However, the combination of HTML markup and Javascript allow both access to Home Network devices functions and access to very capable user interface resources.

Why were you not able to use only existing standards to accomplish this?

• HTML User-Agents do not provided the abstractions necessary for Javascript to issue discover and issue commands to home network devices.
• Basic access methods to home network devices need to be standardized so that developers can implement pages to control Home Network devices using Javascript/HTML.

What might you suggest could be standardized?

• Provide generic access methods to enable a User-Agent to discover and command home network devices.
• Provide a mean for applications to control some of the parameters that may need to be exposed to support well-established home network protocols. A more detailed analysis is needed to identify such parameters and a way to specify them in a transport agnostic way.
• Provide access and privacy controls for untrusted pages accessing home network devices.
• Allow pages to discover functional differences (optional functionality) that may be implemented in some but not all Home Network ecosystem devices.

Dependencies

This use-case provides the basic framework for generic access to home network devices. It is "agnostic" towards the underlying functionality of the devices being controlled.

Requirements

Low Level	High Level
Application allows a User-Agent to discover and control media playback on other Home-Network Devices	section 4.3.5 3 Box Model section 4.3.1 Control of Content Players

5.18 U18. Home Network Enabled User-Agent - Network Record Controller

Description

Enable a User-Agent to control a Home Network Recording Device.

Scenario: The User-Agent controls a Home Network Recording device. For example:

• Request the recording device capture content based on simple time/date criteria.
• Request the recording device capture content based recurring time/date criteria.
• Request the recording device capture content based on an EPG description.
• Request the recording device capture content based on a metadata description.
• Provide controls to suspend/restart/cancel planned recording activities.
• Provide status information for current/future recording activities.
• Provide access to recorded program descriptions and content.

Detailed steps for "Request the recording device capture content based on simple time/date criteria":

1. Web page issues a request to determine the capabilities of the Network Recording device.
2. Web page creates a XML document describing a simple record schedule.
3. Web page sends XML document to Network Recording device.
4. Network recording device creates one or more Recording Tasks.
5. Web page may issue request to Network Recording device to determine status of Recording Tasks.

Detailed steps for "Request the recording device capture content based recurring time/date criteria":

1. Web page creates a XML document describing a recurring record schedule.
2. Note: See above steps.

Detailed steps for "Request the recording device capture content based on an EPG description":

1. Web page obtains a EPG Content Items from Media Server (See prior use-case)
2. Web page creates a XML document containing identifier of the EPG Item.
3. Note: Network Recording service presumes that EPG service resides on same device.
4. Web page sends XML document to Network Recording device.
5. Network recording device creates one or more Recording Tasks.

Detailed steps for "Request the recording device capture content based on a metadata description":

1. Web page creates a XML document describing a recurring record schedule which selects content based on metadata properties.
2. Web page sends XML document to Network Recording device.
3. Network recording device creates one or more Recording Tasks.

Detailed steps for "Provide controls to suspend/restart/cancel planned recording activities":

1. Web page may issue request to Recording Device to get current Recording Tasks.
   Note: Record Tasks are generated from XML Record Schedule documents submitted to Network Recording Device.
2. Web page may issue request to suspend, restart or cancel Record Tasks or Record Schedules.

Detailed steps for "Provide status information for current/future recording activities":

1. Web page may issue request to Recording Device to get current Recording Task documents. Record Tasks contain various status information indicating whether recording is pending (not started), active (started but not completed), or done (completed).

Detailed steps for "Provide access to recorded program descriptions and content":

1. The Network Recording device (Record Tasks) creates Content Items.
2. The Record Task contains identifiers to the created Content Item(s) for the Record Task.
3. The Content Items contain metadata describing what was recorded.

Motivation

Existing Home Network interfaces do not (by scope/tradition) standardize user interface control. However, the combination of HTML markup and Javascript allow both access to Home Network devices functions and access to very capable user interface resources.

Why were you not able to use only existing standards to accomplish this?

• HTML User-Agents do not provided the abstractions necessary for Javascript to issue discover and issue commands to home network devices.
• Basic access methods to home network devices need to be standardized so that developers can implement pages to control Home Network devices using Javascript/HTML.

What might you suggest could be standardized?

• Provide generic access methods to enable a User-Agent to discover and command home network devices.
• Provide a means for applications to control some of the parameters that may be needed to be exposed to support well-established home network protocols. A more detailed analysis is needed to identify such parameters and a way to specify them in a transport agnostic way.
• Provide access and privacy controls for untrusted pages accessing home network devices.
• Allow pages to discover functional differences (optional functionality) that may be implemented in some but not all Home Network ecosystem devices.

Dependencies

This use-case provides the basic framework for generic access to home network devices. It is "agnostic" towards the underlying functionality of the devices being controlled.

Requirements

Low Level	High Level
Application supports various recording schedules: Time of Day, Electronic Programming Guide, Metadata matching	section 4.3.2 Control of Content Recorders
Application provides status information for current and pending recording activities	section 4.3.2 Control of Content Recorders
Application provides ability to cancel, suspend, and restart pending recording activities	section 4.3.2 Control of Content Recorders
Application provides access to recorded content	section 4.3.2 Control of Content Recorders

5.19 U19. UPnP / DLNA ecosystem support

Description

Use cases U15, U16, U17, U18 and U1 describe functionality implemented by existing UPnP/DLNA home network devices in general terms. However, there is an existing install base of UPnP/DLNA compliant devices and the associated SDOs (UPnP Forum, DLNA) continue actively develop additional device related specifications. It would be beneficial to the end-user community if W3C User-Agents provided access to UPnP/DLNA devices without requiring any modification to the existing install base of UPnP/DLNA compliant devices.

Scenarios:

• user agents support applications which can discover UPnP/DLNA compliant devices.
• user agents support applications retrieving UPnP Device and Service Description XML documents.
• user agents support application issuing of SOAP actions to control UPnP/DLNA devices.
• user agents support applications subscribing to UPnP Service Events.
• user agents support applications inspection of UPnP Service State Variables.
• user agents support applications including DLNA specified HTTP transport headers to obtain DLNA content metadata and to control playback features (such as trick-play, time-based positioning).

A summary of UPnP specifications relevant to this use case is provided in section 8.5 Universal Plug'n Play (UPnP) Reference.

Requirements

Low Level	High Level
Application supports access to UPnP/DLNA devices without modification of existing deployed devices	section 4.1.1 Compatibility with widely deployed standards
Application support UPnP devices not related to content playback	section 4.1.1 Compatibility with widely deployed standards

6.1 Threats

6.2 Potential Solutions

The list of techniques listed in this section are not mutually exclusive but can be combined to provide more flexibility in handling user security.

7.1 Requirements Categorization

The HNTF has made an attempt to categorize requirements based on the priority of addressing them to enable some of the use cases that are already available via other technologies or that are felt particularly important to have an enhanced user experience. Go without saying that all identified requirements are considered important by the Task Force; so the criteria followed is more the degree to which each requirements enables use cases that cannot be covered today rather than a value judgment of the importance of one requirement versus another (which differs by individual). By this "enablement" criterion, a feature that enables more use cases is higher priority than a feature that enables a limited subset of use cases.

The following requirements underpin most (if not all) of the use cases (see section 5. Use Cases) listed in this document, so they are considered the starting point for a technical work:

• section 4.2.1 Service Discovery
• section 4.2.3 Content Discovery

These alone are insufficient to fulfill most of the use cases and user scenarios identified. The use cases that seem most straightforward to address next and which also show the most immediate utility are those that support the ability to control and query media playback:

• section 4.1.1 Compatibility with widely deployed standards
• section 4.3.1 Control of Content Players
• section 4.3.3 Playback of Content
• section 4.3.4 Playback of Live Content
• section 4.3.5 3 Box Model
• section 4.3.6 Time-synchronization
• section 4.3.8 Service Communication

The requirements listed above focus on enabling applications to utilize existing home network services. The remaining requirements all enable use cases and scenarios that are of great interest and could be considered a "next step" of making it possible for applications to advertise and/or offer services. These requirements would allow leveraging web technologies and creating new types of application which mashes up Web and home networked devices.

• section 4.2.5 Services Advertisement
• section 4.2.4 Content Advertisement
• section 4.3.9 Application Communication
• section 4.2.2 Application Discovery
• section 4.4.1 Push Migration
• section 4.4.2 Pull Migration
• section 4.3.7 Accurate Time-synchronization

While security requirements are of really high priority in general, some of the requirement listed in this document may or may not be covered by conforming specifications depending on the particular technical solution that will be designed to cover the requirements listed above. That is why the following requirements to no fall into the High/Low priority scheme:

• section 4.5.1 Application Trust Level
• section 4.5.2 Access to Home Network Services
• section 4.5.3 Prevent Leaking of Information

Media Identification is a prerequisite for applications to be able to properly relate items of media content to a wider web of data/content. On the other end this requirement is orthogonal to the other discussed in this document and could be probably discussed in parallel with the work on the other requirements. That is why the following requirement is also not categorized:

• section 4.2.6 Media Identification

7.2 Identified Gaps

A close analysis and discussion of the use-cases and requirements described in this document, lead the group to conclude that the major gap in the Open Web platform is the lack of means for an application to discover services and applications available on the home network. Filling such a gap will probably allow the coverage of most (if not all) requirements listed in this document (see section 4. Requirements).

Some concerns were raised if the discovery alone is enough to address advertisements requirements especially for support of existing protocols such as UPnP. In fact, advertisements itself could be implemented as a service so that applications can discover it and then register to be advertised on the network. Such a service may be provided by the UA itself (i.e. the functionality is provided by the UA but exposed as a service) or by an external device. It is not clear though (lacking implementations of this) if this approach will be enough flexible and efficient.

Furthermore to have an interoperable solution, a common advertising service would have to be standardized or JavaScript binding to already in use advertising services/protocols would have to be provided.

The discussion will have to be deferred to the point in time when a User Agent supporting discovery is available.

7.3 Next Steps

The HNTF believes that all the identified use cases and requirements are important to achieve a better convergence between the Web and TV. The TF also believes that all of them have an impact on the current web platform architecture so a recommendation track work would be needed to make sure that the identified requirements are covered in an open and interoperable way.

The HNTF believes that many of the requirements identified here may match the deliverables in the Device APIs Working Group Charter. Therefore it is proposed to provide this requirement document as an input for further work to the Device APIs (DAP) Working Group. However, if after a more detailed analysis, requirements detailed in this document are found to be out-of-scope for the DAP WG, then the HNTF recommends that additional W3C Working Groups be chartered to address the remaining requirements.

7.4 Open Issues

During his work, the HNTF did not have time to explore topics like the access to the home network from outside the home or concepts like group of homes. The TF believes that this is an area of extreme interest and would suggest the DAP WG (or any other working group working on the requirements extracted from this document) further investigate these topics. The Web & TV IG itself may consider discussing these topics and provide feedbacks to one or more W3C Working Groups.

8.1 CableLabs

CableLabs is a not-for-profit research and development consortium that has cable operators as its members. While working on defining use cases and requirements as member of the Home Network TF of the Web and TV IG, some work has been done by CableLabs to experiment with possible ways to support use cases discussed by the Home Network Task Force in an HTML5 user agent. See CableLabs Revised Home Networking API [CLABS-HNAPI].

8.2 Opera

Opera proposed a low-level API to address some of the use cases outlined in this document and discussed by the Home Network Task Force of the Web and TV IG. This section contains an outline of the proposal as presented to the DAP WG.

8.3 Telecom ParisTech

Telecom ParisTech is a French academic institution where research relevant to HNTF on combining W3C widgets, SVG and UPnP went on from 2008 to 2010. The work has been implemented as part of the open source multimedia player GPAC (see GPAC) and is publically available. All use cases contributed by Telecom ParisTech to HNTF have been implemented in that system, but for the "pull migration" use case.

This work is described in the following papers:

1. Communicating and migratable interactive multimedia documents (PDF) [PTECH-MIGRATE]
2. SVG Communicating Widgets [PTECH-SCW]
3. Declarative Interfaces for Dynamic Widgets Communications (PDF) [PTECH-DECL]
4. Widgets Mobility (PDF) [PTECH-WM]

8.4 CEA-2014 Web-based Protocol and Framework for Remote User Interface - Overview

CEA-2014 [CEA-2014] describes web based Remote UI applications for CE devices. CEA-2014 is referenced by multiple Standards Development Organizations to provide ecosystem specific Remote UI solutions.

CEA-2014 leverages existing web technology standards including XHTML for screen layout and user interactions; and ECMAScript for interactive application support. In addition, CEA-2014 provides additional standardized interfaces addressing the following areas:

• Remote UI Application Listing
• Client Capabilities Matching
• Standardized Audio-Video Player
• Digital Rights Management Framework
• Content Download Management Framework
• UPnP / DLNA Home Network Framework
• SVG (Scalable Vector Graphics) integration with XHTML
• Server to Client Notification Framework
• Remote UI Save and Restore Framework

8.5 Universal Plug'n Play (UPnP) Reference

8.6 Ericsson Labs

Ericsson Labs is the part of Ericsson Research that focuses on iterative open innovation and experiments with new technologies, services and business models. The purpose of Ericsson Labs is to support Ericsson’s vision of the Networked Society by working with partners including technology providers and third-party developers.

Ericsson Labs provides access to experimental APIs in their infancy so that developers can create new, innovative services. "Web Technologies" is one of the major categories of experimental APIs and the category contains API named "Web Device Connectivity".

• Ericsson Labs
• Web Technologies
• Web Device Connectivity [ERICSSON-WDC]

The Web Device Connectivity API enables you to connect end users’ devices to the Web. It provides end users with new experiences of devices in their home networks being a part of the Web and web sites can seamlessly make use of those home devices. For example, an web site or a blog can access the viewer's DLNA enabled TV and let the viewer choose his/her DLNA enabled TV to play the contents on the web site.

• Demo video

Web Device Connectivity platform consists of a software running inside each end users' home network and interacting with home devices, in-cloud servers aggregating device information and enforcing security policy, and a Javascript library providing API for web sites. Developers can create web sites, by including the Javascript library, which accesses devices in end users' home networks through the Ericsson Labs Web Device Connectivity platform.