Subject: RE: Email messages: How large is too large?

From: Danny Iacovou <[email-masked]>
Date: Thu, 16 Dec 1999 16:57:07 -0600

> -----Original Message-----
> From: J. Noel Chiappa [mailto:[email-masked]]
> Sent: Thursday, December 16, 1999 3:30 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Email messages: How large is too large?
> 
> 
>     > From: Jon Knight <[email-masked]>
> 
>     > 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-masked]                                             400 First Ave
N.
www.ancept.com                                                 Suite 450

---

From: "Stephen Sprunk" <[email-masked]>
Date: Thu, 16 Dec 1999 18:00:09 -0600

Interesting approach by UMN...  When UIUC's quad was built, they didn't put
in any sidewalks at all; once the students had worn the grass down in
recognizable patterns, they added sidewalks following those paths.  I can't
recall any time I wanted to cross the quad where there wasn't a sidewalk
going where I wanted, and the rest of the grass stayed nice without the need
for fences or signs.

Customers are generally much happier when you give them what they ask for
instead of forcing them to use something else; if people want to be able to
mail full DVDs to each other, it's our job to determine how to make that
technically feasible and (hopefully) efficient.

S

     |          |         Stephen Sprunk, K5SSS, CCIE #3723
    :|:        :|:        NSA, Network Consulting Engineer
   :|||:      :|||:       14875 Landmark Blvd #400; Dallas, TX
.:|||||||:..:|||||||:.    Pager: 800-365-4578 / 800-901-6078
C I S C O S Y S T E M S   Email: [email-masked]

---

From: "Stephen Sprunk" <[email-masked]>
Date: Thu, 16 Dec 1999 18:00:09 -0600

S

---

From: Kent Crispin <[email-masked]>
Date: Thu, 16 Dec 1999 16:42:04 -0800

> technically feasible and (hopefully) efficient.

To switch analogies from sidwalks back to the postal service: therefore,
it is the postal services job to determine how to send pianos from your
mailbox... 

But it seldom does any good to push analogies too far :-)

SMTP is not a file transport protocol, and it will always be less 
efficient at transporting files than a protocol that is designed for 
that purpose.  Not to say that some new protocol couldn't be designed 
that had the desirable addressing features of email, and the efficiency 
of FTP.  But that would be a new protocol...

Kent

-- 
Kent Crispin                               "Do good, and you'll be
[email-masked]                           lonesome." -- Mark Twain

---

From: Kent Crispin <[email-masked]>
Date: Thu, 16 Dec 1999 16:42:04 -0800

Kent

---

From: Peter Deutsch <[email-masked]>
Date: Thu, 16 Dec 1999 22:28:43 -0500

> But it seldom does any good to push analogies too far :-)

Right idea, wrong analogy. We are geeks, so think of it in terms of
transport. Most users think in terms of "shipping departments". So, if
Alice wants that video of her new cryptographic byte scrambling plant
sent to Bob, she's gonna call the shipping department. Now, Alice has
the launch codes, so we should realize it's in our interest to give her
what she wants. That doesn't necessarily mean putting it all in one
humongous MIME-encoded file, and it's probably fair to say that her mail
service could be tapped for the spool/archive directory, but Alice and
Bob (to return to *your* analogy for the finish) want the piano
delivered. They leave the choice of carrier, packaging and labeling to
the shipping department...

					- peterd
> of FTP.  But that would be a new protocol...

Sounds eminently reasonable... ;-)

				- peterd
-- 
------------------------------------------------------------------

  "I have discovered a way to supply the world's energy needs,
   using nothing more than gerbils on trendmills, powered by 
   raisins! It is a brilliant, original breakthrough!"

  "Yes, all well and good, but unfortunately, gerbils are allergic
   to raisins. Failure, Mr. Jones, is hardly original..."

				- paraphrasing Bloom County...

-----------------------------------------------------------------

---

From: Peter Deutsch <[email-masked]>
Date: Thu, 16 Dec 1999 22:28:43 -0500

- peterd

				- peterd

---

From: "Dick St.Peters" <[email-masked]>
Date: Fri, 17 Dec 1999 10:49:35 -0500 (EST)

> technically feasible and (hopefully) efficient.

