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

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

From: Nilsson, Claes1 <Claes1.Nilsson@sonymobile.com>
Date: Tue, 29 May 2012 13:43:32 +0200
To: Dave Raggett <dsr@w3.org>, "Cathy.Chan@nokia.com" <Cathy.Chan@nokia.com>, "public-web-intents@w3.org" <public-web-intents@w3.org>
Message-ID: <6DFA1B20D858A14488A66D6EEDF26AA35D6A9EBACB@seldmbx03.corpusers.net>
Hello Dave and others,

I have now updated the presentation the Web Intents wiki: http://www.w3.org/wiki/images/2/2e/V4_W3C_Web_Intents_-_Local_UPnP_Service_Discovery.pdf to show the idea of using a separate document for dynamic registration of Services provided by the Web Intents enabled UPnP device.

After working this through we think that this is the best approach as:

* We don't risk to exceed the limit stated by the UPnP specification that each discovery message MUST fit into one UDP packet.
* No dependency on the UPnP description documents, i.e. standard UPnP Device and Service Description documents can be used. 
* Flexible. It will be possible to add more to this registration document, not only html but also JavaScript. For example it will be easier to follow any updates to the Web Intents specification on registration markup or potential JS APIs. Furthermore it might be possible to have code related to service authentication in the registration document.
* Consistent registration procedure for other low level discovery protocols. The same registration document format will be possible to use for other local network discovery protocols, e.g. mDNS.

I am working on the addendum specification.

Best regards
  Claes

-----Original Message-----
From: Nilsson, Claes1 
Sent: den 28 maj 2012 14:10
To: 'Dave Raggett'
Cc: Cathy.Chan@nokia.com; public-web-intents@w3.org
Subject: RE: Web Intents for local network services (DAP Action-510)

Thanks for your response Dave.

> First: It would be helpful to know which devices supported web intents 
> so that you only need to retrieve the service descriptions from those 
> devices that do support web intents.

Yes, we agree.  We propose to define "webintents service type", i.e. ST / NT header:
"urn:schemas-webintents-org:service:WebIntents:1"

Further filtering will be performed through the "Web Intents action" header, e.g. "action.webintents.org:http://webintents.org/view".

> Second: An alternative to extending the UPnP service description 
> format would be to define a new format that is returned separately and 
> used to describe the parameters for web intents. It would be 
> convenient is this used the JSON format. The browser wouldn't need to 
> retrieve the XML service description file until that becomes necessary.

We have considered the way to dynamically register Services on local network devices and come to the conclusion that a separate registration document is preferable. There are several advantages of having a separate document for registration:

* No dependency on the UPnP description documents 
* Flexible. It will be possible to add more to this registration document, not only html but also JavaScript. For example it will be easier to follow any updates to the Web Intents specification on registration markup or potential JS APIs. Furthermore it might be possible to have code related to service authentication in the registration document.
* The same registration document format may be possible to use for other local network discovery protocols, e.g. mDNS. 

However, we don't really see the point of defining a specific JSON format for registration as we already have a standardized html markup format for registration defined by the Web Intents specification. 

So we propose to add the new SSDP header "registration.webintents.org". For example "registration.webintents.org:/registration.html" in which registration.html contains the registration markup with the <intent> tag.

> Have you done any data collection on the size of SSDP responses and 
> unsolicited advertisements for current devices? If it turns out that 
> these are typically small, then 512 bytes might give us sufficient 
> room to further ideas.

Yes, we have done that and come to the conclusion that adding the action and registration headers is ok but for example also providing a "type" header will mean that at least Advertise message will exceed the 512 bytes limit in many cases. If you are interested I can provide more details on this.

So, summary of proposal:

* SSDP "webintents service type" is "urn:schemas-webintents-org:service:WebIntents:1" 
* New "Web Intents action" SSDP header "action.webintents.org:"
* New "Web Intents registration" SSDP header "registration.webintents.org" that points at registration html page containing normal registration markup with <intent> tag
* Standard UPnP Device and Service description documents

Best regards
  Claes

-----Original Message-----
From: Dave Raggett [mailto:dsr@w3.org] 
Sent: den 25 maj 2012 13:45
To: Nilsson, Claes1
Cc: Cathy.Chan@nokia.com; public-web-intents@w3.org
Subject: Re: Web Intents for local network services (DAP Action-510)

On 25/05/12 12:04, Nilsson, Claes1 wrote:
> Hi again,
> 
> It seems as the requirement in the UPnP Device Architecture 1.1 specification that each discovery message MUST fit entirely in a single UDP packet, that might be down to 512 bytes, prohibits us to define long headers that perform full Web Intents Service registrations. So currently I see no other option than relying on the Device Description document, as proposed in Shenzhen, for Service registration. 
> 
> In addition to this we could just add one extra header "action.webintents.org:...." that helps UA's Web Intents implementation to filter SSDP responses. It would be good to have a " type.webintents.org:.." header as well but then we risk to exceed the limit of 512 bytes if several types are supported.
> 
> What do you say. Any views?

First: It would be helpful to know which devices supported web intents
so that you only need to retrieve the service descriptions from those
devices that do support web intents.

Second: An alternative to extending the UPnP service description format
would be to define a new format that is returned separately and used to
describe the parameters for web intents. It would be convenient is this
used the JSON format. The browser wouldn't need to retrieve the XML
service description file until that becomes necessary.

Combining these two, we arrive at a single new header for the SSDP
response/advertisement that references the location for the web intents
description. If the heading is missing, the device isn't web intents aware.

Have you done any data collection on the size of SSDP responses and
unsolicited advertisements for current devices? If it turns out that
these are typically small, then 512 bytes might give us sufficient room
to further ideas.

Best regards,
-- 
Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
Received on Tuesday, 29 May 2012 11:44:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 29 May 2012 11:44:11 GMT