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

RE: ACTION-961: usefulness of multipart-mixed

From: Magnus Lönnroth <magnus.lonnroth@ericsson.com>
Date: Wed, 27 May 2009 09:22:40 +0200
Message-ID: <9520E66537CC4941994C518E3E21091C012B5FA7@esealmw105.eemea.ericsson.se>
To: "Tom Hume" <tom.hume@futureplatforms.com>
Cc: "Luca Passani" <passani@eunet.no>, "Mobile Web Best Practices Working Group WG" <public-bpwg@w3.org>
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.


	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

	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?

	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.
		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>
		> >
		> >

	Future Platforms: hungry and foolish since 2000
	work: Tom.Hume@futureplatforms.com play: tomhume.org
Received on Wednesday, 27 May 2009 07:23:17 UTC

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