Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!lll-tis!ai.toronto.EDU!rayan From: rayan@ai.toronto.EDU (Rayan Zachariassen) Newsgroups: comp.protocols.iso.x400.gateway Subject: Re: Proposed delta to RFC 987 Message-ID: <88Jun27.000416edt.361@neat.ai.toronto.edu> Date: 27 Jun 88 04:04:07 GMT Sender: root@tis.llnl.gov Distribution: inet Organization: The Internet Lines: 57 Approved: post-x400-gateway@tis.llnl.gov The use of source-routes or %-hacks to "access gateways" is incidental to the real purpose and goal of such mechanisms. It is necessary to be able to specify a series of MTA's a message must pass through, and to be able to predict the address seen by each of those MTAs (the latter is pretty irrelevant for attribute-based routing but essential for RFC822). One of the problems I see with X.400 is the lack of such a facility (although I gather it might show up in some form). It is necessary for: - testing, where route predicatibility is important - manual routing when you know something the intermediate MTAs don't - automatic partial routing (e.g. to override normal routing of downstream MTA) out of technical/political/administrative concerns. - the final destination (or originator) address need not be specified in a globally unique or well-understood form in a source route (the wording of the spec makes this arguable, but in practise this is true) I don't understand the comment that RFC822 source routes are at best hazardous when gatewayed into a non-SMTP (which is the real distinction) network like UUCP. Works for me. The idea of a one-way translation is repulsive; it should be possible to send an RFC822 message through an X.400 network and recover the original message (modulo trace info and address translation) on the outgoing end. Similarly it should be possible to send an X.400 message through an RFC822 network without losing information. We also need to distinguish between source routes in the envelope and in the header. It is the envelope address which is significant, but current RFC822 UAs usually default the envelope information from the header. So even though lack of source route information in the header is not a terrible loss, envelope information cannot be treated as nonchalantly. I think RFC987 already is incomplete in terms of transparency, the suggested change would make it more so. It'd be more and more of a trap door for messages, which means it would inherently limit the use of X.400 as a transport mechanism between heterogenous (mail-protocol-wise) nets. Putting the routing info into DD attributes is ok, although I'd prefer that whatever mechanism is being cooked up to address this in native X.400 is the one used. I don't know for sure if this is happening and if it is what the plans are (I don't remember where I got this notion from). One of my perspectives on this is that I dream of building a merged RFC822/X.400 router (i.e. merging X.400 into my RFC822 MTA). This will be relatively easy to do iff there is a well-defined and appropriate textual representation for 100% of the P1/P2 information in an X.400 message. RFC987 to me looks like a good basis, but isn't yet mature/extensive enough to be used for this. The proposed change is therefore a change in the wrong direction. regards, rayan