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

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

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

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

Regards, Cathy.