RE: Web Intents for local network services (DAP Action-510)

Comments inline.
- Cathy.

> -----Original Message-----
> From: ext Nilsson, Claes1 [mailto:Claes1.Nilsson@sonymobile.com]
> Sent: Thursday, May 17, 2012 10:27 AM
> To: Chan Cathy (Nokia-CIC/Boston); public-web-intents@w3.org
> Subject: RE: Web Intents for local network services (DAP Action-510)
> 
> Hi Cathy,
> 
> Thanks a lot for your feedback!
> 
> See replies inline below.
> 
> Best regards
>   Claes
> 
> From: Cathy.Chan@nokia.com [mailto:Cathy.Chan@nokia.com]
> Sent: den 16 maj 2012 22:41
> To: Nilsson, Claes1; public-web-intents@w3.org
> Subject: RE: Web Intents for local network services (DAP Action-510)
> 
> > Hi Claes,
> 
> > Some comments on the proposal.
> 
> > 1. I'm afraid you're misusing the ST header in SSDP. The ST header is
not
> just a simple search string for string matching.
> > It's a means for a client to narrow the SSDP search to devices that
> > implement a particular UPnP device/service type. From the device side,
> > by responding to such a search target, it indicates that it implements
> > the requested UPnP device/service type. By implementing a UPnP service
> > type ("urn:schemas-webintents-org:service:WebIntents:1" in your
> > proposal), it means a device has to include this UPnP service in its
> > device description, and the UPnP service must include some invokable
> > actions, etc. If we create such a UPnP service type, we'll have to
> > define the actual control protocol for this service type (i.e. what
>  > state variables it has and what they mean, what actions are available
and
> what they mean). It doesn't occur to me that that
> > is your intention.
> 
> Right. We expect a device that supports Web-Intent services implements a
> UPnP Service Description for that. It must have at least one UPnP state
> variable as defined in 2.3 of UPnP DA 1.0
> (http://upnp.org/sdcps-and-certification/standards/device-architecture-
> documents/) while no action is required. Note that the state variable may
> not be evented. Thus, only the requirement for device is to add a static
UPnP
> Service Description document in it's UPnP Device Description.  In order to
> clarify this we can add examples of Device Description and Service
> Description pages in the presentation.
 
You're correct. Only state variables are required. Adding those examples
would certainly clear things up.

