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

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

From: Herriot, Robert <Robert.Herriot@pahv.xerox.com>
Date: Mon, 16 Apr 2001 16:37:20 -0700
Message-ID: <51B8ABCE456FD111899900805F6FD6EE0BC3C0CB@mercury.ADOC.xerox.com>
To: Keith Moore <moore@cs.utk.edu>, "Herriot, Robert" <Robert.Herriot@pahv.xerox.com>
Cc: discuss@apps.ietf.org

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

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

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