Review of Web Intents addendum for local services

Here are my comments on the addendum that Claes uploaded last week. (The
link is dead as of today by the way.)

4.1.1 The actionList tags should be removed. The UDA requires that the
actionList must not be listed in the service description when there are no
actions.
4.1.1 The text description says X_State is ui4 but it's in boolean in the
example.
4.1.2 [[To support more than one Web Intents action the action strings must
be separated with one or more commas.]]
- This can be misinterpreted as multiple commas between two action strings.
s/one or more//
4.1.3 [[The UPnP enabled device must store Web Intents documents for the Web
Intents Services the UPnP enabled device supports.]]
- "store" alone does not make it available to the UA. Change "store" to
"host" or "expose" or something else?
- Similarly with 4.1.4.
4.2 Step 2. [[If the action.webintents.org header is present and does not
match the action attributes of the Services registered in the retrieved Web
Intents document the UPnP enabled User Agent silently disregards the
discovered Service.]]
- It's unclear which Service is referred to in "disregards the discovered
Service". I think this refers to a Web Intents service listed inside the Web
Intents document, especially in cases where the Web Intents document
includes multiple services, and not all of them match the
action.webintents.org header. This, however, is a different use of
"disregards the discovered Service" as in the previous sentence, where
Service refers to the entire M-SEARCH response/UPnP service.
- Ideally, the UA may choose to register all services (for future use) but
only present the matching one(s) in the picker. (see the next point.)
4.2 If a Web Intents document includes registration markup for multiple
services, does the UA register all the services or only the matching
service(s)? Step 4 implies the latter, but step 3 may be interpreted to
imply the former.
4.2.1 s/continously listen/continuously listen to/
4.2.2 [[...it is *assumed* that UPnP enabled User Agents that comply to this
specification support Web Intents according to [WEBINTENTS]...]] conflicts
with the Conformance section where [[A UPnP enabled User Agent *must*
support Web Intents [WEBINTENTS].]]
4.2.2 Why is UDA 1.1 referenced here while the rest of the document refers
to UDA 1.0?
4.2.3 is non-normative but starts with a MUST statement.
A.4 The figure has a note [[To support more than one Web Intents Service,
add more service elements with different "serviceId" for the Web Intents
Services.]] In UPnP, multiple instances of a service is used when those
instances would have different state variable values, respond to actions
differently, etc. Since in this spec we already say that the state variable
is dummy and there are no actions, there's no real reason to use multiple
[UPnP] services. (Note that multiple Web Intents services can be registered
with a single Web Intents document and therefore do not necessitate the use
of multiple UPnP services.) I would suggest prohibiting the use of multiple
UPnP WebIntents services altogether, which may make implementations simpler.
This can be done at the beginning sentence of 4.1.1 [[The UPnP enabled
device must support the UPnP service which serviceType is
urn:schemas-webintents-org:service:WebIntents:1 ...]] - s/the UPnP
service/one UPnP service/

This may well be a matter of personal preference. Instead of "UPnP-enabled
device", I would suggest using either "Web Intents enabled UPnP device" to
highlight the Web Intents capability of such devices, or simply UPnP device
to be consistent with common usage. My preference is the former, as it would
also help distinguish these more capable devices from "legacy" UPnP devices
if/when we write new specifications to support those.

- Cathy.