Re: Mail Path MTU discovery?

Once upon a time, there was a feature on RFC822 or MIME that dealt with 
the issue of the recipient using FTP to fetch the file from its source. 
IETF used it for years for announcing Internet Drafts.  Might still? 

Perhaps it was a MIME type.  Maybe someone in this list can recall what 
this was (or still is?) and provide the RFC reference.

But, a URL is very often used for exactly what you suggest. as it often 
works better than an FTP Fetch. 

There is in fact no need to send gigantic Mail Messages...

The requirement is to enable instructions for fetching, and that is all.

Your problem is that you are trying to describe requirements by specifying 
protocols.

Cheers...\Stef 

At 20:50 +0100 2/13/04, Hadmut Danisch wrote:
>On Fri, Feb 13, 2004 at 08:38:18PM +0100, Iljitsch van Beijnum wrote:
> > On 13-feb-04, at 18:56, Hadmut Danisch wrote:
> >
> > >Example: Before sending the 5 GByte E-Mail, a short control
> > >message could be sent to the recipient, where every relay
> > >can reduce the maximum Mail size. Then the message is sent back.
> > >This would of course not be a guarantee, since the path can
> > >change every second. But it's at least a hint and could avoid
> > >the 5 GByte to be sent just for generating an error message.
> > 
> > This makes sense, but I think we can go a little further and see 
> > whether it's necessary to push large messages and especially files out 
> > to the recipient's inbox anyway, why not just send a light-weight 
> > message indiciating the availability of the "real" message or the file 
> > in question, and then the receiver can connect to the place where the 
> > message/file is stored and then the file is transmitted to the place 
> > where it needs to be directly. Additionaly, we can add an optional 
> > proxy layer here, allowing for extremely efficient distribution of 
> > binary information through mailinglists.
> > 
> > So a software maker could send out a message with attached a file that 
> > contains a large update to all their customers. The customers all 
> > receive the message and then proceed to download the file, if they want 
> > to have it, through their ISP's proxy. This
>
>
>Hey, that's a good point. I often asked several friends to 
>not send monster files and jam my mailbox, but to put them on a
>webserver and just sent the link.
>
>So we should support push and pull attachments. Instead of an 
>attachment a URL and a cookie is included which allows to pull
>an attachment which is to be deleted after downloading. 
>
>I think that's a good requirement.
>
>BTW: If we are talking about large messages or attachments: 
>
>Should we require every implementation to use 64bit integers
>to avoid inherent size limits of 4 GB (or 2 GB with signed 
>integers)?
>
>Or should we have a hard size limit? When you transmit 
>4 GB, and the last byte fails, you need to transmit it again.
>Should we simply disallow 4GB transfers and enforce pulling
>attachments?
>
>Or should we support incremental transport? Just open another
>connection and transmit just the last 1kb instead of transmitting
>the 4 GB again?
>
>regards
>Hadmut