RE: DAP Request: Feedback on Applicability and implementation plans for Network Service Discovery

Hello,

I also participated in the HbbTV work on this topic, and just to be sure that everything is smooth I would like to emphasize on thing.
HbbTV is using UPnP mechanism for discovery. But this does not say much, since UPnP is covering a whole stack of technologies.
More precisely, HbbTV is using SSDP mechanism for network discovery.
HbbTV is defining one UPnP device and one UPnP service.
Then HbbTV stops using UPnP at the device description level.
This device description (the XML document) is enhanced with private extensions.

I read NSD spec, and I found what I imagine will be used to discover such private extensions: the "config" element, since for SSDP/UPnP it is said (in 8.2 within "The rule for processing a UPnP Device Description File"):
"2.7. Set network service record's config property to the string value of the contents of the first occurrence of the <device> element in the device descriptor file"

Do you confirm that my understanding is correct, i.e. that "config" is surfacing the XML document itself (the <device> part of it where the service is contained) ?

Thank you

Jean-Baptiste

-----Message d'origine-----
De : Rich Tibbett [mailto:richt@opera.com]
Envoyé : jeudi 17 avril 2014 11:55
À : Matt Hammond
Cc : Daniel Davis; public-web-and-tv@w3.org; Frederick.Hirsch@nokia.com; public-device-apis@w3.org; dom@w3.org
Objet : Re: DAP Request: Feedback on Applicability and implementation plans for Network Service Discovery

Hi Matt,

On Thu, Apr 17, 2014 at 9:09 AM, Matt Hammond <Matt.Hammond@bbc.co.uk> wrote:
> Hello,
>
> Regarding the last two of your questions:
>
> The BBC is participating in HbbTV's development of its 2.0 specification for
> TVs in Europe.
>
> We have been working to ensure CORS support is implemented by HbbTV 2.0
> devices for protocols that may be communicated with by companion devices
> across the home network.

It is good to see this being adopted in industry groups like HbbTV.
Adding CORS support is the _essential_ missing ingredient to bring
networked services and devices to the web. Without CORS there is no
way to communicate with networked services in the current web stack
due to same-origin policy restrictions (that CORS overrides).

> The ability to discover such devices from our web applications gives us more
> flexibility in delivering companion experiences so the NSD API is of
> interest to us.

Agreed. Once we have services and devices that are web-friendly (i.e.
expose CORS HTTP headers) then we will need a bootstrap mechanism for
discovering and connecting those services with web pages. That was
always the goal of the NSD API and the scope of that effort has always
been focused on providing such a bootstrap mechanism only. We can then
hand off to direct communication between web pages and networked
services through e.g. XMLHttpRequest and WebSocket APIs with the help
of CORS.

Making network services and devices accessible through XHR and/or
WebSockets with CORS is (almost) more important than whether the NSD
API gets commissioned in browsers at this stage. Kudos to HbbTV on
this effort and I hope other industry groups and device manufacturers
will adopt a similar approach to enable networked services/devices to
speak cross-origin with the web platform.

>
> Many thanks to those who have worked to progress it as far as it has done so
> far.

+1.

br/ Rich

