Transport of Binary Data in AMHS

Transport of binary data messages in AMHSACP/WGN and SGN3 meetings (Montreal, May 2004)

ACP WGN03-WP25

ACP/SGN3 WP/2-4a

19/05/04

AERONAUTICAL COMMUNICATIONS PANEL(ACP)

Working Group N - NETWORKING

SUBGROUP N3 – GROUND-GROUND Applications

Montréal, May 2004 (SGN3 second meeting, WGN third meeting)

Agenda Item 3 : ATS Message Handling Services

Transport of binary data messages in AMHS

Presented by Jean-Marc Vacher

Summary

The AMHS specification, as defined in ICAO Document 9705 Edition 3, includes the capability to convey binary data messages. This function is defined as part of the Extended ATS Message Handling Service.

The World Meteorological Organization (WMO) has recently decided to migrate to Binary Universal Form for the Representation of meteorological data (BUFR) for Coded Meteorological Messages. This migration creates a new operational requirement for the Aeronautical Fixed Service, to convey OPMET messages in BUFR format. OPMET messages for aeronautical use are currently transferred using the AFTN, and these exchanges will migrate to AMHS as the AFTN/CIDIN environment is progressively replaced by AMHS. The latter is therefore an appropriate means for transfer of OPMET messages with this new format.

The goal of this paper is to review the AMHS specification for transfer of binary data messages, in the light of this new requirement. The paper proposes the adoption of the MHS FTBP (file-transfer body part) for this purpose and its inclusion in Document 9705.

TABLE OF CONTENTS

1Introduction

2Background

3Additional requirements to the current specification

3.1Issues related to the current specification

3.2Requirements

4Alternative options for conveyance of binary data in amhs

4.1List of options

4.2Option A: specific user format within the BBP

4.3Option B: use of IPM heading fields in addition to the BBP

4.4Option C: specification of a new extended body part type

4.5Option D: use of the file-transfer body part (FTBP) defined in the base standards

5Technical recommendation

6Recommendations to the meeting

7Appendix A: Impact on ATS Message servers and P1/P3/P7 protocol

8Appendix B: Proposed Doc 9705 Amendment to support FTBP

REFERENCES

[1]Report of ACP WGN-02 meeting, Bangkok, 14-19 November 2003

[2]Manual of Technical Provisions for the Aeronautical Telecommunication Network (ATN), ICAO Doc 9705, Third Edition - Sub-Volume III, Ground-Ground Applications

[3]Comprehensive ATN Manual (CAMAL), ICAO Document 9739, Second Edition (draft to be published)

[4]CCITT Rec. X.420 (1992). Message handling systems: Interpersonal messaging system.

[5]ISO/IEC 100217:1999. Information Technology— Text Communication— Message Handling Systems (MHS)— Part7: Interpersonal Messaging System

[6]ISO/IEC ISP 120622:1997 (Second Edition). Information Technology — International Standardized Profiles AMH1n — Message Handling Systems — Interpersonal Messaging — Part 2: AMH21 — IPM Content.

[7]ISO/IEC 100214. Information Technology— Text Communication— Message Handling Systems (MHS)— Part4: Message Transfer System: Abstract Service Definition and Procedures (equivalent to ITUT Rec. X.411)

1Introduction

The goal of this paper is to review the AMHS specification for transfer of binary data messages, in the light of this new requirement.

2Background

In MHS/X.400 standards, the requirement to transfer binary user data messages applies to the body of the Inter-Personal Messages (IPM) that are exchanged. The implication is that this requirement applies at the level of the X.400 P2 protocol, which is implemented in UAs, or in AMHS at the level of ATS Message User Agents. The exchanges between MTAs or ATS Message Servers, which are performed using the P1 protocol, are largely unaffected by such a requirement[1].

The ability to convey binary data is conditioned by the types of body parts that a UA is able to generate. At present the body part type specified for conveyance of binary data in ICAO Document 9705 Edition 3 is the “bilaterally-defined body part” (see [2]).

Support of bilaterally-defined body parts is a mandatory requirement for the Extended ATS Message Handling Service. This requirement is applicable to ATS Message User Agents.

3Additional requirements to the current specification

3.1Issues related to the current specification

Bilaterally-defined body parts are adequate for transfer of binary data files. Furthermore, they are supported by the vast of majority of Commercial-Off-The-Shelf MHS/X.400 UAs, this being a significant advantage for ease of implementation.

However, there are a number of limits or drawbacks inherent to this body part type, from both a standardization and an implementation viewpoint.

The definition of bilaterally-defined body part stems from the 1984 MHS standards. It was maintained in subsequent editions of the base standards (CCITT 1988 and 1992, or equivalently ISO/IEC 1990 and 1997), but its use is deprecated in these later editions.