Communication has the unusual property of having two users, and sender
and recipient don't always agree on what they want.  I for one think
it is *not* the ietf's job to continue making it ever easier to send
what recipients do not want.  The recipients' wishes deserve respect,
and the inability of email (as it exists today) to take them into
account is a major flaw.

My first posting in this thread observed that I had imposed our 5 MB
limit on email message size because someone sent a 100 MB email to one
of our dialup users.  A one-size-fits-all limit is a rather blunt
instrument for protecting users, and it occasionally gets in the way
of things users legitimately want to transfer.  It's a balancing act
with no happy alternative.

--
Dick St.Peters, [email-masked] 
Gatekeeper, NetHeaven, Saratoga Springs, NY
Saratoga/Albany/Amsterdam/BoltonLanding/Cobleskill/Greenwich/
GlensFalls/LakePlacid/NorthCreek/Plattsburgh/...
    Oldest Internet service based in the Adirondack-Albany region

---

From: "Dick St.Peters" <[email-masked]>
Date: Fri, 17 Dec 1999 10:49:35 -0500 (EST)

---

From: "Doug Sauder" <[email-masked]>
Date: Fri, 17 Dec 1999 11:22:26 -0500

SMTP is successful because it is simple.  Make it too complex, and you make it difficult to send even the simplest messages, and you make interoperability a bit more challenging.

I propose:

If an SMTP server can't or won't handle a message with a large attachment, then it should (1) drop the attachment, (2) replace it with a message that a large attachment had to be dropped, and (3) maybe also insert a suggestion on how the attachment could be transferred (use FTP, or use compression).  The message would still make it to the recipient, but without the attachment.  The SMTP server should send a message (a DSN maybe ?) back to the sender to tell him the attachment had to be dropped.

Then:

The sender and recipient will likely contact each other and find a way to get the large file transferred.  There are Web sites that allow individuals to upload files for others to retrieve.  If it's really important for individuals to transfer large files, they will find a way.

Also:

As the capabilities of the technology advances, the limit will be expected to increase, but without any centrally recommended "guideline", which would be a moving target.

  -- Doug Sauder

---

From: "Doug Sauder" <[email-masked]>
Date: Fri, 17 Dec 1999 11:22:26 -0500

I propose:

Then:

Also:

  -- Doug Sauder

---

From: [email-masked]
Date: Fri, 17 Dec 1999 14:01:21 -0500

> of FTP.  But that would be a new protocol...

No, it would be an old protocol.  See RFC1440, from July 1993.

Is there sufficient interest to create a working group to overhaul RFC1440
into something more usable in today's Internet?
-- 
				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

---

From: [email-masked]
Date: Fri, 17 Dec 1999 14:01:21 -0500

---

From: John Stracke <[email-masked]>
Date: Fri, 17 Dec 1999 15:12:54 -0500

> into something more usable in today's Internet?

It might not take much work--this might actually be a case where HTTP is
appropriate, since you're sending the same sorts of entities that might
otherwise be downloaded from HTTP servers.  If so, it might suffice to
standardize on an HTTP method and, ideally, define a way to get the right URL
given an email address.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |"HTTP is what happens in the absence of good |
[email-masked]|design." -- Keith Moore                      |
\==============================================================/

---

From: John Stracke <[email-masked]>
Date: Fri, 17 Dec 1999 15:12:54 -0500

---

From: Richard Shockey <[email-masked]>
Date: Fri, 17 Dec 1999 16:27:36 -0600

>standardize on an HTTP method and, ideally, define a way to get the right URL

Excellent idea... HTTP Push to a defined directory with email notification 
of an appropriate URL. One problem.

         http://www.patents.ibm.com/patlist?icnt=US&patent_number=5790790

Richard Shockey
Shockey Consulting LLC
8045 Big Bend Blvd. Suite 110
St. Louis, MO 63119
Voice 314.918.9020
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : [email-masked]
GSTN Fax 314.918.9015
MediaGate iPost VoiceMail and Fax 800.260.4464
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: Richard Shockey <[email-masked]>
Date: Fri, 17 Dec 1999 16:27:36 -0600

Richard Shockey
Shockey Consulting LLC

---

From: Kent Crispin <[email-masked]>
Date: Sat, 18 Dec 1999 07:15:32 -0800