>
>
> Regards
>
>
> Matt
>
>
>
> -----Original Message-----
> From: Daniel Davis [ddavis@w3.org]
> Sent: Thursday, April 17, 2014 07:58 AM GMT Standard Time
> To: public-web-and-tv@w3.org
> Cc: Frederick.Hirsch@nokia.com; public-device-apis@w3.org; dom@w3.org;
> richt@opera.com
> Subject: Re: DAP Request: Feedback on Applicability and implementation plans
> for Network Service Discovery
>
> Hello Web and TV IG members,
>
> Unfortunately there wasn't much time to discuss this on yesterday's call
> but we'd still like feedback to Frederick's questions below and your
> thoughts on the Network Service Discovery (NSD) API.
>
> For example:
> * What would be necessary to keep interest in the API going?
> * Are device manufacturers willing to support CORS in order to enable
> NSD support?
> * Are stakeholders willing to work with user agent vendors for
> implementation?
>
> and similar comments.
>
> Thank you in advance,
> Daniel
>
> On 10/04/14 04:58, Frederick.Hirsch@nokia.com wrote:
>> Dear Web & TV Interest Group Chairs and members:
>>
>> The Device APIs working group [1] has produced a "Network Service
>> Discovery" draft [2] in which the Web & TV Interest Group [3] has shown
>> interest [4].
>>
>> "This specification defines a mechanism for an HTML document to discover
>> and subsequently communicate with HTTP-based services advertised via common
>> discovery protocols within the current network."
>>
>> This allows a web page to discover and establish communication with
>> services on a local network. The specification takes into account Zeroconf,
>> SSDP and DIAL.  The specification does not define the application
>> communications once the connection is established.
>>
>> We are concerned that we will not have adequate implementer interest in
>> this specification to justify progressing it further [5][6][7], and are thus
>> wondering if the the Web & TV Interest Group, as a “customer” of
>> this work would be willing to work with us on obtaining implementers input
>> and feedback on this specification. Without proper interest from
>> implementers the Device APIs Working Group would have no other option than
>> to stop work on it.
>>
>> We are seeking feedback from the Web & TV Interest group and implementers
>> to the following questions:
>>
>> 1. Does this specification address use cases and needs of concern to you?
>>
>> 2. In particular, in light of the recent additional requirement of CORS
>> [8] support from local network services, it is likely that this
>> specification would only work with recently updated devices. Do you plan to
>> deploy CORS support in your UPnP/DIAL/Zeroconf based devices?
>>
>> 3. Are you working on implementations of this specification? If so, have
>> you determined whether these implementations are likely to find their way
>> into a well-deployed browser?
>>
>> 5. Can you provide any assistance in determining implementers plans, and
>> possibly work with implementers on providing input and feedback on the
>> future of this specification?
>>
>> Feedback you give us is important to DAP taking appropriate next steps and
>> will be much appreciated. Please send any comment to the DAP public list
>> (cc’d) , public-device-apis @ w3.org
>>
>> Thanks
>>
>> regards, Frederick
>>
>> Frederick Hirsch, Nokia, @fjhirsch
>> Chair Device APIs Working Group
>>
>> [1] http://www.w3.org/2009/dap/

>>
>> [2] http://www.w3.org/TR/2014/WD-discovery-api-20140220/

>>
>> [3] http://www.w3.org/2011/webtv/

>>
>> [4]
>> http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/att-0098/minutes-2011-07-20.html#item07

>>
>> [5]
>> http://lists.w3.org/Archives/Public/public-device-apis/2014Mar/att-0024/minutes-2014-03-27.html#item08

>>
>> [6]
>> https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/network$20service$20discovery/blink-dev/HT0KZKuTLxM/S3w-SdvjZfUJ

>>
>> [7] https://bugzilla.mozilla.org/show_bug.cgi?id=914579

>>
>> [8] http://www.w3.org/TR/cors/

>>
>> For tracker, this completes ACTION-687
>>
>
>
>
> ----------------------------
>
> http://www.bbc.co.uk

> This e-mail (and any attachments) is confidential and may contain personal
> views which are not the views of the BBC unless specifically stated.
> If you have received it in error, please delete it from your system.
> Do not use, copy or disclose the information in any way nor act in reliance
> on it and notify the sender immediately.
> Please note that the BBC monitors e-mails sent or received.
> Further communication will signify your consent to this.
>
> ---------------------

----------------------------------------- "Privileged/Confidential information may be contained in this e-mail and attachments. This e-mail, including attachments, constitutes non-public information intended to be conveyed only to the designated recipient(s). If you are not an intended recipient, please delete this e-mail, including attachments, and notify us immediately. The unauthorized use, dissemination, distribution or reproduction of this e-mail, including attachments, is prohibited and may be unlawful. In general, the content of this e-mail and attachments does not constitute any form of commitment by VIACCESS SA." -----------------------------------------

Received on Thursday, 17 April 2014 22:23:03 UTC