The main drawback of this body part type is that it does not convey an indication about the nature of the binary data included in the body part. For example, if the data is a Microsoft Windows file, there is no means in the body part to convey the file name, nor even a file extension. Although this is not critical for origination, it is an issue for the recipient UA which does not know, upon reception, the nature and format of the received data.

In practice the recipient UA must therefore store the received data in a non-qualified format (e.g. a COTS UA would store it with a generic filename such as “Body.Bin”), and leave it up to the user (or up to a specific piece of software) at a later stage, to identify by a distinct operation the type and format of data, and to determine or allocate an appropriate file name under the recipient UA’s operating system.

This situation might be acceptable in a closed environment with one single category of binary data messages being exchanged, or with add-on software able to sort out among the different flows. However, in the context of AMHS which may serve for several traffic types (flight plans, OPMET, AIS, etc.) it becomes difficult to manage.

3.2Requirements

From the issues identified above, it appears that at least two major pieces of information related to each binary data message should be made directly available to the recipient UA and user, and are currently missing with the current bilaterally-defined body parts without further specification:

an indication of the message type,
an identification of the binary data set included in the message, such as a file- or pathname.

More detailed information might be required, but at this stage such details are difficult to identify. It may also be assumed that the binary data itself is likely to contain self-descriptive information (e.g. message sub-type, date/time information, etc.).

This paper therefore analyses options to convey such additional information, and to open the capability for conveyance of more if needed.

The term “required additional information” or RAI identifies in this paper the set of descriptive elements that must be conveyed together with the binary data in a given message. This allows to refer to it even without a clear knowledge of what is exactly required.

4Alternative options for conveyance of binary data in amhs

4.1List of options

In this section, a number of alternative options are explored to resolve the issues identified above, through a refinement or amendment to the current specification.

Other options might probably be envisaged, in particular if the requirement that an AMHS IPM must contain a single body part is relaxed to allow multiple body part messages. However this is not considered in the scope of this paper.

The analyzed options are the following:

a)specify a user format for the internal structure of bilaterally-defined body parts (BBP),

b)use of IPM heading fields to convey additional information regarding the contents of the bilaterally-defined body part (BBP),

c)specification of a new body part format, by means of a private extended body part type, as defined in the base standards,

d)use of another standard body part type, namely the file-transfer body part, as defined in the base standards.

4.2Option A: specific user format within the BBP

This option consists in specifying the internal structure of the bilaterally-defined body part, so as to be able to convey at the same time within the body part the required additional information (RAI) and the binary data.

The specification of such an internal structure should use some formal description method capable of being generated and analyzed by standard encoding tools, such as an ASN.1 structure.

The main benefit of this approach is that it does not contradict the current technical provisions included in Document 9705, it only refines them by additional specification.

There are also severe drawbacks inherent to this approach:

An accurate knowledge of the RAI is needed to specify the structure in a way that is software-manageable. To maintain future extensibility, a vision of what RAI may become in the future is also needed. Since this is not formally available, it may require a lot of investigation work and low-productive discussions before getting to an agreeable formal structure.
If not well thought-of in the initial specification, future extensions may require version management to cope with various formats of the internal structure. This may rapidly become impractical.
Such a structure would obviously be ICAO and AMHS-specific. This would prevent the use of COTS UA products, or at least it would require a significant amount of add-on software, thereby contradicting the initial reason for mandating the use of BBP in the Extended ATS Message Handling Service.

4.3Option B: use of IPM heading fields in addition to the BBP

This option consists in conveying the RAI in certain IPM heading fields, while continuing to convey the binary data in a BBP. Such heading fields should be selected among those that are not used in the current AMHS specification. Typically the “Subject” field could be used for this purpose.

If there are not enough fields available, an internal syntax could be defined for the selected fields to convey more information items. An example of this could be to specify a syntax for the use of the Subject-field, resulting in the following:

Subject: [message-type]binarydatafile-ID

The main overall advantage of this option is its simplicity. It only complements the current technical provisions, without preventing the use of COTS UAs since only standard functions are utilized. Because of the simplicity of the approach, the specification work should be quite easy. Finally specific user procedures may need to be defined, or limited bespoke software, to handle the processing of binary data and heading fields upon generation and reception of binary data messages.

Nevertheless this approach is only a work-around, with very limited extension capability and a relative lack of formalism that might hinder interoperability if used on a wide scale. Also there are only a few available built-in heading fields that can be used, and this may also create a significant limit if the RAI is more comprehensive than described above in section 3.2.

4.4Option C: specification of a new extended body part type

