Status of Sub-Volume III PDRsACP WGN/4 - AMSG/2 New Orleans (Nov. 2004)
ACP AMSG/2 WP/__
ACP WGN04 WP43
08/11/04
AERONAUTICAL COMMUNICATIONS PANEL(ACP)
ATN MAINTENANCE SUBGROUP - AMSG
WorkinG group N (NETWORKING) – 4th meeting
New Orleans (U.S.A.), 10th – 19th November 2004
Agenda Item 6 : Ground-Ground Applications
WGN04 WP43 : Status of Sub-Volume III PDRs
Presented by Jean-Marc Vacher (Sub-Volume 3 SME)
Summary
This paper provides a summary status of PDRs raised against Sub-Volume III of Document 9705 since the creation of the ATN Maintenance Subgroup (AMSG). It also includes the detail of PDRs that are currently active (i.e. any status different from RESOLVED and ADOPTED).
Table of contents
1. Introduction...... 2
2. Summary of ATSMHS PDRs...... 2
3. Summary of AIDC PDRs...... Error! Bookmark not defined.
4. Recommendation...... 3
5. ATTACHMENT A : Details of Sub-Volume 3 PDRs...... 3
______
1.Introduction
The goal of this paper is to provide the Working Group with the current status of the Sub-Volume 3 PDRs. All PDRs are related to ATSMHS.
2.Summary of ATSMHS PDRs
The following table lists all PDRs raised against the ATSMHS SARPs (Doc 9705, Sub-Volume 3, Chapter 1) since the creation of AMSG in November 2003. Earlier PDRs are all ADOPTED or RESOLVED.
Number / Applies to / Editions / Name / Status (before AMSG/2) / Im-pact / CommentsM3110001 / AMHS / Ed3 / ATSMHS Terminology / RESOLVED / E
M3110002 / AMHS / Ed3 / Cross-references to CIDIN specification / RESOLVED / E
M3120001 / AMHS / Ed1/Ed2/Ed3 / MF Address Resolution / RESOLVED / B
M4050002 / SVI/AMHS / Ed3 / Date of ISO ISPs Reference / PROPOSED / E
M4050003 / AMHS / DL-expansion parameter / rumored / C
M4050004 / AMHS / Ed3 / Too many recipients / ACCEPTED / C / Needs further discussion within SME list
M4100001 / AMHS / Ed3 / Symmetric composition and conversion of OHI in AFTN and AMHS / ACCEPTED / C / Currently being discussed. Still partly diverging views. Needs further discussion within SME list
M4100002 / AMHS / Ed3 / AFTN/AMHS Address Conversion / SUBMITTED / ? / needs further discussion
M4100003 / AMHS / Ed3 / Processing of AFTN SS ACK messages / PROPOSED / C
M4100004 / AMHS / Ed3 / ATS Message OHI / PROPOSED / C
M4100005 / AMHS / Ed3 / Conversion of an AMHS Recipient Address / PROPOSED / C
M4100006 / AMHS / Ed3 / Processing of AFTN SVC ADS UNKNOWN messages / PROPOSED / C
M4100007 / AMHS / Ed3 / Case insensitivity of the subject IPM identifier / ACCEPTED / C / needs further discussion within SME list
M4100008 / AMHS / Ed3 / Case insensitivity of the subject MTS identifier / ACCEPTED / C / needs further discussion within SME list
M4100009 / AMHS / Ed3 / No Receipt Notification Request for SS ACK messages / PROPOSED / C
M4100010 / AMHS / Ed3 / Use of FTBP / PROPOSED / A / agreed in WGN03 Montreal
3.Recommendation
The AMSG and WGN are invited to note the information provided and to progress the status of PDRs which are either in the screening process or in the resolution process.
4.ATTACHMENT A : Details of Sub-Volume 3 PDRs
PDR M4050002
PDR M4050004
PDR M4100001
PDR M4100002
PDR M4100003
PDR M4100004
PDR M4100005
PDR M4100006
PDR M4100007
PDR M4100008
PDR M4100009
PDR M4100010
Title: AMHS - references to base standards
PDR Reference: M4050002
Originator Reference:M4050002.txt
SARPs Document Reference: 1.x, 3.1.x and sub-sections
Status: PROPOSED
PDR Revision Date: 08/11/2004 ACCEPTED -> PROPOSED
20/07/2004 SUBMITTED -> ACCEPTED
PDR Submission Date: 31/05/2004
Submitting State/Organization: STNA
Submitting Author Name: VACHER Jean-Marc
Submitting Author E-mail Address:
Submitting Author Supplemental Contact Information:
Jean-Marc VACHER
STNA/8CM
1, Av. du Dr Grynfogel
31035 TOULOUSE CEDEX
Tel. (+33) 5 62 14 54 74
Fax (+33) 5 62 14 54 02
SARPs Date: ICAO Doc 9705 Ed.3 Sub-Volume 1
ICAO Doc 9705 Ed.3 Sub-Volume 3
ICAO Doc 9739 Ed.2 Part 3 Chapter 6
SARPs Language: English
Impact :E (Editorial)
Impact on Interoperability : none
Assigned SME: ground-ground applications
Summary of Defect:
Doc 9705 Edition 3 includes references to the latest editions (in general Edition 3) of ISO/IEC MHS Standards and Internationally Standardized Profiles (ISPs).
This is relevant to the following multi-part ISO/IEC standards and standardized profiles:
ISO/IEC 10021 Information technology -- Message Handling Systems (MHS)
ISO/IEC ISP 10611 Information technology -- International Standardized Profiles AMH1n -- Message Handling Systems -- Common Messaging
ISO/IEC ISP 12062 Information technology -- International Standardized Profiles AMH2n -- Message Handling Systems -- Interpersonal Messaging
The joint ISO/ITU-T standardization work concerning these base standards was technically completed in the 1996-1998 timeframe, with a publication foreseen in 1999. The references in Doc 9705 are therefore made to Editions dated 1999. However, for reasons internal to ISO, the final approval and progress of these documents through the publication process was significantly delayed.
The official publication only took place in 2003 and all these documents (apart from ISO/IEC 10021-5 and ISO/IEC ISP 10611-2) are now dated 2003.
It is therefore proposed to update all MHS references in Sub-Volumes 1 and 3 of ICAO Doc 9705 Edition 3 to reflect these 2003 publication dates.
Proposed SARPs amendment:
A) Replace every instance of "1999" with "2003" in the following sections of Doc 9705, Edition 3:
SV-I
1.1.2 References
ISO/IEC 10021-1:1999
ISO/IEC 10021-2:1999
ISO/IEC 10021-4:1999
ISO/IEC 10021-6:1999
ISO/IEC 10021-7:1999
ISO/IEC ISP 10611-4:1999
ISO/IEC ISP 10611-5:1999
ISO/IEC ISP 10611-6:1999
ISO/IEC ISP 12062-1:1999
ISO/IEC ISP 12062-2:1999
ISO/IEC ISP 12062-3:1999
ISO/IEC ISP 12062-4:1999
ISO/IEC ISP 12062-5:1999
ISO/IEC ISP 12062-6:1999
SV-III
3.1.1 Note 2 c)
3.1.2.2.1 Note 2 a)
3.1.2.2.1 Note 2 b) 1) through 4)
3.1.2.2.1.3.1.1 b)
3.1.2.2.1.3.1.1 Note 1
3.1.2.2.1.3.2.1 a)
3.1.2.2.1.3.2.1 b)
3.1.2.2.1.3.2.1 c)
3.1.2.2.1.3.2.1 d)
3.1.2.2.1.3.2.1 Note a) (4 times)
3.1.2.2.1.3.2.2.2 Note 1
3.1.2.2.2 Note 2 a) 1) through 4)
3.1.2.2.2.3.2
3.1.2.2.2.3.3
3.1.2.2.3.3.2
3.1.2.2.3.3.3.1
3.1.2.2.3.3.4.1
3.1.2.2.3.3.4.2
3.1.2.2.3.3.5
B) Replace every instance of "1999" with "2003" in Document 9739, Edition 2, Part 3, Chapter 6
Validation status: Thorough inspection is sufficient for an editorial PDR.
SME Proposal: progress to RESOLVED
AMSG Decision:
PDR M4050004 – AMHS: Too many recipients
Latest contribution: Kolja Wabra on 7th September 2004 14:51
Dear colleagues,
Related to PDR proposed by Brian Cardwell I have following remarks:
In principle agreed.
But the limit should be selected carefully.
From the operational point we have to avoid that a AMHS user sends one AMHS message "to all I know". There are no operational requirements to send out messages to more than (about) 50.
(I prefer 64 due to my informatique knowledge and propose 63 due to my AFTN knowledge 3 x 21 - maybe 60 are ok).
Exception:
For MET distribution, NOTAM, BIRDTAM, ASHTAM ... distribution.
There are more recipients worldwide. But for those international standard distribution needs distribution lists (DL) shall be co-ordinated and established.
Within the AFTN world PDAI are used.
If there is a restriction in the number of recipient addresses (recommended or mandatory) it will help to avoid misuse and SPAM.
Best regards
Kolja Wabra
PDR progression: Jean-Marc Vacher on 21st July 2004 15:47
Dear Colleagues,
in the absence of comments since submission of this PDR, its status is moved to ACCEPTED.
Best regards
Jean-Marc Vacher
------
Title: AMHS: Too Many Recipients
PDR Reference: M4050004
Originator Reference:
SARPs Document Reference: Doc 9705 Ed. 3 ref: 3.1.2.3.5.2.1.8 b)
Status: ACCEPTED
PDR Revision Date: 20/07/04 SUBMITTED -> ACCEPTED
PDR Submission Date: 28/05/04
Submitting State/Organization: NATS
Submitting Author Name: Brian Cardwell
Submitting Author E-mail Address:
Submitting Author Supplemental Contact Information:
SARPs Date: Doc 9705 Ed. 3
SARPs Language: English
Summary of Defect:
This 'SARP' sub-para [3.1.2.3.5.2.1.8 b)] is overly restrictive in that it permits an MTCU to reject outright an AMHS message for more than 21 recipients. The permitted reason for this rejection is simply 'system resource limitation'. In modern IT systems there should be no system resource limitation that prevents an MTCU splitting an AMHS message addressed to a *reasonable* number of AFTN recipients into several messages of no more than 21 recipients. Whilst I can agree that 32,000 AFTN addressees may be considered *unreasonable* and splitting is likely to reach system resource limitations, an AMHS message with 25 addressees should not be considered unreasonable. At the moment this para allows total rejection of an AMHS message addressed to 22 AFTN addressees.
Assigned SME: SME3
Proposed SARPs amendment:
In concept, rather than SARPs changes at this time: This section should be re-written with an an additional 'SARP' para to require MTCUs to handle/split AMHS messages addressed to up to say 250 AFTN recipients.
SME Recommendation to AMSG: amendments proposal are welcome so as to move PDR to PROPOSED
AMSG Decision: ACCEPTED
Title: AMHS / OHI Conversion
PDR Reference: M4100001
Originator Reference:[snip to avoid confusion with PDR Ref]
Document Reference: ICAO Doc 9705 Sub-Volume 3, Editions 1, 2 and 3
Status: ACCEPTED
PDR Revision Date: 18/10/2004SUBMITTED -> ACCEPTED
PDR Submission Date: 07/10/2004
Submitting State/Organization:FIRST (Aena, DFS, BATSO, Avitech AG, COMSOFT, Telefonica Soluciones)
Submitting Author Name: Kolja Wabra
Submitting Author E-mail Address:
Submitting Author Supplemental Contact Information:Tel. (+49) 6103 707 2435
Fax (+49) 6103 707 2495
Document Date: ICAO Doc 9705 Sub-Volume 3, Edition 3: 2002
Document Language: English
Impact : C
Impact on Interoperability :yes
Assigned SME: SME 3
Summary of Defect:
Currently the OHI (AMHS) structure and the ODF (AFTN) structure (length) are not symmetric.
To avoid during conversion of an AMHS message into an AFTN message either a NDR "unable to convert to AFTN" or a loss of OHI information (characters) due to the asymmetry of the OHI and ODF the structure (length) both fields has to be unified.
For detailed information see:
Technical Note 2004/01
Subject: Clarification of composition and conversion of OHI in AFTN and AMHS
Proposed SARPs amendment:
A) Modify clause 3.1.2.2.3.2.3.4.2 as follows:
3.1.2.2.3.2.3.4.2 The value of the optional-heading-information element shall comprise a character string with a maximum length of either:
a)54 characters if the message priority differs from "SS"; or
b)49 characters if the message priority is "SS".
B) Add a new clause (recommendation) 3.1.2.2.3.2.3.4.3 as follows:
3.1.2.2.3.2.3.4.3 Recommendation.- The first character of the optional heading information value should be a space character (2/0).
C) Modify clause 3.1.2.2.3.3.3.2 as follows:
3.1.2.2.3.3.3.2 The value of the optional heading information shall comprise a character string with a maximum length of either:
a)54 characters if the message priority differs from "SS"; or
b)49 characters if the message priority is "SS".
D) Add a new clause (recommendation) 3.1.2.2.3.3.3.3 as follows:
3.1.2.2.3.3.3.3 Recommendation.- The first character of the optional heading information value should be a space character (2/0).
Validation status:
CCB Decision:
Title: AFTN/AMHS Address conversion
PDR Reference: M4100002
Originator Reference:[snip to avoid confusion with PDR Ref]
Document Reference:ICAO Doc 9705 Sub-Volume 3, Editions 1, 2 and 3
Status:SUBMITTED
PDR Revision Date:
PDR Submission Date:07/10/2004
Submitting State/Organization:FIRST (Aena, DFS, BATSO, Avitech AG, COMSOFT, Telefonica Soluciones)
Submitting Author Name: Kolja Wabra
Submitting Author E-mail Address:
Submitting Author Supplemental Contact Information:Tel. (+49) 6103 707 2435
Fax (+49) 6103 707 2495
Document Date: ICAO Doc 9705 Sub-Volume 3, Edition 3: 2002
Document Language:English
Impact :TBD
Impact on Interoperability :yes
Assigned SME: SME 3
Summary of Defect:
In Doc 9705 the rules and algorithm for the conversion of AFTN addresses into AMHS addresses are defined.
In 2003 ICAO Montreal had issued a State letter (SP 54/1-03/39) [3] asking the States
1. to choose the PRMD-name and
2. to select either the (recommended) CAAS addressing scheme in the AMHS MD or the (default) XF addressing scheme.
If the CAAS was chosen the States were asked to fill in a table the regional identifier for each location indicator found in Doc 7910 under the nationality letters of the State concerned.
In the light of the reply of the States a critical review of AMHS SARPs was performed to ensure that the definitions in Doc 9705 [2] meet the practical requirements of future AFTN/AMHS Gateway operations.
For more details see:
Technical Note 2004/04
Subject: AFTN/AMHS Address conversion considering the ICAO State letter reply of States
Proposed SARPs amendment:
1. Modify 3.1.2.3.3.2 a) into:
"a) MD look-up tables as specified in 3.1.2.3.3.2.1, for the conversion of an AF-Address to an MF-Address; and".
2. Modify 3.1.2.3.3.2.1.1 into:
"3.1.2.3.3.2.1.1 Two types of MD (Management Domain) look-up tables (I and II) maintained by in the Message Transfer and Control Unit shall include a list of entries identifying an organizational entity, which either is an AMHS Management Domain, or collectively uses the services of a given AMHS Management Domain. The main entries of MD look-up Table I comprising:"
3. Modify 3.1.2.3.3.2.1.1 a) into:
"a) a string of characters identifying one of the following:
Note:- To reduce the size of the tables, a "wild card" is used where appropriate. A "wild card" character is a character that can be replaced by any alphabetical character.
1) a country (two-letter designator as specified in ICAO Document 7910)
2) a country or a location (four-letter designator as specified in ICAO Document 7910)
3) an organisation within a country (a combination of a four-letter designator as specified in ICAO Document 7910 with a three-letter designator as specified in ICAO Document 8585) (e.g. K***AFR)
4) an organisation at a location (a combination of a four-letter designator as specified in ICAO Document 7910 with a three-letter designator as specified in ICAO Document 8585)"
4. Add after 3.1.2.3.3.2.1.1 b):
"c) a string of characters identifying the addressing scheme of the PRMD (either 'XF' or 'CAAS')
d) the attribute "organization-name" (O) if the CAAS is defined in c). If more than one organization-name is used within a PRMD a separate table (MD look-up Table II) is required defining the relation between "organization-name" (O) and "organisational-unit-name" (OU1)"
5. Delete Note after 3.1.2.3.3.2.1.3
6. Delete 3.1.2.3.3.2.2.4 and 3.1.2.3.3.2.2.5
7. Modify 3.1.2.3.4.2.1.4.1 b) into:
"b) if a) cannot be achieved, translation according to 1) and either 2) or 3) below, depending upon the addressing scheme declared by the AMHS MD which the originator belongs to:
1) determination of the MF-address attributes country-name, administration-domain-name and private-domain-name, determined among the entries in the MD look-up Table I maintained in the Message Transfer and Control Unit, if any, matching exactly the following character substrings of the AF-Address of the originator and selected among these entries, if several are found, on the basis of a decreasing order of precedence from i) to viii):
i) characters 1 to 7,
ii) characters 1, 2, 3, 5, 6 and 7,
iii) characters 1, 2, 5, 6 and 7,
iv) characters 1, 5, 6 and 7,
v) characters 1, 2, 3 and 4,
vi) characters 1, 2, and 3,
vii) characters 1 and 2,
viii) character 1; and
determination of the addressing scheme related to the MF-Address attributes found.
2) if the originator belongs to an AMHS Management Domain having declared use of the XF Addressing Scheme, translation into the XF-Address using the found set of country-name, administration-domain-name and private-domain-name attributes
3) if the originator belongs to an AMHS Management Domain having declared use of the Common AMHS Addressing Scheme, translation into the CAAS-Address using the found set of country-name, administration-domain-name and private-domain-name attributes. The additional organisation-name and organisational-unit-name attributes can be determined either
i) if only one organisation-name is defined from MD look-up Table I. In this case the entry of the organisational-unit-name attribute is determined by the location indicator of the AF-Address of the originator, or
ii) if more than one organisation-name are defined from a separate table (MD look-up Table II) maintained in the Message Transfer and Control Unit;
Note:- In the MD look-up tables (I and II) a "wild card" is used where appropriate. A "wild card" character is a character that can be replaced by any alphabetical character."
8. Modify 3.1.2.3.5.2.2.6.1 and 3.1.2.3.5.2.2.6.2 into:
"3.1.2.3.5.2.2.6.1 The originator MF-Address included in an AMHS message shall be processed for translation into the originator indicator of the converted AFTN Message depending on the contents of the User address look-up table or MD look-up tables, after preliminary conversion of the value of all AMHS address attributes from lower case IA5IRV characters, if any, to upper case IA5IRV characters as follows:
a) determination of an AF-Address matching exactly the MF-Address of the originator in the User address look-up table maintained in the Message Transfer and Control Unit; or
b) allocation of the value of the first element of the organizational-unit-names attribute to the originator indicator of the converted AFTN Message, if this value is a syntactically valid AF-Address, if the organization-name attribute has the value "AFTN" and if the AF-Address can be re-converted into the same (case insensitive) MF-Address with the procedure specified in 3.1.2.3.4.2.1.4.1; or
c) allocation of the value of the common-name attribute to the originator indicator of the converted AFTN Message, if this value is a syntactically valid AF-Address, and if the AF-Address can be re-converted into the same (case insensitive) MF-Address with the procedure specified in 3.1.2.3.4.2.1.4.1.; or
d) if none of the conditions in a), b) and c) can be met, then:
1) rejection of the message for all the message recipients; and
2) generation of a non-delivery report as specified in 3.1.2.3.5.6 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) "invalid-arguments" for the non-delivery-diagnostic-code; and
iii) "unable to convert to AFTN due to unrecognized originator O/R address" for the supplementary-information.
3.1.2.3.5.2.2.6.2 To build the address part of the converted AFTN Message as specified in Annex 10, Volume II, 4.4.15.2.1, each of the recipient MF-Addresses included in an AMHS message, whose responsibility element in the per-recipient-indicators has the abstract-value "responsible", shall be processed for translation into an addressee indicator, after preliminary conversion of the value of all AMHS address attributes from lower case IA5IRV characters, if any, to upper case IA5IRV characters, in following manner:
a) determination of an AF-Address matching exactly the MF-Address of the recipient in the User address look-up table maintained in the Message Transfer and Control Unit; or
b) allocation of the value of the first element of the organizational-unit-names attribute to an addressee indicator in the converted AFTN Message, if this value is a syntactically valid AF-Address, the organization-name attribute has the value "AFTN" and if the AF-Address can be re-converted into the same (case insensitive) MF-Address with the procedure specified in 3.1.2.3.4.2.1.4.2; or
c) allocation of the value of the common-name attribute to the addressee indicator of the converted AFTN Message, if this value is a syntactically valid AF-Address, and if the AF-Address can be re-converted into the same (case insensitive) MF-Address with the procedure specified in 3.1.2.3.4.2.1.4.2; or
d) if none of the conditions in a), b) and c) can be met, then:
1) rejection of the message for the considered message recipient; and
2) generation of a non-delivery report as specified in 3.1.2.3.5.6 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