ietf-822
[Top] [All Lists]

Re: Content-Transfer-Encoding and yEnc

2002-04-03 01:37:52

-----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-----