The X.420 / ISO 10021-7 base standard defines a mechanism allowing the definition of new extended body part types, often referred to as “Body Part 15” or “BP15” (see [4] and [5]). Such extensions are referenced by Object Identifiers. They are composed of Parameters and Data.

This option consists in using this mechanism to specify an “AMHS binary data” body part type. Using this new body part type, the RAI would be conveyed in the body part parameters and the binary data itself would be conveyed in the body part data.

The main benefit of this option would be the appropriate use of standard extension mechanisms for a specific message format. This is truly how the base standards foresee the handling of specific body parts.

There are still drawbacks with this approach, which are part of those observed for Option A:

An accurate knowledge of the RAI is needed to specify this new body part type. A compromise needs to be made between the amount of information to be introduced in the Parameters, based on the long-term vision of what RAI may become in the future, and the possibility to define further new body part types at a later opportunity when the exact requirement is well-known. This work may require significant investigation and specification work before getting to an agreeable formal structure.
Such a new body part type would obviously be ICAO and AMHS-specific. This would prevent the use of COTS UA products, or at least it would require a significant amount of add-on software.

4.5Option D: use of the file-transfer body part (FTBP) defined in the base standards

This option consists in using the file-transfer body part (FTBP) defined in the base standards to convey files within a MHS IPM. Such files can be of any kind (text or binary). The MHS/X.400 File Transfer body part is described in section B.3 of CCITT X.420 (1992) (see [4]) and later editions, or in ISO/IEC 10021-7: 1997 (Second Edition) (see [5]) and later editions, both documents being technically aligned in this area. The FTBP is composed of (optional) Parameters and Data. It is based on the file model defined in ISO 8571-2 (FTAM).

FTAM was not a successful standard in terms of actual implementation and industry support. The FTBP is probably one of the only practical applications of the file model developed for FTAM. Furthermore it should be noted that the FTBP uses only this model and the associated ASN.1 syntaxes, but it does not use in any way the service or protocol specifications that build the main part of FTAM.

The interesting aspect of the FTBP is that it provides an already standardized model for files, that are by default considered as being “unstructured binary”. It therefore offers a framework, that can be used as appropriate depending on the RAI. Furthermore since the RAI is not well-defined and subject to evolution, the existence of pre-defined parameters facilitates the future support of RAI elements.

The FTBP parameters include 5 parameter sets and an extensions field:

related stored file, which indicates to the recipient any intended relationship between the file in this body part and any file held by the recipient. There is no clear requirement for using this parameter in AMHS;
contents type, which indicates the abstract data types of the contents of the file. One of the elements of this parameter set is “document-type”, which is registered in the ISO FTAM arc[2] of the OID tree. There are 5 registered OID values[3]. In AMHS this should be used to indicate “unstructured binary file”;
environment, which describes the machine, operating system, application, etc. from which the file originated. The optional “application” element is an OID. It may be associated with a (optional) descriptive identifier, which is a GRAPHICAL STRING. The Electronic Messaging Association (EMA) has registered OIDs to be used in the “application” field. These OIDs correspond to popular software packages (Word, Excel, WordPerfect, Lotus Notes, etc.), thereby enabling the recipient UA to determine the appropriate viewer for the file. Certain OIDs registered by EMA are also generic (“generic binary attachment”, “generic text attachment”, etc.). In AMHS this could be used to indicate the message-type, by means of the “application” element, provided that it does not conflict with another usage based on EMA- (or another body) registered values.;
compression, which describes the compression type if the file is transferred in a compressed-mode. There is no clear requirement for using this parameter in AMHS;
file attributes, which conveys a set of optional file attributes. When the recipient is to create a new file, these values are to be used in establishing the initial file attributes. 15 attributes are defined, including an attribute-extensions field. The ASN.1 syntax for most of these attributes was originally defined in ISO 8571-2, FTAM, and it is imported in the X.420 IPMS ASN.1. In AMHS this should be used to convey at least the file pathname (one of the attributes), which could include the message type, and possibly date/time information (3possible attributes) if needed.

Furthermore, ISO/IEC ISP 12062-2:1997 (AMH21 – IPM Content) mandates support of FTBP in reception (see ref [6], A.1.3.1) as part of the ISP basic requirements. Support in origination is optional only. ISO/IEC ISP 12062-2:1997 is the 2nd Edition of the ISP[4]. This demonstrates a significant interest for this type of body part among the MHS implementers’ community at the time when the ISPs were developed[5]. ISO/IEC ISP 12062-2 mandates a minimal number of elements among the file-transfer parameters:

contents-type,
application-reference,
pathname,
date/time of last modification,
object-size.

Although minimal, this should be sufficient for the envisaged RAI in AMHS.