kehres@TIS.LLNL.GOV (Tim Kehres) (11/09/88)
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
mhsc@oce.nl (11/16/88)
Hello Tim
I read your minutes of a IFIP meeting on MHS 84/88 interworking. The use of
ODA body part tags was also mentioned in this paper. We are cooperating in
a European research project, funded under the Esprit Programme, where we do
pilot implementations of ODA. It was not exactly clear to me how your group
intends to handle ODA body parts but I would like to explain our position.
At the last Hannover Trade Fair in Germany ICL, Bull,
Olivetti, Siemens and Oce performed
a demonstration of ODIF exchange over an X.400
network. Our experience in this demonstration learned
that the simple use of a body part tag is not suffi-
cient. There is a need to know the Document Architec-
ture and the Document Application Profile used in
the document. These matters have also been signaled by
the CCITT and in the 1988 revision of the standard there
will be a somewhat different handling of ODA body
parts.
Therefore MHS experts of the 11 companies that consider
to participate in the 1989 ODA demonstration have come
together. The companies involved include the 5 demons-
trators of this year and further Nixdorf, British
Telecom, C-labs, Apple Europe and IBM European Network-
ing Center. They set up a more detailed scenario for
the use of 84 X.400 for ODIF document transfer. These
recommendations are based on both the CCITT X.400 and
the ISO MOTIS standards and have taken into account a
smooth transition towards the 1988 revision of the
X.400 standard. Our recommendations have as little as
possible effect on the MHS itself.
Our approach for conveyance of ODA by MHS IPMS
The following is proposed as a medium term solution,
i.e. for the lifetime of MHS based on the 1984 recom-
mendations of the CCITT. When 1988 based system take
over their place, a smooth transition is possible with
the solution sketched in this proposal.
For P2:
An ODA document will be transferred as a single body part
with tag 12:
oda [12] IMPLICIT OCTET STRING
The content of the Octet string will contain (using ASN.1
basic encoding ) a value of type OdaBodyPart, which is a
Sequence containing Parameters and Data components:
OdaBodyPart ::= SEQUENCE {
OdaBodyPartParameters,
OdaData }
The parameters and Data components are each aligned to
Annex E of T.411 (1988) (ie ISO 8613-1)
In this way it is up to the ODA implementation to worry about the handling
of specific ODA content information. We envisage that to ODA
implementation can send a reply message when it is not able to handle the
specific Document Application Profile that is carried in the body, just
like you would want an 1988 MHS implementation to refuse such a message.
I think that besides our configuration there are no ODA/X.400 systems
operational for the moment so I don't think that implementations which
dont't use OdaBodyPartParameters need much attention.
I hope this can be an input to your discussions and I would gladly receive
more detailed information of your ideas on the handling of ODA body parts.
Maarten Schoonwater
PODA project team
Oce Nederland
Venlo Netherlands
mhsc@oce.nl or ...!mcvax!oce-rd1!mhsc