W3C home > Mailing lists > Public > public-bpwg@w3.org > May 2009

Re: ACTION-961: usefulness of multipart-mixed

From: Luca Passani <passani@eunet.no>
Date: Thu, 28 May 2009 23:56:07 +0200
Message-ID: <4A1F0877.3010401@eunet.no>
To: John Hardi <john.hardi@motricity.com>
CC: Mobile Web Best Practices Working Group WG <public-bpwg@w3.org>

John, I just happened to have a N95 8Gb in my drawer, so I hit your site 
with it. The XHTML was there, but none of the pictures were loaded.



This checks out with what I was experiencing with multipart/mixed on 
Nokia devices back in 2003-2004 with Nokia 3650 and 6600, which, in 
turn, made me conclude that accept header and UAProf were a totally 
unreliable source of information to decide which devices can manage 
multipart.
I am sure that Ericsson does it well because they do actual testing with 
devices.

Luca

John Hardi wrote:
> Tom,
>
> We developed it in-house and I don't have an open source code example 
> I can point you to.  If you want to see it in operation, the "dogfood" 
> site for our platform m.mcore.com has multipart enabled.  If you go 
> there with a multipart-capable device, you should get a multipart payload.
>
> If you have curl, this should get you today's home page in multipart:
> curl -H "Accept: 
> text/html,application/xhtml+xml,application/xml,multipart/mixed" -A 
> "Mozilla/5.0 (SymbianOS/9.2; U; Series60/3.1 NokiaN95_8GB-3/20.2.005 
> Profile/MIDP-2.0 Configuration/CLDC-1.1 ) AppleWebKit/413 (KHTML, like 
> Gecko) Safari/413" http://m.mcore.com/motricity/ptl/px/home/i.aspx
>
> An unscientific snapshot from one set of web servers showed a bit over 
> half the mobile pages being delivered in multipart.
>
> As I mentioned in my original post, the degree of difficulty for 
> multipart may  make it unsuitable as a "best practice" recommendation. 
>  It's use is probably most suitable for sites where performance is 
> critical and worth the investment.  But I did want to address the 
> misconceptions that multipart being archaic or only being used in 
> network components.  It is a viable technique which addresses some of 
> the considerations of sections 3.4.5 and 3.5.2 of the best practices.
>
> John
>
> On 5/28/09 12:38 AM, "Tom Hume" <tom.hume@futureplatforms.com> wrote:
>
>     John
>
>     Do you have some example code for this sort of thing, or can you
>     point me at some?
>
>     Tom
>
>     2009/5/27 John Hardi <john.hardi@motricity.com>
>
>         Tom,
>
>         >From a CP POV, one would use it  to improve performance of
>         pages which have a number of frequently changing  dynamic
>         content parts (i.e. images).
>
>         By using the absolute URI/URL of a resource for the
>         Content-Location header URI of its part , you shouldn't need
>         to change the references in the base (X)HTML part.  This
>         allows a packaging filter on the front of your web server's
>         page processing to handle it in a fairly generic fashion.  In
>         general, I think this is consistent with RFC 2557.  As for
>         support, it's fairly broad --- certainly more broad than CSS2,
>         though that hopefully won't remain the case.
>
>         John
>
>
>         On 5/27/09 12:46 PM, "Tom Hume" <tom.hume@futureplatforms.com
>         <http://tom.hume@futureplatforms.com> > wrote:
>
>             John
>
>             How, from a content provider POV, does one make use of
>             this? How would I refer to a specific resource within a
>             multi-part/mixed response - using some sort of URL scheme?
>             And how well supported is this, in your opinion?
>
>             Tom
>
>             2009/5/27 John Hardi <john.hardi@motricity.com
>             <http://john.hardi@motricity.com> >
>
>                 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
>                 <http://magnus.lonnroth@ericsson.com>
>                  <http://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
>                         <http://magnus.lonnroth@ericsson.com>
>                          <http://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
>                             <http://public-bpwg-request@w3.org>
>                              <http://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
>                             <http://Tom.Hume@futureplatforms.com>
>                              <http://Tom.Hume@futureplatforms.com>
>                             >  > <mailto:Tom.Hume@futureplatforms.com>
>                              play: tomhume.org <http://tomhume.org>
>                              <http://tomhume.org>  <http://tomhume.org>
>                             >  > <http://tomhume.org>
>                             > >
>                             >  >
>                             >
>                             >
>                             >
>
>
>
>
>
>
>
Received on Thursday, 28 May 2009 21:56:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:43:00 UTC