RE: about high-level or low-level API (ISSUE-17)

Hello Clarke,

 

1.       Allowing a UA to send arbitrary messages on the HomeNetwork
creates a security exposure. In order to "enforce" some kind of security
model the UA needs to know what kind of device its talking to. A UPnP
framework would need to enforce this by doing partial discovery (only
basic type information about a device) unless the webpage provides the
UA a password to access that device. This requires some predefined
knowledge of the HN protocols being used.

 

2.       How does the HN specific code get installed on a UA. Is it
built in? How does a web-page determine what (built-in) HN Technologies
a particular UA supports? Is a UA allowed to dynamically load
"plugin-like" HN access code? How is this done in a browser neutral way?

 

3.       In terms of access to UA platform functions, I was talking
about something that converts a UA into a HN server (rather than a
client). An example would be a webpage that allows a UA to expose some
part of its underlying file-system to other UAs. This would typically be
done by running a webserver and supplying the necessary PHPs. However,
I think we are looking for an all-in-the-box solution that allows a UA
to do this without installing a webserver and PHPware.

 

4.       Is there a requirement for a "sandbox" mode where a suspect
webpage could be restricted in its access to HN protocols. This would
again require some knowledge of what the webpage was trying to do on the
HN rather than allowing generic access.

 

Regards,

Russell Berkoff

Samsung

 

From: Clarke Stevens [mailto:C.Stevens@CableLabs.com] 
Sent: Wednesday, June 15, 2011 3:55 PM
To: Russell Berkoff; Bob Lund; Jean-Claude Dufourd;
public-web-and-tv@w3.org
Subject: RE: about high-level or low-level API (ISSUE-17)

 

Russell,

 

Let me address your points below. I've done some prototyping on this, so
I have a pretty good idea of at least one way to do it.

 

-Clarke

 

From: public-web-and-tv-request@w3.org
[mailto:public-web-and-tv-request@w3.org] On Behalf Of Russell Berkoff
Sent: Wednesday, June 15, 2011 4:33 PM
To: Bob Lund; Jean-Claude Dufourd; public-web-and-tv@w3.org
Subject: RE: about high-level or low-level API (ISSUE-17)

 

Hello,

 

I'm guess I'm confused on a number of accounts:

 

1.  How does a "generic" discovery framework address the needs of
existing ecosystems with existing and well established discovery and
network protocols.

>>The "browser" (integrated, plug-in, applet, etc.) can send and receive
messages that are reduced to strings. The logic of how these messages
are handled can be done at the JavaScript layer. In our experiments we
can do this with APIs that work for both UPnP and ZeroConf (Bonjour).

2.  How does a UA support one (or more) of the existing HomeNetwork
standards? I thought (an) objective of HTML5 was to eliminate the need
for browser-specific plug-in modules? 

>>It's impossible to implement a specific protocol without defining that
protocol on some level. One way to do this is to have a generic class
that implements a generic interface and derive protocol specific
subclasses from that to do the actual implementations.

3.  How does a UA (in particular one that provides Device/File services)
connect to platform devices and files? I suspect that the demands for
metadata storage alone would greatly exceed what is anticipated in
WebStorage.

>>You don't need to read everything at once. You can limit (e.g. through
a hierarchical interface or limiting the number of displayed items) the
user interface to something that is manageable in the available memory
space.

4.  How would generic UA network access services to do discovery and
commanding be secure? In theory any webpage/plugin code could "hijack" a
UA causing security and privacy issues.

>>Security is relative. Having said that, an authenticated application
from a trusted source using the security features of the specific
protocol or link-level security are tools we can use to increase the
relative security level.

 

I think it would be helpful if the IG focused more on deriving
real-world requirements. If anything the discussion seems to indicate
that the high-level requirements in ISSUE-17 may result in additional
requirements on the UA platform to provide the necessary support for
HNTF access methods for currently deployed HNTF network technologies. I
would suggest the IG address these items.

 

>>I strongly agree that we need to work with existing protocols and the
accomplishment of this objective is a key measure of the success of
HNTF. Fortunately, the low-level solution does not preclude the
high-level solution. Specification of the high-level solution brings
additional challenges in abstracting protocols with different approaches
and assumptions. I think this is something that we need to consider, but
I think the group can provide the simpler and more general solution in
the meantime.

 

Regards,

Russell Berkoff

Samsung

 

 

-----Original Message-----
From: public-web-and-tv-request@w3.org
[mailto:public-web-and-tv-request@w3.org] On Behalf Of Bob Lund
Sent: Tuesday, June 14, 2011 9:54 AM
To: Jean-Claude Dufourd; public-web-and-tv@w3.org
Subject: RE: about high-level or low-level API (ISSUE-17)

 

 

 

> -----Original Message-----

> From: public-web-and-tv-request@w3.org [mailto:public-web-and-tv- 

> request@w3.org] On Behalf Of Jean-Claude Dufourd

> Sent: Tuesday, June 14, 2011 10:10 AM

> To: public-web-and-tv@w3.org

> Subject: about high-level or low-level API (ISSUE-17)

> 

> Dear all,

> 

> I want to ask my question again in writing, because I did not get an 

> answer during the call and yet I think we need to answer it in order 

> to know what to do with ISSUE-17.

> What is the intent of ISSUE-17 ?

> Is it to standardize a list of API calls, the first of which (in the

> text) being "list discoverable home network media servers" ?

> Or is it to standardize a generic messaging API, and check that 

> everything listed in ISSUE-17 is possible ?

> This actually applies to more than just ISSUE-17

> 

> If it is the first, then it is meaningful to discuss ISSUE-17 in 

> detail, bullet by bullet. So we would need a lot of telco time.

> If it is the second, then I believe it is not meaningful to discuss

> ISSUE-17 bullet by bullet, but just keep the list for later validation


> of the standard. If so we should not have spent as much time on it in 

> today's telco.

> 

> Then my opinion on this subject is that we should only standardize a 

> small, low-level API for generic messaging, and not a very large set 

> of high-level messages that would never be up-to-date in the rapidly 

> evolving ecosystem of the home network.

> We should definitely design a standard that allows a document to call 

> any of the UPnP/DLNA services mentioned in ISSUE-17, but does not 

> duplicate the UPnP/DLNA service interfaces.

 

I agree with this. In addition to the issue of staying up to date, some
home networking technologies do not standardize the semantics of a
particular service interface, DNS-SD for example. There is a general
discovery mechanism and a generic syntax for exchanging messages but the
contents of the message are specific to the service. Exposing a service
specific API in the user agent then implies the user agent has service
specific knowledge. Clearly this does not scale.

 

I think the best course of action is to start with a generic API that
focuses on service discovery and a generic message passing and event
mechanism. As the industry gets experience with this, it may become that
higher level APIs would be appropriate. JavaScript functions could be
defined to provide a home network technology specific interface if that
is felt to be valuable.

 

Bob

> Best regards

> JC

> 

> --

> JC Dufourd

> Directeur d'Etudes/Professor

> Groupe Multimedia/Multimedia Group

> Traitement du Signal et Images/Signal and Image Processing Telecom 

> ParisTech, 37-39 rue Dareau, 75014 Paris, France

> Tel: +33145817733 - Mob: +33677843843 - Fax: +33145817144

>