> > 2. You mentioned in another message that you want to add things like
> > Action and Type in the ST header. That again is not something that a
> > vendor or an SDO other than UPnP Forum can do. The format and the
> > allowed values of the ST header are defined in the UPnP Device
> > Architecture [1] and is not designed to be vendor-extensible. If new
> > search criteria other than those defined in [1] are desired, such
request
> should be brought to UPnP Forum. In fact, that idea was discussed in UPnP
> Forum several years ago but that work was shelved at the time (that's
before
> my time so I can't say much about it). Maybe it's a good time to bring it
up
> again (Clarke?).
> 
> Basically we assume that we can follow the UPnP specification. We will not
> change the format of an ST header. We just define a new serviceType as
> vendors do for extension. This is allowed according to 1.2.2 of UPnP DA.
An
> HTTP header extension is allowed because SSDP refers to RFC 2616 and RFC
> 2774 as defined in 1.3 of UDA1.0 as far as the syntax you pointed out in
the
> comment #3 is used.

Good.
 
> To make this proposal as the official spec, we do not want to bring UPnP
> forum!!!

(Not sure if I understand your comment, but not sure if it's critical to the
discussion either. Moving on...) 
 
> > 3. The vendor-defined headers in the SSDP messages (pages 10 and 15)
> > are in the wrong format. For example, instead of X-WebIntents-action,
> > it should be action.webintents.org (header name followed by domain). See
> Section 1.1.3 in [1]. Also, there should not be a HOST header in the SSDP
> response.
> 
> This is correct and we will fix it.
> 
> 
> > 4. Your proposal talks mostly about SSDP searches, and the
> > WebIntents-related headers in SSDP responses. But for completeness, it's
> necessary to add that such headers are also used in SSDP announcement
> messages sent by WebIntents-enabled UPnP devices.
> > This would allow clients (such as a UA's web intents manager) to keep
track
> of WebIntents-enabled UPnP devices that enter the network in the
> background.
> 
> Yes, we will add a scenario showing Advertisment.
> 
> 
> > 5. In alternative 2, shouldn't intent.postResult() occur right after
> > the user selects the device, and before the client page begins sending
> > high-level commands (i.e. above the fat arrow on page 18)? My
> understanding is that getting the success callback (which is triggered by
> intent.postResult() on the service page) is the indication to the client
that the
> user has selected a target service to use.
> 
> I am not sure that we should change this. Generally, the Service page
should
> issue the intent.postResult() when the Service has executed the Action of
> the intent. For simple RPC use cases such as picking an image the Service
is
> invoked by the startActivity call and when the user has selected the image
in
> the Service page image data is returned with intent.postResult()  to the
> Client application. This means that the relation between the Client and
the
> Service is terminated. For alternative 2 in our presentation we have a
longer
> lasting relation between the Client and the Service and my view is that
> issuing intent.postResult() means that this relation is terminated.

I could argue that the "discover" action has been executed once the target
service has been selected by the user and the service page has been loaded.
The subsequent exchanges between the client page and the service page is
beyond the context of Web Intents. In that sense, it would be better to wrap
up the intent by issuing postResult. But I can also see your approach
working, as long as the service page has some way of notifying the client
page that it is up and running (e.g. by sending an initial message over the
message port).

> This is also related to the concept of "hidden" Services. We are currently
> prototyping this and I will give more feedback when we have more practical
> experiences.
> 
> > Regards, Cathy.
> 
> 
> > [1] http://upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf
> 
> 
> From: ext Nilsson, Claes1 [mailto:Claes1.Nilsson@sonymobile.com]
> Sent: Tuesday, May 15, 2012 11:42 AM
> To: public-web-intents@w3.org
> Subject: Web Intents for local network services (DAP Action-510)
> 
> Hi,
> 
> I have updated the proposal for dynamic registration of Web Intents
enabled
> services in local UPnP networks. See wiki page:
> http://www.w3.org/wiki/WebIntents/SonyMobile_-
> _Local_Network_Service_Discovery. New slides are:
> http://www.w3.org/wiki/images/8/8e/V2_W3C_Web_Intents_-
> _Local_UPnP_Service_Discovery.pdf.
> 
> The main difference compared to the proposal in Shenzhen is that we for
> dynamically discovered UPnP Services propose additional SSDP headers
> stating the Service registration data (Action, Type, href, Title and
Disposition)
> instead of having the registration markup in the UPnP Device Description
> document.  The main reason for this proposal is that it scales better in
local
> networks with many Web Intents enabled devices. The UA does not have to
> retrieve the Device Description page for each Web Intents enabled device
> found in order to check matching Action and Type. Instead this information
is
> found in the SSDP headers and a more efficient matching can be performed.
> 
> I have also removed the slides on Web Intents discovery of services on
> legacy UPnP devices as I assume this is covered by
> http://www.w3.org/2009/dap/track/actions/511.
> 
> We are also planning to make a proposal for mDNS.
> 
> Next step is to  make a Web Intents addendum specification according to
> http://www.w3.org/2009/dap/track/actions/510.
> 
> Best regards
>   Claes
> 
> [cid:image001.gif@01CD3442.07E47130]
> 
> Claes Nilsson M.Sc.E.E
> Master Engineer, Research
> Technology Research - Advanced Application Lab
> 
> Sony Mobile Communications
>  Phone:  +46 10 80 15178
> Mobile: +46 705 56 68 78
> Switchboard: +46 10 80 00000
> E-Mail:
> mailto:claes1.nilsson@sonymobile.com<mailto:claes1.nilsson@sonyericsson.
> com>
> Visiting Address; Nya Vattentornet
> SE-221 88 LUND,
> Sweden
> Disclaimer:
> The information in this e-mail is confidential and may be legally
privileged. It
> is intended solely for the named recipient(s) and access to this e-mail by
> anyone else is unauthorized. The views are those of the sender and not
> necessarily the views of Sony Ericsson and Sony Ericsson accepts no
> responsibility or liability whatsoever or howsoever arising in connection
with
> this e-mail.Any attachment(s) to this message has been checked for
viruses,
> but please rely on your own virus checker and procedures. If you contact
us
> by e-mail, we will store your name and address to facilitate
communications.
> If you are not the intended recipient, please inform the sender by
replying
> this transmission and delete the e-mail and any copies of it without
disclosing
> it.