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

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

(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

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

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.

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?

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)

 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.

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

Section 7.3 Dial

 add a reference for dial,  www.dial-multiscreen.org, or spec on that page?

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.


regards, Frederick

Frederick Hirsch
Nokia

Received on Thursday, 8 August 2013 00:07:22 UTC