Re: Review of Web Intents addendum for local services

Hello Cathy and all,

I agree with Cathy, just with adding a comment.
(The link is still dead...)

As you mentioned, even a device supports more than one Intent actions, 
it does not have to enumerate more than one WebIntents serviceTypes.
The text in the A.4 figure should be removed. 
I think this is enough as the document and it doesn't have to prohibit
multiple WebIntents serviceTypes explicitly because even if a device
happens to have multiple WebIntents serviceTypes, it doesn't make a
client implementation more complex. I assume a client in the web intents
scenario may not see the content of UPnP description document.

Best Regards,
Kikkawa

---------------------------------------------
 Norifumi Kikkawa <Norifumi.Kikkawa@jp.sony.com>
  Section 1
  Network Technology Dept.
  Information Technology Development Division
  System & Software Technology Platfotm 
  Sony Corporation
 (TEL) +81 50 3750 3953 
----------------------------------------------- 

On Fri, 6 Jul 2012 05:10:51 +0900
"Cathy.Chan@nokia.com" <Cathy.Chan@nokia.com> wrote:

> 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.
>

Received on Friday, 6 July 2012 07:49:05 UTC