Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!lll-tis!oce.nl!mhsc From: mhsc@oce.nl Newsgroups: comp.protocols.iso.x400.gateway Subject: Re: IFIP Gateway Workshop Report Message-ID: <8811161332.AA04235@oce-rd2.oce.nl> Date: 16 Nov 88 15:32:49 GMT References: <8811100223.AA13170@tis.llnl.gov> Sender: root@tis.llnl.gov Distribution: inet Organization: The Internet Lines: 83 Approved: post-x400-gateway@tis.llnl.gov 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