ISSUE-151: USN should not be used as device identifier

USN should not be used as device identifier

State:
CLOSED
Product:
Network Service Discovery
Raised by:
Cathy Chan
Opened on:
2013-09-06
Description:
In Section 8.2 Simple Service Discovery Protocol (SSDP), the USN is used as the device identifier in order to tie all UPnP services belonging to the same UPnP device together. The device identifier is used later to remove all services belonging to the same UPnP device when the UA finds out that a UPnP device is no longer available on the network.

The problem of using the full USN string as it appears in an SSDP message is that it can take on multiple formats depending on where the message originates from. The possible formats of the USN are:
- uuid:{device-UUID}
- uuid:{device-UUID}::upnp:rootdevice
- uuid:{device-UUID}::urn:{domain}:device:{deviceType}:{version}
- uuid:{device-UUID}::urn:{domain}:device:{serviceType}:{version}
where {device-UUID} is a unique identifier for that UPnP device, {deviceType} is the UPnP device type (if the message comes from a UPnP device), {serviceType} is the UPnP service type (if the message comes from a UPnP service).

As can be seen above, for different services under a UPnP device, the USN values would also be different, rendering the full USN value useless as a device identifier. One might be tempted to use the {device-UUID} portion of the USN value as the device identifier. However, complicating matters is the possible existence of embedded devices within a root (top-level) UPnP device. Each of these embedded devices would have their own device-UUID value (and services within embedded devices carry the device-UUID value of their immediate parent device). As such, the USN value, or part thereof, cannot be used as the device identifier.

A true device identifier that is the same for all services and embedded devices (and their respective services) under the same root UPnP device can be found in the <UDN> element of the root device description document.

Given the above, I propose the following changes in recording the device Id of a service:
1. In step 5 of "HTTP Response" processing, when invoking the rule for obtaining a UPnP Device Description File, pass in an empty string as the device identifier argument.
2. Similarly, in step 4 of "HTTP Request" processing, when invoking the rule for obtaining a UPnP Device Description File, pass in an empty string as the device identifier argument.
3. In "processing a UPnP Device Description File", add a step before step 1: If device identifier is an empty string, let device identifier be the value of the first occurrence of the <UDN> element in the device description file.
That would ensure that all services and embedded devices (and their services) all contain the same device identifier value - that of the root device, which comes from the UDN element of the root device description document.

For service removal, when a byebye message is received, it can be sent from the root device, a service under the root device, an embedded device, or a service under an embedded device. Only the first two would come with a USN value with a root-level device-UUID that readily matches the deviceId property of existing network service records. The latter two would come with an embedded device-UUID that would not match the deviceId property of any network service record. Thus, the device-UUID portion of the USN value cannot be used to locate services to be removed. Instead, it would be necessary to first locate a network service record that has the device-UUID (which could be root device UUID or an embedded device UUID) in its id property, look up its deviceId property (which is always a root device UUID), and then remove all other services that share the same deviceId.

