In message
<9907271056(_dot_)ZM3873(_at_)cbmail(_dot_)cb(_dot_)lucent(_dot_)com> on
07/27/99(23:56:14)
you "Mark Horton" <mark(_at_)lucent(_dot_)com> wrote:
|It seems that a new MIME standard for content-transfer-encoding that
|would indicate a compressed base64 type ala gzip could be nice.
I think the standard should satisfy followings:
- Content-Type must indicate the type of the body properly (of course)
- any combination of Content-Type and C-T-Encoding should be possible
- any order of recursive (nested) C-T-Encodings should be applicable
Maybe I reinvented something rejected in past but I'm curious why using
message/rfc822 for nested encoding is not good. For example, I think
we can send gziped text encoded in base64 like this:
Content-Type: message/mime
Content-Transfer-Encoding: base64
<base64-encoded-body>
where the <base64-encoded-body> is decoded into a MIME message like this:
Content-Type: text/plain
Content-Transfer-Encoding: x-gzip
<gzip-encoded-body>
Cheers,
Yutaka
--
Yutaka Sato <ysato(_at_)etl(_dot_)go(_dot_)jp> http://www.etl.go.jp/~ysato/ @
@
Computer Science Division, Electrotechnical Laboratory ( - )
1-1-4 Umezono, Tsukuba, Ibaraki, 305-8568 Japan _< >_