RE: [discovery] Comments/Questions on Network Service Discovery

I'll bite and chime in on some of these comments/questions. See inline.
- Cathy.

> -----Original Message-----
> From: Hirsch Frederick (Nokia-CIC/Boston)
> Sent: Wednesday, August 07, 2013 8:07 PM
> To: public-device-apis@w3.org
> Cc: Hirsch Frederick (Nokia-CIC/Boston)
> Subject: [discovery] Comments/Questions on Network Service Discovery
> 
> I have some questions/comments on the latest network service discovery
> editors draft , https://dvcs.w3.org/hg/dap/raw-file/default/discovery-
> api/Overview.html
> 
> General Comments
> 
> (1) Should we limit service discovery mechanisms in the core specification?
> 
> At a high level, what is the criterion for including service discovery
> mechanisms?
> 
> will it be feasible to interop test all of them to move the specification forward?
> 
> How hard will it be to  maintain the specification relative to the evolving
> status of some of them, such as DIAL?
> 
> Would it make sense to have separate specifications for some of the
> discovery mechanisms, beyond SSDP and Zeroconf?
> 
> For example, is DIAL well adopted or currently an exploratory effort?
> 
I agree with the sentiment here. We need to agree on the criteria for which service discovery mechanisms are included in the spec. SSDP and Zeroconf are well established and deployed to warrant inclusion. I'm far more skeptical about DIAL. Maybe what we should do is turn this spec into a framework that's generic enough that in the future we would be able to add extensions to the spec to support other service discovery mechanisms, much like what we did with Web Intents and the Pick Contacts and Pick Media extensions. Short of that, we should at least leave enough room for possible extension. For instance, currently the spec dictates that the service type has to be "zeroconf:", "upnp:" or "dial:". There should be a provision for other types to be defined in the future.

> (2) The  NetworkServices and NetworkService are core and probably warrant
> definition in the terminology section, section 3. I offer a proposal:
> 
> "A Network Service" object records information about a network service that
> has been discovered on the local network, is allowed by the user agent (for
> security or other reasons) and  that the user has granted permission for a
> specific web site origin to access. A "Network Services" object is a collection
> of Network Service objects, all of which are available services accessible for a
> specific web origin and approved by the user. User approval may be by dialog,
> preference setting or some other means defined by the UA."
> 
> I would place that before "In this specification"
> 
> also maybe we can update the definition of "existing service" to make it clear
> that only user approved services for the page should be included, to protect
> privacy:
> 
> 	* An existing service is a Local-networked Service, represented by a
> NetworkService object, that has previously been discovered and is
> registered in the list of available service records.
> 
> Add at the section end:
> 
> "Neither an existing nor a current service may be shared with a web page
> without user approval since that was required to create the NetworkService
> object representation."
> 
An existing service is one that is on the local network and that the UA knows about, but is not necessarily known to a web page. Once the user approves it, it becomes a "current service". The only thing that a web page would know about an existing service (before user grants permission) is that "one exists". No further information is leaked to the page. Also, an existing service exists only internally within the UA, and is not necessarily represented as a NetworkService object. Thus I don't think these clarifications on existing service are necessary (or entirely accurate).

> (3) For clarity, should we change the terminology from 'Valid service type' to
> 'valid service name", since it really seems to be naming?; might be clearer
> 
"service type" is the terminology used in UPnP (where "service name" means something else), while "service name" is the terminology used in Zeroconf. Sticking with "service type" might be a little less confusing (at least for those familiar with UPnP).

