RE: Review of Web Intents addendum for local services

I have uploaded a new version the addendum specification,

Thanks again for your review Cathy!


>-----Original Message-----
>From: Nilsson, Claes1
>Sent: den 7 juli 2012 11:31
>To: '';; public-device-
>Subject: RE: Review of Web Intents addendum for local services
>Thanks for your review and comments Cathy. It helps a lot!
>All comments make sense and I plan to upload a new version on Monday.
>Best regards
>  Claes
>P.S. I uploaded the specification to CVS again. There was some error in
>the configuration of the DAP repository that made the folder for my
>specification disappear.
>>-----Original Message-----
>>From: []
>>Sent: den 5 juli 2012 22:11
>>Subject: Review of Web Intents addendum for local services
>>Here are my comments on the addendum that Claes uploaded last week.
>>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
>>4.1.1 The text description says X_State is ui4 but it's in boolean in
>>4.1.2 [[To support more than one Web Intents action the action strings
>>be separated with one or more commas.]]
>>- This can be misinterpreted as multiple commas between two action
>>s/one or more//
>>4.1.3 [[The UPnP enabled device must store Web Intents documents for
>>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 header is present and does
>>match the action attributes of the Services registered in the retrieved
>>Intents document the UPnP enabled User Agent silently disregards the
>>discovered Service.]]
>>- It's unclear which Service is referred to in "disregards the
>>Service". I think this refers to a Web Intents service listed inside
>>Intents document, especially in cases where the Web Intents document
>>includes multiple services, and not all of them match the
>> 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)
>>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 [[ is *assumed* that UPnP enabled User Agents that comply to
>>specification support Web Intents according to [WEBINTENTS]...]]
>>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
>>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
>>add more service elements with different "serviceId" for the Web
>>Services.]] In UPnP, multiple instances of a service is used when those
>>instances would have different state variable values, respond to
>>differently, etc. Since in this spec we already say that the state
>>is dummy and there are no actions, there's no real reason to use
>>[UPnP] services. (Note that multiple Web Intents services can be
>>with a single Web Intents document and therefore do not necessitate the
>>of multiple UPnP services.) I would suggest prohibiting the use of
>>UPnP WebIntents services altogether, which may make implementations
>>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-
>>device", I would suggest using either "Web Intents enabled UPnP device"
>>highlight the Web Intents capability of such devices, or simply UPnP
>>to be consistent with common usage. My preference is the former, as it
>>also help distinguish these more capable devices from "legacy" UPnP
>>if/when we write new specifications to support those.
>>- Cathy.

Received on Monday, 9 July 2012 08:25:10 UTC