W3C home > Mailing lists > Public > xml-dist-app@w3.org > April 2001

[Robert.Herriot@pahv.xerox.com: Two new drafts: Multipart/Interleaved and Application/BatchBeep]

From: Mark Nottingham <mnot@akamai.com>
Date: Mon, 16 Apr 2001 15:14:54 -0700
To: XML Distributed Applications List <xml-dist-app@w3.org>
Message-ID: <20010416151453.H11508@akamai.com>


FYI; may be interesting in the context of SOAP with attachments for
small devices (or not).


----- Forwarded message from "Herriot, Robert" <Robert.Herriot@pahv.xerox.com> -----

Date: Mon, 16 Apr 2001 12:36:12 -0700
From: "Herriot, Robert" <Robert.Herriot@pahv.xerox.com>
To: discuss@apps.ietf.org
Subject: Two new drafts: Multipart/Interleaved and Application/BatchBeep
X-Mailer: Internet Mail Service (5.5.2653.19)

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
--------------------------------------------------------------------
The following is the abstract for the Multipart/Interleaved draft.
The Multipart/Interleaved content-type, like the Multipart/Related
content-type, provides a mechanism for representing objects that consist of
multiple components.  Each body part of a Multipart/Related entity
represents a component, whereas each body part of a Multipart/Interleaved
entity represents either a component or a part of a component. A body part
that represents a part of a component has the content-type of
Application/Chunk. With Multipart/Related, a body part and its reference in
some other body part may be separated by many octets -- more octets than a
memory-constrained device can deal with. With Multipart/Interleaved, a body
part can represent a part of a component. This allows a body part and its
reference in some other body part to be made quite close -- close enough for
a memory-constrained device to deal with.  This document defines the
Multipart/Interleaved content-type and the Application/Chunk content-type.
It also provides examples of its use.
---------------------------------------------------------------------
The following is the abstract for the Application/BatchBeep draft.
The Application/BatchBeep content-type, like the Multipart/Related
content-type, provides a mechanism for representing objects that consist of
multiple components.  An Application/BatchBeep entity contains the wire
representation of the client-to-server part of a BEEP (Blocks Extensible
Exchange Protocol) session, which consists of sequence of frames. Each frame
contains a message or a part of a message. Each message (other than channel
0 messages) represents a component of the compound object, just as a body
part of a Multipart/Related entity represents a component. With a
Multipart/Related entity, a body part and its reference in some other body
part may be separated by many octets -- more octets than a
memory-constrained device can deal with. With an Application/BatchBeep
entity, a frame can contain part of a message. This allows a message and its
reference in some other message to be made quite close -- close enough for a
memory-constrained device to deal with.  This document defines the
Application/BatchBeep content-type. It also provides examples of its use.

----- End forwarded message -----

-- 
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA USA)
Received on Monday, 16 April 2001 18:15:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:00 GMT