S.Kille@cs.ucl.ac.UK (Steve Kille) (02/25/91)
------- Forwarded Messages From: Simon Poole <poole@ch.SWITCH.VERW> To: "harald.alvestrand" <harald.alvestrand@no.sintef.elab-runit> Subject: Re: RFC 987 mapping and DDA usage Date: Fri, 22 Feb 1991 15:19:26 +0100 Wrong assumtion >it seems to me that the proposed "gateway list" is something that is NOT >as critical as the RFC-987 mapping tables, and that the coordination may >even be advisory, not mandatory like the tables. because this >This is on the assumption that RFC-1148/2 is deployed in a network with >reasonably full interconnectivity on both X.400 and RFC-822 sides. is not true. Our REAL EXISTING PROBLEM is: A -----> B -------XXXXXXXX------> C -------> D RFC-822 RFC-987 GW X.400 RFC-987 GW RFC-822 A doesn't have RFC-822 connectivity with C and D D doesn't have RFC-822 connectivity with A and B Assuming our topology there are a handful of B's and tons of A's, gateway C has to know for EVERY possible A the B that serves it (note that it is enough for A just simply to be RFC-822 local delivery for this situation to arise). Simon PS: just for the UK: assume that we have NO administrative control over A's ------- Message 2 From: Christian Huitema <Christian.Huitema@fr.inria.mirsa> To: Simon Poole <poole@ch.SWITCH.VERW> Subject: Re: RFC 987 mapping and DDA usage Date: Fri, 22 Feb 1991 14:48:08 +0000 >Our REAL EXISTING PROBLEM is: > > > A -----> B -------XXXXXXXX------> C -------> D > RFC-822 RFC-987 GW X.400 RFC-987 GW RFC-822 > > >A doesn't have RFC-822 connectivity with C and D >D doesn't have RFC-822 connectivity with A and B ... then either "D" or "A" should stop pretending to belong to the RFC-822 Internet! Using the "RFC-822" type of DDA with an address that cannot be reached from e.g. a NSFNET site is, in my opinion, a protocol error. Christian Huitema ------- Message 3 From: Simon Poole <poole@ch.SWITCH.VERW> To: Christian Huitema <Christian.Huitema@fr.inria.mirsa> Subject: Re: RFC 987 mapping and DDA usage Date: Fri, 22 Feb 1991 16:06:32 +0100 >>Our REAL EXISTING PROBLEM is: >> >> >> A -----> B -------XXXXXXXX------> C -------> D >> RFC-822 RFC-987 GW X.400 RFC-987 GW RFC-822 >> >> >>A doesn't have RFC-822 connectivity with C and D >>D doesn't have RFC-822 connectivity with A and B > >... then either "D" or "A" should stop pretending to belong to the RFC-822 >Internet! Using the "RFC-822" type of DDA with an address that cannot be >reached from e.g. a NSFNET site is, in my opinion, a protocol error. Christian, there are sometimes other constraints that purely technical ones and technical arguments will not make them go away. We still need a workable solution for this case. Simon ------- Message 4 From: Christian Huitema <Christian.Huitema@fr.inria.mirsa> To: Simon Poole <poole@ch.SWITCH.VERW> Subject: Re: RFC 987 mapping and DDA usage Date: Fri, 22 Feb 1991 15:27:28 +0000 >>>Our REAL EXISTING PROBLEM is: >>> >>> >>> A -----> B -------XXXXXXXX------> C -------> D >>> RFC-822 RFC-987 GW X.400 RFC-987 GW RFC-822 >>> >>> >>>A doesn't have RFC-822 connectivity with C and D >>>D doesn't have RFC-822 connectivity with A and B >> >>... then either "D" or "A" should stop pretending to belong to the RFC-822 >>Internet! Using the "RFC-822" type of DDA with an address that cannot be >>reached from e.g. a NSFNET site is, in my opinion, a protocol error. > >Christian, there are sometimes other constraints that purely >technical ones and technical arguments will not make them go >away. We still need a workable solution for this case. > > > Simon If your problem is to connect a local network which uses TCP internally but can only communicate to the world through the X.400 network, then declaring them as an X.400 domain and using mapping tables would appear a reasonable solution... Christian Huitema ------- Message 5 From: Simon Poole <poole@ch.SWITCH.VERW> To: Christian Huitema <Christian.Huitema@fr.inria.mirsa> Subject: Re: RFC 987 mapping and DDA usage Date: Fri, 22 Feb 1991 16:01:26 +0000 >If your problem is to connect a local network which uses TCP internally but >can only communicate to the world through the X.400 network, then declaring >them as an X.400 domain and using mapping tables would appear a reasonable >solution... It is NOT a mapping table problem. Example: user on host/MTA uses RFC-822 local delivery, his originator address is a_b@c this goes thru a RFC-987 gateway and either gets mapped to /S=a(u)b/... standard attribute mapping of c .../ (this is done by EAN) or /RFC-822=a(u)b(a)c/... standard attributes of gateway .../ the mail then gets forwarded to a further RFC-987 gateway that maps the originator address back to a_b@c and by doing this naturally looses the infomation on which gateway to send replies to this message back to. Now it is clear that if ALL addresses in the domain c are cleanly mapable to standard attributes then everything works OK, but enforcing this means administrative control over the domain c. (Which I explicty said we didn't have.) Simon ------- Message 6 From: Serge Aumont <aumont@fr.reunir.sunir> To: RARE-WG1@ch.SWITCH, rd-mhs-managers@no.rare Subject: Re: RFC 987 mapping and DDA usage Date: Mon, 25 Feb 1991 08:47:14 +0000 Paul, your are write when you say that the entry for France in a gateway table could be unique using C=fr;ADMD=red;DD=... . This is just a exemple of what can be done in France. In the general case you must not reduce the standart part of the adress to the ADMD but to any Management Domain (ie ADministrative one or PRivate one). So it must be possible to have several entries in this table for each top level domain. You can see something like : ac.uk PRMD=AC.UK;ADMD= ;C=gb; co.uk ADMD=gold 400;C=gb; anyway you are true if you meant by this that we don't need hundred entries in the table for the same top level domain. Serge ------- Message 7 From: BUCLIN@ch.epfl.sic To: rd-mhs-managers@no.rare Subject: Re: RFC 987 mapping and DDA usage Date: 25 Feb 91 09:10 +0100 RFC-822-Headers: X-ST-Vmsmail-To: GW::"rd-mhs-managers@rare.no" ================== >> >> >> A -----> B -------XXXXXXXX------> C -------> D >> RFC-822 RFC-987 GW X.400 RFC-987 GW RFC-822 >> >> >>A doesn't have RFC-822 connectivity with C and D >>D doesn't have RFC-822 connectivity with A and B > >.... then either "D" or "A" should stop pretending to belong to the RFC-822 >Internet! Using the "RFC-822" type of DDA with an address that cannot be >reached from e.g. a NSFNET site is, in my opinion, a protocol error. Christian, who told you "D" or "A" where not on Internet ? They are both. The situation in Switzerland, is that we have an X.400 backbone which interconnects all different sites. We want to keep this backbone (for some reasons out of the scope of this discussion). There is clearly no protocol error, just the topology is a bit unusual. If you look at Simon's drawing, you can see that the arrow is only one way. RFC-822 hosts on SWITCH sends their mail to a local gateway which then uses the X.400 backbone to the WEP. Then the WEP converts the mail back to RFC-822 to send it on Internet. I agree, this could be considered as a waste of resource, but it is the way we are doing things. I guess the topology we have will be quite common in the future, and will last as long as SMTP and X.400 will coexist on the same network. Bertrand Buclin SIC-EPFL ------- Message 8 From: BUCLIN@ch.epfl.sic To: rd-mhs-managers@no.rare Subject: Re: RFC 987 mapping and DDA usage Date: 25 Feb 91 09:21 +0100 RFC-822-Headers: X-ST-Vmsmail-To: GW::"rd-mhs-managers@rare.no" ================== >This is on the assumption that RFC-1148/2 is deployed in a network with >reasonably full interconnectivity on both X.400 and RFC-822 sides. >So, can we agree that gateway tables, like source route strippers, are >an OPTIMIZATION feature and not a CRITICAL feature? Harald, use of gateway tables have an impact on the mapping algorithm used. I don't think we can make it only optional. Bertrand Buclin SIC-EPFL ------- Message 9 From: BUCLIN@ch.epfl.sic To: rd-mhs-managers@no.rare Subject: Re: RFC 987 mapping and DDA usage Date: 25 Feb 91 09:26 +0100 RFC-822-Headers: X-ST-Vmsmail-To: GW::"rd-mhs-managers@rare.no" ================== Christian, I agree with your 4 first points, but not with the last 3 : >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". This should normally not happen since the gateway is a at least a WEP. Furthermore, the gateway listed in the gateway table should accept mails from everywhere, provided the recipient is in one of the domains served by that gateway. Of course, there should be provisions made to avoid gateway abuse... >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. In that case, there is no need for a gateway, except if the originating host has no access to Internet. >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". This is exactly the point. If we send a mail through X.400, of course one can assume the mail should travel as long as possible in the X.400 network, else there is no need to have a RARE project for MHS coordination ... Bertrand Buclin SIC-EPFL ------- End of Forwarded Messages