Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!killer!lll-winken!lll-tis!NRTC.NORTHROP.COM!Stef
From: Stef@NRTC.NORTHROP.COM (Einar Stefferud)
Newsgroups: comp.protocols.iso.x400.gateway
Subject: Re: Delivery and Nondelivery notifications
Message-ID: <983.584645281@nma.com>
Date: 11 Jul 88 03:28:01 GMT
References: <9097.584618184@UK.AC.UCL.CS>
Sender: root@tis.llnl.gov
Reply-To: Stef@nrtc.northrop.com
Distribution: inet
Organization: The Internet
Lines: 27
Approved: post-x400-gateway@tis.llnl.gov

Steve -- I have to agree with your assessment and conclusion.  The
reality is that RFC822 does not offer the desitred services, and would
require an upgrade of RFC822 to add them in any consistent and
"standard" way.  

RFC987 stands between RFC822 and X.400 and as such must either hold
enough intelligence to map the functional services of each to the other,
or not offer the missing services of one to the other.  There is no
middle ground that I can see.  

I guess this means that RFC987 might should deal with the question of
how to graceefully deny services that are missing when a message
traverses the gateway in either direction.  Should it non-deliver?
Should it notify the sender of forward-tranfer without the service?
Etc ....

AS for finding ways to invole service from RFC822 that are missing in
RFC822, I think we are not going to be able to standarize on it, so
RFC987 compliant systems should not offer it in general.

I think this means that ATT and SUN and others can do it where they
violate the intent of RFC987 to NOT use RFC822 for a local UA (because
of this problem), but they should be very careful to not offer the
service beyond their locally attached UA.  In short, this facility
should only be embodied in the local posting or delivery channel of
their MTA (assumning channelized MTA architecture).  

Cheers...\Stef