Effectively, the required change is the following:
1. In the second part of step 4 in "HTTP Request" processing, the first occurrence of USN from ssdp device is still used as the argument, but that argument isn't technically the "device identifier argument". s/device identifier argument/USN argument". Similarly, in "removing all services from a registered UPnP Device", s/device identifier/USN.
2. The rule for "removing all services from a registered UPnP Device" needs to be overhauled:
1. Let root uuid be an empty string.
2. Let current uuid be the substring of the USN value from the beginning of the USN value up to and not including the first occurrence of "::", or the full USN value if it does not contain "::".
3. For each existing service record in the current list of available service records, run the following sub-steps:
1. If the existing service record's id property begins with the current uuid value then let root uuid be the deviceId property of the network service record. Continue to the step labeled Remove services below.
2. Continue at the next available existing service record.
4. If root uuid is an empty string then abort these steps.
5. Remove services: For each existing service record in the current list of available service records, run the following sub-steps:
1.If the existing service record's deviceId property does not match root uuid then skip any remaining sub-steps for the current existing service record and continue at the next available existing service record.
2.Run the general rule for removing an available service passing in existing service record's id property as the only argument.
Related Actions Items:
No related actions
Related emails:
  1. [admin] Agenda - Distributed Meeting 15 May 2014 (from frederick.hirsch@nokia.com on 2014-05-12)
  2. [admin] Agenda - Distributed Meeting 27 March 2014 (from Frederick.Hirsch@nokia.com on 2014-03-27)
  3. [admin] Agenda - Distributed Meeting 20 March 2014 (from Frederick.Hirsch@nokia.com on 2014-03-19)
  4. [admin] Cancel teleconference 6 March, next call 20 March (from Frederick.Hirsch@nokia.com on 2014-03-05)
  5. Re: [admin] Agenda - Distributed Meeting 27 February 2014 (from dom@w3.org on 2014-02-27)
  6. [admin] Agenda - Distributed Meeting 27 February 2014 (from Frederick.Hirsch@nokia.com on 2014-02-26)
  7. [admin] Agenda - Distributed Meeting 20 February 2014 (from Frederick.Hirsch@nokia.com on 2014-02-18)
  8. [admin] Agenda - Distributed Meeting 13 February 2014 (resend corrected date) (from Frederick.Hirsch@nokia.com on 2014-02-13)
  9. [admin] Agenda - Distributed Meeting 12 February 2014 (from Frederick.Hirsch@nokia.com on 2014-02-13)
  10. [admin] Agenda - Distributed Meeting 6 February 2014 (from Frederick.Hirsch@nokia.com on 2014-02-05)
  11. Regrets: [admin] Agenda - Distributed Meeting 30 January 2014 (from dom@w3.org on 2014-01-29)
  12. [admin] Agenda - Distributed Meeting 30 January 2014 (from Frederick.Hirsch@nokia.com on 2014-01-28)
  13. [admin] Agenda - Distributed Meeting 16 January 2014 (from Frederick.Hirsch@nokia.com on 2014-01-15)
  14. [admin] Agenda - Distributed Meeting 9 January 2014 (from Frederick.Hirsch@nokia.com on 2014-01-08)
  15. [admin] Agenda - Distributed Meeting 12 December2013 (from Frederick.Hirsch@nokia.com on 2013-12-11)
  16. Re: [admin] Agenda - Distributed Meeting 21 November 2013 (from jean-claude.dufourd@telecom-paristech.fr on 2013-11-21)
  17. [admin] Agenda - Distributed Meeting 21 November 2013 (from Frederick.Hirsch@nokia.com on 2013-11-21)
  18. Agenda - Distributed Meeting 7 November 2013 (Thursday) (from Frederick.Hirsch@nokia.com on 2013-11-05)
  19. [admin] Minutes 31 Oct 2013 (updated) (from Frederick.Hirsch@nokia.com on 2013-11-04)
  20. [admin] Minutes 31 October 2013 teleconference (from Frederick.Hirsch@nokia.com on 2013-10-31)
  21. Re: Agenda - Distributed Meeting 31 October 2013 (Thursday) (from jean-claude.dufourd@telecom-paristech.fr on 2013-10-29)
  22. Agenda - Distributed Meeting 31 October 2013 (Thursday) (from Frederick.Hirsch@nokia.com on 2013-10-28)
  23. Re: Agenda - Distributed Meeting 17 October 2013 (Thursday) (from jean-claude.dufourd@telecom-paristech.fr on 2013-10-17)
  24. Re: Agenda - Distributed Meeting 17 October 2013 (Thursday) (from dom@w3.org on 2013-10-17)
  25. Agenda - Distributed Meeting 17 October 2013 (Thursday) (from Frederick.Hirsch@nokia.com on 2013-10-17)
  26. Agenda - Distributed Meeting 10 October 2013 (Thursday) (from Frederick.Hirsch@nokia.com on 2013-10-10)
  27. Draft minutes today 3 October 2013 (from Frederick.Hirsch@nokia.com on 2013-10-03)
  28. Agenda - Distributed Meeting 3 October 2013 (Thursday) (from Frederick.Hirsch@nokia.com on 2013-10-02)
  29. Minutes 26 Sept 2013 (from Frederick.Hirsch@nokia.com on 2013-09-26)
  30. Agenda - Distributed Meeting 26 Sept 2013 (Thursday) (from Frederick.Hirsch@nokia.com on 2013-09-26)
  31. Agenda - Distributed Meeting 19 Sept 2013 (Thursday) (from Frederick.Hirsch@nokia.com on 2013-09-18)
  32. Cancel DAP call this week, meet next Thursday 19 Sept; pls work on ISSUES and ACTIONS on mail list (from Frederick.Hirsch@nokia.com on 2013-09-10)
  33. DAP-ISSUE-151: USN should not be used as device identifier [Network Service Discovery] (from sysbot+tracker@w3.org on 2013-09-06)

Related notes:

No additional notes.

Display change log ATOM feed

Anssi Kostiainen <anssi.kostiainen@intel.com>, Reilly Grant <reillyg@google.com>, Chairs, Fuqiao Xue <xfq@w3.org>, Staff Contact
Tracker: documentation, (configuration for this group), originally developed by Dean Jackson, is developed and maintained by the Systems Team <w3t-sys@w3.org>.
$Id: 151.html,v 1.1 2019/11/08 08:58:10 carcone Exp $