NSD spec implementation feedback

Please find below some hopefully constructive feedback we gathered while implementing the NSD API.

Regards,
                Youenn


1.       A single query type is easier to translate to a question that a user can understand and answer.
In most cases we encountered, a single query type is sufficient.
Having something like "this app wants to discover printers" is more meaningful than "this app wants to discover local services".

In cases where more than one type is needed, having several specific queries in parallel seems better than one catch-them-all query.
The user agent keeps the freedom to organize its UI (group parallel queries or not).
Web application will find it also more convenient (no need to filter services according their service type).


2.       Returning an array of services is not flexible.
Progressive discovered service return (like sending an event per granted service) seems a better choice than a fixed array of services.
This model is closer to existing discovery node.js modules.

This gives the flexibility to the user agent to send discovered services at various times:
- according the granting process (always-granted services, user-clicked-granted services...)
- according the discovery process (new service appearing).
Also, recalling the NSD API when a new service is appearing may not be that efficient, both for web app (user denied a previously agreed service, by mistake?) or for user (which service is new?).


3.       The prescriptive bindings to the low-level discovery protocols cannot always be ensured
If implementers start from scratch, the current bindings are very good and detailed.
If implementers start from existing libraries (avahi, gssdp e.g.), the exact control of the discovery process is not always guaranteed.
Having these sections as normative adds perceived complexity (particularly the SSDP binding) and may pose questions related to testing and conformance.


4.       NSD spec is solely targeted at XHR.
Primary goal of NSD should be discovery of HTTP services.
But there are other means of communication (WebRTC, Raw socket API, chromecast, Presentation-API like communication channel...) that would all benefit from the NSD API.
Making that clear (and maybe reorganize the spec accordingly) would make the spec more appealing.

It is not that clear what would be the impact on the API (no change, surface the expected communication channel in the API?).
More discussion on the integration of NSD with other ongoing communication efforts seems useful.