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