Transport of binary data in AMHS



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

1 Introduction 3

2 Background 3

3 Additional requirements to the current specification 3

3.1 Issues related to the current specification 3

3.2 Requirements 4

4 Alternative options for conveyance of binary data in amhs 4

4.1 List of options 4

4.2 Option A: specific user format within the BBP 5

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

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

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

5 Technical recommendation 8

6 Recommendations to the meeting 9

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

8 Appendix B: Proposed Doc 9705 Amendment to support FTBP 11

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 10021-7:1999. Information Technology — Text Communication — Message Handling Systems (MHS) — Part 7: Interpersonal Messaging System

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

[7] ISO/IEC 10021-4. Information Technology — Text Communication — Message Handling Systems (MHS) — Part 4: Message Transfer System: Abstract Service Definition and Procedures (equivalent to ITU-T Rec. X.411)

Introduction

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 (see [1]). The AMHS is an appropriate transfer means for OPMET messages in BUFR 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.

Background

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.

Additional requirements to the current specification

1 Issues 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.

2 Requirements

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.

Alternative options for conveyance of binary data in amhs

1 List 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.

2 Option 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.

3 Option 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 Option 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.

5 Option 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 (3 possible 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.

There are no obvious drawbacks to the use of FTBP in the AMHS context. The only uncertainty is the level of support of this body part type by COTS UAs, in general and also in terms of supported elements of the ASN.1 syntax and/or parameters for AMH21 conformance.

Based on initial investigations, it may reasonably be expected that the FTBP be supported by various COTS UA software suppliers. At present at least three distinct European MHS suppliers have been already identified as supporting the FTBP [Atos, Bouldon James, Maxware]. For those from which detailed information was available, the supported parameters correspond to those mandated by AMH21 (ISO/IEC ISP 12062-2).

Technical recommendation

Based on the analysis in section 4 above, it is proposed that the use of FTBP be included in the AMHS specification, in Doc 9705, for the transport of binary data.

The question of its status should be addressed. In line with the current specification for bilaterally-defined body parts (BBP), It is proposed that the FTBP status be mandatory upon origination and reception, in the Extended ATS Message Handling Service. In the Basic Service it would be optional in all cases. This requirement refers to static conformance, i.e. a conformant UA shall have the capability to generate AMHS messages including this body part type.

Another question is the resulting status of the BBP, currently specified as mandatory in the Extended Service. Two options are possible:

• Revert the mandatory requirement for BBP to an optional requirement when introducing FTBP. This more or less leads to replacing BBP with FTBP;

• Maintain the requirement for BBP and additionally insert the mandatory requirement for FTBP, together with a recommendation / explanation to use the latter.

The first option is preferred to avoid confusing AMHS users with two potential body parts for the same use. However relaxing requirements in such a way is sometimes controversial and a consensus should be made within ACP WGN.

When this proposal is accepted by ACP WGN, the relevant Amendments to Document 9705 and Document 9739 should be prepared for approval by the ACP/1 meeting. A draft amendment proposal is attached as Appendix B to this paper, regarding Document 9705.

Recommendations to the meeting

The meeting is invited to endorse the recommendation above to mandate support of FTBP in the AMHS specification, for the transport of binary data. It is further invited to determine the status of BBP in view of this additional requirement.

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

The processing performed by MTAs, as well as the P1 protocol exchanges between MTAs, (or the P3/P7 submission/delivery exchanges) are largely independent of the message contents, i.e. of the IPM itself and consequently of the body parts which it is composed of. The IPM is BER-encoded to build an Octet String that constitutes the content of the P3-message (and of the P1-message). It is not decoded by the transferring MTAs.

However, there is one element of the P1/P3 envelope conveying an IPM which is directly related to the body parts building the IPM, it is the encoded-information-types or EITs (see [7]). This element qualifies the encoding of the IPM, it is a parameter of the P1/P3 envelope that can be generated by the submitting UA, and its value must be conveyed by the transferring MTAs. Upon reception by the delivering MTA, the EITs value provided by the P1 envelope of the received message is checked against the recipient’s UA capabilities, to determine whether the IPM body (and its body parts) can be decoded by the recipient UA. If the EITs value matches the recipient’s UA capabilities, the message is delivered, otherwise a non-delivery-report is generated by the delivering MTA with an appropriate non-delivery-diagnostic-code.

For basic body part types (e.g. ia5-text or bilaterally-defined) the EITs is a base-standard specified builtin-encoded-information-types element, with a BIT STRING syntax. For extended body types (e.g. general-text or file-transfer) the EITs is an extended-encoded-information-types element, which consists in an Object Identifier (OID).

According to X.420 (1992) (ref [4]) and ISO/IEC10021-7:1997 (ref [5]), B.3.8, the extended EIT OID value is {joint-iso-itu-t(2) mhs(6) ipms(1) eit(12) file-transfer(0)}.

The requirement placed upon the MTA with regard to the EITs is limited to the transparent transfer of its value and to the checking procedure described above. This is however a standard MTA function that should logically be part of any ATS Message Server conformant to the Basic ATS Message Handling Service. The support of extended EITs by ATS Message Servers is already mandatory for the support of general-text body parts.

In summary the AMHS support of FTBP (or of another extended body part type) does not create any identified additional requirement upon an ATS Message Server conformant to the Basic ATS Message Handling Service.

Appendix B: Proposed Doc 9705 Amendment to support FTBP

A) Amend Section 3.1.2.2.1.3 as follows:

