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

First of all, thank you Rich and Clarke for putting together the draft. I
think it cleaned up a lot of ambiguities in the previous drafts. I also
applaud the change to now allow UAs to choose to implement SSDP or zeroconf
or both as opposed to mandating both. Below are some comments and questions
on the design of the API in general. I'll be sending a separate message with
comments specific to UPnP discovery as I expect those to draw a different
set of audience.

4.1
- In Step 1, add "and return" at the end (to be consistent with e.g. Step
5).
- 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.
- In Step 13-2, instead of using "service was originally created from a UPnP
discovery process", using "the type attribute of service begins with "upnp:"
is a more precise condition. (Probably similar changes are needed at other
places.)

5.1
- [typo] s/in one or the requested valid service types/in one of the
requested valid service types/ (two instances)
- On servicesAvailable: "By default, servicesAvailable must be set to 1."
When do we expect a default value to be in use instead of an actual value?
Why is the default value not 0?
- 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?

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?

6.1
- "The id attribute is a unique identifier for the service. Two services
provided at different times or on different objects must have the same id
value." Shouldn't they have "different" values?
 
6.3
- There is no description on when these events will be fired (albeit quite
obvious).

7.
- In the first sentence, the reference to Zeroconf is to RFC 3927, which is
misleading, as RFC 3927 is only one part of what is generally known as the
Zeroconf discovery mechanism and does not have much to do with discovery.
Implementing that reference alone is not sufficient to provide the feature
detailed in this specification. The actual relevant reference would be mDNS
and DNS-SD.

7.3
- In the case that the user has dropped from the network, there needs to be
a Step 2-4 to set servicesAvailable to 0, and possibly to dispatch an
onserviceunavailable event.
- 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. Also, s/Section 6: Service Discovery/Section 7: Service Discovery/.

References
- RFC 3927 has been published and is no longer a draft. The reference should
be to http://www.ietf.org/rfc/rfc3927.txt, unless there is a reason to refer
to the specific draft.

Regards, Cathy.