Re: Operations requirement: no hop-by-hop

Einar,

At 09:00 PM 3/10/2004, Einar Stefferud wrote:

>Paul: --
>
>What you say makes very good sense to me, because the current Internet is
>capable of single-hop delivery across the great central part of the Internet,

I have always assumed that the 3rd-party relay (i.e., in a domain other
than the message sender and receiver) acted like a point of presence
when the sender or the receiver had intermittent connectivity, as
was the case with many institutions in the U.S. in the 1980's.  I imagine
that there are global regions with intermittent-connectivity today and
that this will be true in outer space as well.

Mark

>but has no say about what happens to a message sent to a mailing list 
>expander,
>or a corporate firewall, (or a home firewall for that matter)!
>
>And, i might add, it is a very  good thing that the internet does not have
>control of what happens in mailing list expanders or inside corporate
>private networks.
>
>Your proposal follows the rules of good organizational buffering logic.
>
>Cheers...\Stef
>
>At 20:21 -0800 3/10/04, Paul Hoffman / IMC wrote:
> >At 2:33 PM -0800 3/10/04, Dave Crocker wrote:
> >>Paul,
> >>
> >>PHI> The mail-ng transport protocol should be designed to only know about
> >>PHI> a single hop, from sender to recipient. The sender may have multiple
> >>PHI> hops to a designated transport agent, and the receiving transport
> >>PHI> agent may have multiple hops to a mailstore, but the transport
> >>PHI> protocol should not make any accommodation for these additional hops
> >>PHI> other than to allow them to add metadata to the transit stream. These
> >>PHI> requirements are to make the protocol more sensible and to limit the
> >>PHI> responsibility of operators to just what they control.
> >>
> >>How is this different from the current SMTP model?
> >
> >In the current SMTP model, I believe we have been restricted from having 
> SMTP options that "speak for" SMTP servers further in the chain. For 
> example, we were prevented from making a "NO UCE" banner because there 
> was no way for the server making that claim to know what SMTP servers 
> behind it would have as policy. Different but just as complex logic was 
> used in 8BITMIME.
> >
> >I am proposing that we think of transport as just between two transport 
> agents. What the receiving agent does with the message is not part of the 
> protocol. Said another way, the transport protocol should not have rules 
> that tell receiving agents what kind of policy decisions they need to 
> transmit further down the line.
> >
> >--Paul Hoffman, Director
> >--Internet Mail Consortium