This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 11326 - A proposal to add web application access to home network A/V devices and content
Summary: A proposal to add web application access to home network A/V devices and content
Status: CLOSED NEEDSINFO
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-16 16:24 UTC by Bob Lund
Modified: 2011-08-04 05:11 UTC (History)
7 users (show)

See Also:


Attachments

Description Bob Lund 2010-11-16 16:24:09 UTC
Cable operators currently deliver video services to browsers via video plugins and wish to deliver program guides with full video services to HTML5 browsers. CableLabs® (www.cablelabs.com), on behalf of its cable operator member companies, is in the process of becoming a W3C member and would like to propose an extension to HTML5 to meet this important goal. As a key requirement of current program guides, cable operators want to expose home network devices (such as set top boxes), services and content to web applications. This need was also identified in the recent W3C Web on TV workshop in Tokyo. CableLabs OpenCable Home Networking specifications define the use of UPnP protocols for such access.

Exposing home network devices, services and content to web applications has these requirements: 

1) User agents need to provide an API to JavaScript for discovering home network web-servers that host applications which advertise content and other services. Such servers are called remote user interface servers in UPnP. UPnP  provides the ability to discover such servers as described in detail in http://upnp.org/specs/rui/UPnP-rui-RemoteUIServer-v1-Service.pdf.

2) User agents should provide an API to JavaScript for discovery and control of home network devices, services and content. OpenCable Home Networking uses several UPnP APIs:

- Device and service discovery (http://upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf)

- Content discovery (http://upnp.org/specs/av/UPnP-av-ContentDirectory-v3-Service.pdf, http://upnp.org/specs/av/UPnP-av-ContentDirectory-v3-Service-AnnexA-20101006.pdf)

- A/V connection management (http://upnp.org/specs/av/UPnP-av-ConnectionManager-v2-Service.pdf, http://upnp.org/specs/av/UPnP-av-ConnectionManager-v2-Service-AnnexA-20101006.pdf)

- A/V transport  (http://upnp.org/specs/av/UPnP-av-AVTransport-v2-Service.pdf, http://upnp.org/specs/av/UPnP-av-AVTransport-v2-Service-AnnexA-20101006.pdf)

3) A web application needs to determine if the user agent supports transport protocols and content formats for content presented in a web page or discovered over the home network. It appears that media.canPlayType(type)  can be used to query the user agent if it supports type, where type can come from the type attribute of the source element for HTML page content or can be generated from UPnP content res property information (Section B.2 and table B-5 of the content discovery reference above).  There is no method for determining what URI schemes (equivalent to UPnP transport protocol) are supported by the user agent. Rather than querying the user agent for each content type, and because a URI scheme method is required, a new interface, UserAgentCapabilities for example, could be defined and implemented by the (JavaScript) global object. The interface would define two methods, supportedMimeTypes() and supportedURISchemes(), which would return MIME types and URI schemes supported by the user agent.

It does not appear that HTML5 or other W3C API specs provide the functionality to meet requirements 1 and 2 above. Possible implementations that could meet these requirements are:

a) An API that exposes the referenced UPnP protocols.

b) A more general home networking API for user-agents that could support UPnP, Bonjour and other home networking protocols (this is the approach taken in the OpenCable Home Networking API spec (http://www.cablelabs.com/specifications/OC-SP-OCAP-HNEXT-I05-100603.pdf)

c) General, low-level networking tools, like WebSocket, upon which JavaScript could build UPnP, Bonjour or other home networking applications. 

More information regarding CableLabs OpenCable Home Networking can be found here http://www.cablelabs.com/specifications/OC-SP-HOST-HN2.0-I04-100507.pdf. More information on the W3C Web on TV workshop including the request for home networking APIs can be found here: http://www.w3.org/2010/09/web-on-tv/summary.html.

Thank you in advance for consideration of this proposal.

Bob Lund
CableLabs
b.lund@cablelabs.com
Comment 1 Bob Lund 2010-11-18 20:43:00 UTC
Here is so some additional information regarding a possible implementation to meet the requirement 1) and 2) in the proposal.

One implementation approach is to define a new UPnP user agent WebIDL (a portion of this has been implemented in a proof-of-concept):


// WebIDL for User Agent UPnP protocol

