Re: ACTION-961: usefulness of multipart-mixed

AFAIK Openwave has some similar software installed in a number of  
cases and does pretty much what Magnus described in this e-mail a few  
days ago.

I am sorry I don't know where they get the information about  
multipart support.

Andrea


Il giorno 28/mag/09, alle ore 09:26, Magnus Lönnroth ha scritto:

> I don't have first hand experience using MIME digests as a content  
> provider, but I'll take your word for it concerning the usefulness.  
> So my comment about multi-part MIME digest being irrelevant to  
> content providers stands corrected.
>
> The scenario I am familiar with is delivering fairly standard XHTML  
> content with ~10 or so inlined images per page (as well as inlined  
> CSS) in a proxy model (we make the proxy). In this scenario we can  
> achieve the biggest performance improvements if we do "smart"  
> packaging, i.e. if we know that a specific image was delivered in  
> the previous page we can avoid packaging it in the current request  
> (depending of course on the device's capabilities). As I mentioned  
> in my first response, if we just package the complete digest with  
> each request, the performance gain is questionable (which is in  
> line with Luca's view), unless of course latency in the specific  
> situation happens to be truely horrendous (which fortunately is  
> getting rarer).
>
> I still don't think my example has any major relevance for BP, I  
> just brought it up in order to illustrate that multi-part MIME  
> digests are still very much used in a slightly broader context.
>
> thanks,
>
> Magnus Lönnroth
> Head of Development
> Service Delivery & Provisioning, Ericsson ///
>
> From: John Hardi [mailto:john.hardi@motricity.com]
> Sent: Wednesday, May 27, 2009 8:18 PM
> To: Magnus Lönnroth; Tom Hume
> Cc: Luca Passani; Mobile Web Best Practices Working Group WG
> Subject: Re: ACTION-961: usefulness of multipart-mixed
>
> Magnus & Tom,
>
> While not a regular contributor, I did want to add a bit of  
> perspective on this topic.
>
> First I must concur with Magnus that MIME multipart is still in use  
> and can improve the user’s experience in page load times as a round- 
> trip latency reduction tool.  While it can be a network  
> optimization as Magnus describes, the benefit is actually greater  
> if done at the page source, thus eliminating the multiple round  
> trip latencies between the mobile network gateway / proxy and the  
> CP as well as from the handset across the mobile network.
>
> Sprites / Composite images are not comparable; they only offer  
> improvement for static, decorative images.  If the multiple images/ 
> parts of a page are dynamic content (news photos, album art, etc.)  
> multipart still provides benefit where sprites would not.  It also  
> provides the delivery performance benefits of embedded CSS with the  
> flexibility of a linked style sheet.
>
> Being a content type, use of multipart is independent of Content- 
> Encoding.  So it’s not required that multipart payloads be gzipped,  
> though doing so may be worthwhile where it is also supported by the  
> device.
>
> There are cases, as Luca describes, where devices advertise support  
> in HTTP headers but don’t necessarily handle it well.  So device  
> awareness and the ability to override the devices’ claim of support  
> is necessary.  However, I don’t believe this is significantly  
> different from other advertised device / browser capabilities (CSS2  
> positioning, for example).
>
> The degree of difficulty may make multipart debatable as a best  
> practice, but I don’t consider it irrelevant “from the content  
> provider’s point of view”.
>
> Hope this helps...
>
> John Hardi
> Dir, Technology Strategy
> Motricity, Inc.
>
> On 5/27/09 12:22 AM, "Magnus Lönnroth"  
> <magnus.lonnroth@ericsson.com> wrote:
>
> Yes, I'm referring to HTTP responses. A proxy is needed. URL- 
> rewriting is needed. I'm not sure if the context for my response  
> was appropriate - I was just reacting to the previous statements  
> saying that packaging content in multi-part MIME digests was kind  
> of obsolete. >From the content provider's point of view MIME multi- 
> part digests are irrelevant and have probably always been so. From  
> the service provider's point of view it's still an important  
> network level optimization. But it should be completely transparent  
> and hence most likely not part of a best practices discussion.  
> Sorry if I'm confusing matters.
>
> /Magnus
>
>
>
> From: Tom Hume  [mailto:tom.hume@futureplatforms.com]
> Sent: Wednesday, May 27, 2009  8:51 AM
> To: Magnus Lönnroth
> Cc: Luca Passani; Mobile Web  Best Practices Working Group WG
> Subject: Re: ACTION-961: usefulness  of multipart-mixed
>
>
> Magnus
>
>
> Are you referring to using multi-part/mixed for HTTP responses from  
> a web  server?
>
>
>
> If so, can you explain how resources within a multi-part/mixed  
> HTTP  response are referred to from each other, or from outside the  
> response?
>
>
>
> Tom
>
>
> 2009/5/27 Magnus Lönnroth <magnus.lonnroth@ericsson.com>
>
> Hi,  delivering multi-part MIME digests has been and still is an  
> important part  of optimizing performance in our installations. The  
> main reason for  developing this is the latency in 3g networks  
> compared to wired broadband or  wi-fi. It must of course be fully  
> transparent and not affect content or  content design in any way.  
> One important aspect is to have detailed  knowledge of the device's  
> own caching capabilities and support for digests  so that  
> subsequent deliveries not include content that is already  
> available  (cached) on the handset. If full digests are delivered  
> with each request I  agree that the benefit is questionable. But if  
> you have a good  implementation with device knowledge the  
> improvement is  significant.
>
> thanks,
>
> Magnus  Lönnroth
> Head of Development
> Service Delivery & Provisioning,  Ericsson ///
>
>
>
>
> > -----Original Message-----
> > From: public-bpwg-request@w3.org
> >  [mailto:public-bpwg-request@w3.org] On  Behalf Of Luca Passani
> > Sent: Tuesday, May 26, 2009 11:49 PM
> >  To: Mobile Web Best Practices Working Group WG
> > Subject: Re:  ACTION-961: usefulness of multipart-mixed
> >
> >
> > Multipart  was a useful mechanism to deliver a full page in one  
> shot.
> > Vodafone  leveraged multipart for its vodafone live service on
> > devices which  supported it. Multipart allowed for snappy (or at  
> least
> >  "2002-snappy") display of the top page, which looked great as
> >  compared to everything WAP had represented until that day.
> > There was  no way to know whether multipart was properly
> > supported by a device,  except testing on that device.
> > Notably, many devices declared  multipart support in headers
> > and UAProfs, but the information was  not reliable at all. I
> > recall that I never managed to get multipart  to work on a
> > Nokia device (still vaguely curious about whether there  was a way).
> > Vodafone maintained its own db with this info for  devices in
> > its portfolio. Not sure if they still do. Probably not.  Too
> > much effort for too little value.
> >
> > 3G networks  and faster browsers make the use of multipart
> > much less relevant,  particularly because pages become much
> > harder to build and maintain  if multipart is in the middle. I
> > made space for multipart in WURFL  back in 2003, but the
> > community did not really follow: nobody was  using it obviously.
> >
> > Luca
> >
> > Tom Hume  wrote:
> > > I took an action a couple of weeks ago to look into  multipart/ 
> mixed
> > > MIME types, to see if they might be usefully  related to
> > sections 3.4.6
> > > and 3.4.7 of MWABP[1]  (ACTION-961). In particular it would seem
> > > helpful to be able to  bundle many images up into a single HTTP
> > > request, avoiding  unnecessary round trips to download a set
> > of them.
> > > The  current advice is to combine related images into a single  
> file,
> > >  download this, and use CSS positioning and clipping to
> > render parts  of
> > > this file. multipart/mixed would provide another route  for
> > downloading
> > > many resources at once.
> >  >
> > > The only reference I can find to mobile usage of  multipart- 
> mixed is
> > > this tutorial from OpenWave:
> >  >
> > >
> > http://developer.openwave.com/dvl/support/documentation/ 
> technical_note
> >  > s/multipart.htm
> > >
> > > From running this experiment  with desktop browsers, multipart- 
> mixed
> > > doesn't seem to be well  supported. I've set up an HTTP response
> > > matching the above and  found that:
> > >
> > > - Firefox and Opera render the second  page in the message
> > > - Safari doesn't recognise it as HTML and  downloads it
> > > - IE renders content from both pages
> >  >
> > > I've also got a question of how, from within CSS or  similar, an
> > > individual part of a multipart-mixed message might  be uniquely
> > > referred. The only reference I can find for a  URL-scheme for such
> > > things is a scheme for references to body  parts of messages,  
> which
> > > date back to 1997 or earlier, and seem  to be designed with
> > HTML email
> > > in mind:
> > > http://www.ietf.org/rfc/rfc2392.txt
> > >
> >  > Beyond the Openwave tutorial, and the following tool which
> >  exists to
> > > create these messages:
> > >
> > > http://www.umts-tools.org/docs/multipart/
> >  >
> > > ...I can't find any other reference to them; and it's not  a
> > technique
> > > I've come across myself. Am I missing  something obvious here?  
> From
> > > where I'm sitting this looks like  a barely-used, poorly-  
> supported
> > > technique which I'd hesitate  to consider a best practice -
> > though it
> > > might be handy  if it worked.
> > >
> > > Tom
> > >
> > > [1] http://www.w3.org/TR/2009/WD-mwabp-20090507/#d1e8981
> >  >
> > > --
> > > Future Platforms: hungry and foolish since  2000
> > > work: Tom.Hume@futureplatforms.com
> >  > <mailto:Tom.Hume@futureplatforms.com>  play: tomhume.org  
> <http://tomhume.org>
> >  > <http://tomhume.org>
> > >
> >  >
> >
> >
> >
>
>
>