Re: ACTION-961: usefulness of multipart-mixed

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