ACTION-961: usefulness of multipart-mixed

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_notes/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 play: tomhume.org