Re: Review of Web Intents addendum for local services

Hi Cathy,

Thank you for your response.

I also think the document should indicate a single WebIntents service
basically. I don't have a good example that people want to implement
multiple WebIntents service. Therefore, I suppose that your restriction
wouldn't hurt people's implementation. 

I just feel additional restriction over UPnP should be minimized 
in the document. I think people will not implement multiple 
WebIntents services even if the document doesn't prohibit it clearly.
Since this is just my preference, I could be OK with introducing the
restriction.

Note that when a device has more than one services of the same 
serviceType, it just responds a number of types in SSDP. 
For example, a Device holding one A service and two B services 
will advertise only two messages standing for service A and service B.
So multiple WebIntents service doesn't make a traffic busy. (But this 
is not my point.)

Regards,
Kikkawa

On Sat, 7 Jul 2012 01:19:50 +0900
"Cathy.Chan@nokia.com" <Cathy.Chan@nokia.com> wrote:

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

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

Received on Monday, 9 July 2012 00:53:43 UTC