On Fri, Dec 17, 1999 at 04:27:36PM -0600, Richard Shockey wrote:
[...]
>          http://www.patents.ibm.com/patlist?icnt=US&patent_number=5790790

You would be hard pressed to come up with a more absurd patent...

---

From: Kent Crispin <[email-masked]>
Date: Sat, 18 Dec 1999 07:15:32 -0800

---

From: Peter Deutsch <[email-masked]>
Date: Sat, 18 Dec 1999 12:02:52 -0500

> You would be hard pressed to come up with a more absurd patent...

Actually, there have been a few of these in recent years. I've done some
consulting for lawyers seeking to overthrow patents where someone has
obviously simply gone out and documented things done by others.

To revisit a theme I raised back in the summer, this need to be able to
prove prior art is the reason I believe we need to preserve Internet
Drafts, not just mailing lists and other work output from the IETF.  I'm
all for protecting innovation, and believe patents have a role in this
industry, but I've seen a few bogus claims and am happy to do my bit to
see them struck down. They tend to fall fairly easily if you have access
to suitable examples of prior art.

It's obviously a separate question as to whether it's worth the hassle
for a working group to get involved with patented material, as deciding
to fight a patent is primarily a political decision, not a technical
one, so not in scope for the IETF. Protecting the net from bogus claims,
though (for example, by protecting and preserving prior art through
copyright, archiving etc) certainly seems to be appropriate behaviour.

					- peterd

  "Skill without imagination is craftsmanship and gives us many 
   useful objects, such as wickerwork baskets. Imagination 
   without skill gives us modern art...

- Tom Stoppard

---

From: Peter Deutsch <[email-masked]>
Date: Sat, 18 Dec 1999 12:02:52 -0500

- peterd

- Tom Stoppard

---

From: "Perry E. Metzger" <[email-masked]>
Date: 18 Dec 1999 12:03:20 -0500

> You would be hard pressed to come up with a more absurd patent...

There are far more absurd patents coming out every day. That is not to
say that this isn't absurd.

---

From: "Perry E. Metzger" <[email-masked]>
Date: 18 Dec 1999 12:03:20 -0500

---

From: Dave Crocker <[email-masked]>
Date: Sat, 18 Dec 1999 09:03:08 -0800

>to suitable examples of prior art.

Hmm, that makes two of us who have tried to pursue this.  It is currently 
extremely difficult for research about prior art to access the treasure 
trove of IETF discussion and development.  Essentially, you have to know 
exactly what you want, by name.  A searchable, permanent archive would be 
simple and incredibly useful.

d/

=-=-=-=-=
Dave Crocker  <[email-masked]>
Brandenburg Consulting  <www.brandenburg.com>
Tel: +1.408.246.8253,  Fax: +1.408.273.6464
675 Spruce Drive,  Sunnyvale, CA 94086 USA

---

From: Dave Crocker <[email-masked]>
Date: Sat, 18 Dec 1999 09:03:08 -0800

d/

=-=-=-=-=

---

From: Richard Shockey <[email-masked]>
Date: Sat, 18 Dec 1999 11:16:22 -0600

>to suitable examples of prior art.

I couldn't agree more..but the problem is that the patent examiners do not 
look at the IETF or OSI drafts or work product during the process and even 
ignore it when it is brought to their attention.

Richard Shockey
Shockey Consulting LLC

---

From: Richard Shockey <[email-masked]>
Date: Sat, 18 Dec 1999 11:16:22 -0600

Richard Shockey
Shockey Consulting LLC

---

From: thomas lakofski <[email-masked]>
Date: Sat, 18 Dec 1999 17:40:27 +0000 (GMT)

> into something more usable in today's Internet?

I find saft (simple asynchronous file transfer protocol) to work well for
me.  there's a reference implementation for unix and description at
http://www.belwue.de/aktivitaeten/projekte/saft/index-us.html

I think I've seen an old winnt implementation around somewhere, but I
didn't get it to work.