3.1.2.2.1.3 Additional UA profile specification in support of the Extended ATS Message Service

Note.— An ATS Message User Agent supporting the Extended ATS Message Service also needs to maintain the Basic ATS Message Service capability. Therefore the profile requirements in this section are in addition to those in 3.1.2.2.1.1.

3.1.2.2.1.3.1 Message Content Profile Specification

3.1.2.2.1.3.1.1 An ATS Message User Agent supporting the Extended ATS Message Service shall conform to:

a) the requirements of 3.1.2.2.1.1.1;

b) the requirements additional to AMH21, described in Clause A.2.5 of ISO/IEC ISP12062-2:1999 for the support of the IPM Business Class (BC) Functional Group; and

c) the additional requirements described in Table 3.1.2-2.

Note 1.— Table 3.1.2-2 specifies the additional requirements in the form of a PRL (Profile Requirement List) expressing restrictions to a set of rows of the AMH21 profile, which are referred to using their reference in ISO/IEC ISP 12062-2:1999.

Note 2.— The use of the bilaterally-defined body part as specified in Table 3.1.2-2/AMH21/A1.3.1 ensures enables operability with both 1984 and 1988 IPM (Inter-Personal Message) UAs for the exchange of unstructured binary data. In accordance with ISO/IEC 10021-7 clause 7.3.10 and subsequent Note, its use is now discouraged.

Note 3.- The use of the file-transfer body part as specified in Table 3.1.2-2/AMH21/A1.3.1 is the preferred means of conveying unstructured binary data in IPMs exchanged between ATS Message User Agents.”

B) Amend Table 3.1.2-2/AMH21/A1.3.1:

- Amend Part 3 as shown below

- Insert Note 3 and comments at the bottom of the table as shown below

|Ref |Element |Origination |Reception |Extended ATS Message|ATN reference |ISP 12062-2 |

| | | | |Handling Service | |Notes/References |

| | | | |Support | | |

| | |Base |ISP |Base |ISP | | | |

|Part 3 : AMH21/A.1.3.1 Extended body part support |

|9 |bilaterally-defined-bo|O |O |O |O |MO/M |3.1.2.2.3.4.1 | |

| |dy-part | | | | | | | |

|12 |file-transfer-body-par|O |O |O |M |M/M |3.1.2.2.3.4.2 |Note 3 and A.1.3.3 |

| |t | | | | | | | |

Legend : see 3.1.1

M = mandatory support

M1 = mandatory O/R name minimal support

