ietf-822
[Top] [All Lists]

Re: Content-Transfer-Encoding and yEnc

2002-04-06 12:06:44

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 05 April 2002 19:03, Charles Lindsey wrote:
<snip>
But there is another problem with a gzip CTE, which is that you may have
gzip on top of Base64, or gzip on top of yEnc, or qzip on top of whatever
else. Maybe, in an ideal world, one would define an encoding (yEnc say)
and then define a gzip option inside that.

Or maybe you could define a compression=gzip parameter that could be used
with any CTE. That would seem to be more flexible.
<snip>

More flexible, yes.

But it would also change the syntax of the header, as CTE (the header) 
currently doesn't allow parameters.
What about a list of cte's (then better dubbed 
"content-transfer-transformations") to be applied in the format
innermostCTE+...+outermostCTE
(or vice versa), so you could say
C.-T.-E: gzip+base64
meaning "first remove base64 encoding, then gunzip". The + here is chosen for 
being not tspecial (the cte identifier is a "token") and suggestive of "and" 
and of the "+xml" convention (rfc3023).
A legacy agent would parse the cte name to be the full "gzip+base64" and get 
an unknown cte, much like when plain "gzip" would be used.

I know it's uglier than introducing a "compression" parameter, but it doesn't 
change the syntax of the cte header field and gets rid of the need of 
backreferencing a classical CTE to be used with any newly defined 
(compressing) one.

The yEnc problem of where to put the CRC would also be solvable:
C.-T.-E: yenc-crc+yenc
meaning compute the crc, append (or prepend) it, then do the actual encoding 
that is yenc.
Not that I like it this way...

Marc

- -- 
Marc Mutz <mutz(_at_)kde(_dot_)org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8r0RT3oWD+L2/6DgRAkVfAKCJIZrlI/89tWe0Zb9qpRBO/NA3jQCeLCAl
gkxBseWWIlFqIHyEkSHtvpQ=
=gvK0
-----END PGP SIGNATURE-----