Path: utzoo!utgpu!watserv1!watmath!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!jarthur!ucivax!gateway
From: Christian.Huitema@mirsa.inria.fr (Christian Huitema)
Newsgroups: comp.protocols.iso.x400.gateway
Subject: Re: RFC 987 mapping and DDA usage
Message-ID: <9102221344.AA00929@jerry.inria.fr>
Date: 25 Feb 91 14:19:04 GMT
Lines: 57
Approved: usenet@ICS.UCI.EDU
X400-Originator: huitema@jerry.inria.fr
Content-Identifier: Re: RFC 987 m...
In-Reply-To: <1749.667221350@UK.AC.UCL.CS>
X400-Received: by mta bells.cs.ucl.ac.uk in /PRMD=uk.ac/ADMD=gold 400/C=gb/;
               Relayed; Fri, 22 Feb 1991 13:46:12 +0000
X400-Received: by /PRMD=inria/ADMD=atlas/C=fr/; Relayed;
               Fri, 22 Feb 1991 13:44:08 +0000
X400-Content-Type: P2-1984 (2)
X400-MTS-Identifier: [/PRMD=inria/ADMD=atlas/C=fr/;667230340@kwai.inria.fr]

> >What is your reason against the proposed solution by Bertrand:
>
> > >   user%host.decnet@cs.manchester.ac.uk
>
> > >   C=GB;A= ;P=AC.UK;O=Manchester;OU=CS;
> > >   DD.RFC-822=user(p)host.decnet(a)cs.manchester.ac.uk)
>
>It is making an assumption that there is a 1148 gateway at Manchester.
>There is no reason for this to be the case, particularly as we shift towards
>sites without RFC 822.

Lets start to clarify some points.

1) First, X.400 routing: the standard in the X.400 world is to base the
routing on the "standard attributes", and mostly on <C, ADMD, PRMD>.

2) Thus, we should assume that DD values are ignored by intermediate routers,
as long as they cannot deduce from the "standard attributes" that the ORName
belong to their local "name space", and can be "solved" by using the local
directory or gateway functions.

3) From this, we deduce that the standard attributes of a gateway address
(DD.RFC-822) will suffice to route the message towards an MTA with gateway
capability. We cannot assume that all MTAs do have gateway capability. A
standard UA will look for a user identified by an attribute of type "RFC-822"
and of value "user(p)host.decnet(a)cs.manchester.ac.uk" within its own name
space; chances are that the message will be bounced. This is the essence of
Steve's argument above.

4) Doing otherwise (routing on DD attribute value) must be exercized very
cautiously if at all, as the risks for loops are enormous (M.PLUS detects a
loop when the DD and the standard attributes are "contradictory").

5) However, there are often good reasons to "direct the message towards the
nearest gateway", e.g. go through the French WEP rather than make your way
towards a private gateway in the UK were the message will get bounced because
"you have not payed your subscription fee to our gateway".

6) A solution to (5) is to recognize that the standard attributes points
toward "a gateway", and to organize the local (regional, national) routing
tables so that all addresses within "standard gateway domains" get routed
through the local gateway.

7) If on the contrary one wants to stay within X.400 as long as possible, then
the standard attributes should be derived from the "preferred gateway table".

Solution (6) can be implemented by keeping a list of registered (supposedly
equivalent) gateways to the RFC-822 Internet. The size of the list is probably
of the same order of magnitude as the size of the WEP table.

Solution (7) is in principle mostly needed for gateways from the RFC-822
Internet towards X.400; it would be extremely tempting to use the DNS to store
it. Note that the purpose of this table is only an optimisation of the X.400
path; the mail should also arrive if one of the "registered gateways" is
choosen.

Christian Huitema