Stef@NRTC.NORTHROP.COM (Einar Stefferud) (07/06/88)
I recall adding another idea to the pile here, but I guess it did nt catch any attention, so here is another try. How about reversing the attribute/value pair on the RFC822 side, with a new RFC822 field for each attribute value of interest, with the content of the filed indicating which addresses are to be so treated? Example: X-ReturnContent: addr1, addr2, addr3 The addr-indicators only need be unique in this message for the gateway to figure out what to do for each. Defaults should be set to minimize the use of these fields. What say? I think it simplified many of your concerns. Cheers...\Stef
Stef@NRTC.NORTHROP.COM (Einar Stefferud) (07/11/88)
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
steve@CS.UCL.AC.UK (Steve Kille) (07/11/88)
I'm still not sure where to go with this one. Comments: 1) Your original approach lacks generality. 2) Adding attributes is, as you say, ugly. Also, and perhaps more serious, it does not really fit with 822 addressing. X.400 allows you to carry additional information WITH the address. Forcing this info INTO the 822 address is really changing the semantics. 3) Stef's comprimise introduces a nasty issue of cross-correlating stuff. Don't like this at all. On balance, I am inclided to go away and forget about the whole thing! The major issue here is not one of gatewaying. It arises where (as ATT and SUN have done), 987 is used as an interface to the X.400 world. RFC 987 specifically advises against this! Steve