RE: Review of Web Intents addendum for local services

It's true that a UPnP-enabled UA is not going to look at the content of the
UPnP description document. However, there are other implications of having
multiple instances of the UPnP WebIntents service in there.

First, a UPnP device is required to send periodic NOTIFY messages for each
service listed in the UPnP description document. Similarly, it is required
to send search response messages for each matching service listed there.
Each additional instance of the UPnP WebIntents service results in more such
messages in the network, and more messages for the UPnP-enabled UAs to
process (or at the very least, inspect). If there are other regular UPnP
entities (control points) in the network, they will be burdened by the extra
messages as well.

Additionally, while UPnP-enabled UAs have no interest in the UPnP
description document, other regular UPnP entities (control points) in the
network typically process description documents in their normal operations.
Having additional instances of the UPnP WebIntents service in these
documents also adds to the workload of such entities.

As the creator of this almost-dummy UPnP service (the sole purpose of its
creation is to be able to do targeted SSDP searches) with full knowledge of
what it does and what it does not do, we have the responsibility (instead of
leaving it up to developers/implementers to do the right thing) of limiting
the impact it has on both the devices that we target at (UPnP-enabled UAs)
and those that we don't (all other UPnP entities on the network), and
network traffic in general. Thus I stand by my suggestion to prohibit
multiple instances of the UPnP WebIntents service in the UPnP description
document.

- Cathy.
 

> -----Original Message-----
> From: ext Norifumi Kikkawa [mailto:Norifumi.Kikkawa@jp.sony.com]
> Sent: Friday, July 06, 2012 2:52 AM
> To: Chan Cathy (Nokia-CIC/Boston)
> Cc: public-web-intents@w3.org
> Subject: 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.
> >
>