RE: Two new drafts: Multipart/Interleaved and Application/BatchBe ep

Keith,

Thanks for the feedback.

I agree that existing MIME readers would treat a multipart/interleaved
entity as a multipart/mixed entity and would see all of the
application/chunk body parts are opaque data. I also agree that only updated
MIME readers could deal with multipart/interleaved and application/chunk. So
perhaps, there is no advantage in adding another multipart subtype. That's
the sort of feedback I'm looking for.

Your application/multiplexed suggestion sounds very close the
application/batchbeep that I describe in the other draft I submitted
(http://www.ietf.org/internet-drafts/draft-herriot-application-batchbeep-00.
txt).

As I see it, the issue is whether the solution should extend multipart or
whether it should be completely new. I think you are saying that it should
be completely new but easily transformable into multipart/related.  The
examples in the application/batchbeep draft show that the conversion between
application/batchbeep and multipart/related is simple. The
application/batchbeep representation also has the advantage that each chunk
has a length field rather than a boundary string to determine the end of the
chunk. Some people I've talked to want the efficiency of a length field
rather than a boundary string to search for.

What do you think of the application/batchbeep proposal?

Bob Herriot

> -----Original Message-----
> From: Keith Moore [mailto:moore@cs.utk.edu]
> Sent: Monday, April 16, 2001 3:27 PM
> To: Herriot, Robert
> Cc: discuss@apps.ietf.org
> Subject: Re: Two new drafts: Multipart/Interleaved and
> Application/BatchBeep 
> 
> 
> I only glanced at this, so maybe I misunderstood it.  However...
> given that the components of a multipart/interleaved aren't 
> likely to be
> usable by a traditional MIME reader anyway, I see little point in
> using the MIME multipart syntax to distinguish one chunk from another.
> and I don't really see a good way to build this in such a way that
> existing MIME readers are likely to deal with it well.
> 
> I would suggest a new application/multiplexed content-type which would
> be divided up into chunks, each chunk representing the next 
> consecutive
> element of some stream.  Each stream could be a MIME body part, with
> the normal header and content, but each stream could also be 
> fragmented
> as necessary.  Ideally, the semantics would be similar to multipart
> related, and it would be possible to transform an 
> application/multiplexed 
> content into an equivalent multipart/related content - just that in
> the first case the various components would be divided up into chunks
> and multiplexed into a single body part (as far as MIME was concerned)
> and in the second case the components would each appear as a separate
> MIME body part within an enclosing multipart/related.
> 
> Keith
>

Received on Tuesday, 17 April 2001 08:41:38 UTC