--- Begin Message ---
I have been going over the latest spec and the discussion archives for
this group and have some questions that I'll try to articulate over the
next few days. My first one concerns use of message/external-body:
- Is there any reason that the body of a message/external-body entity
has to be outside of the top-level message? If not, then what is the
right way to handle it ?
There was the following message from Ned Freed:
^ Date: Thu, 11 Feb 1993 00:16:39 -0700 (PDT)
^ From: Ned Freed <NED(_at_)sigurd(_dot_)innosoft(_dot_)com>
^ Subject: RE: simplemail (formerly simpletext) and referential markup
^ To: Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu>
^ Cc: Bill Janssen <janssen(_at_)parc(_dot_)xerox(_dot_)com>,
ietf-822(_at_)dimacs(_dot_)rutgers(_dot_)edu,
^ moore(_at_)cs(_dot_)utk(_dot_)edu
^ Message-Id: <01GUKQR5ZWB08Y53Y8(_at_)SIGURD(_dot_)INNOSOFT(_dot_)COM>
^
^ > I'd be tempted to make all external references be of the form
^ > [ref: some-content-id], where the content-id must refer to a
^ > content that appears in the same message as the reference. The
^ > content-id could, however, be that of a message/external-body
content...
^ > that way any extensions to the MIME external reference mechanism are
^ > automatically incorporated into simplemail. Mail readers would have
^ > to provide hooks for this, but I'm sure other content-types will want
^ > to be able to do this kind of referencing also.
^
^ I agree with Keith on this; I think it builds nicely on the MIME
multipart
^ facilities that are already available. Note that you can also reference
a
^ Content-Id: on a multipart/alternative if multiple versions of the same
^ [sub]document are available.
^
^ I also think the ability to include a single document in multiple
places will
^ be more useful that you might think at first. The idea of providing
multiple
^ ways to navigate through information is a very powerful one.
^
^ Ned
Here's an example of potential usage. Let's say I am sending you an
image specified as a gif file. In addition, I have a 1-plane mask
specified as an xbm file that provides a nice floating effect for the
image. I have defined a new multipart type called "multipart/X-masked"
for this.
Content-type:multipart/X-masked;boundary=foo
--foo
Content-type:image/x-xbm
bitmap data here (1 k)
--foo
Content-type:image/gif
gif data here (150 k)
--foo--
If your UA understands multipart/X-masked then everythings fine. If it
doesn't then it will fall back to multipart/mixed and likely show the
1-plane bitmap followed by the gif image (I assume it will know how to
handle image/x-xbm).
So I then figure that I'll use
multipart/alternative to do the right thing such that if they don't
understand the multipart/X-masked, they will only use the image and not
the mask:
Content-type:multipart/alternative;boundary=alt
--alt
Content-type:image/gif
gif data here (150 k)
--alt
Content-type:multipart/X-masked;boundary=foo
--foo
Content-type:image/x-xbm
bitmap data here (1 k)
--foo
Content-type:image/gif
gif data here (150 k)
--foo--
--alt--
The problem then becomes one of size. I don't want to have two
copies of the image (150 k) inside the message. Here is where I use
some as yet unspecified access-type of message/external-body that
references another part by its content-id.
Content-type:multipart/alternative;boundary=alt
--alt
Content-type:message/external-body;
access-type:X-local
Content-type:image/gif
Content-id:xyz
--alt
Content-type:multipart/X-masked;boundary=foo
--foo
Content-type:image/x-xbm
bitmap data here (1 k)
--foo
Content-type:message/external-body;
access-type:X-local
Content-type:image/gif
Content-id:xyz
--foo--
--alt--
... somwhere else in the message
Content-type:image/gif
Content-id:xyz
150 k worth of gif data
This is a useful capability in its own right for intra-message
references. One additional use I see for it is to provide an implicit
table of contents capability. If all leaf nodes of a mime tree are
specified as local external references to bodies that are located at the
end of the message,then you have a table of contents. This doesn't seem
that useful if the UA is parsing thru the entire message anyway, but
there may be circumstances where being able to access just the TOC
without the leaf bodies will be useful.
The question then comes up of how to describe the bodies. Is this
covered by the Content-Disposition header with a value of "hidden"?
Gabe
--
Gabe Beged-Dov e-mail: gabe(_at_)cv(_dot_)hp(_dot_)com
Hewlett-Packard
Open Systems Software Division,
Corvallis, Oregon phone: (503)750-4415
--- End Message ---