module core {
  interface [
    DelegatingGetOwnPropertSlot,    //various inherited functions required
    DelegatingPutFunction,
    .
    .
    .
  ] UPnP {
    // UPnP control point management

    //start control point
    [Custom] void startControlPoint();
	
    //stop control point
    [Custom] void stopControlPoint();

    //set call-back for discovery events
    [Custom] void addNotifyListener();
	
    //set call-back for search results
    [Custom] void addSearchResponseListener();
	
    //set call-back for evented variables
    [Custom] void addEventListener();
	
    //set call-back for device added or dropped
    [Custom] void addDeviceChangeListener();

    // Deivce, service and content discovery
	
    //find devices
    [Custom] void discoverDevices();
	
    //authentication for control of secure devices
    [Custom] void loginToDevice(in DeviceHandle deviceHandle, in DOMString password);
    
    //time before automatic logout
    [Custom] void getLoginTimeRemaining(in DeviceHandle  deviceHandle);
 	
    //identify services on each device	
    [Custom] void discoverServices(in DeviceHandle deviceHandle);
	
    //identify actions for each service
    [Custom] void discoverActions(in DeviceHandle deviceHandle, in ServiceHandle serviceHandle);
	
    //determine if a service is a RUI server service
    [Custom] void isRUIService(in DeviceHandle deviceHandle, in ServiceHandle serviceHandle);
	
    //determine if a service is a content directory service
    [Custom] void isContentDirectoryService(in DeviceHandle deviceHandle, in ServiceHandle serviceHandle);
	
    //search for content that meets the filtering criteria
    [Custom] void searchContent(in DeviceHandle deviceHandle, in ServiceHandle serviceHandle, in Filter filter);
	
    //traverse the content tree of a content directory service
    [Custom] void browseContent(in DeviceHandle deviceHandle, in ServiceHandle serviceHandle);
	
    //determine if a content item is of a particular type
    [Custom] void isContentType(in ContentHandle contentHandle, in ContentType contentType);
	
    //determine if a service is a connection management service
    [Custom] void isConnectionManagementService(in DeviceHandle deviceHandle, in ServiceHandle serviceHandle);
 
    // Determine protocols and media formats supported by devices

    //determine if a device supports a transport type
    [Custom] void isSupportedTransportType(in DeviceHandle deviceHandle, in TransportType transportType);
	
    //get a list of transport types supported by a device
    [Custom] void getSupportedTransportTypeList(in DeviceHandle deviceHandle);
	
    //determine if a content type is supported on a device
    [Custom] void isSupportedContentType(in DeviceHandle rendererDeviceHandle, in ContentType contentType);
	
    //get a list of supported content types for a device
    [Custom] void getSupportedContentTypeList(in DeviceHandle rendererDeviceHandle);

    // Control content playback

    //play a content item on a device
    [Custom] void play(in DeviceHandle deviceHandle, in ServiceHandle serviceHandle, in URI contentURI);
	
    //pause the content playing
    [Custom] void pause(in DeviceHandle deviceHandle, in ServiceHandle 
serviceHandle);
	
    //stop the content playing
    [Custom] void stop(in DeviceHandle deviceHandle, in ServiceHandle serviceHandle);
	
    //fastforward at a specified speed
    [Custom] void forward(in DeviceHandle deviceHandle, in ServiceHandle serviceHandle);
	
    //rewind at a specified speed
    [Custom] void rewind(in DeviceHandle deviceHandle, in ServiceHandle serviceHandle);
	
    //move the playback position
    [Custom] void seek(in DeviceHandle deviceHandle, in ServiceHandle serviceHandle, in int location);

    //UPnP attributes
    
    //current number of devices found
    Attribute [CustomSetter] DOMString numDevices;
	
    //device number for the current operation
    Attribute [CustomSetter] DOMString deviceNumber;
	
    //true if the list of devices found has changed
    Attribute [CustomSetter] DOMString isDeviceListChanged;
	
    //current number of content items found
    Attribute [CustomSetter] DOMString numContentItems;
	
    //content item number for the current operation (as needed)
    Attribute [CustomSetter] DOMString contentItem;
	
    //true if the list of available content items has changed
    Attribute [CustomSetter] DOMString isContentChanged;

    //list of current devices and embedded devices
    Attribute [CustomSetter] DOMString devicesTree;
	
    //list of services available on each device and embedded device
    Attribute [CustomSetter] DOMString servicesList;
	
    //list of actions available on each service
    Attribute [CustomSetter] DOMString actionList;
	
    //structure for security information
    Attribute [CustomSetter] DOMString securityInfo;
	
    //definition of RUI
    Attribute [CustomSetter] DOMString ruiDefinition;
	
    //list of current content items found
    Attribute [CustomSetter] DOMString contentTree;
  }
}
Comment 2 Ian 'Hixie' Hickson 2010-12-13 20:20:34 UTC
Standardisation is the last step one takes to do this kind of thing.

First, you need to research the use cases and requirements by discussing the issue with authors and implementors, on a public list (e.g. public-html@w3.org).

Then you need to come up with a clear description of the problem that needs to be solved, including any security issues. (For example, your description above doesn't discuss the problem of whether a Comcast customer should have his Comcast set-top box accessible to http://attacker.evil.example/, or whether only comcast.com should have access to it.)

Then, you discuss your problem proposal with authors and implementors. Read the responses. Listen to the feedback. Consider whether your ideas are good solutions to the use cases and requirements put forward. Discussions here should be done in public, e.g. on an archived public mailing list or documented in blogs.

Once the problem is well-established, you get implementors to commit to implementing the feature. If you can't get several implementors to implement the feature, then get at least one user agent to implement it experimentally. Experimental implementations should be publicly available.

Only once you have experimental implementations or a number of committed implementors, as well as a clear problem description, is it appropriate to consider the issue for standardisation. Even then, you will need to document the experience found from any implementations, the use cases and requirements that were found in the first step, the data that the design was based on, and so forth, as well as demonstrate the importance of the problem, and demonstrate that the solution is one that will be used correctly and widely enough for it to solve the stated problem.

Typically at this step the original design gets thrown out and a significantly better design is developed, informed by the previous research, new research, and implementation and author experience with experimental implementations. Sometimes, the idea is abandoned at this stage. Only after this is the spec updated.


EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Did Not Understand Request
Change Description: no spec change
Rationale: See above. Before this can be added to the platform's specifications, we need significantly more research and experimental implementation experience.
Comment 3 Michael[tm] Smith 2011-08-04 05:11:58 UTC
mass-move component to LC1