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

It looks like the consensus there is "or not"; I was too quick on the
forward. There was fairly decisive discussion of the issues (I'd like
to point to an archive, but I can't find one that's current; if
you're really interested, mail me).

Basically, the fact that MIME parsers would have to be substantially
rewritten, coupled with the feeling that this can be better addressed
at a different layer (e.g., transport, with BEEP) or other
techniques, means that this isn't considered a practical approach.



On Mon, Apr 16, 2001 at 03:14:54PM -0700, Mark Nottingham wrote:
> 
> 
> 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)

-- 
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA USA)

Received on Tuesday, 17 April 2001 02:10:31 UTC