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

It is, in fact, a great time to bring up new feature proposals in UPnP. We are just getting started with an initiative called UPnP+ that is adding things to UPnP to meet current technology changes. One initiative is integrating with HTML. We have the CableLabs/Opera proposal and are closely following the WebIntents discussion. We would certainly welcome new participants. We want to converge on the best solution, whatever that is.

-Clarke

From: "Cathy.Chan@nokia.com<mailto:Cathy.Chan@nokia.com>" <Cathy.Chan@nokia.com<mailto:Cathy.Chan@nokia.com>>
Date: Wednesday, May 16, 2012 2:41 PM
To: "Claes1.Nilsson@sonymobile.com<mailto:Claes1.Nilsson@sonymobile.com>" <Claes1.Nilsson@sonymobile.com<mailto:Claes1.Nilsson@sonymobile.com>>, "public-web-intents@w3.org<mailto:public-web-intents@w3.org>" <public-web-intents@w3.org<mailto: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.
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?).
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.
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.
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.

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<mailto: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@01CD3370.3C60C120]

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.