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

Le 8/8/13 02:06 , Frederick.Hirsch@nokia.com a écrit :
> 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?
JCD:
Should we limit the applicability of the NSD spec to some exhaustive 
list of protocols ? NO
Should we limit the mention of specific protocols in the core spec ? YES
>
> At a high level, what is the criterion for including service discovery mechanisms?
JCD: If it is a discovery protocol that is widely implemented and 
meaningful to the industry, it should work with NSD.
As this is a moving target, the text should be flexible.
>
> will it be feasible to interop test all of them to move the specification forward?
JCD: No, hence we should mention none in the core spec. I am aware this 
is not the policy currently applied to the spec.

>
> How hard will it be to  maintain the specification relative to the evolving status of some of them, such as DIAL?
JCD: Hard, so please move it to a separate annex or spec.

>
> Would it make sense to have separate specifications for some of the discovery mechanisms, beyond SSDP and Zeroconf?
JCD: Yes. It might even make sense to move SSDP and Zeroconf to separate 
documents, as smaller documents are usually easier to manage.
Best regards
JC

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


-- 
Télécom ParisTech <http://www.telecom-paristech.fr> 	*Jean-Claude 
DUFOURD <http://jcdufourd.wp.mines-telecom.fr>*
Directeur d'études
Tél. : 01 45 81 77 33 	37-39 rue Dareau
75014 Paris, France

Site web <http://www.telecom-paristech.fr>Twitter 
<https://twitter.com/TelecomPTech>Facebook 
<https://www.facebook.com/TelecomParisTech>Google+ 
<https://plus.google.com/111525064771175271294>Blog 
<http://blogrecherche.wp.mines-telecom.fr>