Re: ACTION-961: usefulness of multipart-mixed

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> 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>
>> 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> > 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> >
>>>>  
>>>>> 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>
>>>>>> >  [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>
>>>>>> >  > <mailto:Tom.Hume@futureplatforms.com>  play: tomhume.org
>>>>>> <http://tomhume.org>  <http://tomhume.org>
>>>>>> >  > <http://tomhume.org>
>>>>>>> > >
>>>>>> >  >
>>>>>> >
>>>>>> >
>>>>>> >
>>>>> 
>>>> 
>>>> 
> 
>