X400-Received:  
 by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 22 Mar 1996 15:52:00 -0500 
X400-Received:  
 by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 22 Mar 1996 14:56:07 -0500 
X400-Received:  
 by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 22 Mar 1996 14:21:00 -0500 
Date:  Fri, 22 Mar 1996 14:21:00 -0500 
X400-Originator:  /dd.id=0141677/g=michael/i=m/s=hartman/@bnr.ca 
X400-MTS-Identifier:  
 [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars520.b.696:22.02.96.19.56.07] 
X400-Content-Type:  P2-1984 (2) 
Content-Identifier:  Re: Issues su... 
From: "michael (m.) hartman" <hartman@bnr.ca>
Sender: "michael (m.) hartman" <hartman@bnr.ca>
Message-ID:  <"2444 Fri Mar 22 15:39:56 1996"@bnr.ca> 
To: drums@cs.utk.edu
Subject:  Re: Issues summary 

> ... (additional issues for the drums web page) ..
>
> Added.

I'm unsure of the protocol for adding issues, and even whether or not my
issue is within the scope of the DRUMS charter, but there's no harm in stating 
something which I think needs to be resolved, right ?

I would like to see some clarification in 821bis of which specifications
apply to the "abstract" message transfer protocol per se, and which apply 
to the use of this protocol in the public Internet.  That is, there is a 
distinction between what the protocol is to do, and what level of 
service is to be provided on a particular network (set of hosts with
multi-lateral agreements on use of the protocol).  Of course the two are
related, but some attempt to delineate would be useful.

For example, one could implement an SMTP mta which rejects connections from
unknown hosts as a method of providing a private corporate mail network
(yes I know I'm oversimplifying).  Or one which uses Internet as a backbone 
for a private virtual network, and TCP-connecting directly point-to-point 
within the "private" network rather than using mail-relay hosts.  Or using
SMTP over SPX, or on a discrete/unconnected corporate intranet.  The level of 
service on these types of network may be desired to be much different than that 
so far specified in drums-smptupdt-00

In real world products, for example, networked voice messaging systems 
provide VERY high reliability and response time, something customers 
will continue to request even if SMTP is used as the networking method.
Thus, delaying for at least 4-5 _*DAYS*_ (while retrying delivery, as 
suggested by drums) before returning a non-delivery msg is completely 
unacceptable in this market type of network, and will not be implemented 
by any vendors addressing this market... voice mail networks are 
reliable, and customers want to know within an hour whether or not their
mail got through.

I think what we need is a way to allow compliance with SMTP seperately from
compliance with public Internet use of SMTP.

For the example I've given, we could change wording which states
"... the give-up time generally needs to be at least 4-5 days..."
to 
"... the give-up time depends on the level of service required in the
network.  For hosts wishing to connect to the public Internet mail
relay network, the give-up time generally needs to be at least 4-5 days
given the current level of service provided by these public Internet hosts."

In fact, it might even be argued that such level-of-service specification
could be a different document, or moved to RFC1123, etc.

Comments (on the general idea, not specifically the above example) ?

-------------------------------------------------------------------------
Michael Hartman                        Multimedia Networking Applications
                                       Northern Telecom Canada Ltd.,
Tel:  +1-416-597-7311                  522 University Avenue,
FAX:  +1-416-597-7110                  Toronto, Ontario, Canada
AMIS: 7311@+1-416-598-3540             M5G 1W7
SMTP: hartman@bnr.ca                   
X400: G=Michael; S=Hartman; DD.ID=141677; P=BNR; A=Telecom.Canada; C=CA