RE: [discovery-api] Draft spec updates

Comments inline...

richt@opera.com wrote:
>
> Hi Cathy,
>
> I've added my responses to your feedback in-line below.
>
> The latest specification with the changes described below is available @
> http://dvcs.w3.org/hg/dap/raw-file/tip/discovery-api/Overview.html
>
> Cathy.Chan@nokia.com wrote:
> > Below please find my comments on the updated spec.
> >
> > 1. At the beginning of Section 7, there's discussion on when the UA
> > might perform the service discovery mechanisms.
> > [[It is expected that user agents will perform these service discovery
> > mechansisms asynchronously and periodically update the list of
> > networked devices as required. The timing of any service discovery
> > mechanisms is an implementation detail left to the discretion of the
> > implementer (e.g. once on user agent start-up, every X seconds during
> > user agent execution or on invocation of this API from a Web page).]]
> > It's unclear to me what exactly "service discovery mechanism"
> > encompasses, especially in the UPnP case. Does it refer only to
> > issuing a search request for UPnP root devices? Or does it also
> > include the *continuous* monitoring of the standard UPnP address and
> > port for incoming requests and responses? To me, it doesn't make sense
> > for a UA to issue a search at start-up but not follow up by
> > continuously monitoring the standard address+port for new/updated
> > announcements and disconnection messages (byebye messages).
>
> Me neither.
>
> > Such an
> > implementation is bound to return either stale or useless information
> > to web pages on invocations of the getNetworkServices API as time goes
> by.
>
> It wouldn't be in anyone's interest to implement the service discovery
> mechanisms in this way. FWIW, "Service Discovery Mechanisms" is intended
> to encompass everything currently included in Section 7 of the 
> specification.
> I've included a definition to that effect in the specification.
>
> The text is written as-is since the exact strategy to obtain network service
> records is intended to be left up to the discretion of the implementer. The
> specification gives detailed descriptions of what to do with particular 
> service
> discovery protocols but is not prescriptive on exactly when things need to
> occur in any given strategy.
>
> I've re-worded this statement in the specification (and added a definition 
> of
> 'service discovery mechanisms'). If you have ideas for further improvements
> in this area of the specification that would be interesting.
>
I can live with that for now. :-)

> > This
> > also affects whether the definition of the list of available service
> > records as " track all the services that have been discovered and are
> > available in the current network *at any given time*" is accurate or not.
>
> I've updated this to 'at the current time'. The previous text could have 
> been
> implied to only apply to the continuous monitoring strategy.
>
Looks like you only updated this for the list of active service managers, but 
not the list of available service records.

> > Secondly, if the UA only performs discovery on invocation of the
> > getNetworkServices API, does it still issue the search looking for all
> > device types (using "_services._dns-sd._udp" with Zeroconf or
> > "upnp:rootdevice" with UPnP, as described in 7.1 and 7.2), or should
> > it issue the search based on the requested types?
>
> Since a search for all devices on the local network is going to yield a 
> super-set
> of the requested services, and since the current web page or another web
> page may re-invoke getNetworkServices at some point in the near future
> with an entirely different set of requested service types, I believe it 
> makes
> sense to issue more generic searches and for the UA to maintain a more
> holistic overview of the services available in the current network at all 
> times*.
>
It's true that a search for all devices would always yield the targeted 
devices that one is interested in, but the ability to initiate targeted search 
helps save resources on all entities involved, the UA, the local networked 
devices, and the local network as a whole.

> * Note the general caveat included in the spec: "Conformance requirements
> phrased as algorithms or specific steps may be implemented in any manner,
> so long as the end result is equivalent". If the result is equivalent (I get 
> the
> network services I asked for), the means is unimportant (how the UA has
> actually accumulated those records).
>
While I generally agree with the inherent flexibility in implementing the 
detailed steps, I'm not sure how an implementer is supposed to dissect the 
sentence below to determine which part is absolutely a must and which part has 
room for flexibility. (Note that this is not in an algorithm or a step either, 
so I'm not sure if the quoted caveat applies.)
[[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.]]
The way I read this: the UA must absolutely always issue search requests with 
(among other things) ST header equal to upnp:rootdevice, which would yield all 
UPnP devices on the local network. I would prefer that it says "equal to 
upnp:rootdevice or a valid UPnP service type", and then describe somewhere how 
a valid UPnP service type can be obtained the type parameter in the 
getNetworkServices API.

<snipping the responses and changes that look good to me>

> > 3.2. Step 4.3 is missing the necessary conditions: 1) if the new
> > service registration flag is set to false, 2) the id of the "network
> > service record" (i.e. the one being
> > added) matches that of the current active service object, and 3) the
> > online attribute of the current active service object was previously
> > false (before being replaced in step 2.3).
> > Both of these comments also apply to the rule for "removing an
> > available service".
>
> Good catch. I've added these in to the algorithm (now Step 4.2.3 in
'adding an
> available service' and Step 1.3.2.3 in 'removing an available service').
>
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.)

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.

> > 5. In 7.1, step 2.7, why is an expiration time of 120 seconds mandated? My
> > understanding is that DNS-SD/mDNS allows the expiration time to be
> specified
> > in either the PTR or TXT record. Even if it's not available from there, 
> > this
> > value should be left up to the implementation.
>
> 120 seconds is the default and servers shouldn't have any need to change
> this value. Having said this, I do intend to review the Zeroconf section
> in detail soon and allow services to set their own expiration times in
> an upcoming edit.
>
I'll await this update...

<snip>

> > 9. In 7.2, in the steps for processing HTTP Requests...
> > 9.1 In Step 1, s/return a HTTP 200 OK response,//.
>
> Done.
>
> > 9.2 Step 3 applies only to ssdp:alive messages. It should start with "If 
> > the
> > value of the NTS entry of the ssdp device is 'ssdp:alive'". Also, s/return 
> > a
> > 400 Bad Request response,//.
The first part of this comment has not been addressed. Written the way it
is, the algorithm would force the UA to discard all ssdp:byebye messages
because they don't contain CACHE-CONTROL and LOCATION entries.

*snip*

Some additional comments.
- in the rule for adding an available service, step 4 determines if the 
network service record is of a type that the service manager would be 
interested in (and hence whether the servicesAvailable attribute needs to be 
updated and the serviceavailable event be sent). It would be more accurate to 
simply compare the network service record's type attribute with the type 
attribute that was used in the getNetworkServices API to create the particular 
service manager object. Consider the case where the web page invokes 
getNetworkServices with two types (A and B). At the time of the invocation, 
two service records of type A were found but nothing of type B was found. The 
associated service manager object would therefore have two service records, 
both of type A, but it (or the web page) would certainly still be interested 
in being notified if a new service of type B do become available later on. 
With the current algorithm, when a new service of type B is found by the UA, 
the service manager would not be made aware of it.
- in the rule 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.

Regards, Cathy.