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. 
 
> 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.
 
To make this proposal as the official spec, we do not want to bring UPnP forum!!!
 
 
> 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. 

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.