O = optional support

NOTE 3 - The octet-aligned EXTERNAL encoding should be used. Only one EXTERNAL component should be used. Where the file to be conveyed contains a compound structure, this may be represented as a SEQUENCE OF EXTERNALS; the primary data should be placed in the first EXTERNAL. Receiving systems may ignore all but the first EXTERNAL in the SEQUENCE.

C) Amend clause 3.1.2.2.3.4 as follows:

3.1.2.2.3.4 Binary data exchanges

3.1.2.2.3.4.1 Recommendation.- The use of bilaterally-defined body parts for IPMs in support of binary data exchanges should be avoided, except when, for reasons outside the scope of AMHS, interoperability with both 1984 and 1988 IPM (Inter-Personal Message) UAs is required.

3.1.2.2.3.4.2 Bilaterally-defined body orFile-transfer body parts shall be used only for IPMs in support of the binary data exchanges that contain any binary data.

3.1.2.2.3.4.3 For the support of file-transfer body parts, an ATS Message User Agent shall comply with the requirements of ISO/IEC ISP 12062-2:1999 (AMH21) section A.1.3.3 (file transfer parameters).

D) Amend table 3.1.2-42:

- Amend Part 3 and introduce new Parts 4 and 5 as shown below,

- Renumber existing Parts 4 and 5 into 6 and 7.

|Ref |Element |Origination |Action |Mapping / Notes |

| | |Base |ISP |Extend. ATS | | |

| | | | |Mess. | | |

| | | | |Handling | | |

| | | | |Service | | |

|Part 3 : AMH21/A.1.3 IPM body |

|1 |ia5-text |O |O |M |T1 |see Part 3/1.1 and 1.2 |

|1.1 |parameters |M |M |M |G |See Part 3/1.1.1 |

|1.1.1 |repertoire |O |O |O |G |see 3.1.2.4.5.1.2.3.5 |

|1.2 |data |M |M |M |T |see Part 5 |

|2 |voice |I |I |I |X |- |

|3 |g3-facsimile |O |O |O |X |- |

|4 |g4-class-1 |O |O |O |X |- |

|5 |teletex |O |O |O |X |- |

|6 |videotext |O |O |O |X |- |

|7 |encrypted |O |O |O |X |- |

|8 |message |O |O |O |X |- |

|9 |mixed-mode |O |O |O |X |- |

|10 |bilaterally-defined |O |O |MO |T1X |see 3.1.2.4.5.1.2.3.5 and Part 6- |

|11 |nationally-defined |O |O |O |X |- |

|12 |extended |M |M |M |XG |-see Part 4 |

|Part 4 : AMH21/A.1.3.1 Extended body part support |

|12 |file-transfer-body-part |O |O |M |T1 |see 3.1.2.4.5.1.2.3.5 and Part 6 |

|Part 5 : AMH21/A.1.3.3 File transfer parameters |

|1 |related-store-file |O |O |O |X |- |

|2 |contents-type |O |M1 |M1 |G |see ISO/IEC ISP 12062-2 Note 1 |

| | | | | | |and 2.1 below |

|2.1 |document-type |O |O |O |G |see 2.1.1 below |

|2.1.1 |document-type-name |M |M |M |G |see 3.1.2.4.5.1.2.3.12 |

|2.1.2 |parameter |O |O |O |X |- |

|2.2 |constraint-set-and-abstrac|O |O |O |X |- |

| |t-syntax | | | | | |

|3 |environment |O |M |M |G1 |see 3.1 below |

|3.1 |application-reference |O |O |O |G |see 3.1.1 below |

|3.1.1 |registered-identifier |O |M |M |G1 |see 3.1.2.4.5.1.2.3.13 |

|3.1.2 |descriptive-identifier |O |O |O |X |- |

|3.2 |machine |O |O |O |X |- |

|3.3 |operating-system |O |O |O |X |- |

|3.4 |user-visible-string |O |M2 |O |X |- |

|4 |compression |O |O |O |X |- |

