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

Fwd: New Internet Drafts for Interleaved XHTML and Images

From: Jean-Jacques Moreau <moreau@crf.canon.fr>
Date: Thu, 29 Mar 2001 10:07:41 +0200
Message-ID: <3AC2ED4C.EECE3B22@crf.canon.fr>
To: "xml-dist-app@w3.org" <xml-dist-app@w3.org>
Dear all,

FYI, and possible input to the "binary/application data" issue.

Jean-Jacques.

-----
Robert Herriot, Xerox, has developed two different approaches to
solving
the problem of interleaving XHTML with images. They have been
submitted
as Internet-Drafts to the IETF.

The first draft is entitled: "The MIME Multipart/Interleaved and
Application/Chunk Content-types":

   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 second draft is entitled: "The MIME Application/BatchBeep
Content-type":

   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.


Received on Thursday, 29 March 2001 03:08:30 GMT

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