W3C home > Mailing lists > Public > public-device-apis@w3.org > September 2013

DAP-ISSUE-131: A proposal for supporting UnP Device discovery

From: Igarashi, Tatsuya <Tatsuya.Igarashi@jp.sony.com>
Date: Tue, 17 Sep 2013 17:02:30 +0900
To: "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-ID: <DAB1CC3FAB54D3438F667F8E7B7599A202158657F49A@JPTKYXMS218.jp.sony.com>
Hi folks,

I have talked with Cathy about DAP-ISSUE-131. The following is our proposal for supporting UPnP device discovery.

This proposal does not change the common Interface, but minimally changes the protocol specific section, 8.2 Simple Service Discovery Protocol (SSDP). This proposal enables a web application to discover a UPnP device and obtain the content of UPnP device description to control it as defined in UPnP[1].

Our position is that UPnP device is “network service” as well as mDNS service. As defined in UPnP [1], UPnP device is designed as a container of UPnP services because of function modulatility and the word “Device” is used because it is easily recognizable by human users. The <friendlyName> property of UPnP device is usually used to recognize a physical device. which provides the network service. For the same purpose. the <Instance> name property of mDNS SRV record [2] is recommend to be a user-visible, user-friendly name, such as "Stuart's Printer".

[1] http://upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf
[2] http://tools.ietf.org/html/rfc6763#section-4.1.1

In addition, we propose to add the following clarification on “network service” in the section of terminologies.

Network service: A network service is a software system designed to support interoperable machine-to-machine interaction over a network.

*Note that I referred to the following words in the W3C glossy.
http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/#webservice

Thank you.

---- from here, the proposal for changes (The changes are red-colored) -------------------------------------
8.2 Simple Service Discovery Protocol (SSDP)

A user agent that implements UPnP device and service discovery MUST issue a search request for UPnP root devices against the user's current local network according to the full normative text and timing provided in 'Section 1.3.2: Search request with M-SEARCH' detailed in [UPNP-DEVICEARCH11<https://dvcs.w3.org/hg/dap/raw-file/tip/discovery-api/Overview.html#bib-UPNP-DEVICEARCH11>].

<!-- text as is -->

3.     Run the rule for processing a UPnP Device Description File, passing in the device descriptor URL, the current device descriptor file, device identifier and device expiry arguments.

<!-- text as is -->

The rule for processing a UPnP Device Description File is the process of parsing the contents of a standard UPnP Device Description [UPNP-DEVICEARCH11<https://dvcs.w3.org/hg/dap/raw-file/tip/discovery-api/Overview.html#bib-UPNP-DEVICEARCH11>] and registering the UPnP device and services contained therein within the list of available service records<https://dvcs.w3.org/hg/dap/raw-file/tip/discovery-api/Overview.html#dfn-list-of-available-service-records>

The rule for processing a UPnP Device Description File<https://dvcs.w3.org/hg/dap/raw-file/tip/discovery-api/Overview.html#dfn-processing-a-upnp-device-description-file> takes four arguments - device descriptor URL, device descriptor file, device identifier and device expiry - and when called the user agent MUST run the following steps:

1.     Let base URL be the base URL of the device descriptor URL. If the string value of the first occurrence of the <URLBase> element obtained from the device descriptor file is not empty, set base URL to the string value of the <URLBase> element.

2.     Let advertised services be a list of all advertised services obtained from the device descriptor file containing the value of the first occurrence of the <serviceList> element as it is defined in 'Section 2.3: Device Description' in [UPNP-DEVICEARCH11<https://dvcs.w3.org/hg/dap/raw-file/tip/discovery-api/Overview.html#bib-UPNP-DEVICEARCH11>].

3.     For each <service> element - known as an advertised service - in advertised services run the following steps:

1.     Let network service record be a new Object consisting of the following empty properties: id, deviceId, name, type, url, eventsUrl, config, expiryTimestamp.

2.     Set network service record's id property to the concatenated string value of the first occurrence of the <UDN> element in the device descriptor file with the advertised service's <serviceId> sub-element.

3.     Set network service record's deviceId property to the value of device identifier.

4.     Set network service record's name property to the string value of the first occurrence of the advertised service's <serviceId> sub-element.

5.     Set network service record's type property to the concatenation of the string upnp: followed by the string value of the first occurrence of the advertised service's <serviceType> sub-element.

6.     Set network service record's url property to the string value of the first occurrence of the advertised service's <controlURL> sub-element.

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.

8.     If advertised service's <eventSubURL> sub-element is not empty, then set network service record's eventsUrl property to the string value of the first occurrence of the advertised service's <eventSubURL> sub-element. Otherwise, do not set network service record's eventsUrl property.

9.     Set network service record's expiryTimestamp property to the value of the current date, in UTC timestamp format, plus the value of device expiry.

10.   Run the general rule for adding an available service<https://dvcs.w3.org/hg/dap/raw-file/tip/discovery-api/Overview.html#dfn-adding-an-available-service>, passing in the current network service record as the only argument.

4.    Let an advertised service be the first occurrence of the <device> element as it is defined in ‘Section 2.3: Device Description’ in [UPNP-DEVICEARCH11<https://dvcs.w3.org/hg/dap/raw-file/tip/discovery-api/Overview.html#bib-UPNP-DEVICEARCH11>].

1.    Let network service record be a new Object consisting of the following empty properties id, deviceId, name, type, url, config, expiryTimestamp

2.     Set network service record's id property to the string value of the first occurrence of the <UDN>  sub-element.

3.     Set network service record's deviceId property to the value of device identifier.

4.     Set network service record's name property to the string value of the first occurrence of the <friendlyName> sub-element.

5.     Set network service record's type property to the concatenation of the string upnp: followed by the string value the first occurrence of the <deviceType> sub-element.

6.     Set network service record's url property to the value of base URL.

7.     Set network service record's config property to the string value of the contents in the device descriptor file.

8.     Set network service record's expiryTimestamp property to the value of the current date, in UTC timestamp format, plus the value of device expiry.

9.     Run the general rule for adding an available service<https://dvcs.w3.org/hg/dap/raw-file/tip/discovery-api/Overview.html#dfn-adding-an-available-service>, passing in the current network service record as the only argument.
5. If device descriptor file contains a <deviceList> element then for each <device> element within <deviceList> - herein known as an embedded device descriptor file - the user agent MUST run the rule for processing a UPnP Device Description File<https://dvcs.w3.org/hg/dap/raw-file/tip/discovery-api/Overview.html#dfn-processing-a-upnp-device-description-file>, passing in the current embedded device descriptor file as the device descriptor file argument, along with the current device identifier and device expiry arguments.
-------------------------- ended here -------------------------------------------

-***---***---***---***---***---***---***---***---***--***---***---***-
Tatsuya Igarashi (Tatsuya.Igarashi@jp.sony.com<mailto:Tatsuya.Igarashi@jp.sony.com>)
Information Technology Development Div, R&D Platform
Sony Corporation
Received on Tuesday, 17 September 2013 08:03:09 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:00 UTC