RE: ACTION-961: usefulness of multipart-mixed

I don't have first hand experience using MIME digests as a content provider, but I'll take your word for it concerning the usefulness. So my comment about multi-part MIME digest being irrelevant to content providers stands corrected. 
 
The scenario I am familiar with is delivering fairly standard XHTML content with ~10 or so inlined images per page (as well as inlined CSS) in a proxy model (we make the proxy). In this scenario we can achieve the biggest performance improvements if we do "smart" packaging, i.e. if we know that a specific image was delivered in the previous page we can avoid packaging it in the current request (depending of course on the device's capabilities). As I mentioned in my first response, if we just package the complete digest with each request, the performance gain is questionable (which is in line with Luca's view), unless of course latency in the specific situation happens to be truely horrendous (which fortunately is getting rarer).
 
I still don't think my example has any major relevance for BP, I just brought it up in order to illustrate that multi-part MIME digests are still very much used in a slightly broader context. 
 
thanks,
 
Magnus Lönnroth
Head of Development
Service Delivery & Provisioning, Ericsson /// 



________________________________

	From: John Hardi [mailto:john.hardi@motricity.com] 
	Sent: Wednesday, May 27, 2009 8:18 PM
	To: Magnus Lönnroth; Tom Hume
	Cc: Luca Passani; Mobile Web Best Practices Working Group WG
	Subject: Re: ACTION-961: usefulness of multipart-mixed
	
	
	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> 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>
			 
			

				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
				>  [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> 
				>  > <http://tomhume.org>
				> >
				>  >
				>
				>
				>