In message <QgX=scq0M2UDMcoiou(_at_)thumper(_dot_)bellcore(_dot_)com> on
09/08/93(02:00:24)
you Nathaniel Borenstein <nsb(_at_)thumper(_dot_)bellcore(_dot_)com> wrote:
|I'm very sorry that some mail from Yutaka Sato has gotten overlooked in
|the midst of everyone's summer vacations:
The original subject was "Robustness of message/partial" :-)
|> I hope the message/partial type to be more ROBUST against some ill
|> mannered MTAs and MUAs which automatically insert something before
|> or after a message body.
|
|> For example, I know a mail-list handler and a mail-to-news gateway,
|> which insert additional information at beginning of bodies of resent
|> messages. And "Inews" appends ".signature" file at the end of
|> article body.
|
|> Can I save partial messages from such destructions ?
|
|> If there is no way to do so, I wish some extension to be added to
|> the spec. of message/partial, or need new content type like
|> "MESSAGE/ROBUST-PARTIAL" to be introduced. I think the most
|> naive solution is introducing "boundary" parameter to the partial
|> message, and wrap up the message body with the defined boundary.
|
|> (Such MTAs/MUAs are also harmful to all of basic content-types like
|> audio and image, but they can be saved by enclosing them in a
|> multipart message.)
|
|I think this message is worth answering, but I don't see any good
|answer. In particular, I haven't been able to come up with a better
|answer than "the programs that do these things should be made
|MIME-smart." I think that a message/robust-partial would be a major new
|complication to MIME at this point. Does anyone have any other ideas?
|
|The only other one that occurs to me is wrapping each message/partial up
|as a one-part multipart message, since multipart has this robustness
|quality you seek. Note that in these casees, the things prepended or
|appended to the body will be thrown away, so this still doesn't change
|the general advice that it would make sense to update these programs and
|make them MIME-smart.... -- Nathaniel
Although I think your idea is good, I can point out a problem of it.
It may make automatic collection of partial messages expensive because
we must peep the body of each message to examine if it is a partial
message of the currently assembling message.
But practically, it will not be so expensive because we can get hints
from the Subject field before investigating the body part header to
get the parameters "id" and "number" of the encapsulated partial
message.
I prefer your idea to mine.
Yutaka
--
Yutaka Sato <ysato(_at_)etl(_dot_)go(_dot_)jp>
Information Base Section
ELECTROTECHNICAL LABORATORY
1-1-4 Umezono, Tsukuba, Ibaraki, 305 Japan