|5 |file-attributes |O |M |M |G |see 5.1 below |

|5.1 |pathname |O |M |M |G1 |see 5.1.1 below |

|5.1.1 |incomplete-pathname |O |M3 |M3 |G1 |see ISO/IEC ISP 12062-2 Note 3 and |

| | | | | | |3.1.2.4.5.1.2.3.14 |

|5.1.2 |complete-pathname |O |O |O |X |see ISO/IEC ISP 12062-2 Note 3 |

|5.2 |permitted-actions |O |O |O |X |- |

|5.3 |storage-account |O |O |O |X |- |

|5.4 |date-and-time-of-creation |O |O |O |X |- |

|5.5 |date-and-time-of-last-modi|O |M4 |M4 |G1 |see ISO/IEC ISP 12062-2 Note 4 and |

| |fication | | | | |3.1.2.4.5.1.2.3.15 |

|5.6 |date-and-time-of-last-read|O |O |O |X |- |

| |-access | | | | | |

|5.7 |date-and-time-of-last-attr|O |O |O |X |- |

| |ibute-modification | | | | | |

|5.8 |identity-of-creator |O |O |O |X |- |

|5.9 |identity-of-last-modifier |O |O |O |X |- |

|5.10 |identity-of-last-reader |O |O |O |X |- |

|5.11 |identity-of-last-attribute|O |O |O |X |- |

| |-modifier | | | | | |

|5.12 |object-availability |O |O |O |X |- |

|5.13 |object-size |O |M5 |M5 |G1 |see ISO/IEC ISP 12062-2 Note 5 and |

| | | | | | |3.1.2.4.5.1.2.3.16 |

|5.13.1 |no-value-available |O |O |O |X |- |

|5.13.2 |actual-values |O |M |M |G1 |see 3.1.2.4.5.1.2.3.16 |

|5.14 |future-object-size |O |O |O |X |- |

|5.15 |access-control |O |O |O |X |- |

|5.16 |legal-qualifications |O |O |O |X |- |

|5.17 |private-use |O |O |O |X |- |

|5.18 |attribute-extensions |O |O |O |X |- |

|6 |extensions |O |O |O |X |- |

| | | | | | | |

Legend (see 3.1.1):

M = mandatory support

O = optional support

I = out of scope

- = not applicable

G = generated

G1 = optionally generated

T = translated

T1 = conditionally translated

X = excluded (not used)

ISO/IEC ISP 12062-2:1999 Notes:

1 - The DEFAULT value "unstructured-binary" should be used for all byte stream formats (e.g. DOS, UNIX). This is the only required value.

2 - This element should be used to convey any additional distinguishing information that might be of use to the receiver e.g. for presentation to a user or in cases where the application-reference OID is not recognized by the receiving system.

3 - The SEQUENCE should only consist of a single GRAPHICSTRING element containing a string that might provide an end-user with additional information about the attachment.

3 - The SEQUENCE should only consist of a single GRAPHICSTRING element containing the target file/attachment name without any preceding path information.

4 - Localtime should be used i.e. with timezone indication.

5 - The value used represent the size of the Attachment data in bytes. Absence of the object size attribute is equivalent to no object size value being available. Use of the information on receipt is a local matter.

E) Amend clause 3.1.2.4.5.1.2.3.5 as follows:

3.1.2.4.5.1.2.3.5 The body part type of the converted AMHS message shall be depending on the value of the Data Designator included in the Abbreviated Heading either:

a) “ia5-text” where the element repertoire takes the abstract value “ia5”, if the value of the Data Designator indicates a textual data type; or

b) “bilaterally-defined”“file-transfer-body-part”, if the value of the Data Designator indicates a non-textual data type.

Note.—The relevant details of the Abbreviated Heading are described for guidance purposes in ICAO Document 9739.

F) Create new clauses 3.1.2.4.5.1.2.3.12 to 3.1.2.4.5.1.2.3.16 as follows:

