Tim's suggestion has real merit. It's an embodiment of what I suggested in
an earlier post - without being the inventor - that something as easy as
email and as flexible as ftp might be a really good idea - if we agree
there's a real problem. How does one proceed with this in IETF?
To summarize much of what's been said and to wholeheartedly throw my
(crrent) bias into it:
I continue to reject the notions:
1) People who are clueless are pathetic examples of internet humanity. At
least training should be required.
2) We need to have rules or guidelines for email.
I continue to support the ideas:
1) Users are the public now - they don't understand all the underlying
technical details. Accept it and deal with the reality. They will send
files that somebody (with good reason) will deem are "too big".
2) Focus on the real issues - not the things that happen at 3 sigma. Are
download rejections and other disruptions at 1 sigma, 3 sigma, 6 sigma?
What's an acceptable rate?
3) Users and providers alike will respond to real problems - either with
larger capabilities or smaller message content.
4) Hard drives are quite cheap. Populations are rising rapidly. File
sizes have reason to be going up as well. Pipes are getting fatter. Right
now storage spaces are limiting and pipes/access (therefore transport times)
are limiting.
So, if we need to do something, let's support at least the spirit of Tim's
idea and make something happen. First thing on the agenda should be to
decide if we need to do something - which will include at what cost? to
what benefit? for how long (i.e. will the need disappear before the
solution appears)? I'm not suggesting a flurry of emails to address these
questions right here and now. I'm suggesting a bit more deliberate process
to deal with it.
Fred Marshall
Mission Systems, Inc.
http://fcmarshall.home.mindspring.com
http://expert-market.com/pengroup/missionsystems/index.html
----- Original Message -----
From: Tim Dierks <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, December 16, 1999 4:21 PM
Subject: RE: Email messages: How large is too large?
> OK, I'll make a suggestion.
>
> When the sending user injects the message into the mail system, the SMTP
> server could detect large e-mail attachments and replace them with
reference
> pointers; it would then cache the attachment someplace; possibly in local
> storage, but an ISP or an enterprise with multiple SMTP servers could have
a
> seperate set of file storage servers. The reference pointer would refer to
> the storage location of the attachment and would be obscurely chosen in a
> manner to make it difficult to index and/or retrieve attachments without
> access to the e-mail message containing the reference link.
>
> When the receiving user's mail agent sees such a reference, it can
directly
> contact the caching server and download the attachment. This retrieval can
> happen immediately or it can wait until the user explicitly requests it.
The
> retrieval protocol should support interruption and restart of the download
> process.
>
> In addition, SMTP servers which handle the e-mail message between the
> initial server and the end user could choose to fetch the attachment on
> behalf of the user and reassemble the e-mail message into a monolithic
> whole. They would presumably do this based on some local policy.
>
> The attachment would be deleted from the SMTP server's cache based on some
> set of criteria, which could include:
> - After some period of time
> - After being completely fetched by the intended recipient[s]
> - Some combination of the above.
>
> If the initial SMTP server doesn't have enough caching space, the user
agent
> could automatically upload the attachment to some other caching server
> (possibly just using the user's local machine, if it has appropriate
access
> to the Internet and sufficient availability) and edit the outgoing message
> to include a reference rather than the inline attachment.
>
> Regardless, compression should be added to MIME and integrated into user
> agents to automatically compress and decompress large attachments.
>
> While it's non-trivial to implement and deploy this proposal, it would
seem
> to offer a more flexible mechanism for large message delivery without
> forcing users to unduly conform their usage to the limitations of
> implementations.
>
> - Tim
>
> Tim Dierks
> Chief Technology Officer, Certicom
> [EMAIL PROTECTED]
> 510.780.5409 [Hayward] -- 905.501.3791 [Mississauga]
>
> > -----Original Message-----
> > From: Mason, Shane [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, December 16, 1999 3:40 PM
> > To: [EMAIL PROTECTED]
> > Subject: RE: Email messages: How large is too large?
> >
> >
> > What's the SOLUTION??? Watching this thread is like watching a dog
chase
> > it's tail. The distinguished left hand keeps saying that "E-mail wasn't
> > designed to do this." The down and dirty right hand keeps
> > asserting "User's
> > will keep using it if there is no good alternative."
> >
> > Well I have news for all of you. You are all correct!
> >
> > Quit arguing and let's come up with a solution.
> >
> > Shall a new WG be created to deal with this issue??
> >
> > ICMan
> >
> > -----Original Message-----
> > From: Danny Iacovou [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, December 16, 1999 5:57 PM
> > To: J. Noel Chiappa; [EMAIL PROTECTED]
> > Subject: RE: Email messages: How large is too large?
> >
> >
> > > -----Original Message-----
> > > From: J. Noel Chiappa [mailto:[EMAIL PROTECTED]]
> > > Sent: Thursday, December 16, 1999 3:30 PM
> > > To: [EMAIL PROTECTED]
> > > Cc: [EMAIL PROTECTED]
> > > Subject: Re: Email messages: How large is too large?
> > >
> > >
> > > > From: Jon Knight <[EMAIL PROTECTED]>
> > >
> > > > sending an email with a large Word attachment to all
> > > 15000 users on
> > > > campus isn't a good idea as our mail servers will melt.
> > > ... especially
> > > > from non-academic departments who are used to doing
> > > paper based mass
> > > > mailings to students. ... depite us offering to put the
> > > Word document
> > > > on a web page and then send a small email pointing at it
> > >
> > >
> > > The caveat about using the email system to transfer things
> > > from one user to
> > > another is that it is, after all, an *email* system, and
> > > engineered for that,
> > > not a generic bulk-data-transfer system. To use a real-world
> > > analogy, the
> > > post-office may take parcels, but above a certain size, you
> > > have to switch to
> > > a shipping company, which is set up to deal with larger
> > > items. In a similar
> > > vein, the email system was designed for certain
> > > characteristic payloads,
> > > particularly size - i.e. *email*.
> >
> > Speaking of University campuses:
> >
> > The University of Minnesota has a great looking mall. They spend a
> > lot of time and money maintaining the trees, shrubs, and grass. The
> > sidewalks running between buildings were a great idea. A lot of people
> > used them and stayed off the grass. But you know, a lot of other
people
> > did the math and the shortest distance between 2 points is a straight
> > line. Too bad the sidewalks weren't designed to run along that line.
> > So a lot of nice pretty grass turned to ugly mud as more and
> > more people
> > stomped over the grass to get were they needed to be in the
> > most "optimal"
> > way.
> >
> > This practice continued for a long time. Sure, eventually signs went
up
> > telling people not to step on the grass. But that didn't work.
> >
> > Eventually the University put chain fences on every corner of the
mall.
> > The chain fences look nice. The grass is well maintained now. I
> > guess they
> >
> > decided not to add sidewalks.
> >
> > E-mail should either be able to handle a message of any size or
> > the user
> > should be told right away that the message can't be sent. People have
> > already mentioned the GUI aspect of this problem. I agree to a large
> > extent
> > with them.
> >
> > So the problem essentially comes down to money. When are message sizes
> > causing too many problems for admins to cost justify their
> > efforts on? At
> > that point we either decide to put up nice fences or we build
sidewalks.
> >
> > The post-office has a nice fence in place. They didn't want to build a
> > sidewalk. I think eventually we are going to opt for the sidewalk.
> >
> > ------------------------------------------------------------------
> > ----------
> > ----
> > Neophytos Iacovou Ancept
Inc.
> > [EMAIL PROTECTED]
> > 400 First Ave
> > N.
> > www.ancept.com Suite 450
> >
>
