-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wednesday 03 April 2002 04:28, Bruce Lilly wrote:
<snip>
Plan A requires no changes to existing RFCs and does not
mandate changes to existing transfer agents.
<snip>
Plan B would require an RFC to amend RFC 2045. That RFC would
need to specify "yenc" as a new token for use as a
Content-Transfer-Encoding value and would need to specify
the domain associated with that value as 8bit. That may
lead to interoperability problems:
<snip>
I know rfc2049 is vague about this, but
(3) Must treat any unrecognized Content-Transfer-Encoding
as if it had a Content-Type of "application/octet-
stream", regardless of whether or not the actual
Content-Type is recognized.
seems to indicate to me that on encountering an unknown encoding, the dafault
should be to treat the part as a blob, ie. cte = binary (interpreted) and ct
= app/octet-stream.
So the problem boils down as to what extend the deployed mailers use this
interpretation of MIME.
No necessity for a new Content-Transfer-Encoding value has been
established, as Plan A does everything that Plan B would do
without the need for a new value and without requiring wholesale
modification of transport agents. No benefit has been established,
as the encoding method and its compactness are not at issue.
Indeed, there are a number of disadvantages to Plan B, not
least of which is hindrance of interoperability.
<snip>
<insider>
I wonder how a person so picky about strict rfc compliance in mailers can
support such ugly misuses of the MIME mechanism. ;-)
</insider>
It's bad enough that there is no mechanism to correctly label {,g,b}zip'ed
parts, but now using the same broken behaviour for something that clearly is
a cte.
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
iD8DBQE8qr8q3oWD+L2/6DgRArZbAKCyU6VKt5AeS4IJYRIpAg5Ak+p2egCeKIry
UuHXjit5GVR9cHqvadZHEW0=
=luXP
-----END PGP SIGNATURE-----