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

Hi Rich,

Thanks for the response. My comments below refer to the Aug 22 draft at
http://w3c-test.org/dap/discovery-api/.

>   > - 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 
thing,
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
correct:
[[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 
Zeroconf
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.