W3C home > Mailing lists > Public > ietf-discuss@w3.org > April 2001

Re: Two new drafts: Multipart/Interleaved and Application/BatchBeep

From: Martin Duerst <duerst@w3.org>
Date: Tue, 17 Apr 2001 12:31:43 +0900
Message-Id: <4.2.0.58.J.20010417122726.05c2de80@sh.w3.mag.keio.ac.jp>
To: "Herriot, Robert" <Robert.Herriot@pahv.xerox.com>, discuss@apps.ietf.org
One possible solution to the problem described would be to take
the XML document, cut out suitable pieces and put them into
separate external entities, change the remainder of the XML document
appropriately, and then use plain old Multipart/Related,
with the core XML document first, and then the separated-out
entities and the gifs interleaved as appropriate. For external
entities, see http://www.w3.org/TR/REC-xml#sec-external-ent.

Regards,   Martin.


At 12:36 01/04/16 -0700, Herriot, Robert wrote:
>I recently published two drafts
>
>
>http://www.ietf.org/internet-drafts/draft-herriot-multipart-interleaved-00.t
>xt
>
>http://www.ietf.org/internet-drafts/draft-herriot-application-batchbeep-00.t
>xt
>
>(Note that the first draft is not available via the Internet Drafts Search
>engine, but is accessible via the URL supplied above).
>The problem that motivates these two proposals is the case of an XML
>document with attachments, such as gif images. Normally, a Multipart/Related
>representation would suffice. The first body part would be the XML and the
>remaining body parts would be gif images, each referenced from the XML. But
>when a memory constrained printer encounters a reference to a gif image body
>part in the XML, it might not have the space to hold the remaining XML while
>it scans ahead for the gif image. This problem suggests the need to be able
>to interleave chunks of XML and gif images. Each of the two drafts provide a
>solution for interleaving chunks.
>Both drafts define new MIME types. The first draft defines
>Multipart/Interleaved and Application/Chunk content types, which extend
>Multipart/Related for use with memory constrained devices. The second draft
>defines Application/BatchBeep content type, which defines a MIME type whose
>contents is the client-to-server portion of a BEEP session.  Although the
>two drafts are based on two very different ideas, the examples show that the
>two solutions are nearly byte-for-byte identical. The primary difference is
>that the boundary string in the Multipart/Interleaved solution is a trailer
>and/or header in the Application/BatchBeep solution.
>I would appreciate any comments on these drafts.
>Bob Herriot
Received on Tuesday, 17 April 2001 00:46:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:38:01 UTC