W3C home > Mailing lists > Public > public-web-intents@w3.org > July 2012

RE: Review of Web Intents addendum for local services

From: <Cathy.Chan@nokia.com>
Date: Mon, 9 Jul 2012 17:38:24 +0000
To: <Norifumi.Kikkawa@jp.sony.com>
CC: <public-web-intents@w3.org>
Message-ID: <A46437648ECB3D4F852B077AFF9099F518DC1499@008-AM1MPN1-061.mgdnok.nokia.com>
Hi Kikkawa-san,

I stand corrected regarding the number of SSDP messages sent by the device.
Indeed, it depends only on the number of service types and not the number of
service instances. Thanks for pointing that out.

With that in mind, although I still don't see any good reason why anyone
would implement multiple WebIntents services on one device, I won't insist
on prohibiting it either. I'll leave that decision up to you and Claes.

Regards, Cathy.


> -----Original Message-----
> From: ext Norifumi Kikkawa [mailto:Norifumi.Kikkawa@jp.sony.com]
> Sent: Sunday, July 08, 2012 8:53 PM
> To: Chan Cathy (Nokia-CIC/Boston)
> Cc: public-web-intents@w3.org
> Subject: 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 17:39:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 9 July 2012 17:39:00 GMT