At 12:11 PM 7/28/97 -0700, Ned Freed wrote:
I think application/mime and application/signed that allow binary encoding
inside are a nonstarter. I for one will certainly object to such a
specification getting registered, let alone being placed on the standards
track, and I suspect I will not be alone. I would not mind
application/mime and
application/signed that allow for recursive encoding of all but binary leaf
objects, but I doubt if my personal preferences matter much here -- the
obstacles that have to be overcome here would be huge. Frankly, I think that
this group is doomed to destruction if it pursues this course -- asking the
IESG to charter a group after failing to meet the stated criteria the IESG
said
the group had to meet is one thing -- the IETF is nothing if not flexible --
but then asking to grant that group the authority to pry open one of the most
important application-level standards and change it in ways that will almost
certainly reset it to proposed status boggles my mind.
I left most of the above paragraph intact because I suspect that a
number
of people have similar impressions of the application/mime specifications
and I want to lay some points to rest.
App/Mime was written without attention to the recursive encoding
problem.
Sorry 'bout that, but I missed the isue. I believe it also escaped the
others who participated in discussions about it. So, at the least there is
really and truly no intention to alter MIME fundamentals. We can quibble
about the purity of Application/* but we cannot quibble about such
fundamental issues as rules for encoding. So, to paraphrase Ned's comment,
any effort to have Application/Mime alter basic processing rules for MIME
is a non-starter.
Observing that App/Mime is really an aggregage object in sheep's
clothing
is quite useful. The whole idea was simply to wrap a Mime object up, but
the ramifications of its being an aggregate object were not considered
nearly as carefully as (now obviously) necessary.
The idea for app/mime comes from several different discussions and
contexts. It isn't just trying to solve a problem for one "customer" but
several. The need to tunnel objects is often necessary, so it's no great
shock that Mime, too, can use such a mechanism. It would be a shame to
invent a series of specialized tunneling mechanisms, when one will do the
job. This, of course, assumes that we can make the one do the job correctly.
We already have rules for aggregate objects. As I queried in the fast
note I sent before getting on a plane (the riding on which I am doing as I
type this) it seems to me that the simplest way to solve this quandary is
to apply the same rules for encoding data in app/mime as, say,
multipart/mixed.
To the extent that this idea is fatally flawed, I suggest that we still
need a general wrapping mechanism and need, therefore, to find a response
to the coding scheme which is sufficient to the task and, of course, which
does not in any way alter the basic Mime specification.
d/
ps. I note that this thread is on ietf-smime, rather than ietf-types.
Being loathe to copy two lists, I nonetheless fear that -types should be
participating in this discussion.
--------------------
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