Re: comments on Administrative Maximum Message Size document

["Mr. Shannon Yeh" <yeh@xxxxxxxxx>]

 > Ned is right.  Automatic fragmentation may be a bad idea, but
 > fragmentation is an essential facility.  I would prefer using FTP to
 > mail, but in the absence of FTP, I will use mail rather than *any*
 > physical delivery service.

Let me state my point again: I would agree that with-fragmentation is better 
than no-fragmentation if and only if:

	1.  too many people are suffering from the current un-fragmentable
	    mailer;

	2.  many people think that they would wait until the fragmentable
	    mailer available rather than make their Internet site FTPable.

	3.  there is no technical overhead (local processing overhead and 
	    traffic overhead) or financial overhead for existing users.

	4.  There is potential real-time communication capability based on
	    this fragmentable mailer.

By the way, let me again state my old point: if XYZ Corporation likes to put
50k (an example numer) as the upper limit of msg size, then, it is XYZ's
responsibility to fragment their customers large messages.

If fragmentation is not a very important feature at the present time, but it 
costs too much, then, we should give up this idea.  Technically speaking, i 
understand that it is an overnight job to implement fragmentation feature 
(base ID number plus offset, right?).

shannon
-------

		
 > For example, the IESG secretariat now uses MIME when annoucing I-Ds.
 > (Good job, Greg!)  If you have a MIME-capable mail reader, you can now
 > read about an I-D and have your UA ask you if want to retrieve it.  If
 > you have FTP, the I-D is retrieved via FTP.  Otherwise, you can get the
 > I-D via mail.  This functionality is *critical* for people who are
 > members of the mail-connected Internet.  (Keep in mind that the
 > mail-connected Internet is larger than the IP-connected Internet.)
 > 
 > I don't understand why you categorically state that mail is poorly
 > suited for delivery of big things.  If you mail something big, it's
 > gonna take up storage and bandwidth.  Using a new protocol won't change
 > that.  The solution is to get more storage, more bandwidth, and to be
 > sensitive to resources constraints of mail relays.  
 > 
 > Right now there are dozens of commercial IP- and mail- providers.  Some
 > of the IP-providers charge on the basis of the size of the pipe you get.
 > Ditto for the mail-providers.  Some mail-providers also charge on the
 > basis of connect-time and/or octets transferred.  In other words,
 > economic forces can be used to enforce resource constraints.  If I need
 > a lot of things via e-mail, then I can pay for it...
 > 
 > /mtr