At 01:11 PM 12/14/1999 , Ned Freed wrote:
> > But I guess we forgot to take the next big step, redesigning email to
> > properly scale to handling arbitrarily large messages in a relatively
> > graceful manner when necessary.
>
>I remain to be convinced that problems handling large messages have
>much if anything to do with the modern ESMTP protocol. It seems to me
>that it has a lot more to do with implementation and deployment.
Adding to Ned's response --
In fact ESMTP is getting quite good at supporting large file transfers:
(0. Pipelining isn't really relevant for bulk transfer, but it doesn't
hurt and is at least worth mentioning explicitly so no one thinks it was
forgotten.)
1. ESMTP Checkpoint/restart permits recovering from interrupted sessions;
too bad it's not well deployed
2. ESMTP Message Size Declaration permits the receiving server to declare
its limit
3. MIME Message/Partial permits fragmenting (and reassembling...) large
messages so that the Size Declaration can be honored for over-sized
messages; too bad reassembly is not well deployed
4. End-user application-to-application negotiation work being done in the
Conneg and Fax working groups is emerging; it will permit recipients to
inform senders of preferences and constraints.
Since it is a highly asynchronous channel, with potentially very high
latencies, email is a bit of a challenge for dealing with arbitrary message
sizes. The existing and emerging specifications appear to be adequate to
the task, but implementation has been slow. That is almost certainly a
question of lack of market pull.
d/
=-=-=-=-=
Dave Crocker <[EMAIL PROTECTED]>
Brandenburg Consulting <www.brandenburg.com>
Tel: +1.408.246.8253, Fax: +1.408.273.6464
675 Spruce Drive, Sunnyvale, CA 94086 USA
