Re: [discovery-api] Comments A3, A4, A7 (was: [discovery-api] Consolidated comments and questions)

Cathy.Chan@nokia.com wrote:
>>> A. Technical comments on the current draft
>>> 3. Unnecessary requirement on UA to issue UPnP search requests with
>>> search target of "upnp:rootdevice". From Cathy [4], [6]:
>>> In the introductory text of 7.2 Simple Service Discovery Protocol,
>>> [[The user agent must issue all search requests for UPnP root devices
>>> with a HTTP request line equal to M-SEARCH * HTTP/1.1, with a HOST
>>> header equal to the reserved multicast address and port of
>>> 239.255.255.250:1900, a MAN header equal to ssdp:discover, an ST
>>> header equal to upnp:rootdevice and a user-agent defined MX header
>>> equal to a maximum UPnP advertisement response wait time value
>> between
>>> 1 and 5 seconds.]] This requires UAs to always issue search requests
>>> for "upnp:rootdevice".
>>> However, in cases where the UA invokes a search in response to a call
>>> to
>>> getNetworkServices() with a particular UPnP service type, the UA
>>> should be allowed to issue a search with the requested search target
>>> instead of the much broader "upnp:rootdevice" one. This would cause
>>> only the targeted services to respond (as opposed to all services
>>> responding and leaving it to the UA to filter out those that do not
>>> match).
>> Agreed and I've updated the specification accordingly:
>>
>> https://dvcs.w3.org/hg/dap/rev/7639401e21f4
>
> "The user agent must also send an ST header with this HTTP request equal to
> the String value of ssdp:all or upnp:rootdevice or a single valid service
> type token." A valid service type token includes the leading "upnp:" string
> introduced by this spec and is not a valid UPnP search string. The UA would
> need to strip the "upnp:" part before using the token as a search string.
> (Additionally, a valid service type by definition can also be a token
> beginning with "zeroconf:" or "dial :", which should not be used here.)

I've updated the specification with this clarification: 
https://dvcs.w3.org/hg/dap/diff/8621c3c1faf5/discovery-api/Overview.src.html

>>> 4. Simplify algorithm for "adding an available service"? From Cathy [6]:
>>> [[Actually looking at the algorithm again, step 4.2.3 should be
>>> performed when the new service registration flag is *true*. In the
>>> case that the flag was false, the service was already in the list of
>>> available service records, meaning it must have already been online
>>> (by definition of the list of available service records). Thus, all
>>> the corresponding NetworkService objects within each NetworkServices
>>> object would also have had the online attribute set to true. There
>>> would be no need to change their online attributes and no need to
>>> dispatch the serviceonline events. On the other hand, in the case that
>>> the new service registration flag is true, and a matching service
>>> record is found in the service manager, the service must have been
>>> previously discovered, the service record removed from the list of
>>> available service record (because it went offline), and was retained
>>> in the service manager and marked as offline (per step 1.3.2.3 in
>>> 'removing an available service'). Now that the service is back online,
>>> the matching record in the service manager needs to be marked as
>>> online and the serviceonline event be dispatched. (Note also that the
>>> condition that the online attribute was previously false is
>>> unnecessary, as it must always be the case.)
>> I had to read this around 10 times but finally I figured it out ;)
> Trust me. I re-read and re-wrote that even more times. Too bad you still
> ended up needing 10. :-)
>
>> I've updated the spec with changes to the algorithms as suggested:
>>
>> https://dvcs.w3.org/hg/dap/rev/bc1d9819cad3
>>
>>> Furthermore, since steps 3 and 4 both apply only when the new service
>>> registration flag is true, one can simplify the algorithm by aborting
>>> at the end of step 2.3 (where an existing service record is found in
>>> the current list of available service records). In fact, the new
>>> service registration flag is not even needed at all, simplifying this
>>> even more.]]
>> I've incorporated this in to the commit provided above.
>
> Is Step 3.1.1, which essentially applies only to services that were
> previously already online, really necessary? Put another way, is it
> necessary for the serviceonline event to be fired when a service renews its
> service registration (as described in Section 8), or should it only be fired
> when a service goes from offline to online? I can't see how a web app would
> benefit from knowing that an online service has renewed its registration.

Agreed. When the online attribute is currently false however, it does 
make sense. I clarified this in the spec: 
https://dvcs.w3.org/hg/dap/diff/38bf34c08d76/discovery-api/Overview.src.html

>
>>> 7. From Cathy [6]: In 7, in the steps for removing an available
>>> service, step
>>> 2 attempts to unsubscribe from existing UPnP events subscriptions.
>>> However,
>>> event
>>> subscription is done once per each *authorized* service, i.e. per
>>> NetworkService object instances in service manager objects, and not
>>> per instance of the service record in the list of available service
>>> records. Thus step 2 should be a sub-step of 3.2.3.
>> I've made a few structural changes to how this algorithm is laid out that
>> hopefully resolves this issue:
>>
>> https://dvcs.w3.org/hg/dap/rev/89d1cef16d35
>>
> Unfortunately not.

Aww...

> UPnP un-subscription is still done per instance of the
> service record, whereas it should be per instance of active manager. So,
> step 1.4 should be part of step 1.3.4.

The current algorithm checks whether the events subscription is in use 
in any other active NetworkService object. If it is then it is not 
terminated. If it isn't then it is terminated. That termination happens 
at a global level and we only maintain one events subscription to a UPnP 
service shared between all relevant NetworkService objects.

The issue may be in the setup of a UPnP Events Subscription. I'd prefer 
if we were maintaining only one UPnP Events Subscription per service 
rather than one subscription per active service object. That might mean 
changing Step 13.2 of the getNetworkServices() algorithm to check 
whether a subscription to this service already exists. If not then we 
should create a new one otherwise we can bind to the already existing 
events subscription.

Could we do this? Other thoughts?

> Additionally, do we need to mention somewhere explicitly that the
> subscription ID needs to be recorded while setting up events subscription in
> order for it to be available for terminating the events subscription?

Well we do have "A user agent can terminate an existing UPnP Events 
Subscription at any time for a network service record by sending an HTTP 
UNSUBSCRIBE request - as defined in 'Section 4.1.4: Cancelling a 
subscription with UNSUBSCRIBE' in [UPNP-DEVICEARCH11] - with... a SID 
header set to the callback ID obtained when the initial setup a UPnP 
Events Subscription action occurred."

As an internal variable this may be sufficient prose. If you don't send 
this ID in a UPnP Event subscription cancellation request then its 
simply not going to work.

- Rich

Received on Friday, 8 February 2013 15:11:29 UTC