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

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

From: SULLIVAN, BRYAN L <bs3131@att.com>
Date: Mon, 28 May 2012 14:06:47 +0000
To: "Nilsson, Claes1" <Claes1.Nilsson@sonymobile.com>, Dave Raggett <dsr@w3.org>
CC: "Cathy.Chan@nokia.com" <Cathy.Chan@nokia.com>, "public-web-intents@w3.org" <public-web-intents@w3.org>
Message-ID: <59A39E87EA9F964A836299497B686C350FEDD714@WABOTH9MSGUSR8D.ITServices.sbc.com>
See my response inline.

Thanks,
Bryan Sullivan 

-----Original Message-----
From: Nilsson, Claes1 [mailto:Claes1.Nilsson@sonymobile.com] 
Sent: Monday, May 28, 2012 5:11 AM
To: SULLIVAN, BRYAN L; 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 Bryan.

See inline below and also my response to Dave's mail today.

Claes

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

Could we use tokenized headers and values to compress the information? This is how OMA Push achieves its data transmission capacity over SMS, which is limited to 140 characters per message and typically 4 segments (though sometimes up to 10 are supported)?
[claes] This would be possible but it seems a bit old-fashioned and not really inline with the web today to have optimizations that were motivated by having SMS as transport.
<bryan> If tokenization is "old-fashioned", then why is header compression one of the key features of SPDY? The objective clearly hasn't changed (save bits over the wire). Tokenization is an efficient method of compression that works much better for small data payloads. In this sense, the constrained bearer characteristics of SMS are very similar to that of UDP and AFAICT UPnP, i.e. there is very little payload space. 

Also is there any option to break the information across multiple UDP packets?
[claes] Yes, it should but we need to follow the UPnP Device Architecture 1.1 specification. I assume the requirement to have each discovery message to fit entirely in a single UDP packet is motivated by performance reasons.

Thanks,
Bryan Sullivan 

-----Original Message-----
From: Nilsson, Claes1 [mailto:Claes1.Nilsson@sonymobile.com] 
Sent: Friday, May 25, 2012 4:04 AM
To: Dave Raggett
Cc: Cathy.Chan@nokia.com; public-web-intents@w3.org
Subject: RE: Web Intents for local network services (DAP Action-510)

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?

Claes

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

Hi again Dave,

Regarding line breaking rules for SSDP I assume that the HTTP rules apply. RFC2616, section 4.2 states: 
"Header fields can be extended over multiple lines by preceding each extra line with at least one SP or HT."

However, the length of SSDP packets is an issue. Section 1.2.2 in UPnP(tm) Device Architecture 1.1 states:

"Note that UDP packets are also bounded in length (perhaps as small as 512 Bytes in some implementations); each discovery message MUST fit entirely in a single UDP packet. There is no guarantee that the above 3+2d+k messages will arrive in a particular order."

So if UDP packets can be as small as 512 bytes and each discovery message MUST fit entirely in a single UDP packet we have a problem. One option would be to just add the action.webintents.org and type.webintents.org headers, which makes it possible for UAs to filter responses based on these headers and only retrieve the Device Description, that contains the full Service registration markup, for matching Services. 

We are further investigating the issue.

Best regards
  Claes



-----Original Message-----
From: Dave Raggett [mailto:dsr@w3.org] 
Sent: den 21 maj 2012 18:04
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 21/05/12 16:35, Nilsson, Claes1 wrote:
> Hi Dave,
> 
> Yes, this is a good idea but want to be sure that we don't propose something that is against the UPnP standard. Taking the example at slide 10 would the following be ok?
> 
> registration.webintents.org:
> [{"action":"http://webintents.org/view",
>   "type":["video/mp4", "video/ogg", "video/webm"],
>   "href":"/control.html",
>   "title":"Living room TV",
>   "disposition":"window"},
>  { ...2nd service...},
>  { ...3rd service...}]
> 
> Regards
>   Claes

Yes, that seems fine to me so long as we conform to the line breaking
rules for SSDP, which at a guess may be similar to those for HTTP. The
SSDP spec may also have some wording about maximum line or field
lengths, so that would be worth checking too.

Best regards,
-- 
Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
Received on Monday, 28 May 2012 14:07:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:14:46 UTC