I believe this document should not be approved for Proposed Standard,
for the following reasons (in no particular order)
1. It adds a lot of complexity to SMTP clients and servers that
implement it, and in exchange they get a model which is rather limited
and inflexible. Experience suggests that when someone tries to do this
they're solving the wrong problem, and they need to try a different
tack.
2. Imposing separate quotas for different kinds of media seems to be of
limited applicability.
3. The proposed extension interacts poorly with multipart/alternative
In many recipient environments (eFax, voice mail, pager, IM) the
potential exists to send a message in alternative formats and to allow
the recipient (or the recipient's MUA, or an MTA acting on behalf of the
recipient) to choose which content to convey to the recipient. For
instance, the same message could be conveyed by each of voice, image,
and text using MIME multipart/alternative. If the message were being
received by a voice mail system, the image and text portions might be
discarded on receipt by the voice mail system's MTA. But if that MTA
rejected a message because it contained images, the message would be
bounced even though the MTA could have conveyed the message to the
recipient.
More generally, rejecting on the total size of content might not
be appropriate when some of those attachments might be discarded
by the recipient, or converted to an alternate format by the reciving
MTA. If the same audio clip were sent using three different codecs, the
receiving MTA might choose to store only one of those. The sum of the
sizes of those attachments may not be relevant; what's relevant is the
size of the single attachments that is actually stored. Similarly
if the same text were sent in three different languages (using
multipart/alternative with content-language body part header fields),
the sum of the text sizes is not relevant; what's relevant is the size
of the text in the language preferred by the recipient.
4. The proposed extension interacts poorly with current and proposed
content negotiation mechanisms.
There are many reasons why an MTA, especially an MTA acting on behalf
of a recipient, might reject a message, or - more to the point -
modify a message (with the recipient's permission) before delivering
it to a recipient. These involve not only sizes of the media contained
in the message (byte count, physical dimensions, duration, etc.) but
also the kinds of encodings used (compression, codecs), the number
of colors, the resolution, sampling rate, etc. A message might be
of reasonable size after a recipient-authorized conversion, even if
it appeared to be too large as transmitted on-the-wire.
The possibility also exists that a receiving-MTA, acting with a
recipient's authorization, could authorize the sending MTA to
perform conversions on its behalf. In this case the MEDIASIZE
extension and the conversion could send conflicting messages.
It makes far more sense to have a general purpose content-
negotiation/conversion/rejection scheme than to address one aspect of
content-negotiation (size in this case) separately from the others.
5. The proposed extension overloads the SIZE keyword defined in
RFC 1870.
While it might appear that this only affects mutually consenting
parties and there is no harm done, experience suggests that this
is dubious for two reasons. One is that bugs do occur and
implementations have been known to use extensions without properly
negotiating them. Another is that firewalls are known to exist which
impose syntactical restrictions on SMTP parameters. Changing the
format of the SIZE parameter invites both kinds of failures for no
good reason.
Keith