ACP WGN02-WP25
ACP/SGN3 WP/2-4a
12/02/16
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.
Transport of binary data messages in AMHS
ACP/WGN and SGN3 meetings (Montreal, May 2004)
TABLE OF CONTENTS
1
INTRODUCTION ................................................................................................................................................. 3
2
BACKGROUND .................................................................................................................................................... 3
3
ADDITIONAL REQUIREMENTS TO THE CURRENT SPECIFICATION ................................................. 3
3.1
3.2
4
ISSUES RELATED TO THE CURRENT SPECIFICATION ........................................................................................... 3
REQUIREMENTS ................................................................................................................................................ 4
ALTERNATIVE OPTIONS FOR CONVEYANCE OF BINARY DATA IN AMHS ..................................... 4
4.1
4.2
4.3
4.4
4.5
LIST OF OPTIONS ............................................................................................................................................... 4
OPTION A: SPECIFIC USER FORMAT WITHIN THE BBP........................................................................................ 5
OPTION B: USE OF IPM HEADING FIELDS IN ADDITION TO THE BBP .................................................................. 5
OPTION C: SPECIFICATION OF A NEW EXTENDED BODY PART TYPE.................................................................... 6
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 .................................................................................................. 8
7
APPENDIX A: IMPACT ON ATS MESSAGE SERVERS AND P1/P3/P7 PROTOCOL ............................. 9
8
APPENDIX B: PROPOSED DOC 9705 AMENDMENT TO SUPPORT FTBP ........................................... 10
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)
DGAC/STNA/106727733
WGN03-WP__ - SGN3 WP/2-4a
2
12/02/16
Transport of binary data messages in AMHS
1
ACP/WGN and SGN3 meetings (Montreal, May 2004)
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.
2
BACKGROUND
In MHS/X.400 standards, the requirement to transfer binary user data messages applies to the body of the InterPersonal 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
requirement1.
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.
3
3.1
ADDITIONAL REQUIREMENTS TO THE CURRENT SPECIFICATION
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
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).
DGAC/STNA/106727733
WGN03-WP__ - SGN3 WP/2-4a
3
12/02/16
Transport of binary data messages in AMHS
ACP/WGN and SGN3 meetings (Montreal, May 2004)
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.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.
4
ALTERNATIVE OPTIONS FOR CONVEYANCE OF BINARY DATA IN AMHS
4.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 bilaterallydefined body part (BBP),
DGAC/STNA/106727733
WGN03-WP__ - SGN3 WP/2-4a
4
12/02/16
Transport of binary data messages in AMHS
ACP/WGN and SGN3 meetings (Montreal, May 2004)
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.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:
4.3

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.
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.
DGAC/STNA/106727733
WGN03-WP__ - SGN3 WP/2-4a
5
12/02/16
Transport of binary data messages in AMHS
ACP/WGN and SGN3 meetings (Montreal, May 2004)
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.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:
4.5

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.
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:
DGAC/STNA/106727733
WGN03-WP__ - SGN3 WP/2-4a
6
12/02/16
Transport of binary data messages in AMHS
ACP/WGN and SGN3 meetings (Montreal, May 2004)

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 arc2 of the OID tree. There are 5
registered OID values3. 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 attributeextensions 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 ISP4. 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:
2

contents-type,

application-reference,
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)”, “simplehierarchy(5)”.
4
Doc 9705 refers to the 1st ISP Edition for the Basic ATS Message Handling Service, and to some extensions included in the 3 rd 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).
DGAC/STNA/106727733
WGN03-WP__ - SGN3 WP/2-4a
7
12/02/16
Transport of binary data messages in AMHS

pathname,

date/time of last modification,

