Status of my Actions from Shenzhen meeting (relating to Web Intents for local network service discovery)

Hi,

I would just like to give a short update on my Actions from the Shenzhen meeting Web Intents session:

ACTION-510: Create new spec how WebIntents UPnP registration
Our idea is to add Intents Service markup to the UPnP Device Description xml-document. We are prototyping this idea and also considering the alternative solution to instead just have a URL to a Web Intents Service registration page in the UPnP Device Description xml-document. One motivation for that is that it would be easier to adapt to standardization changes for registration (referring to discussions on this list and WHAT WG), e.g. usage of a JS API for registration.

We are also considering inclusion of Action and Type in an SSDP header. The motivation is that in a network with many Web Intents enabled UPnP devices it would not be necessary to download the UPnP Description Document for all discovered Web Intents enabled devices in order to find matching Action and Type.

I will start editing this Web Intents addendum specification when we have decided on the approach to the issues above.

ACTION-521: Coordinate with UPnP forum about extensions required for Intents
Section "2.5 Description: Non-standard vendor extensions" of the "UPnP Device Architecture 1.0", http://upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.0.pdf describes how UPnP vendors may differentiate their devices and extend a standard device by including additional services and embedded devices. It is possible to add a new UPnP device type, e.g. "DeviceType:  urn:w3c-org:device:webIntent:1"  and state a W3C Web Intents xml-name space for the XML elements in device or service description.

So according to my understanding a UPnP W3C extension is possible without coordination with UPnP Forum. This could be our initial approach but does not preclude a later coordination with UPnP Forum.

ACTION-519: Add a proposal for hidden disposition
In our prototyping we are using a hidden iframe for a Service that has no UI and we have important use cases for Services running with UI, or at least without user interaction, i.e. the user interaction lies within the Client page.  At the Shenzhen meeting security concerns were raised on having a Service running in the background without any visibility for the user. After getting more experiences from our prototyping we will come back with a proposal for hidden disposition taking the security concerns into consideration.

ACTION-529: Work with Greg and Bryan on investigating white list/CORS for networked services
For the cases when the Service page is retrieved from the UPnP device it is controlling there as is no cross-domain issue. It occurs when a Service page is fetched from another domain than the UPnP device it should communicate with.  I haven't yet analyzed this further but a white list approach similar to Opera/Cable Lab's proposal in http://people.opera.com/richt/release/specs/discovery/Overview.html is one possible solution.

Best regards
  Claes
[cid:image001.gif@01CD22CC.2DA986D0]

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.