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