ned+ietf-822(_at_)mrochek(_dot_)com wrote:
the use of content-disposition filenames is seen by many of us as such
an egregious offense.
A receiver using the suggested filename to determine the content type
is indeed egregious; only the content-type should be used for that. A
receiver blindly using the suggested filename when saving to a file,
even if that filename is inconsistent with the content type according
to local naming rules, is also wrong. But I see nothing wrong with a
receiver using the suggested filename for its stated purpose (RFC 2183
section 2.3): as a starting point for constructing a suitable default
filename.
See RFC 2048 section 2.2.1. It really could not be clearer.
Thanks for the reference. Actually, it could be clearer. It says:
Media types must function as an actual media format: Registration of
things that are better thought of as a transfer encoding ... is not
allowed.
The problem is that compression is neither a media format nor a transfer
encoding. A transfer encoding is an encoding needed to allow the
message to conform to the transport requirements. Compression is not
needed for that. The purpose of compression is to save resources, not
only during transport but perhaps also before transport (on the original
sending host) and after transport (on the final receiving host). It's
quite likely that the file being attached was already compressed before
the sending MUA ever saw it, so it's hardly a "transfer encoding".
HTTP had the right idea with Content-Encoding. It's too bad that it's
too late for MIME to use that model.
AMC