Bruce Lilly <blilly(_at_)erols(_dot_)com> wrote:
It's actually worse than that; there are other transformations
unrelated to transport transparency that one might perform on content.
List syntax might be a cleaner fit to existing paradigms
Good points.
An approach along the lines of RFC 2633 could be used...
Yet another approach would be...via a multipart encapsulation.
Correct me if I'm wrong, but I think these approaches would obscure the
actual media type. For example, given a Postscript attachment that is
transformed somehow (signed, say) and then compressed, the receiver
cannot know that it's Postscript without first decompressing it.
Here's a revision of my earlier proposal that tries to address your
concerns above.
Content-Type: meta/encoded
Content-Encodings:
foo; param=value; param=value,
bar; param=value; param=value,
gzip
Content-Decoded-Type: application/postscript
Content-Disposition: attachment; filename="hello.ps.foo.bar.gz"
Content-Transfer-Encoding: escaped-8bit
The new top-level media type "meta" is for messages whose type
information is to be found in new Content-* fields. The type
meta/encoded means that the actual type information is in the fields
Content-Encodings and Content-Decoded-Type. A receiving MUA unaware of
meta/encoded would treat it as application/octet-stream, which is safe.
AMC