Path: utzoo!utgpu!watmath!clyde!mcdchg!chinet!att!rutgers!apple!bionet!agate!helios.ee.lbl.gov!lll-tis!TIS.LLNL.GOV!kehres From: kehres@TIS.LLNL.GOV (Tim Kehres) Newsgroups: comp.protocols.iso.x400.gateway Subject: IFIP Gateway Workshop Report Message-ID: <8811100223.AA13170@tis.llnl.gov> Date: 9 Nov 88 10:23:07 GMT Sender: root@tis.llnl.gov Distribution: inet Organization: The Internet Lines: 209 Approved: post-x400-gateway@tis.llnl.gov Below is the current text for the gateway workshop report from the recent IFIP conference in Costa Mesa. This report was compiled by Mike Westbrook and myself and we believe the contents to accurately reflect what was discussed in the meeting. This text will be sent to North Holland for publication with the conference proceedings. If there are any errors or omissions, please let me know as soon as possible so that the corrections can be incorporated into the final text. Tim Kehres ---------- cut here ---------- cut here ---------- cut here ---------- MHS Gateway Working Group Report October 11, 1988, Costa Mesa, California, U.S.A. A working group met at the IFIP 6.5 working conference to discuss X.400(84) and X.400(88) interworking problems. Those in attendance were Brad Benson, Jaime Delgado, Tim Kehres, Hanne Larsen, Erik Lillevold, Arne Litlere, Yarran Lu, Jim McHugh, Sonu Mirchandani, Bob Purvy, Michael Rosin, Steve Schramm, Norry Shimizu, Alnoor Shivji, and Mike West- brook. The group used the position paper by Tim Kehres, Message Handling Systems: Interoperability Problems Between 1984 and 1988 X.400 as the basis for most of the discus- sions. The meeting started out by trying to identify the prob- lems with MHS(84) and MHS(88) interworking. The CCITT/ISO recommendations state how this is to be accomplished in Annex B of X.419. They specify reasons for non-delivery and a downgrading function for the MTS Transfer Protocol (P1), but give no recommendations for interworking of the 1984 and 1988 versions of the Interpersonal Messaging Protocol (P2). The group felt that X.419, Annex B does not provide an adequate means for the interworking of 1984 and 1988 sys- tems. Some reasons for this are that the downgrading func- tion for P1 will substantially reduce the quality of service for 1988 users when messages are routed through a 1984 MTA. In addition, there are no guidelines for the interworking of P2(84) and P2(88). In order to solve some of the interworking problems, a gateway type of solution was proposed. The group felt that a non-gateway type of solution would be preferable, but no suitable proposals were presented. At this time, the group split into two sub-groups to investigate the interworking problems associated with the P1 and P2 protocols. The P1 sub-group agreed that the rules defined in Annex B of X.419 for non-delivery were acceptable and should be followed. The discarding of protocol elements in X.419 downgrading was determined not to be acceptable when both end systems were 1988 MHS. When routing a message through a 1984 MTA, this downgrading reduces the quality of service to November 9, 1988 - 2 - the 1988 end systems to that of the 1984 routing MTA, which was determined to be unacceptable. One recommendation is to try to avoid all 1984 MTA's whenever possible, but this clearly is not always practical. The other proposal was to construct a gateway between 1984 and 1988 MTA's which would save the discarded protocol elements in a gateway-specific body part. This gateway would exist in each 1988 system that communicates with a 1984 MTA. The gateway would save the discarded protocol elements when transferring to a 1984 domain, and would re-insert such elements into the P1 envelope when received back into a 1988 domain. The P2 sub-group identified differences between the body part types allowed by P2(84) and P2(88). P2(84) defines the Telex and Simple Formattable Document body part types which are no longer included in P2(88). In addition, P2(88) defines the Bilaterally Defined and the Externally Defined body part types which are not present in P2(84). In the case of a Telex(84) body part arriving in a 1988 MTA, this should be converted to an IA5 body part type using the ITA2 character set. No conversion in the 1988 to 1984 direction is needed. A lot of interest was expressed in the handling of ODA body parts in both 1984 and 1988 systems. The procedures for the conversion of the Simple Formattable Document Type, Bilaterally Defined body part type, and the Externally Defined body part type are for further study. When the two sub-groups met, a recommendation was made that MTA routing algorithms should take downgrading into account, and if possible route around 1984 MTA's, instead of downgrading to route through them. It was also felt that Annex B of X.419 violated the spirit of X.400 since the emphasis was on non-delivery at the domain boundary rather than delivery across domains. A solution needs to be iden- tified that is transparent to the 1984 routing MTA's, but at the same time provides some level of pass-through capability when 1988 end systems are communicating via 1984 relays. This group feels that such a solution would best be met by the specification of a gateway between 1984 and 1988 Message Handling Systems. There were several work items that were identified for further study. They are: o The need for more specific O/R Address downgrading procedures. o The need for further definition of P2 interworking problems and potential solutions. o The need to define a gateway body part type to hold November 9, 1988 - 3 - downgrade-removed service elements. o The need to define rules for the packaging and unpack- aging of discarded P1(88) protocol elements. An internet mailing list has been set up to discuss these issues. Contributions to the list can be submitted by sending messages to: ifip-gtwy@tis.llnl.gov Administrative requests such as subscription requests for addition and deletion from the list can be sent to: ifip-gtwy-request@tis.llnl.gov November 9, 1988