At 09:08 AM 8/1/97 -0700, Ned Freed wrote:
Well, I for one disagree with this assessment. The problem with having two
formats is that it then becomes a matter for the sender to choose which
one to
use. And that's simply wrong -- this choice cannot in general be made
At base, I strongly agree with you. The reason for suggesting a
construct
like application/mime was to make sure that we COMPLETELY SEPARATE the
structuring/labeling activites for real data service, like s/mime, from
peculiar transport situations, such as needing to bullet-proof. That's why
content-transfer-encoding is separate from content-type.
I am not as sure as Ned about the ultimate and complete failure of
any/all
bullet-proofing. My guess is that it can be useful on a small scale and
disastrous on a large scale. But I am very certain that the the issue must
be dealt with separately from the semantic efforts, as for s/mime.
Let's be clear: There is nothing about s/mime which requires two ways
of
doing the same thing.
There ARE differences in particular communications scenarios which need
additional bullet-proofing. Such bullet-proofing needs to be achieved --
assuming it can work at all -- by one or more separate mechanisms.
app/mime is an experiment. there is no question that some gateways will
know about it and mess with it. At a minimum, the purpose of the
bullet-proofing is to serve as a very clear label to keep one's processing
mits off this thing unless the software knows what it is doing.
mulipart has a default handling defined. it is fine for many situations
and is proving to be a problem for others. that's what app/mime tries to
respond to.
if the approach to bullet-proofing used by app/mime works, there needs
to
be onlyone way of doing it, for a variety of data types. If it doesn't
work, we need to be able to back out from using it easily. If we have this
approach to bullet-proofing implemented deeply into each of several
different semantics efforts, we won't be able to back out.
d/
--------------------
Dave Crocker
Internet Mail Consortium +1 408 246 8253
675 Spruce Dr. fax: +1 408 249 6205
Sunnyvale, CA 94086 USA info(_at_)imc(_dot_)org ,
http://www.imc.org
Member, interim Policy Oversight Committee http://www.gtld-mou.org