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

> -----Original Message-----
> From: ext Rich Tibbett [mailto:richt@opera.com]
> Sent: Friday, February 08, 2013 10:11 AM
> To: public-device-apis@w3.org
> Subject: 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
> 
That works for me.

> >>> 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
> 
Ha! I actually overlooked the case of the online attribute being currently
false in my original comment, when I proposed aborting the algorithm at Step
1.2. Now, to accommodate this case, instead of always aborting at Step 1.2,
we should only abort at Step 1.2 if the online attribute of the existing
service record was already true, as nothing (updating online attribute,
dispatching serviceonline or serviceavailable events) needs to be done. On
the other hand, if the online attribute of the existing service record was
false, continue to Step 3 to update the online attribute of corresponding
service records in active service managers, dispatch serviceonline events to
those service records, and dispatch serviceavailable events to the relevant
active service managers.

> >
> >>> 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.
> 
Ok. This does make sense.

> 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?
> 
Instead of changing Step 13.2 of the getNetworkServices() algorithm, I would
suggest modifying the "Setup a UPnP Events Subscription" algorithm to
perform the checking. If there is already an ongoing subscription, all the
UA needs to do is to add the service record to the list of event recipients.
The listening step then needs to be modified to dispatch the notify event to
each of these service records.
Do we need a mechanism to "Remove a UPnP Events Subscription" when a service
record object is being garbage collected? (I understand that "Terminate an
Existing UPnP Events Subscription" is for the case that the networked
service disappears from the network and hence serves a different purpose.)

- Cathy.

> > 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