object-size.
ACP/WGN and SGN3 meetings (Montreal, May 2004)
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. For those from which detailed information was available, the supported parameters correspond
to those mandated by AMH21 (ISO/IEC ISP 12062-2).
5
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.
6
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.
DGAC/STNA/106727733
WGN03-WP__ - SGN3 WP/2-4a
8
12/02/16
Transport of binary data messages in AMHS
7
ACP/WGN and SGN3 meetings (Montreal, May 2004)
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-encodedinformation-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 {jointiso-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.
DGAC/STNA/106727733
WGN03-WP__ - SGN3 WP/2-4a
9
12/02/16
Transport of binary data messages in AMHS
8
ACP/WGN and SGN3 meetings (Montreal, May 2004)
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
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.”
DGAC/STNA/106727733
WGN03-WP__ - SGN3 WP/2-4a
10
12/02/16
Transport of binary data messages in AMHS
ACP/WGN and SGN3 meetings (Montreal, May 2004)
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
Base
Part 3 : AMH21/A.1.3.1
9
12
ISP
Reception
Base
Extended ATS
Message Handling
Service Support
ATN reference
ISP 12062-2
Notes/References
ISP
Extended body part support
bilaterally-definedbody-part
file-transfer-bodypart
O
O
O
O
O/M
3.1.2.2.3.4.1
O
O
O
M
M/M
3.1.2.2.3.4.2
Note 3 and A.1.3.3
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 File-transfer body parts shall be used only for IPMs in support of the 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.
DGAC/STNA/106727733
WGN03-WP__ - SGN3 WP/2-4a
11
12/02/16
Transport of binary data messages in AMHS
Ref
Element
Origination
Base
Part 3 : AMH21/A.1.3
ACP/WGN and SGN3 meetings (Montreal, May 2004)
ISP
Extend.
ATS
Mess.
Handling
Service
Action
Mapping / Notes
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
O
X
-
11
nationally-defined
O
O
O
X
-
12
extended
M
M
M
G
see Part 4
M
T1
see 3.1.2.4.5.1.2.3.5 and Part 6
Part 4 : AMH21/A.1.3.1
12
Extended body part support
file-transfer-body-part
Part 5 : AMH21/A.1.3.3
O
O
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-andabstract-syntax
O
O
O
X
-
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
-
DGAC/STNA/106727733
WGN03-WP__ - SGN3 WP/2-4a
12
12/02/16
Transport of binary data messages in AMHS
ACP/WGN and SGN3 meetings (Montreal, May 2004)
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-lastmodification
O
M4
M4
G1
see ISO/IEC ISP 12062-2 Note 4 and
3.1.2.4.5.1.2.3.15
5.6
date-and-time-of-lastread-access
O
O
O
X
-
5.7
date-and-time-of-lastattribute-modification
O
O
O
X
-
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-attributemodifier
O
O
O
X
-
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.
DGAC/STNA/106727733
WGN03-WP__ - SGN3 WP/2-4a
13
12/02/16
Transport of binary data messages in AMHS
ACP/WGN and SGN3 meetings (Montreal, May 2004)
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 enduser 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)“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 contentstype 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.
DGAC/STNA/106727733
WGN03-WP__ - SGN3 WP/2-4a
14
12/02/16
Transport of binary data messages in AMHS
ACP/WGN and SGN3 meetings (Montreal, May 2004)
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
parameter shall:
The element actual-values of the object-size element in the file attributes
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
Base
Action
ISP
Extend.
ATS
Mess.
Handling
Service
Mapping / Notes
PART 2 : AMH11/A.1.5 COMMON DATA TYPES
3
EncodedInformation
Types
3.1
built-in-encodedinformation-types
M
M
M
X
3.2
(non-basic parameters)
O
M-
M-
X
-
3.3
extended-encodedinformation-types
M
M
M
G
see 3.1.2.4.5.1.2.4.4
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, if the
value of the Data Designator indicates a textual data type; or
b) take the form of an extended-encoded-information-types, including at least the OID value {joint-iso-itut(2) mhs(6) ipms(1) eit(12) file-transfer(0)} if the value of the Data Designator indicates a non-textual data
type.
DGAC/STNA/106727733
WGN03-WP__ - SGN3 WP/2-4a
15
12/02/16
Transport of binary data messages in AMHS
ACP/WGN and SGN3 meetings (Montreal, May 2004)
Note 1.— The OID value of the extended encoded information type 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-encodedinformation-types, if existing, in the trace-information element, or as the abstract-value of the originalencoded-information-types element if the previous does not exist:
a)
b)
processing as specified in 3.1.2.4.5.2.2.1.2 if the (abstract-)value of the current encodedinformation-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.
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:
DGAC/STNA/106727733
WGN03-WP__ - SGN3 WP/2-4a
16
12/02/16
Transport of binary data messages in AMHS
ACP/WGN and SGN3 meetings (Montreal, May 2004)
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:
b)
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
if the body part type is different from the body part types 1) to 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
O
O
O
X
see Note 1
O
X
see Note 1
PART 3 : AMH21/A.1.3 IPM BODY
10
bilaterally-defined
PART 4 : AMH21/A.1.3.1 EXTENDED BODY PART SUPPORT
9
bilaterally-defined-bodypart
DGAC/STNA/106727733
WGN03-WP__ - SGN3 WP/2-4a
O
O
17
12/02/16
Transport of binary data messages in AMHS
12
file-transfer-body-part
O
ACP/WGN and SGN3 meetings (Montreal, May 2004)
O
M
T1
see Part 7
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 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 -
DGAC/STNA/106727733
WGN03-WP__ - SGN3 WP/2-4a
18
12/02/16