> (4) I notice if you print the specification then the boxes around the examples
> disappear and the statement that the box contents is non-normative does
> not really make sense, also this would probably not be accessible since it
> requires visible formatting. Perhaps change to mark summaries with a
> summary section and text stating that the summary is not normative, (or just
> let it be normative and make sure the section is consistent)
> 
> Detailed comments
> 
> 1. Introduction
> 
> "Using this API consists of requesting a well-known service type"
> 
> what makes a service type "well-known"? Is there a registry? How does the
> reader learn what is well-known?
> 
For UPnP, well-known service types generally refer to those that are standardized by UPnP Forum (http://upnp.org/sdcps-and-certification/standards/sdcps/) and possibly other industry consortia.

For Zeroconf, I believe a registry is maintained by IANA. http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml

With both mechanisms, vendors can create their own service types/names and use them for discovery. Personally, I think it's onerous to restrict the use of this API to well-known service types. As long as a web page understands how to use a service, it should be allowed to use this API to look for proprietary services. I would suggest changing "well-known service type" to "well-formatted service type". 

> 4.1 Methods
> 
> Step 9, sub-step 1, "For each requested control type in requested control
> types: If ... continue at the step labeled attach below."
> 
> Could there be more than one match, so is jumping to attach on the first one
> found appropriate? Maybe it is implicit that following step 3 continue with
> step 1 until no more, if so maybe that should be clarified.
> 
Since each "available service" has only one service type to be matched against the list of requested control types, there is by definition at most one match. So it's correct to stop looking after finding a match.

> Step 11: How is prior-permission given by the user? How will we test this
> MUST NOT (not that I argue against user control, and if this were removed
> then the final requirement in the requirements section would not be met)
> 
> Step 22: Which URL value is added to whose whitelist? The URL of the
> discovered service added to the whitelist for the web page, as maintained by
> the UA?
> 
Maybe s/the url property/its url attribute value/ to make it clearer?

> Section 5.1 Obtaining Networked Services; Attributes
> 
> Is servicesAvailable limited on a web page origin basis, what prevents privacy
> leakage across web pages by seeing which services might be available (oh,
> Rich as an 'abc TV' etc)
> 
servicesAvailable is a count of services that are available on the network and contains no details of those services. The maximum leakage would be "oh, Rich has a device that can stream media", not the specific device model (or even whether it's a physical TV or an app running on a PC).

>  Section 7, Discovery
> 
> States in p3 "It is expected that user agents will perform these service
> discovery mechanisms asynchronously and periodically update the list of
> available service records as required."
> 
> Should this be
> 
> "User agents SHOULD perform these service discovery mechanisms
> asynchronously and periodically update the list of
> available service records as necessary."
> 
> it is not clear what "it is expected" means, and who expects it.
> 
Agreed.

> Section 7, List item # 2 "Add network service record "
> 
> formatting - Is item 3 performed for each #2, e.g. do we need an item #3 or is
> it just what it is done for #2
> 
The whole algorithm is run for a single network service record, so both steps #2 and #3 are run once (or not at all, if aborting at #1) for that network service record. 

> Section 7.3 Dial
> 
>  add a reference for dial,  www.dial-multiscreen.org, or spec on that page?
> 
Agreed.

> Section 8
> 
> To clarify is the  reason to maintain the distinction of existing and current
> service (defined in terminology section) and the corresponding events
> (serviceunavailable and serviceoffline) to make it possible for a web page to
> know that it should no longer  try to connect to a service that it is not using
> versus handling termination of an existing connection? Is this an optimization?
> A few words of explanation in the text might be helpful, especially if any web
> app author guidance is needed.
> 
As mentioned above, an existing service is one that is available on the local network, while a current service is one that has been approved by the user for the web page to access. Perhaps changing the terminology of "current service" to "approved service" would make the distinction clearer?
 
The serviceunavailable event informs the web page that there is one less matching services on the local network. The web page should consider refreshing its list of [current(approved)] services by re-invoking the API.

The serviceoffline event informs the web page that a specific current(approved) service is no longer available. The web page should stop communicating with that service and/or expect responses/events from it.

There was an issue raised to rename these events (http://www.w3.org/2009/dap/track/issues/134).


> 
> regards, Frederick
> 
> Frederick Hirsch
> Nokia
> 
> 
>

Received on Thursday, 15 August 2013 22:06:41 UTC