W3C home > Mailing lists > Public > public-html@w3.org > January to March 2007

Re: Multipart response support

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 29 Mar 2007 15:48:54 +0200
Message-ID: <460BC3C6.1080505@gmx.de>
To: Henrik Dvergsdal <henrik.dvergsdal@hibo.no>
CC: public-html@w3.org

Henrik Dvergsdal schrieb:
> 
> 
> On 29. mar. 2007, at 12.27, Julian Reschke wrote:
> 
>> But that's not an HTML feature, but a browser feature. IE already 
>> supports it, and the spec is at <http://tools.ietf.org/html/rfc2387>. 
>> You may want to lobby for an update of that spec, and for support in 
>> Mozilla, but that really isn't something for the HTML WG (imho).
> 
> That RFC just describes the multipart/related MIME content type. What 
> feature are you referring to?

Sorry, you also need <http://tools.ietf.org/html/rfc2557>, which defines 
"MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)" on top 
of multipart/related.

> What *is* something for the HTML WG, however, is to decide wether or not 
> we should extend the syntax of some href and src attributes to accept 
> references to attachments. Who else should make that kind of decisions?

As far as I can tell, the HTML WG doesn't need to define this as long as 
it doesn't appear in documents of type text/html. Thus the usage of 
multipart/related in the MTHML format.

> Pre-loading:
>> You can already do that with "data" URIs
> 
> I realize that everything that can be done with multipart responses can 
> also be done with data URI's - at least in principle. The only problem 
> is the size limitation and the reduced readability of the HTML document.

AFAIK, the size of encoding in data URIs will be the same as with 
multipart/related; both require some kind of escaping.

I'm not sure about the readability requirement - didn't you want to make 
this harder to read for the recipient anyway? :-)


> Generated content in server side applications:
>> Can you explain how you need "separate applications" for that?
> 
> If you want to ouput a image that is generated on the fly, say a clock 
> or map something, you have to create a separate application that outputs 
> that image. You then refer to the URL of that application in the src 
> attribute of the img element.
> 
> Alternatively you may include the image by means of a data URI. What I 
> suggest is to provide an opportunity to include it in an attachment and 
> refer to that attachment in the src attribute.

Understood, but it's a mystery to me how these choices affect the number 
of applications involved to do that...

Best regards, Julian
Received on Thursday, 29 March 2007 13:49:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 29 March 2007 13:49:11 GMT