The reference implementation does have some access-control features, but
they could use a little work (currently allows wildcarded 'don't receive
from' lists, could use being able to instead have an allow list).

-tl

......
         who's watching your watchmen?
EF D8 33 68 B3 E3 E9 D2  C1 3E 51 22 8A AA 7B 98

---

From: thomas lakofski <[email-masked]>
Date: Sat, 18 Dec 1999 17:40:27 +0000 (GMT)

-tl

......

---

From: Peter Deutsch <[email-masked]>
Date: Sat, 18 Dec 1999 12:52:38 -0500

g'day,

> ignore it when it is brought to their attention.

I can't comment on that aspect of it, as I've always gotten involved
when it reaches the litigation stage. At that point, since money is
going to change hands one way or the other, the simplest thing for a
defendent to do is to  get your expert witnesses to attack the patent or
otherwise show that you're not infringing. Having someone who can
present a document and testify that it appeared two years before the
claim was filed can get the patent set aside, once you've convinced the
judge that you're talking about the same material (I'm sure you're aware
of this, but I offer it as background for others).

Of course, sometimes even when a patent looks like it can be attacked,
it's not as easy as you first thought. I recently looked at one which
seems kind of bogus to me,  as it clearly used only already available
technology, but we're having trouble on the "innovation" front, as the
use of existing technology in a clever way is also patentable. In any
event, I definitely think the IETF could be doing a lot more in this
area, but that's just one person's opinion.

				- peterd

- Tom Stoppard

---

From: Peter Deutsch <[email-masked]>
Date: Sat, 18 Dec 1999 12:52:38 -0500

g'day,

				- peterd

- Tom Stoppard

---

From: Peter Deutsch <[email-masked]>
Date: Sat, 18 Dec 1999 12:52:42 -0500

Hi Dave,

> simple and incredibly useful.

I recall that the general attitude when this was last discussed was that
preserving drafts was evil, although personally I wasn't convinced. At
the same time, Iit turned out I was at least partially wrong on the
mailing list issue - as Steve Coya pointed out, they are now archived.
The problem is that this collection isn't complete, and the mail is just
dumped into one place. A systemic archiving of all work out (such as
drafts, agendas, charters, etc) and a few other simple steps could make
the job easier. The problem seems to be that this archival role isn't
seem as important and/or appropriate by some at the IETF.

</opinion>

				- peterd

- Tom Stoppard

---

From: Peter Deutsch <[email-masked]>
Date: Sat, 18 Dec 1999 12:52:42 -0500

Hi Dave,

</opinion>

				- peterd

- Tom Stoppard

---

From: Richard Shockey <[email-masked]>
Date: Sat, 18 Dec 1999 12:24:04 -0600

>area, but that's just one person's opinion.

We are spinning off into another area from the original problem of how to 
make the transfer of large email files attachments easier and more 
efficient for users and relieve the stress on the SMTP system. That concept 
is worthy of IETF work.

That said.. your point is well taken.  Is there something the IETF 
[probably the Internet Society] can do to point out the dangers of 
patenting these kinds of "obvious" concepts based on IETF work? How do we 
define the difference between " unique and innovative" from the merely 
"clever use of"?  How do we educate the legislative authorities? I wish I 
had an answer.

Richard Shockey
Shockey Consulting LLC

---

From: Richard Shockey <[email-masked]>
Date: Sat, 18 Dec 1999 12:24:04 -0600

Richard Shockey
Shockey Consulting LLC

---

From: Dave Crocker <[email-masked]>
Date: Sat, 18 Dec 1999 10:29:52 -0800

>preserving drafts was evil, although personally I wasn't convinced. At

Not quite right.  The drafts ARE preserved.  Just sned a note to the 
Secretariat, asking for a specific one, and they can produce it.  The 
problem is that this is inefficient at its base, as well as preventing 
searching.

Your comments about mailing lists archives are on-target.

Richard's comments about patent examiners appears to be correct, but we 
can't do anything about that.

However we CAN make prior art researching MUCH easier for our little piece 
of the world.

d/

=-=-=-=-=

---

From: Dave Crocker <[email-masked]>
Date: Sat, 18 Dec 1999 10:29:52 -0800

d/

=-=-=-=-=

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sat, 18 Dec 1999 21:25:36 +0100

>and the inability of email (as it exists today) to take them into

And we're trying to address that - see the RESCAP WG.
Warning: it won't be easy, and probably won't be pretty.

                      Harald
--
Harald Tveit Alvestrand, EDB Maxware, Norway
[email-masked]

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sat, 18 Dec 1999 21:25:36 +0100

Harald