Network Service Discovery Review

Hi Rich,

I looked at the network service discovery API specification.
This definitely brings interesting functionalities, with already a precise definition (especially section 7).

The model (several types in the request, whitelist persistency) seems a bit complex to me though.
Maybe this is just a matter of clarification.

Please find below some additional comments and questions.

Regards,
                Youenn

1. Multi-type query
What is the benefit of having one single query with a set of types?
Wouldn't it be simpler for application developers to make several requests for different types?
Like requesting access to a local media storage service and then, if needed, requesting access to a print service.
Wouldn't it be simpler as well for users to grant access for one service type at a time?

Also, one NetworkServices for each service type may be more convenient.
For instance, onserviceavailable handlers would directly be linked to a single service type.

2. Available services
What is the goal behind servicesAvailable?
What functionality does it bring to web applications?
Wouldn't the current NetworkServices events and authorized services length be sufficient in most cases?
Or just as a boolean value stating that there are some changes in the services of interest?
It seems that serviceAvailable is counting services of potentially different types, which may not be all that useful.

3. Service monitoring
Monitoring of services availability looks like a useful feature.
Probably a user has three options that should be clearly stated:

-          A user is granting permission to 1+ service(s) and grants permission to monitor services

-          A user is granting permission to monitor services

-          A user is denying permission to any service and to monitoring
As per step 9 in section  4.1, it is not explicit whether the second option is valid.
Two choices are currently described: granting permission to 1+ services or denying permission (probably to all services?).

Also, what about a user that wants to grant access to one specific service while denying access to monitoring information?
Maybe this behavior does not make any sense in practice?
But the spec could probably be updated to enable that behavior at a small cost.
Something like not mandating to add the generated NetworkServices in the list of active service managers.
Or making the serviceavailable/serviceunavailable events sending optional?

4. Relationship with Web Intent based discovery
Service monitoring is a potentially nice feature in the network discovery API specification.
This monitoring does not seem to be available with the "Web Intents Addendum - Local Services" approach.
For instance, dynamically adding a print button, or changing its color, when a local printer is showing up may be convenient in terms of user experience.
This seems to be feasible with this API, while this may not be the case with the web intents approach.
Is that ok as is?
Is monitoring out of scope (or a potential requirement) for the "Web Intents Addendum - Local Services" approach?
Should service monitoring be a separate feature that can be used by both approaches?

More generally, the question of the relationship between the two approaches will probably show up in the future (what is the difference, what is the scope, which approach should I use...).
It may be good to have some answers publicly available (if it is not already the case?).

5. Whitelist removal
To disable access to a particular service, a user can decide to remove access to all services (reloading the app or recalling the function using the web app UI).
Some browser implementations may want to propose authorization removal globally or on a per service basis.
Is it the purpose of the "ongoing local-network communication" indicator?
In that case, if a user disables access to a particular service, how would the application be notified of such change?
Is it expected that the application will be notified from error messages coming from the protocol level?
What happens if there is an ongoing XHR exchange?

6. No access to previous services
The four bullets at the end of section 4.1 describe when access to any of the whitelist URL is authorized or not.
After reading the different points, everything is not crystal clear to me.
Here are some questions that came to my mind:

What is the exact meaning of the first bullet (same script related in same or different window)?
What potential security issue is it addressing?
Does it mean that if the same script is loaded in two different windows,
the authorizations for the script in the first window are cancelled (whitelist becomes empty) when the script in the second window is loaded?
If that is the case, similarly to the previous point 5 on whitelist removal,
while it is easy for application developers to understand that authorizations are removed when getNetworkServices is called again,
it may be less obvious for developers to handle bullet 1.

As of the second bullet, does it mean that all granted URLs are removed from the whitelist when getNetworkServices is called again?
If so, would it make sense to exactly precise when the previous whitelist is emptied?
Section 4.1 defines the different steps of the getNetworkServices call and one could envision doing this at step 1, 12 or 18 for instance.
If a web application has access to a content provider and also wants to access a particular printer, the app will call again getNetworkServices.
It would be nice if the access to the content provider is not cut during the 10 seconds the user takes to answer to the getNetworkServices call.

The third bullet (going through the history) probably leads to empty the current whitelist.
On the other hand, the fourth bullet (a script running in a different origin) does not probably lead to empty the current whitelist.
This fourth bullet may different in nature to the other items and, if that is the case, may be separated from the list.

7. Active service managers
The list of active service managers contains the NetworkServices objects being shared with all web pages.
Each NetworkServices object in that list will issue serviceavailable events whenever needed.
NetworkServices objects not in this list will not generate those events.

What happens to a NetworkServices object delivered by a getNetworkServices call that is made obsolete by a new getNetworkServices call?
Is it still in that list of active service managers?
When reading section 9, it seems to be the case.
But what is the point in processing online/offline events for services that the application can no longer get access to?
Would it make sense to apply section 4.1 rules on NetworkServices object removal from the list of active service managers?
Also, if a user is revoking access authorizations, he may also want to revoke the implicit monitoring authorization.

8. Zeroconf expiryTimestamp
Section 7.1 step 7 states how the expiryTimestamp is computed (by adding 120 seconds to the current time).
120 seconds seems a pretty small value.
Depending on the message types, the recommended TTL value is either 120 seconds or 75 minutes as per the mdns spec.
Would 75 minutes be more appropriate in that case?

More generally, a browser may have a precise knowledge of the TTL and may prefer using a value different from the one in the spec.
Would it make sense to accommodate the rules accordingly?

9. Network topology
A device may have more than one ongoing network connection.
If one network connection is dropped amongst several, only the service records that are related to the dropped network should probably be removed.
First sentence in section 7.3 may be further precised on that respect.