Christian.Huitema@mirsa.inria.fr (Christian Huitema) (02/25/91)
> >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
S.Kille@cs.ucl.ac.UK (Steve Kille) (02/25/91)
I have forwarded your message to ifip-gtwy PLEASE PLEASE PLEASE - let us have this disucssion on ONE list only: the ifip-gtwy list. This is the correct place for this discussion, and all interested parties should be on this list. It is very bad messaging style to continue discussions on multiple lists. Where there are lists such as these three, with overlapping interestests, many people will be on all lists. So lets keep the technical discussions of 1148 to ifip-gtwy. Policy impacts of these choices can be discussed on WG1 and operational issues on rd-mhs-managers. Overlap in membership of these lists should ensure coherency. ((General aside/gripe which I have made before: too many messages go to both rare-wg1 and rd-mhs-managers. I think that the scope of these lists should be examined, so that most messages can go to only one)) Brief comments. Christians points in his message are sound (aligned to my previous succinct comment and what the changes to 1148) On Simon's A-B-C-D topology, and the discussion theron: The RFC 822 world is larger than the Internet/RFC 821. You cannot assume that all 822 sites (or 1148 gateways) are on the Internet. This was discussed extenisvely on ietf-osi-x400@cs.uwisc.edu in the context of DNS support for 1148. RFC 822 recognises this discontinuity by the extenisve use of MX records to point to parts of the 822 world which are not directly accessible. Simon's topology is real, and needs supporting (1148bis does this). Even if it was technically possible, there are political reasons (Those described by Betrand Buclin are a good example) which will force this approach. Betrand is also correct that use of the gateway table will need to be mandatory. Steve