Claus Färber <list-ietf-rfc822(_at_)faerber(_dot_)muc(_dot_)de> wrote:
Content-Type: application/message-partial; number=1; total=1;
id="sdfvwef34rzsdkvchn(_at_)example(_dot_)com"
Content-Transfer-Encoding: 8bit
Content-Type: application/postscript
Content-Disposition: attachment; filename="hello.ps"
Content-Transfer-Encoding: quoted-binary; foo="bar"
Content-Encoding: gzip (from HTTP)
Content-Required-Fields: Type, Transfer-Encoding, Encoding (list of
fields which a EMIME parser must know to fully decode the
entity)
The advantage of this is: If it crosses the border to the non-8bit
world, everything inside the enclosing entity can be encoded with qp
or base64.
...by an agent that doesn't know about quoted-binary. That's a nice
feature. And you can encapsulate another application/message-partial if
you want to apply another Content-Encoding. The drawback there is that
you won't be able to see the ultimate Content-Type without undoing the
encodings of all but the innermost encapsulation.
I don't know whether I prefer the encapsulation approach or the
meta approach, but we might as well see how good we can make them
both. Here's another revision of the meta approach that provides the
recodability feature:
Content-Type: meta/encoded
Content-Decoded-Type: application/postscript
Content-Encodings:
foo; param=value; param=value,
bar; param=value; param=value,
gzip
Content-Transfer-Encodings:
blah; param=value,
escaped-8bit
Content-Disposition: attachment; filename="hello.ps.foo.bar.gz"
Content-Transfer-Encoding: 8bit
The type meta/encoded means that the object type, object encodings, and
message encodings are all supplied by three new header fields. The very
last message encoding goes in the Content-Transfer-Encoding field (and
is omitted from the Content-Transfer-EncodingS field) only if it is
one of the original well-known encodings (quoted-printable or base64),
otherwise the Content-Transfer-Encoding field is used only to describe
the body format (7bit, 8bit, or binary).
AMC