3.1.2.4.5.1.2.3.12 The element document-type-name in the document-type element of the contents-type parameter shall take its default value in conformance with ISO/IEC 10021-7:1999 clause 7.4.12, which is the OID value {iso(1) standard(0) 8571(8571) document-type(5) unstructured-binary(3)}.

3.1.2.4.5.1.2.3.13 The element registered-identifier in the application-reference element of the environment parameter shall:

a) be optionally generated; and

b) when present, take the OID value registered by the Electronic Messaging Association (EMA) to represent the abstract-value “generic-binary-attachment”, which is the OID value { 2.16.840.1.113694.2.2.1.1 }.

3.1.2.4.5.1.2.3.14 The element pathname in the file attributes parameter shall:

a) be optionally generated using the incomplete-pathname element; and

b) when present, contain a file name value, without preceding path information, to be potentially used for local storage of the ATS-Message-data by the receiving CIDIN/AMHS gateway or direct user.

3.1.2.4.5.1.2.3.15 The element date-and-time-of-last-modification in the file attributes parameter shall be optionally generated.

3.1.2.4.5.1.2.3.16 The element actual-values of the object-size element in the file attributes parameter shall:

a) be optionally generated; and

b) when present, take a value representing the size of the ATS-Message-data element in bytes.

G) Amend Table 3.1.2-43 Part 2 element 3 as follows:

|Ref |Element |Origination |Action |Mapping / Notes |

| | |Base |ISP |Extend. ATS | | |

| | | | |Mess. | | |

| | | | |Handling | | |

| | | | |Service | | |

| |

|PART 2 : AMH11/A.1.5 COMMON DATA TYPES |

|3 |EncodedInformation Types | | | | | |

|3.1 |built-in-encoded-informati|M |M |M |GX |see 3.1.2.4.5.1.2.4.4 |

| |on-types | | | | | |

|3.2 |(non-basic parameters) |O |M- |M- |X |- |

|3.3 |extended-encoded-informati|M |M |M |G |see 3.1.2.4.5.1.2.4.4 |

| |on-types | | | | | |

H) Amend clause 3.1.2.4.5.1.2.4.4 as follows:

3.1.2.4.5.1.2.4.4 The element original-encoded-information-types shall be formed as specified in Table 3.1.2-43/ Part 2/ 3, depending on the value of the Data Designator included in the Abbreviated Heading :

a) take the abstract-value “ia5-text”, which is a value of type BuiltInEncodedInformationTypes and be formed as specified in Table 3.1.2-43/ Part 2/ 3, if the value of the Data Designator indicates a textual data type; or

b) take the value “undefined”, take the form of an extended-encoded-information-types, including at least the OID value {joint-iso-itu-t(2) mhs(6) ipms(1) eit(12) file-transfer(0)} if the value of the Data Designator indicates a non-textual data type.

Note 1.— The OID value of the extended encoded information type “undefined” is taken in compliance with ISO/IEC 10021-7:1999, clauses 7.4.12.8 and 20.4. Additional OID values may be included as a local matter but they are not interpreted upon reception.

Note 2.— The relevant details of the Abbreviated Heading are described for guidance purposes inICAO Document 9739.

H) Amend clause 3.1.2.4.5.2.2.1.1 as follows:

3.1.2.4.5.2.2.1.1 Upon reception by the Message Transfer and Control Unit of an IPM, the received message shall be processed in one of the following manners, depending on the abstract-value of the current encoded-information-types, determined as either the abstract-value of the latest converted-encoded-information-types, if existing, in the trace-information element, or as the abstract-value of the original-encoded-information-types element if the previous does not exist:

a) processing as specified in 3.1.2.4.5.2.2.1.2 if the (abstract-)value of the current encoded-information-types is any of the following:

1) basic “ia5-text”;

2) externally-defined “ia5-text”;

3) OID {id-cs-eit-authority 1} as specified in ISO/IEC 10021-7;

4) OID {id-cs-eit-authority 2} as specified in ISO/IEC 10021-7;

