W3C home > Mailing lists > Public > public-device-apis@w3.org > August 2012

RE: Comments on Networked Service Discovery and Messaging draft (general comments)

From: <Cathy.Chan@nokia.com>
Date: Tue, 28 Aug 2012 19:45:18 +0000
To: <richt@opera.com>
CC: <public-device-apis@w3.org>
Message-ID: <A46437648ECB3D4F852B077AFF9099F518DFC537@008-AM1MPN1-062.mgdnok.nokia.com>
Hi Rich,

Thanks for the response. My comments below refer to the Aug 22 draft at

>   > - The PERMISSION_DENIED_ERR error code is used in Steps 8 and 10, but
> the
>   > error conditions in Step 8 ("services found is an empty array") and
>   > Step 10
>   > ("based on a previously-established user preference", "for security
>   > reasons", "or due to platform limitations") do not really match the
>   > definition of the error "The user denied the page permission to access
>   > any
>   > services." I would suggest either making the error code (and
> description)
>   > more generic, or creating a separate error code to handle these other
>   > conditions and leaving the PERMISSION_DENIED_ERR error code for use
>   > solely
>   > in the situation where the user *actively* denies permission.
> I think this is a privacy preserving feature. We don't want web pages to
> develop an attitude toward users if it knows that the user was the one to
> reject feature permission.
> If permission is denied then the page doesn't need to know exactly who
> denied that permission or why it was denied, just that it was denied for any
> of the reasons you mention above.
> Having said that, I've updated the definition of PERMISSION_DENIED to "The
> user or user agent denied the page permission to access any services".
That sounds reasonable to me.

>   > - On servicesAvailable: "By default, servicesAvailable must be set to
> 1."
> Because successCallback cannot fire unless at least one service is provided
> to
> the page by the user (step 7 in getNetworkServices algorithm). Therefore
> the default case is for a page to be provided with
> 1 service and servicesAvailable defaults to 1.
This is not necessarily true. The one service that is found could be offline
(online=false). In that case, length is 1, but servicesAvailable would be 0.
Speaking of which, the definition of servicesAvailable is ambiguous as to
whether only online services are included:
[[servicesAvailable - Returns the current number of services matching one of
the app-requested valid service type tokens that are actively available within
the user's current network.]]
[[The servicesAvailable attribute must return the number of services available
in the user's network that match the valid service type that was initially
used to create the current NetworkServices object.]]
I would also suggest more coherent use of the terms "actively available",
"available", "online" and "accessible". I take it that they all mean the same 
but seeing different words used in disparate sections makes me wonder if I
assumed right.

> If no services are provided then errorCallback, if provided, is invoked.
>   > When do we expect a default value to be in use instead of an actual
>   > value?
>   > Why is the default value not 0?
> I think you're right that we don't need a default value here since
> servicesAvailable is always set in step 13 of the getNetworkServices
> algorithm before a success callback is ever fired.
By the way, if the NetworkServices object is always only initialized when
there is at least one authorized service, then this statement in 5.2 is not
[[A NetworkServices object represents the current list of zero or more current
authorized services, of which zero or more can be available at a time.]]
-> s/current list of zero/current list of one/
And this should be removed:
[[If a NetworkServices object represents no current authorized services, it
has no supported property indices.]]

>   > - The onserviceavailable event is fired when a previously unknown
>   > instance
>   > of a matching service becomes available. How about the case when a
>   > previously known instance re-connects to the network (after having been
>   > disconnected from the network for any period of time)? In other words,
> is
>   > the onserviceavailable event tied solely to newly available services, or
>   > does it reflect an increase in the value of servicesAvailable?
> onserviceavailable is intended to fire each time a service connects or re-
> connects, having been dropped from the 'list of available service records'
> table. If a service is dropped then onserviceunavailable is fired and
> servicesAvailable is decremented by 1.
I agree with that behavior, but the current text does not cover the
"re-connects" case. It talks about cases where "a previously unknown
instance ... becomes available..." and "a previously known instance ...
becomes unavailable...". As far as I can tell, when an instance becomes
unavailable, it still remains in the list of service records and is therefore
still a "previously known instance" when it re-connects, which is thus not
covered by either of the above two cases.

>   >
>   > 5.2
>   > - In previous drafts, the list of "current authorized services" in
>   > NetworkServices is explicitly stated as immutable. Similar language is
> no
>   > longer found in this draft, and the Note also mentions the UA
> dynamically
>   > adding or removing network services. Does it mean that the list can
>   > dynamically change now? If so, how, and where is it described?
> The authorized services list provided in NetworkServices remain immutable.
> I've (re-)added some text to this effect in this section.
How about the note in 5.2 that says [[If the user agent dynamically adds or
removes network services for any reason, ...]]? Does it still apply?

>   > 6.3
>   > - There is no description on when these events will be fired (albeit
>   > quite
>   > obvious).
> A 'message' event is fired only in the algorithm to 'setup a UPnP Events
> Subscription'. I wouldn't mind changing the name of this event to e.g.
> 'notify' since it is only applicable in the UPnP service case and 'message'
> conflicts with other well-defined event names. I haven't made this change
> yet pending further feedback.
> A 'readystatechange' event is fired when a service leaves or rejoins the
> user's current local network. The latter case was a little underdefined in
> the
> spec so I've added an additional step in both discovery algorithms for this
> (Step 8.3 for UPnP. Step 9.3 for Zeroconf).
The serviceonline event should only be fired if there is a change in the
online attribute (i.e. going from offline to online).

> I think these sections are not
> really fully defined at this point though so I'm going to have to revisit
> their definition at a later time.
>   > - In the case that the user has connected to a new network, what
>   > parameters
>   > are being used in re-issuing the discovery search (e.g. what search
>   > target
>   > is used in SSDP)? There is not mentioned in the section on Service
>   > Discovery either.
> I haven't found a reasonable way to include this in the draft yet. It will
> probably require a rewrite or the UPnP and Zeroconf sections in Section 7 so
> I'll have to re-visit this at a later date.
> Again, thank you for your review and if you have any further feedback please
> let us know. As I mentioned above, I hope to address your feedback on
> UPnP in a separate thread soon.
There is indeed one other thing that I missed in the first pass. In both 
and UPnP, the search responses and announcement messages contain an
expiration date/time, at which point, if the UA has not received refreshed
announcements/search responses, the service should be considered offline.
I don't see either algorithm covering that scenario.

Regards, Cathy.

Received on Tuesday, 28 August 2012 19:46:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:41 UTC