5) OID {id-cs-eit-authority 6} as specified in ISO/IEC 10021-7; or

6) OID { joint-iso-itu-t(2) mhs(6) ipms(1) eit(12) file-transfer(0)} as specified in ISO/IEC 10021-7.basic “undefined”; or

7) externally-defined “undefined”; or

b) if the abstract-value differs from all values indicated in item a) above:

1) rejection of the message for all the message recipients; and

2) generation of a non-delivery report as specified in 3.1.2.4.3.4 with the following elements taking the following abstract-values in all the per-recipient-fields of the report:

i) “unable-to-transfer” for the non-delivery-reason-code; and

ii) “encoded-information-types-unsupported” for the non-delivery-diagnostic-code.

I) Amend clause 3.1.2.4.5.2.2.1.3 as follows:

3.1.2.4.5.2.2.1.3 A message which was not rejected as the result of 3.1.2.4.5.2.2.1.2 shall be processed in one of the following manners:

a) processing as specified in 3.1.2.4.5.2.2.1.4 if the body part type is one of the following:

1) a basic body part type “ia5-text”;

2) a standard extended body part type “ia5-text-body-part”;

3) a standard extended body part type “general-text-body-part” of which the repertoire set description is Basic (ISO 646); or

4) a standard extended body part type “file-transfer-body-part”; or basic body part type “bilaterally-defined”; or

5) a standard extended body part type “bilaterally-defined”; or

b) if the body part type is different from the body part types 1) to 5)4) under a) above:

1) rejection of the message for all the message recipients; and

2) generation of a non-delivery report as specified in 3.1.2.4.3.4 with the following elements taking the following abstract-values in all the per-recipient-fields of the report:

i) “unable-to-transfer” for the non-delivery-reason-code;

ii) “content-syntax-error” for the non-delivery-diagnostic-code; and

iii) “unable to convert to CIDIN due to unsupported body part type” for the supplementary-information.

J) Amend the elements extracted from Table 3.1.2-45 as follows:

|Ref |Element |Reception |Action |Mapping / Notes |

| | |Base |ISP |Extend. ATS | | |

| | | | |Mess. | | |

| | | | |Handling | | |

| | | | |Service | | |

| |

|PART 3 : AMH21/A.1.3 IPM BODY |

|10 |bilaterally-defined |O |O |MO |T1X |see Part 7 Note 1 |

| |

|PART 4 : AMH21/A.1.3.1 EXTENDED BODY PART SUPPORT |

|9 |bilaterally-defined-body-p|O |O |O |T1X |see Note 1Part 3/10 |

| |art | | | | | |

|12 |file-transfer-body-part |O |O |M |XT1 |see Part 7Note 1 |

K) Amend clause 3.1.2.4.5.2.2.1.3 as follows:

3.1.2.4.5.2.2.3.5 The ATS-Message-Data component included in a bilaterally-defined file-transferbody part shall be used as the CIDIN user-data of the generated CIDIN/OPMET Message.

Note.— For the CIDIN/OPMET Message the Data Designator included in the Abbreviated Header specifies the data type in use (cf. Table 3.1.2-44).

- END OF DOCUMENT -

-----------------------

[1] Appendix A to this paper explains the only consequence of the support of body part types over the P1, P3 and P7 protocols, which is at the level of encoded-information-types (EITs).

[2] The arc is {iso(1) standard(0) iso8571(8571) document-type(5) }.

[3] Registered values are “unstructured-text(1)”, “sequential-text(2)”, “unstructured-binary(3)”, “sequential-binary(4)”, “simple-hierarchy(5)”.

[4] Doc 9705 refers to the 1st ISP Edition for the Basic ATS Message Handling Service, and to some extensions included in the 3rd ISP Edition for the Extended ATS Message Handling Service.

[5] It should be recalled that the MHS ISPs were prepared with the collaboration of:

- OSI Asia-Oceania Workshop (AOW);

- European Workshop for Open Systems (EWOS);

- Open Systems Environment Implementors’ Workshop (OIW).

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download