BEFORE THE

DEPARTMENT OF TRANSPORTATION
WASHINGTON, D.C.

Notice of IATA Traffic Conference Actions Tentatively Exempted From Filing for Approval Docket OST

- 2012

- 0058

NOTICE OF TIER 1 AGREEMENTS FILING

BY THE

INTERNATIONAL AIR TRANSPORT ASSOC IATION

4 July 2013

Communications with respect to this

Document should be sent to

Douglas Lavin Regional Vice President

– North America International Air Transport Association
1201 F Street, NW, Suite 650 Washington, DC 20004
(202) 628

- 92 92Summary DOCKET: DOT

- OST

- 2012

- 0058 DOT ORDER: None Requested

Date: 4 July 2013

Filing fee/IATA Acct: Waived by Order 2012

- 4

- 18, Appendix
A, Section D

US/UST involved Yes

Intended effective date: 1 June 201 2

Meeting site, date: 3 3 rd Passenger Services Conference
(PSC), Singapore

, 12

- 13 October 201 1

Agreement(s)/Minutes PSC/RESO/15 1 bis dated 4 July 2013

PSC/MINS/038 dated 23 February 2012

Resolutions 003, 720a, 722, 722f, 722g,
722h, 725a, 725b, 725 d , 725 f

, 725g,
725h, 726e, 728, 762, 763, 767

, 780 e and

7 92

.

Recommended Practices 1701a, 1701d,
1701h, 1701i, 1701j, 1701k, 1706, 1706c,
1707a, 1707b, 1708, 1715, 1719, 1719b,

1720a, 1728 , 173 9

, 1740c, 1745, 1790

and 1797.NOTICE OF TIER 1 AGREEMENTS FILING

Pursuant to statements submitted by Me mber airlines of the International Air Transport

Association (IATA), the undersigned has been constituted to be their attorney

- in

- fact for filing

with the Department of Transportation copies of agreements adopted by the IATA Traffic

Conferences.

On their b ehalf, and pursuant to the procedures specified in Order 2012

- 4

- 18 (13 April

2012), I am filing with the Department, in Docket OST

- 2012

- 0058, this Notice, the subject

agreements and supporting documentation. These agreements are Tier 1 agreements tentativ ely

exempted by Order 2012

- 4

- 18 from Condition #2 to the Department’s approval of the Provisions

for the Conduct of the IATA Traffic Conferences, which condition requires pre

- implementation

Department review. The intended effective date of the agreements is 1 June 201 2

.

The subject agreements amend or establish Resolutions and/or Recommended Practices

that do not address subject areas which the Department has indicated it still chooses to review

under Condition #2. The text of the agreements and other co nference documentation sent to

airline Members of IATA accompany this Notice. The cover pages of the documentation clearly

identify each affected Resolution and /or Recommended Practice and show whether the subject

agreements are amendments or new agreeme nts. Other pages provide the text of each subject

agreement. Where an affected Resolution or Recommended Practice has previously been

exempted from Condition #2 by Department action, the cover pages include the appropriate

docket and order number. The co ver pages include a summary to explain the nature and purpose

of the subject amendments and/or agreements.- 2

-

13461343.1 Respectfully submitted,

/s/ Douglas Lavin Douglas Lavin

Regional Vice President

– North America International Air Transport Association

A ttorney

- In

- Fact- 3

-

13461343.1 CERTIFICATE OF SERVICE

A copy of this notice has been served this day by first class or priority mail on the following person:

Chief, Transportation, Energy & Agriculture Section

Antitrust Division Department of Justice Washington, D.C. 20530

A copy of this notice has been sent this day by email to John Kiser (John.Kiser@dot.gov) and to Della Davis (Della.Davis@dot.gov) of the Department of Transportation.

/s/ Douglas Lavin Douglas Lavin

4 July 2013

Date Served- 4

-

13461343.1

## MINUTES

31 st 

### Joint ATA/IATA Passenger Services Conference (JPSC)

33 rd 

### IATA Passenger Services Conference (PSC)

Singapore

12-13 October 2011International Air Transport Association

Route de l’Aeroport 33

PO Box 416 CH - 1215 Geneva 15 Airport

Switzerland

Tel: +41 22 770 2724

Fax +41 22 770 2662 www.iata.org E-Mail: bruyerep@iata.org 

### M E M O R A N D U M

PSC/MINS/038

TO: All Members, Passenger Serv ices Conference - Accredited Representatives All Members, Joint ATA/IATA Passenger Services Conference - Accredited Representatives (ATA members via Ms P. Edwards)

COPY: IATA Strategic Partners

FROM: Head, Passenger Interline Standards

DATE: 23 February 2012

SUBJECT: "PASSENGER WEEK 2011"

MINUTES

31 st Joint ATA/IATA Passenger Se rvices Conference (JPSC)

33 rd IATA Passenger Services Conference (PSC) Singapore, 12-13 October 2011

Please find attached the Minutes of the 31 st Joint ATA/IATA Passenger Services Conference (JPSC) and the 33 rd IATA Passenger Services Conference (PSC) as approved by the Chairman.

The “book of finally adopted resolutions & RPs” referred to in these Minutes are issued

under cover of Memorandum PSC/ RESO/151 dated 23 February 2012.

Michael Muller

## M I N U T E S

31 st Joint ATA/IATA Passenger Services Conference (JPSC)

33 rd IATA Passenger Services Conference (PSC) Singapore, 12-13 October 2011



### TABLE OF CONTENTS

Agenda

Item Subject Page

Number

ADMINISTRATION

A1 Opening of Meeting 1

A2 Examination of Credentials of Accredited Representatives 1

A3 Approval of Minutes – JPSC/30 and PSC/32 1

A4 Status of PSC Resolutions and RPs 2

A5 Effectiveness Date of Am endments to Industry Standards 2

A6 Any Other Business 2

A7 Date and Place of Next Meeting 2

POLICY

P1 Report – Status of Industry Coding Systems 2

P2 Ratification of Special Fees and Charges Codes (Resolution 728) 2

P3 Report – Coding Working Group (Resolutions 762, 763 and 767) 3

P4 Airline Designator and Accounting Code for an Indirect Air Carrier (Resolutions 762 and 767) 3

P4.1 Airline Designators for ULD Owners (Resolution 762) 3P5 Report – BSP Form Codes and Document Supply Chain 3

P5.1 Changes to RP 1720a New Form Codes for EMD 4

P5.2 Changes to RP 1720a New Form Codes 4

P6 Report – Simplifying the Business (StB) 4

P6.1 Report – Automated Baggage Rules Task Force (ABRTF) 4

P6.2 Report – IATA e-services 4

P6.3 Report – Fast Travel / Passenger Experience Working Group (PEMG) 5

P6.3.1 RP 1701a - Passenger Data Harmonization 5

P6.3.2 RP 1701d - Self-Service Automated Document Check 5

P6.3.3 RP 1701h - Security Checkpoint Access and Egress 5

P6.3.4 RP 1701k - Self-Boarding 5

P6.3.5 RP 1701j Automated and Self-Servi ce Flight Rebooking for Irregular Operations 6

P6.3.6 RP 1701 l - International Traveler Scheme 6

P6.3.7 RP 1706c – Common Use Self-Service (CUSS) 6

P6.3.8 RP 1797 – Common Use Passen ger Processing Systems (CUPPS) 6

P6.3.9 Resolution 792 – Bar Coded Boarding Pass (BCBP) – Version 5 7

P7 Co-ordination with the Commission of European Communities (CEC) on PSC Matters 7

P8 Elimination of Remaining Paper Tickets – Paper Out Strategy 7

P8.1 Add Paragraph 2.2.6 to Resolution 780e 8

P9 ZED-MIBA Forum – Sunset of P aper Tickets for Interline Staff

Travel 8

P10 Report – Passenger Distribution Group (PDG) 8P11 Report - PCI DSS Working Group (PDWG) 8

P12 Co-ordination with the US Depar tment of Transportation (DoT) –

Initiative for Self-Assessment 8

P13 US DoT – Enhancing Airli ne Passenger Protections Bill 9

P14 Report – Involuntary Rerouting Working Group (IRWG) 9

AIRPORT SERVICES

B1 Report of the Airport Services Committee (ASC) 9

B1.1 ASC Membership 9

B1.2 ASC Election of Chairman 9

B1.3 ATA Baggage Committee – Terms of Reference and Membership 9

B2 Report of the IATA Ground Handling Council (IGHC) 9

B3 Report – Fast Travel – Pass enger Experience Management Group (Resolution 705) 10

B4 Report of the Baggage Working Group (BWG) 10

B4.1 The New Baggage Steering Group 10

B5 Report of the DCS Messages Working Group (DCSMWG) 10

B6 Standardized Special Baggage Codes 10

B7/P DCS Working Group Packaged Items 11

B7.1/P Add Time and Date Variation to .O/ Element 11

B7.2/P Editorial Issues in RP1706 – Add Baggage Information Message (BIM) 11

B7.3/P Number of Services in Remarks Elements in DCS Messages 11

B7.4/P Clarification of Name Fields in the SSR DOCS 11

B7.5/P Report – OCI DSS Working Group (PDWG) 12

B7.6/P SSR UPGR Upgrades 12

B7.7/P Editorials for Ne w PSC Resolutions Manual 12

B7.8/P Unique Passenger Pe r Segment Identifier 12

B7.9/P Web Check –in Data on PNL / ADL 13B8/P Baggage Working Group Packaged Items 13

B8.1/P Resolution 740 / RP 1740a Review 13

B8.2/P RP 1740c review 13

B8.3/P Creation of a BSM Testing Contact List 13

B8.4/P Clarify and Correct Errors in RP 1745 re Batch BSM 14

B8.5/P Amendments to RP 1745 Secti on 9 Baggage Manifest Message (BMM) 14

B8.6/P Amendments to RP 1745 Secti on 8 Baggage Control Messages 14

B8.7/P Amendments to RP 1745 Section 7 Baggage Not Seen Message (BNS) 14

B8.8/P RP1739, Attachment ‘E’ – Add RP1800 Reference to ‘Common

Automation Methods’ 14

B8.9/P Editorial Issues in RP 1745 – BNS,.H Missing in Example Messages 15

B8.10/P Editorial Issues in RP 1745 – Attachment E 15

B8.11/P Editorial Issues in RP 1745 – In consistencies in .U Example Message 15

B8.12/P Editorial Issues in RP 1745 and ot her – Questionable reference to the ‘IATA Systems and Communi cation Reference Manual’ 15

B8.13/P Editorial Issues in RP1740c – References 15

B9 Second City/Airport Code in PNL 16

TICKETING

T1 Report of the Ticketing Committee

Selection of Committee Member ship for the IATA Passenger Forms and Procedures Committee (PFPC) 16

T2/P Ticketing “Package” 16

T2.1/P Remove the Condition on ET Co upon before Requesting Control of EMD-A Coupon 17

T2.2/P Disassociate when Carrier Not Part of the Itinerary Obtains Control of ETKT or EMD Coupon 17

T2.3/P Amendment to Definition of Coupon Status Indicator ‘C’ (CheckedIn) 17T2.4/P Disassociation Upon COS to ‘E’, ‘P’, ‘R’, ‘X’ 17

T2.5/P Remove Mandate to Request EMD Control 18

T2.6/P Revise EMD Definitions in RP 1790 and ATA 10.90 18

T2.7/P Revise ‘Consumed At Issuance’ Glossary Definition (Superseded by agenda item s T2.21/P and T2.22/P) 18

T2.8/P Clarify Definition of System Update Message 18

T2.9/P Add ‘In Connection With Qualifier’ to ET Neutral Display Response 18

T2.10/P Revise Ambiguous EMD Definitions 19

T2.11/P Remove Mandate for Disassociat ion Prior to Coupon Status Update 19

T2.12/P Removal of XT from fare Calculation 19

T2.13/P Revise Coupon Notification Coupon Status Indicator 19

T2.14/P Amendment to System Update 19

T2.15/P Amendment to Change of Status 20

T2.16/P Unsolicited Airport Control to Marketing Carrier with Flown

Information 20

T2.17/P Remove RFISC from EM D Refund Cancel response Message 20

T2.18/P EMD Special Characters used in Reason for Issuance Sub-Code Description 20

T2.19/P EMD Mutual Exclusivity of Coupo n Value and Fare Calculation 20

T2.20/P EMD Product Characteristics 21

T2.21/P EMD Update Glossary Defi nition of Consumed at Issuance

Indicator 21

T2.22/P EMD Consumed at Issuance Indicator Glossary Definition 21

T2.23/P Addition of Attri bute Group and Attribute Sub-Group 21

T2.24/P Inconsistency in EM D Coupon Status Definitions 21

T2.25/P Unsolicited Billing Message 22

T2.26/P EMD Create Dependency Between RFIC and RFISC 22

T2.27/P Definition of Total Ticket Document Amount 22

T2.28/P Add ABR MSC Information to the ET Record 22

T2.29/P Resolution Editorials 23T2.30/P Current Surcharge Ticketing – RAWG Requests 23

T2.31/P Current Surcharge Ticketing – Clean-Up 23

T2.32/P Expiry of Neutral Paper Documents 23

T2.33/P Delete Reference to Sundry Charges 24

T2.34/P Single Source RBD Service 24 T2.35/P Industry Implem entation Strategy for Alphanumeric TFC Coding 24

T3 Credit Card as FOID and PCI DSS Compliancy 24

T4 Fee Calculation on EMD 24 T5 Update to Resolution 728 25

T6 Current Surcharge Ticketing – Reductions 25

T7 Deletion of Carrier Fee Type OA 25

T8 Corrections to Matrices for Carrier Fees 25

T9 Removal of Tax Reporting Form From Resolution 728 25

T10 Reporting of Taxes at Coupon Level 26

T11 “Consumed at Issuance” Indicator 26

RESERVATIONS

R1 Report – ATA/IATA Reservations Committee (ResCom) 27

R2 Report – Reservations Working Group (RESWG) 27

R3 Remove Credit Cards as Form of Identification (FOID) 27

R4 SSR Matrix 27

R5 EMD-S and SVC – Number of Location Codes 27

R6/P Reservations “Package” 28

R6.1/P Allow HS to be Sent Without a Previously Received KD 28

R6.2/P New SSR PCTC Example 28

R6.3/P Advanced Passenger Information (API) Codes 28

R6.4/P Advice of Electronic Ticket Number for Passive Segments Where a Passive Segment Notifi cation Agreement Exists 28R6.5/P Service PNR Message 29

R6.6/P SSR UPGR Upgrades 29

R6.7/P Visa Place of Issuance in SSR DOCO 29

R6.8/P Add Military ID (M) to list of Tr avel Documents for SSR DOCS in

AIRIMP 29

R6.9/P Establish procedures for accurate completion of SSR DOCS 29

R6.10/P Clarification of Name Fi elds in the SSR DOCS 29

R6.11/P SSR DOCx for Passive Segments 30

R6.12/P Infant without a Seat and EMD issuance 30

R6.13/P Update paragraph references in AIRIMP 30

R6.14/P Editorial Repairs to AIRIMP 30

R6.15/P Multiple services fo r one passenger in AIRIMP 30

R6.16/P Bilateral SSRs 30

R6.17/P Seat Characteristics in Replies 31

R6.18/P Additional Services 31

R6.19/P Unsolicited Reply Messages 31

R6.20/P Correct SSR DOCS Examples 31

MISCELLANEOUS

M1 Report – PSC Steering Group (PSCSG) 31 M2 Report – PADIS Board (PADIS) 32 M2.1 Report – PNRGOV Working Group 32

M3 Report – Cargo Services Conference (CSC) 32 M4 Report – Scheduling Services 32 M4.1 Report – Schedules Information Standards Committee (SISC) 32

M5 Report – Fraud Prevention Working Group (FPWG) 32

M5.1 Circulation of Fraudulent Emails under IATA’s Name 32

M6 Report – BSP Data Interchange Standards Group (BDISG) 32 M7 Report – Strategic Partnerships 32 M8 Report - Agency Solutions Technical Working Group (ASTWG) 33 M9 Rescinding AIRDES (RP 1737) and Reconfirmation Procedures (RP 1762) 33

Close of Meeting 331

MINUTES

31 st Joint ATA/IATA Passenger Services Conference (JPSC)

33 rd IATA Passenger Serv ices Conference (PSC)

Singapore, 12-13 October 2011



### ADMINISTRATION

A1 Opening of Meeting

1. The Chairman, Mrs. Patricia George, opened the 31 st Joint ATA/IATA Passenger Services Conference (JPSC) and the 33 rd IATA Passenger Services Conference (PSC) at 1400 hours on 12 October 2011. She introduced Rosalie Crabbe (UA), Chairperson of the ATA Passenger Council. The Chairman welcomed IATA’s new legal counsel, Mr Daniel Kanter, and she expressed her thanks to his predecessor, Mr Colin Flynn, who had recently taken up a senior position in the legal department of SQ. The

attendance list is shown in Attachment A

.

2. The Chairman reminded the meeting of the importance of the industry standard-setting which took place under the auspices of the JPSC and its committees. These industry standards had enabled the Simplifying the Business strategy to be successful in ar eas such as Electronic Ticketing and other global industry projects and provided a solid foundation on which the

Board of Governors would be able to base its recommendations for future industry projects.

3. Conference noted the anti-trust warnings regarding discussion on competitively sensitive topics as well as meeting guidelines for the Chairman and delegates.

A2 Examination of Credentials of Accredited Representatives

4. Conference noted the list of IATA PSC accredited representatives and ATA Passenger Council representatives.

Secretary note: towards the end of 2011 the ATA (Air Transport Association of America) re-branded itself as the A4A - Airlines for America

.

A3 Approval of Minutes – JPSC/30 and PSC/32

5. Conference approved as published the Minutes from the 30 th meeting of the

JPSC and 32 nd meeting of the PSC.2

A4 Status of PSC Resolutions and RPs

6. The Secretary, Mr Mike Muller (IATA), reported that he had received approval from the US Department of Transportation (DoT) for the Book of Finally Adopted Resolutions and RPs (BoF) from the 2008 meeting. He advised that IATA had not yet filed the BoF from the 2009 and 2010 meetings inanticipation of positive action on the IATA initiative to move to a selfassessment environment (refer to agenda item P12).

A5 Effectiveness Date of Amendments to Industry Standards

7. Conference confirmed that the general effective date of 1 June 2012 would apply to all amendments regarding Resolutions, RPs and AIRIMP unless otherwise agreed.

A6 Any Other Business

8. No other business was presented.

A7 Date and Place of Next Meeting

9. The Secretary advised that it is planned to hold the next meeting in conjunction with a commercial event to be held in TC2 in October 2012. Final

confirmation of dates and venue will be advised.

Secretary note: the 2012 meeting of the Joint A4A/IATA Passenger Services Conference (JPSC) will be held in Abu Dhabi during the week of 15 October in conjunction with several other industry meetings as well as the commercial conference called the World Passenger Symposium. For an overview of these events, please refer to the “week-at-a-glance” document posted on the PSC private site (refer to folder “PSC 34”), access via: http://www.iata.org/workgroups/Pages/psc.aspx

Secretary note: for online information on future IATA meetings, refer to : www.iata.org/workgroups/calendar



### POLICY

P1 Report – Status of Industry Coding Systems

10. Conference noted this report.

P2 Ratification of Special Fees and Charges Codes (Resolution 728)

11. Conference agreed to ratify the list of codes shown in Attachment B that had been assigned on a provisional basis since the last meeting of the JPSC in

October 2010.3 12. Mr Dave McEwen (IATA) advised that only 28 alpha/alpha codes remain available in the stock and consequently the entire industry needs to ensure that it would be able to handle alpha/numeric codes as soon as possible and no later than June 2012 (agenda item T2.35/P refers).

P3 Report – Coding Working Group (R esolutions 762, 763 and 767)

13. The Coding Working Group (CODEWG) had made a thorough review of the coding assignment processes with a view to updating Resolutions 762, 763 and 767 to simplify and make more transparent the assignment procedures. Noting an abstention from Adria Airways, the PSC agreed to amend Resolutions 762, 763 and 767 as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council adopted counterpart changes to Resolution 5.38 as shown in Section II of the ATA Minutes.

14. Conference complimented Mr Karr Cannelin (formerly with Finnair) who had voluntarily made a significant contribution to the accuracy of IATA data regarding location identifiers.

15. Conference agreed that the CODEWG should continue its mandate and in 2012 focus on developing workable solutions for problematic metropolitan areas and multiple city locations. Volunteers were noted from JP, OS, LH, LY, SITA and UA.

P4 Airline Designator and Accounting Code for an Indirect Air Carrier (Resolutions 762 and 767)

16. Mr Jim Gallagher (PublicCharters.com) provided an overview of the business model of “indirect air carriers” and requested that Resolutions 762 and 767 be amended to allow access to IATA codes by such companies. This item failed due to lack of support.

P4.1 Airline Designator for UL D Owners (Resolution 762)

17. The Secretary noted that Resolution 762 allowed non-airline ULD owners to apply for an airline designator code on the condition that they are members of the Interline ULD Control User Group (IULDUG). However, since this group no longer exists, it was proposed that new criteria be established based on participation in the ULD area of the IATA strategic Partnership Program. The PSC agreed to amend Resolution 762 as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to Resolution 5.38 as shown in Section II of the ATA Minutes.

P5 Report – BSP Form Codes and Document Supply Chain

18. Conference noted this report and Sabre’s comment that GDSs require plenty

of advance notice for re cycling of form codes.4

P5.1 Changes to RP 1720a New Form Codes for EMD

19. The Ticketing Committee (JPTC) proposed to reassign form codes for usewith EMD and also proposed to release some form codes for use with OffPremise EMD. The PSC agreed to amend RP 1720a as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to Resolution 20.04 as shown in Section II of the

ATA Minutes.

P5.2 Changes to RP1720a New Form Codes

20. The Transport Clearing House (TCH) of Russia proposed to expand the definitions of form codes within the range of 61 to provide more details regarding type of tickets per sub-range. The PSC agreed to amend RP 1720a as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to Resolution 20.04

as shown in Section II of the ATA Minutes.

P6 Report – Simplifying the Business (StB)

21. Conference noted the report. Mr Eric Leopold (IATA) advised that a new initiative would be launched regarding airline distribution aiming to sell a wide range of airline products through all distribution channels, identifying customer trends and personalizing both offers and prices. Also another initiative would be launched regarding Passenger Facilitation to enable simple and common ways for passengers to provide advanced passenger data that different governments require. These two new projects would be supported by the goals towards sustainable profits and better service reflected on the StB Think Tank white paper as shown in Attachment C.

Secretary note: for more information on StB initiatives please refer to: http://www.iata.org/whatwedo/stb/Pages/index.aspx

P6.1 Report – Automated Baggage Rules Task Force (ABRTF)

22. Conference noted this report and disbanded the ABRTF in view that they had completed their mandate to automate baggage rules. It was advised that any outstanding standards issues should be handled by existing IATA working groups and ATPCO.

P6.2 Report – IATA e-services

23. Conference noted this report and IA TA gave heartfelt thanks to the system providers for all their support to airlines to achieve EMD capability.5

P6.3 Report – Fast Travel / Passenge r Experience Working Group (PEMG)

24. Members were reminded that Conference had adopted IATA Resolution 705/ATA 1.40 to establish the Passenger Experience Management Group(PEMG) to drive the development of standards to provide an end-to-end selfservice experience at airports. And that the “end-to-end” passenger process

is described in IATA RP 1701/ATA 30.301 whereas individual RPs are published (or will be developed) in the 1701 series from 1701a to 1701n. Conference noted this report.

P6.3.1 RP 1701a - Passenger Data Harmonization

25. The Passenger Facilitation Working Group (PFWG) developed a global framework for aircraft operators to provide passenger data to States to enhance border security. Accordingly the PSC established RP 1701a (Passenger Data Harmonization) as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council established counterpart RP

30.301a as shown in Section II of the ATA Minutes.

P6.3.2 RP 1701d - Self-Service Automated Document Check

26. The Fast Travel Working Group (FTWG) proposed changes to the guidelines in RP 1701d (Self Service Automated Document Check) to reflect improvements in the accompanying implementation guide. The PSC agreed to amend RP 1701d as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to

RP 30.201d as shown in Section II of the ATA Minutes.

P6.3.3 RP 1701h - Security Checkpoint Access and Egress

27. The Passenger Facilitation Working Group (PFWG) developed guidelines in cooperation with the Airports Council International (ACI) to improve the passenger process at security checkpoint access and exit points (egress). It was proposed to publish these recommendations to provide a useful reference for airport terminal design and management of the passenger flow around security checkpoints. The PSC established RP 1701h (Security Checkpoint Access and Egress) as show n in the book of finally adopted Resolutions & RPs. The ATA Passenger Council established counterpart RP

30.301h as shown in Section II of the ATA Minutes.

P6.3.4 RP 1701k - Self-Boarding

28. The Fast Travel Working Group (FTWG) proposed changes to the guidelines in RP 1701k (Self Boarding) to reflect improvements in the accompanying implementation guide. The PSC agreed to amend RP 1701k as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to RP 30.201k as shown in Section II of

the ATA Minutes.6

P6.3.5 RP 1701j Automated and Se lf-Service Flight Rebooking for Irregular Operations

29. The Fast Travel Working Group (FTWG) developed guidelines to address automated and self-service rebooking facilities for irregular operations. These guidelines would be for airlines to use on their own self-service machines or in a common use environment to facilitate self-service rebooking at airports. The PSC established RP 1701j as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council established counterpart RP 30.301j as shown in Section II of the ATA Minutes.

30. Mr Jerry Foran (BA) reported that the adopted text had not been reviewed by the entire membership of the Ticketing Committee and Reservations

Committee. The Chairman directed that the RP should be sent to the next meetings of the JPTC and ResCom for their review and comment.

ACTION: JPTC and ResCom

P6.3.6 RP 1701i - Intern ational Traveler Scheme

31. The Passenger Facilitation Working Group (PFWG) developed guidelines to promote the adoption of commonalities between na tional registered traveler schemes to foster interoperability for the benefit of passengers. The PSC established RP 1701i (International Traveler Scheme) as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council established counterpart RP 30.301i as shown in Section II of the ATA Minutes.

P6.3.7 RP 1706c – Common Use Self-Service (CUSS)

32. The Common Use Working Group (CUWG) developed changes to RP 1706c to amend the procedures for using credit card numbers as a form of identification (FOID). This action was required to comply with PCI-DSS requirements. The PSC agreed to amend RP 1706c as shown in the book of finally adopted Resolutions & RPs. Noting an abstention from Southwest, the ATA Passenger Council agreed to make counterpart changes to RP 30.100

as shown in Section II of the ATA Minutes.

P6.3.8 RP 1797 – Common Use P assenger Processing Systems (CUPPS)

33. The Common Use Working Group (CUWG) developed changes to RP 1797 to amend the procedures for using credit card numbers as a form of identification (FOID). This action was required to comply with PCI-DSS requirements. The PSC agreed to amend RP 1706c as shown in the book of finally adopted Resolutions & RPs. Noting an abstention from Southwest, the ATA Passenger Council agreed to make counterpart changes to RP 30.201

as shown in Section II of the ATA Minutes.7 P6.3.9 Resolution 792 – Bar Coded Boarding Pass (BCBP) – Version 5

34. The Passenger Experience Management Group (PEMG) and the BCBP task force had identified the requirement to add a new element in the 2D bar code to manage passenger eligibility for “Fast Track” lanes at airports, independently from possibly already existing criteria (e.g. class of transport, frequent flyer status, etc.). The PSC agreed to amend Resolution 792 as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to Resolution 20.205 as shown

in Section II of the ATA Minutes.

P7 Co-ordination with the Commission of European Communities (CEC) on

PSC Matters

35. Conference noted this report.

P8 Elimination of Remaining Pape r Tickets – Paper Out Strategy

36. Members were reminded of the resolution adopted by the 60 th IATA AGM held in Singapore in 2004 that endorsed action by the IATA Board of Governors to establish a program of cost reduction that became known as ‘Simplifying the Business’ and the agreement that the ‘ priority area to be addressed is a transition to 100% electronic ticketing, targeting the phase-out of all paper tickets by 31 December 2007’

.

37. However, to date, the large majority of carriers still maintain some form of legacy paper ticketing (in their own offices and at airports) which is still used for both online and interline sales. This means that many carriers are obliged to maintain legacy paper infrastructure for what is rapidly becoming a decreasing part of their business with all of the incumbent costs. Carriers therefore cannot fully realize the benefits that operating in a 100% paperless environment would bring. For example, carriers still have the costs of the procurement and shipment of paper tickets by secure courier, maintenance of printers and legacy revenue accounting processes.

38. Accordingly the Secretary proposed that Conference establish a deadline date of 1 April 2014 for the abolition of all remaining paper tickets, miscellaneous documents, excess baggage tickets and Flight Interruption Manifests (FIMs). This date was chosen in recognition of the deadline of 1 January 2014 for BSPs to use exclusively the EMD and th e deadline date of 31 March 2012 for interline staff travel to be 100% paperless.

39. Whereas Conference supported the concept of a deadline date, several airlines voiced concern at the date itself in view of merger activity and other issues which would prevent them from meeting such an aggressive deadline date. After some debate it was agreed that 1 April 2016 would be a realistic target date for the entire industry. Moreover Conference endorsed a proposal to request that the StB Steering Group recommend the launch of a business case to ensure appropriate resources are available to launch a project to oversee the rapid expansion of paperless carriers to meet the deadline date.

ACTION: StB Steering Group8

40. In addition Conference instructed the JPTC to review all ticketing Resolutions and RPs with a goal to sunset paper ticket standards effective 1 April 2016.

ACTION: JPTC

P8.1 Add Paragraph 2.2.6 to Resolution 780e

41. The JPTC proposed that Resolution 780e be updated to align its provisions with those of Resolution 780. The PSC agreed to amend Resolution 780e as shown in the book of finally adopted Resolutions & RPs.

P9 ZED-MIBA Forum – Sunset of Paper Tickets for Interline Staff Travel

42. Conference noted this report an d disbanded the ZMF/IATA Staff Travel Automated Solutions (ZISTAS) Working Group.

P10 Report – Passenger Distribution Group (PDG)

43. Members noted the Terms of Reference of a new group called the Passenger Distribution Group (PDG) as shown in Attachment D . Mr Eric Leopold (IATA) advised that there is an emerging vision for multi-channel airline distribution as described in goal one of the StB Think Tank white paper as shown in

Attachment C

.

44. He reported that the first meeting of the PDG had agreed to develop a direction on how to develop standards and infrastructure for a new distribution model. Mr Patrick Graf (LX) enquired about any plans on how standards for the new distribution model would be developed. Mr Leopold replied that consideration would be given to more agile and quicker ways of creating standards, perhaps in a similar fashion to OpenTravel and OpenAXIS.

P11 Report - PCI DSS Wo rking Group (PDWG)

45. Conference noted this report and agreed to extend the mandate of the PDWG for 12 more months. Volunteers to participate in the group were identified as: BA, DL, LH, SK and UA.

P12 Co-ordination with the US Depa rtment of Transportation (DoT) –

Initiative for Self-Assessment

46. The Secretary reminded Conference that IATA had submitted an exemption from “Condition #2” (Docket OST-2010-0114) in May 2010. Whereas it was frustrating not to have had an Order issued after 17 months of waiting, he advised that recent dialogue with the US DoT had resulted in a promise that action would likely be taken before the end of 2011. The Secretary committed to advising all members as soon as an Order is issued.

ACTION: Secretary9

P13 US DoT – Enhancing Airlin e Passenger Protections Bill

47. Conference noted this report. Mr Jim Casey (ATA) reported that some elements had been given a delayed implementation date of 24 January 2012

after interventions from ATA and IATA.

P14 Report – Involuntary Rero uting Working Group (IRWG)

48. Conference noted this report and agreed to extend the mandate by 12

months with terms of reference as shown in Attachment E

.

49. Mr Johan Lodewijckx (KL) said that the work to establish a new proposed resolution to handle schedule changes was on-going and was definitely needed by the industry. As a result he requested Conference to extend the mandate of IRWG and looked forward to the face-to-face meeting in March

after JPTC.



### AIRPORT SERVICES

B1 Report of the Airport Services Committee (ASC)

50. Conference noted this report which advised that all items in the JPSC agenda had been endorsed by the ASC through electronic means.

B1.1 ASC Membership

51. A copy of the ASC membership for 2012 is shown in Attachment F . New

nominations to fill the vacant seats should cont act the ASC Secretary Mr Andrew Price ( pricea@iata.org ).

B1.2 ASC Election of Chairman

52. Conference noted that the chair of the ASC remained vacant. There were no on-site volunteers for the position. Volunteers should contact the ASC Secretary Mr Andrew Price ( pricea@iata.org ).

B1.3 ATA Baggage Committee – Terms of Reference and Membership

53. Conference noted the ToR and the membership.

B2 Report of the IATA Grou nd Handling Council (IGHC)

54. Conference noted the report of the IGHC.10

B3 Report – Fast Travel – Passen ger Experience Management Group (Resolution 705)

55. Conference noted that report for Fast Travel and the PEMG had been addressed in agenda item P6.3.

B4 Report of the Baggage Working Group (BWG)

56. Conference noted the report of the BWG and agreed to extend its mandate by a further 12 months so that it could develop the detail for the strategy developed by the Baggage Steering Group (refer to agenda item B4.1). The PSC agreed to amend the Terms of Reference as shown in Attachment G

.

B4.1 The New Baggage Steering Group (BSG)

57. Conference agreed that the group should be formally established for a period of 1 year to start with. A vote was held for the vacant positions on the group, with South African Airlines and Lufthansa being elected to the membership. A copy of the BSG Terms of Reference and 2012 membership

is shown in Attachment H

.

B5 Report of the DCS Messages Working Group (DCSMWG)

58. Conference agreed to extend the mandate of the DCSMWG by 12 months

and amend their Terms of Reference as shown in Attachment I . Conference also agreed to establish the Multi-channel Merchandise Sales and Delivery Task Force (MMSDTF) with Terms of Reference as shown in Attachment J in order to develop standards that would support the issuance of EMDs at check-in at the airport following re quests from certain DCS systems. Volunteers for this new group were noted from Amadeus, AF, AY, DL, LH,

SITA and UA.

B6 Standardized Sp ecial Baggage Codes

59. The ASC had endorsed a proposal from LH regarding the addition of several baggage codes in RPs 1747 and 180 0 to facilitate sales of ancillary services. However, it was reported that the Reservations Committee had reviewed this item and determined that current procedures exist to transmit this kind of information. The item failed due to lack of support.11 B7/P Packaged Items (DCSMWG)

60. This “package” contained miscellaneous items documented in B7.1/P through B7.9/P which had been developed by the DCSMWG and endorsed by the ASC with no opposition noted. The Secretary advised that items B7.5/P had been removed from the package by SK. The PSC agreed to all proposed changes in agenda items B7.1/P through B7.9/P (except B7.5/P) as shown in the book of finally adopted Resolutions and RPs.

B7.1/P Add Time and Date Variation to .O/ Element

61. The ASC noted that when ground handling an international flight into the USA, the handling agent must send vetting messages to the US Government for the passenger’s trip. If the passenger has several onward connections, it is difficult for a DCS to calculate the time between flights to know whether more than one vetting message is needed for the trip. Accordingly it was proposed that the .O/ element should be modified to include departure and arrival times, as well as an optional date change indicator on the arrival time, so that the DCS can correctly calculate the timeframe. The PSC agreed to amend RPs 1707a, 1707b, 1708, 1708a, 1715 and 1719b as shown in the book of finally adopted Resolutions & RPs. LH advised that they could not support any changes to DCS messages for at leas t the next three years due to system migration planned for 2014.

B7.2/P Editorial Issues in RP1706 – Add Baggage Information Message (BIM)

62. The ASC noted that the message type BIM is missing from the list in RP 1706. The PSC agreed to amend RP 1706 as shown in the book of finally adopted Resolutions & RPs.

B7.3/P Number of Services in Remarks Elements in DCS Messages

63. The ASC noted that certain types of PNRs with unequal services and names are causing many errors on the DCS side when the PNL/ADL entries are misleading, causing deficiencies in cu stomer service. Accordingly, it was proposed to change RP 1707b to bring consistency to the format that RES systems use when creating PNL/ADLs for PNRs of this nature. The PSC agreed to amend RP 1707b as shown in the book of finally adopted

Resolutions & RPs.

B7.4/P Clarification of Name Fields in the SSR DOCS

64. SITA proposed to the Reservations Committee (ResCom) that AIRIMP be updated to reduce the amount of mismatches regarding passenger names exchanged for advance passenger information (API). This would be based on the chevron characters (<) in the machine readable zone (MRZ) of passports. DCSMWG was requested to make counterpart changes regarding the chevron to RP 1707b. The PSC agreed to amend RP 1707b as shown in the book of finally adopted Resolutions & RPs.12

B7.5/P Report – PCI DSS Working Group (PDWG)

65. IATA noted that credit card schemes prohibit the use of card numbers for any purpose other than for payment transactions. This was confirmed by several airlines at ResCom who agreed to remove credit cards as a form of identification (FOID) in AIRIMP (refer to agenda item R3). Accordingly the Secretary had scanned the DCS standards and identified one example of a credit card being used as a FOID and proposed changes to RP 1708. However, there was no support for this item which was declared defeated and referred to the next meeting of the DCSMWG.

B7.6/P SSR UPGR Upgrades

66. Delta proposed to ResCom the establishment of SSR code UPGR that would be sent with the Cancel/Rebook message for a passenger who wanted to be upgraded using the frequent flyer miles of somebody else. This was in recognition that code FQTU can only be used if the passenger to be upgraded is also the frequent flyer member. ResCom agreed to establish a new SSR code UPGR. Accordingly, the PSC agreed to add code UPGR to the

PNL/ADL in RP 1708 and the PSM list of codes in RP 1715 as shown in the book of finally adopted Resolutions & RPs.

B7.7/P Editorials for New PSC Resolutions Manual

67. The ASC proposed several editorial updates to RP 1707b and RP 1708a. These were agreed by the PSC agreed as shown in the book of finally adopted Resolutions & RPs.

B7.8/P Unique Passenger Per Segment Identifier

68. AF advised that it would be beneficial to be able to identify a passenger on a flight segment and to guarantee the passenger’s uniqueness. AF proposed to add a key element to always match the relevant passenger on a given flight segment through various systems (e.g . GDS, DCS and other peripheral systems). This new element, originated in the GDS, would be transmitted on PNL/ADL and on PRL, moreover it could also be used to convey this unique reference on other DCS messages when necessary.

69. Accordingly the ASC proposed the establishment of a new optional .U element to convey a unique identifier for a passenger travelling on a flight segment. This element would only be used when bilaterally agreed. The PSC agreed to this proposal for RPs 1707b, 1708, 1719 and 1719b as shown in the book of finally adopted Resolutions & RPs. ACTION: DCSMWG13

B7.9/P Web Check –in Data on PNL / ADL

70. The ASC reported that several airlines had requested that a standard format and content be developed for sending data to DCS for passengers who had checked-in in advance (such as web based check-in). It was noted that there are already a number of different formats being used so it would be ideal to agree on an industry standard. The ASC proposed to modify the .R/ element in the PNL/ADL to be used on a bilateral basis. The PSC agreed to amend RP 1708 as shown in the book of finally adopted Resolutions & RPs.

B8/P Packaged Items (BWG)

71. This “package” contained miscellaneous items documented in B8.1/P through B8.13/P which had been developed by the BWG and endorsed by the ASC. The Secretary advised that items B8.1/P, B8.2/P and B8.3/P were for information only and B8.5/P was withdrawn from the package by IATA. The PSC agreed to all proposed changes in agenda items B8.4/P through B8.13/P (except B8.5/P) as shown in the book of finally adopted Resolutions and RPs. The ATA Passenger Council agreed to all counterpart changes as shown in

Section II of the ATA Minutes.

B8.1/P Resolution 740 / RP 1740a Review

72. The baggage working group was requested to advise whether or not a review of currently used baggage label stock recommendations and resolutions was necessary in order to align the resolutions and standards with commercially available products. The Baggage Working Group did not feel that this alignment was needed.

B8.2/P RP 1740c Review

73. The baggage working group was asked to advise whether this recommended practice should be updated or removed from the Passenger Services Conference Resolutions Manual as the technology has not been widely adopted. The group advised that as some members were using the technology it should remain in place.

B8.3/P Creation of a BSM Testing Contact List

74. One of the major challenges in baggage handling is the correct reception and interpretation of baggage messages. The BWG has established this list of people who may be contacted in order to ensure the correct handling of messages between airlines. Conference noted this item. For an updated copy of this list please contact Mr Andrew Price ( pricea@iata.org ).14 B8.4/P Clarify and Correct Errors in RP 1745 re Batch BSM

75. This agenda item was to correct the handling of batch BSM messages making the .S element mandatory for each set of .N messages. The .G element was also added to the table of repeatable elements. The PSC agreed to amend RP 1745 as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to Resolution

30.45 as shown in Section II of the ATA Minutes.

B8.5/P Amendments to RP 1745 Section 9 Baggage Manifest Message (BMM)

76. The ASC proposed to change RP 1745 to align the element usage of the baggage manifest message with how these elements are used in RP 1800, removing the .K element, (default printer) .Y element (frequent traveler) and .L (automatic PNR addr ess) elements, and adding th e .S (reconciliation data) element. The PSC agreed to amend RP 1745 as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to Resolution 30.45 as shown in Section II of the ATA

Minutes.

B8.6/P Amendments to RP 1745 Section 8 Baggage Control Messages

77. The ASC proposed to change RP 1745 to align the element usage of the baggage control message with how these elements are used in RP 1800 to add the .H and .R elements. The PSC agreed to amend RP 1745 as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to Resolution 30.45 as shown in

Section II of the ATA Minutes.

B8.7/P Amendments to RP 1745 Section 7 Baggage Not Seen Message (BNS)

78. This change to RP 1745 was to align the element usage of the baggage not sent message with how these elements are used in RP 1800, to add the .H and .E elements, and remove the .L, .W and .Y elements. The PSC agreed to amend RP 1745 as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to Resolution 30.45 as shown in Section II of the ATA Minutes.

B8.8/P RP1739, Attachment ‘E’ – Add RP1800 Reference to ‘Common

Automation Methods’

79. The ASC proposed to change RP 1739 for consistency’s sake to include the following reference: Common automation methods for passenger and baggage security reconciliation are described in RP 1800 and RP 1745 . The PSC agreed to amend RP 1739 as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to Resolution 30.45 as shown in Section II of the ATA Minutes.15

B8.9/P Editorial Issues in RP 1745 – BNS, .H Missing in Example Messages

80. The ASC proposed to change RP 1745 to add the .H field to the example message, aligning the example to the text of the RP. The PSC agreed to amend RP 1745 as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to

Resolution 30.45 as shown in Section II of the ATA Minutes.

B8.10/P Editorial Issues in RP 1745 – Attachment E

81. The ASC proposed to change RP 1745 to correct the reference to a BTM (baggage transfer message) to the BPM (Baggage Process Message). The PSC agreed to amend RP 1745 as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to Resolution 30.45 as shown in Section II of the ATA Minutes.

B8.11/P Editorial Issues in RP 1745 – Inconsistencies in .U Example Message

82. The ASC proposed to change RP 1745 to remove inconsistencies in the examples in section 2.3.24. The PSC agreed to amend RP 1745 as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to Resolution 30.45 as shown in Section

II of the ATA Minutes.

B8.12/P Editorial Issues in RP 1745 and other – Questionable reference to the ‘IATA Systems and Communication Reference Manual’

83. The ASC proposed to change RP 1745 to remove reference to the IATA Systems and Communication Reference Manual. The PSC agreed to amend RP 1745 as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to Resolution

30.45 as shown in Section II of the ATA Minutes.

B8.13/P Editorial Issues in RP 1740c – References

84. The ASC proposed to change to RP 1740c to remove the phrase “pending approval by the PSC in 2005” as the approval was given in 2005. The PSC agreed to amend RP 1740c as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to Resolution 30.49 as shown in Section II of the ATA Minutes.16 B9 Second City/Airport Code in PNL

85. Members were referred to agenda item R5 (EMD-S and SVC – Number of Location Codes). It was noted that ticketing resolutions provide for either one or two locations, whereas a teletype message sent from a third party does not allow for more than one location. Accordingly it is concluded that it is necessary to make amendments to AIRIMP section 2.10.6 and examples in section 3.21.2 for the SVC element transmission to allow for 2 locations, corresponding to EMD origin and destination codes.

86. Regarding DCS, the difference in format would only be the addition of an optional second city/airport code for the PNL. Accordingly it was proposed to add an example in RP 1708 to show an optional second city/airport code. The PSC agreed to amend RP 1708 as shown in the book of finally adopted

Resolutions & RPs.



### TICKETING

T1 Report of Ticketing Committee – Se lection of Committee Membership for the IATA Passenger Forms and Procedures Committee (PFPC)

87. Conference noted the report of the Joint Passenger Ticketing Committee (JPTC) as presented. Chairman thanked the Committee for its work done throughout the year.

88. Conference was advised that the term of office for AC, AF, NH, AA, CO, SA UA and VS, were expiring and that eight Ticketing Committee members would need to be selected. The Chairman asked if there were any other

Members that wished to be considered.

89. There were a total of 8 nominations for the eight vacant positions. Accordingly AA, AC, AF, CO, LY NH, SA, and UA were elected by acclamation for a three year period. A copy of the updated membership is

shown in Attachment K. Conference noted that all places are now taken.

90. Conference also extended the mandate of the EMDWG and IRWG for a

further 12 months.

T2/P Ticketing “Package”

91. This “package” contained miscellaneous items documented in T2.1/P through T2.35/P which had been approved at JPTC with no opposition noted. Agenda items T2.28/P, T2.32/P and T2.35/P were withdrawn from the package for further consideration.

92. The PSC unanimously adopted agenda items T2.1/P through T2.34/P (except for T2.28/P, T2.32/P) as shown in the book of finally adopted

Resolutions & RPs as detailed below.17

93. Noting that T2.32/P and T2.34/P were for IATA action only, the ATA Passenger Council unanimously agreed to counterpart changes in items T2.1/P through T2.33/P (except for T2.28/P) as shown in Section II of the ATA

Minutes.

T2.1/P Remove the Cond ition on ET Coupon before Requesting Control of EMD-A Coupon

94. The Ticketing Committee (JPTC) proposed to remove the condition that a carrier must have control of the electronic ticket flight coupon before requesting control of the associated EMD. The PSC agreed to amend Resolution 725f as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to

Resolution 20.63 as shown in Section II of the ATA Minutes.

T2.2/P Disassociate when Carrier Not Part of the Itinerary Obtains Control of ETKT or EMD Coupon

95. The Ticketing Committee (JPTC) proposed to amend Resolutions 722f and 725f requiring the Validating Carrier of the ET to disassociate an EMD-A coupon(s) when control of the associated ET coupon(s) is passed to a carrier not part of the itinerary. The PSC agreed to amend Resolutions 722f and 725f as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to Resolution 20.60

and 20.63 as shown in Section II of the ATA Minutes.

T2.3/P Amendment to Definition of Coupon Status Indicator ‘C’ (Checked-In)

96. The Ticketing Committee (JPTC) propos ed to align the definitions in all of the electronic ticket and EMD resolutions for the Coupon Status Indicator ‘C’. The PSC agreed to amend Resolutions 722f, 722g, 722h, 725f, 725g and 725h as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to Resolutions 20.60, 20.61, 20.62, 20.63, 20.64 and 20.66 as shown in Section II of the ATA

Minutes.

T2.4/P Disassociation Upon COS to ‘E’, ‘P’, ‘R’, ‘X’

97. The Ticketing Committee (JPTC) proposed to amend Resolution 722f to indicate which carrier should disassociate the EMD-A coupon(s) when setting final status to ‘E’, ‘P’, ‘R’ or ‘X’ on the associated ET coupon(s) The PSC agreed to amend Resolution 722f as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to Resolution 20.60 as shown in Section II of the ATA Minutes.18

T2.5/P Remove Mandate to Request EMD Control

98. The Ticketing Committee (JPTC) proposed to amend Resolution 722f to remove the requirement to request control of the EMD-A coupon(s) on receipt of the System Update request for association. The PSC agreed to amend Resolution 722f as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to

Resolution 20.60 as shown in Section II of the ATA Minutes.

T2.6/P Revise EMD Definitions in RP 1790 and ATA 10.90

99. The Ticketing Committee (JPTC) pr oposed to align the definitions in

Recommend Practice 1790 with those in the EMD Resolutions. The PSC agreed to amend Recommended Practice 1790 as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to Recommend Practice 10.90 as shown in

Section II of the ATA Minutes.

T2.7/P Revise ‘Consumed At Issuance’ Glossary Definition

100. According to the decisions of the June 2011 Ticketing Committee this proposal was entirely replaced with agenda items T2.21/P and T2.22/P

.

T2.8/P Clarify Definition of System Update Message

101. The Ticketing Committee (JPTC) proposed to clarify that the System Update message applied at coupon level. The PSC agreed to amend Resolutions 722f, 722h, 725f and 725h as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to Resolutions 20.60, 20.62, 20.63 and 20.66 as shown

in Section II of the ATA Minutes.

T2.9/P Add ‘In Connection With Qualif ier’ to ET Neutral Display Response

102. The Ticketing Committee (JPTC) proposed to add the ‘In Connection With Qualifier’ in the display response and correct the number of characters for the ‘In Connection with Document Number’ to 14.The PSC agreed to amend Resolutions 722g and 725g as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to Resolutions 20.61 and 20.64 as shown in Section II of the ATA

Minutes.19

T2.10/P Revise Ambiguo us EMD Definitions

103. The Ticketing Committee (JPTC) proposed to synchronize the EMD definitions in all of the ET and EMD Resolutions. The PSC agreed to amend Resolutions 722f, 722g, 722h, 725f, 725g and 725h as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to Resolutions 20.60, 20.61, 20.62, 20.63, 20.64

and 20.66 as shown in Section II of the ATA Minutes.

T2.11/P Remove Mandate for Disassociation Prior to Coupon Status Update

104. The Ticketing Committee (JPTC) proposed to remove the timing to disassociate an EMD-A coupon(s) when setting it to a final status of ‘E’, ‘R’, ‘V’ or ‘Z’. The PSC agreed to amend Resolution 725f as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to Resolution 20.63 as shown in Section II of the

ATA Minutes.

T2.12/P Removal of XT from fare Calculation

105. The Ticketing Committee (JPTC) proposed to clarify that the code ‘XT’ cannot be used in the fare calculation of an ET. The PSC agreed to amend Resolutions 720a, 722, 722f and 722g as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to Resolutions 110.15, 20.10, 20.60 and 20.61 as shown in Section II

of the ATA Minutes.

T2.13/P Revise Coupon Notifica tion Coupon Status Indicator

106. The Ticketing Committee (JPTC) proposed to make complete the definition of Coupon Status ‘N’ by adding coupon status indicators ‘G’ and ‘Z’. The PSC agreed to amend Resolutions 722f and 722h as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to Resolutions 20.60 and 20.62 as shown in

Section II of the ATA Minutes.

T2.14/P Amendment to System Update

107. The Ticketing Committee (JPTC) proposed to align the text in Resolution 722f for ‘System Update’ to the text in Resolution 725f. The PSC agreed to amend Resolution 722f as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to Resolution 20.60 as shown in Section II of the ATA Minutes.20

T2.15/P Amendment to Change of Status

108. . The Ticketing Committee (JPTC) proposed to clarify when the Change of Status should be synchronized for the ET and EMD-A. The PSC agreed to amend Resolution 722f as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to Resolution 20.60 as shown in Section II of the ATA Minutes.

T2.16/P Unsolicited Airport Control to Marketing Carrier with Flown

Information

109. The Ticketing Committee (JPTC) proposed to add a process for the Operating Carrier to send an Unsolicited Airport Control message to the Marketing Carrier when the Marketing Carriers is not the Billing Carrier. The PSC agreed to amend Resolution 722f as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to Resolution 20.60 as shown in Section II of the ATA

Minutes.

T2.17/P Remove RFISC from EMD Refund Cancel response Message

110. The Ticketing Committee (JPTC) proposed to remove the RFISC from the Refund Cancel response message. The PSC agreed to amend Resolution 725g as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to Resolution 20.64

as shown in Section II of the ATA Minutes.

T2.18/P EMD Special Characters used in Reason for Issuance Sub-Code Description

111. The Ticketing Committee (JPTC) proposed to prevent the use of special characters in the Reason for Issuance Sub-Code Description of the EMD. The PSC agreed to amend Resolution 722f as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to Resolution 20.60 as shown in Section II of the

ATA Minutes.

T2.19/P EMD Mutual Exclusivity of Coupon Value and Fa re Calculation

112. The Ticketing Committee (JPTC) proposed to clarify that Coupon Value and Fare Calculation were mutually exclusive at the document level. The PSC agreed to amend Resolution 722f as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to Resolution 20.60 as shown in Section II of the ATA Minutes.21

T2.20/P EMD Product Characteristics

113. The Ticketing Committee (JPTC) proposed to introduce new data elements that would capture product characteristics. The PSC agreed to amend Resolutions 722f, 725f and 725h as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to Resolutions 20.60, 20.63 and 20.66 as shown in

Section II of the ATA Minutes.

T2.21/P EMD Update Glossary Defi nition of Consumed at Issuance

Indicator

114. The Ticketing Committee (JPTC) proposed to update the glossary definition for the ‘Consumed at Issuance Indicator’. The PSC agreed to amend Resolution 722f as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to

Resolution 20.60 as shown in Section II of the ATA Minutes.

T2.22/P EMD Consumed at Issuance Indicator Glossary Definition

115. The Ticketing Committee (JPTC) proposed to further update the glossary definition for the ‘Consumed at Issuance Indicator’ making it applicable to Resolution 725g/ATA 20.63 only. The PSC agreed to amend Resolution 722f as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to

Resolution 20.60 as shown in Section II of the ATA Minutes.

T2.23/P Addition of Attribute Group and Attribute Sub-Group

116. The Ticketing Committee (JPTC) proposed add additional data elements available from the Optional Services pricing record. The PSC agreed to amend Resolutions 722f, 725f, 725g and 725h as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to Resolutions 20.60, 20.63, 20.64 and

20.66 as shown in Section II of the ATA Minutes.

T2.24/P Inconsistency in EM D Coupon Status Definitions

117. The Ticketing Committee (JPTC) proposed to align the Coupon Status definitions across the EMD resolutions. The PSC agreed to amend Resolutions 725f, 725g and 725h as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to Resolutions 20.63, 20.64 and 20.66 as shown in Section II of the

ATA Minutes.22

T2.25/P Unsolicite d Billing Message

118. The Ticketing Committee (JPTC) proposed to amend the Unsolicited Airport Control message to send billing information to the Marketing Carrier in a block space code-share scenario. The PSC agreed to amend Resolution 725f as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to Resolution 20.63,

as shown in Section II of the ATA Minutes.

T2.26/P EMD Create Dependenc y Between RFIC and RFISC

119. The Ticketing Committee (JPTC) proposed to group certain RFISCs to a specific RFIC. The PSC agreed to amend Resolution 722f as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to Resolution 20.60 as shown in Section

II of the ATA Minutes.

T2.27/P Definition of Total Ticket Document Amount

120. The Ticketing Committee (JPTC) pro posed to align the definitions of data elements related to the Total Ticket Document Amount. The PSC agreed to amend Resolution 722f as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to

Resolution 20.60 as shown in Section II of the ATA Minutes.

T2.28/P Add ABR MSC Information to the ET Record

121. This item was removed from the package of items referenced in agenda item T2/P. The Ticketing Committee (JPTC) proposed to introduce new data elements to the ET to be able to identify the carrier whose baggage rules have been applied in an itinerary. This would facilitate the interpretation of IATA Tariff Composite Resolution 302 which defines a hierarchy as to whose baggage rules will apply.

122. A Member felt there remained too many regulatory issues that were unresolved that needed clarification particularly with the U.S. DoT. As a result, this Member felt that information would not be accurate and thereby increase the possibility of liability where incorre ct baggage information was placed on the ET receipt.

123. Following a deferred vote, with 1 Member remaining in opposition this item was declared defeated by the IATA PSC. However since voting rules for the ATA are different, this same proposal was agreed by the ATA Passenger Council to make changes to ATA Resolutions 110.15, 20.10, 20.12, 20.13, 20.51, 20.52 and 20.60 as shown in Section II of the ATA Minutes. This item was subsequently referred back to the JPTC for review since now IATA and ATA resolutions would reflect different requirements.

ACTION: JPTC23

T2.29/P Resolution Editorials

124. The Ticketing Committee (JPTC) proposed a number of editorial amendments to Resolutions 722f and 725g. The PSC agreed to amend Resolutions 722f and 725g as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to Resolution 20.60 and 20.64 as shown in Section II of the ATA

Minutes.

T2.30/P Current Surcharge Ticketing – RAWG Requests

125. The Ticketing Committee (JPTC) proposed to include verbiage to cover new additional surcharge scenarios. The PSC agreed to amend Resolution 722 as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to Resolution 20.10

as shown in Section II of the ATA Minutes.

T2.31/P Current Surcharge Ticketing – Clean-Up

126. The Ticketing Committee (JPTC) proposed to amend verbiage to cover additional surcharge scenarios not currently part of the existing resolutions. The PSC agreed to amend Resolution 72 2 as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to Resolution 20.10 as shown in Section II of the ATA

Minutes.

T2.32/P Expiry of Neutral Paper Documents

127. This item was removed from the package of items referenced under T2/P. The Ticketing Committee (JPTC) proposed to add a sunset date into Resolutions 725d and 725e which currently are used as a standard to support the issuance of the vMCO and vMPD in IATA BSPs, reflecting the IATA Board target for the wide introduction of the EMD in BSPs with all BSPs being 100%

EMD no later than 31 December 2013.

128. A Member felt that, whilst they were not against the concept in principle, they had a concern that not all GDSs would be fully ready in all BSPs to support this deadline. UA abstained by name and following a deferred vote,

JL abstained on the condition that IATA consults with all members in 2012 to review EMD penetration and assess options for case-by-case workaround

solutions for those airlines who are unable to meet the deadline of 31 December 2013. The PSC agreed to amend Resolutions 725d and 725e as shown in the book of finally adopted Resolutions & RPs.

ACTION: IATA24

T2.33/P Delete Refere nce to Sundry Charges

129. The Ticketing Committee (JPTC) proposed to remove references to Sundry Charges in Recommended Practice 1790. The PSC agreed to amend Recommend Practice 1790 as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to Resolution 10.90 as shown in Section II of the ATA Minutes.

T2.34/P Single S ource RBD Service

130. The Ticketing Committee (JPTC) proposed to amend Recommended Practice 1728 to make it clear that ATPCO is the only source of RBD data. The PSC agreed to amend Recommended Practice 1728 as shown in the book of finally adopted Resolutions & RPs.

T2.35/P Industry Implemen tation Strategy for Alphanumeric TFC Coding

131. This item was removed from the package of items referenced under agenda item T2/P. The Ticketing Committee (JPTC) proposed to amend Resolution 728 to set a deadline by which all systems should be ready to accept alphanumeric coding of taxes, fees and charges.

132. The original proposal was submitted with a deadline of 31 December 2012. However IATA noted that, since the JPTC had met, there had been a
substantial increase in the number of code allocations and, as such, it would

be better to ensure that systems were ready no late r than 30 June 2012. The PSC agreed to amend Resolution 728 as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to Resolution 110.15 as shown in Section II of the ATA Minutes.

T3 Credit Card as FOID and PCI DSS Compliancy

133. The Ticketing Committee (JPTC) proposed to remove the option to use a credit card number as FOID as it was understood that this violates operating regulations of the card schemes. A Member advised that using the credit card was inherent in their ET process and could not support the entire removal of this provision from the resolution. It was clarified that, as long as the full card number was not transmitted, then this met the requirements of the PCI DSS rules. With three Members in opposition and 3 abstaining this item was declared defeated by the PSC Chairperson. There was no motion to vote by

ATA carriers and this item wa s referred back to the JPTC.

ACTION: JPTC25

T4 Fee Calculation on EMD

134. The Ticketing Committee (JPTC) proposed to formalize the standard format for entering a fee calculation on an EMD. The PSC agreed to amend Resolutions 725a and 725b as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to Resolution 110.25 as shown in Section II of the ATA Minutes.

T5 Update to Resolution 728

135. The Ticketing Committee (JPTC) proposed to remove the credit card product codes of all cards other than international or national brands acceptable in the BSP an d remove the BIN numbers. The PSC agreed to amend Resolution 728 as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to

Resolution 110.16 as shown in Section II of the ATA Minutes.

T6 Current Surcharge Ticketing – Reductions

136. The Ticketing Committee (JPTC) proposed a new way of showing negative surcharges. Even though the current method of showing ‘LESS’ was not providing as much information as was available in pricing, a Member felt that, given the number of times this would occur, it was not worth making expensive changes to revenue accounting and prorate systems. With one Member in opposition this item was declared defeated by the IATA PSC Chairperson. There was no motion by ATA carriers and this item was sent

back to JPTC for further evaluation.

ACTION: JPTC

T7 Deletion of Carrier Fee Type OA

137. The Ticketing Committee (JPTC) proposed to remove the Carrier Fee Type OA as it was suggested that it was not supported in the ATPCO optional services filing solution and no carrier had requested it to be implemented. A Member clarified that in fact they had requested for the automation of OA fees by ATPCO and therefore could not support the removal from the Resolution. With two Members in opposition this item was declared defeated by the IATA PSC Chairperson. There was no motion by ATA carriers.

T8 Corrections to Matrices for Carrier Fees

138. IATA management proposed to correct a number of omissions and typographical errors in the Carrier Fee data elements and matrices. The PSC agreed to amend Resolutions 722f, 722g, 722h, 725f, 725g and 725h as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to Resolutions 20.60, 20.61, 20.62, 20.63, 20.64 and 20.66 as shown in Section II of the ATA Minutes.26

T9 Removal of Tax Reporting Form From Resolution 728

139. IATA TTBS management proposed to remove the tax, fee, charge reporting from Resolution 728 as it no longer meets the requirements for reporting new TFC requests and changes to existing TFCs. The PSC agreed to amend Resolution 728 as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to

Resolution 110.16 as shown in Section II of the ATA Minutes.

T10 Reporting of Taxes at Coupon Level

140. The Coupon Tax Task Force (CCTF) on behalf of BDISG submitted an agenda item to the JPTC in June 2011 to request new data elements to support revenue accounting to identify taxes, fees and charges at the ticket coupon level. However it was not addressed by the JPTC since no firm proposal was submitted. It had been suggested by a Member that industry could not wait another year to have these data elements in place as TFCs were getting ever more complex. Accordi ngly this item was submitted direct to conference to agree to add a number of new data elements to the data elements glossary and related matrices in order to add further clarity to the reporting of taxes, fees and charges at the ticket coupon level.

141. A Member felt that this issue was complex and the implications for such changes had not been fully thought through. As a result, this Member felt that this issue should have been reviewed first by the JPTC. After a deferred vote and with three abstentions the PSC agreed to amend Resolutions 722f, 722g 722h, 725f, 725g and 725h as shown in the book of finally adopted

Resolutions & RPs. The ATA Passe nger Council, however with one opposing, three abstentions and two Members in agreement did not agree to make counterpart changes to Resolutions 20.60, 20.61, 20.62, 20.63, 20.64 and 20.66. It was requested that this item be referred back to the JPTC for review and possible enhancements.

ACTION: JPTC

T11 “Consumed at Is suance” Indicator

142. Discussion at the JPTC and EMD Task Force revealed a concern that

there is no automated mechanism for a GDS to send the ‘Consumed at Issuance Indicator’ for an EMD-S. Further discussion revealed that the only logical conclusion was that it would have to be the I.T. hosted solution provider that would be the only one able to set this indicator upon instruction from the Validating Carrier it hosts. As this was an important issue for EMD implementation, IATA Management was asked to prepare an agenda item directly to conference removing the data element from the issuance request message. This would make it clear that a GDS, when sending an issuance request message to the validating carrier, will not be required to send the

indicator.27 143. A Member felt it was premature to remove the indicator from the messaging matrices since it was not known how this indicator might be used

in the future. Moreover that this issue should have nonetheless have had the opportunity to be reviewed by the JPTC. Following a deferred vote and, with one abstention, the PSC agreed to amend Resolutions 722f and 725g as shown in the book of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to make counterpart changes to Resolutions 20.61 and 20.63

as shown in Section II of the ATA Minutes.



### RESERVATIONS

R1 Report - ATA/IATA Reser vations Committee (ResCom)

144. Conference noted this report. BA, EK, EY, IB, MS, SA and US were appointed to the IATA Reservations Committee as shown in Attachment AA

.

R2 Report - Reservations Working Group (RESWG)

145. Conference noted this report and endorsed the work plan as shown in

Attachment BB . Conference agreed to extend the mandate of RESWG for a

further 12 months.

R3 Remove Credit Cards as Form of Identification (FOID)

146. ResCom proposed amendments to AIRIMP to delete examples of using a credit card as a form of identification (FOID) in order to comply with PCI-DSS standards. Ms Michelle Bryant (LH) advised that her airline would require a delayed effective date due to automated systems issues. However, Ms Elaine Rusen (SK) advised that her airline continued to require payment cards as FOID and therefore she could not accept the proposal as written. Noting opposition from SK and abstentions from KL, MS and UA, this item

was declared defeated and sent back to the Reservations Committee (ResCom) for further study.

ACTION: ResCom

R4 SSR Matrix

147. Rescom proposed that the SSR matrix in AIRIMP be clarified to more clearly identify exceptions for processing, and additionally proposed a new section to explain exceptional processing of SSRs. Conference agreed to

amend AIRIMP as shown in Attachment CC

. The ATA Passenger Council agreed to counterpart changes in SIPP also as shown in Attachment CC

.28

R5 EMD-S and SVC – Number of Location Codes

148. The EMD Task Force (EMDTF) proposed amending AIRIMP for the SVC element transmission to allow for two locations, corresponding to EMD origin and destination codes. Conference agreed to amend AIRIMP as shown

in Attachment DD

. The ATA Passenger Council agreed to counterpart changes in SIPP also as shown in Attachment DD.

R6/P Reservations “Package”

149. This “package” contained miscellaneous items documented in R6.1/P through R6.20/P which had been approved at ResCom with no opposition noted. Conference unanimously adopted changes to AIRIMP in agenda items R6.1/P through R6.20/P as shown in Attachments EE through XX . The ATA Passenger Council unanimously agreed to counterpart changes to SIPP in agenda items R6.1/P through R6.20/P also as shown in Attachments EE through XX

.

R6.1/P Allow HS to be Sent Without a Previously Received KD

150. ResCom proposed to amend AIRIMP to allow sending an SSR ASVC with an HS action code without a previously received ASVC KD. Conference agreed to amend AIRIMP as shown in Attachment EE

. The ATA Passenger Council agreed to counterpart changes in SIPP also as shown in Attachment

EE

.

R6.2/P New SSR PCTC Example

151. ResCom proposed to update AIRIMP with an example in which an airline has elected to collect, in the PNR, passenger contact information as required by a legislative mandate such as the EC Regulation on “Investigation

and Prevention of Accidents and Incidents in Civil Aviation”. Conference agreed to amend AIRIMP as shown in Attachment FF

. The ATA Passenger Council agreed to counterpart changes in SIPP also as shown in Attachment

FF

.

R6.3/P Advanced Passenge r Information (API) Codes

152. ResCom proposed to amend AIRIMP to clarify procedures for the use of SSR DOCO codes. Conference agreed to amend AIRIMP as shown in

Attachment GG

. The ATA Passenger Council agreed to counterpart changes in SIPP also as shown in Attachment GG

.29

R6.4/P Advice of Electronic Ticket Number for Passive Segments Where a Passive Segment Notification Agreement Exists

153. ResCom proposed to amend AIRIMP to clarify procedures when a passive segment notification agreement exists by adding SSR RLOC to the example. Conference agreed to amend AIRIMP as shown in Attachment

HH

. The ATA Passenger Council agreed to counterpart changes in SIPP also

as shown in Attachment HH

.

R6.5/P Service PNR Message

154. ResCom proposed to amend AIRIMP to clarify the sequence of record locators in AIRIMP. Conference agreed to amend AIRIMP as shown in

Attachment II

. The ATA Passenger Council agreed to counterpart changes

in SIPP also as shown in Attachment II

.

R6.6/P SSR UPGR Upgrades

155. ResCom proposed to amend AIRIMP to add a new SSR code UPGR that would be sent with the Cancel/Rebook message for a passenger who wanted to be upgraded using the frequent flyer miles of somebody else or for any upgrade based on partner agreement. Conference agreed to amend

AIRIMP as shown in Attachment JJ

. The ATA Passenger Council agreed to counterpart changes in SIPP also as shown in Attachment JJ.

R6.7/P Visa Place of Issuance in SSR DOCO

156. ResCom proposed to update AIRIMP to clarify examples regarding the place of issue of the visa. Conference agreed to amend AIRIMP as shown in

Attachment KK

. The ATA Passenger Council agreed to counterpart changes

in SIPP also as shown in Attachment KK

.

R6.8/P Add Military ID (M) to List of Travel Documents for SSR DOCS in

AIRIMP

157. ResCom proposed to amend AIRIMP to show a separate code to distinguish military identification (ID) in view that such code is already being used by several governments. Conference agreed to amend AIRIMP as

shown in Attachment LL

. The ATA Passenger Council agreed to counterpart changes in SIPP also as shown in Attachment LL

.

R6.9/P Establish Procedures for Accurate Completion of SSR DOCS

158. ResCom proposed to add a new section for AIRIMP regarding “irregular names”. Conference agreed to amend AIRIMP as shown in

Attachment MM

. The ATA Passenger Council agreed to counterpart changes in SIPP also as shown in Attachment MM

.30

R6.10/P Clarification of Name Fields in the SSR DOCS

159. ResCom proposed to update AIRIMP to reduce the amount of mismatches regarding passenger names exchanged for advance passenger information (API). Conference agreed to amend AIRIMP as shown in

Attachment MM

. The ATA Passenger Council agreed to counterpart changes in SIPP also as shown in Attachment MM

.

R6.11/P SSR DOCx for Passive Segments

160. ResCom proposed to amend AIRIMP to allow the transmission of SSR DOCx element in a Passive Segment Notification messages. Conference agreed to amend AIRIMP as shown in Attachment OO

. The ATA Passenger Council agreed to counterpart changes in SIPP also as shown in Attachment

OO

.

R6.12/P Infant without a Seat and EMD Issuance

161. ResCom proposed to amend AIRIMP to clarify procedures when an

infant without a seat is issued an EMD. The change would cater for instances when the name on the EMD and the associated ET may not be the actual user of the service. Conference agreed to amend AIRIMP as shown in

Attachment PP

. The ATA Passenger Council agreed to counterpart changes

in SIPP also as shown in Attachment PP

.

R6.13/P Update Paragraph References in AIRIMP

162. ResCom proposed some editorial amendments to AIRIMP. Conference agreed to amend AIRIMP as shown in Attachment QQ

. The ATA Passenger Council agreed to counterpart changes in SIPP also as

shown in Attachment QQ

.

R6.14/P Editorial Repairs to AIRIMP

163. ResCom proposed to amend AIRIMP in order that the field in SSR construction rules for the “number in party” should be changed to “number of services”, as was adopted for the SSR ASVC. Conference agreed to amend

AIRIMP as shown in Attachment RR

. The ATA Passenger Council agreed to counterpart changes in SIPP also as shown in Attachment RR

.

R6.15/P Multiple Services for One Passenger in AIRIMP

164. ResCom proposed to amend AIRIMP to align the verbiage used to describe “Unequal number of names/services” to use the term ‘number of services’. Conference agreed to amend AIRIMP as shown in Attachment

SS

. The ATA Passenger Council agreed to counterpart changes in SIPP also

as shown in Attachment SS

.31

R6.16/P Bilateral SSRs

165. ResCom proposed to add a new paragraph in AIRIMP to define the

difference between a bilateral SSR and a non-bilateral SSR. Conference agreed to amend AIRIMP as shown in Attachment TT

. The ATA Passenger Council agreed to counterpart changes in SIPP also as shown in Attachment

TT

.

R6.17/P Seat Characteristics in Replies

166. ResCom proposed to amend AI RIMP to allow systems to exchange seat location codes in reply messages when bilaterally agreed. Conference agreed to amend AIRIMP as shown in Attachment UU

. The ATA Passenger Council agreed to counterpart changes in SIPP also as shown in Attachment

UU

.

R6.18/P Additi onal Services

167. ResCom proposed to amend AIRIMP to add examples describing when the seat has been confirmed through an interactive conversation. Conference agreed to amend AIRIMP as shown in Attachment VV

. The ATA Passenger Council agreed to counterpart changes in SIPP also as shown in

Attachment VV

.

R6.19/P Unsolicited Reply Messages

168. ResCom proposed to add a new paragraph in AIRIMP to describe an Unsolicited Reply message. It was noted this will resolve many issues some are having with SSR DOCS. Conference agreed to amend AIRIMP as shown

in Attachment WW

. The ATA Passenger Council agreed to counterpart changes in SIPP also as shown in Attachment WW

.

R6.20/P Correct SSR DOCS Examples

169. ResCom proposed to amend AIRIMP to make the SSR DOCS examples more accurate in accordance with government regulations. It was clarified these amendments do not require programming changes. Conference agreed to amend AIRIMP as shown in Attachment XX

. The ATA Passenger Council agreed to counterpart changes in SIPP also as shown in

Attachment XX

.32



### MISCELLANEOUS

M1 Report - PSC Steering Group (PSCSG)

170. Conference noted this report. The position for TC3 was filled by All Nippon (NH). The Secretary noted that the position to represent TC1 remains vacant. An updated governance chart showing industry standards setting groups that report to the PSC is shown in Attachment L

.

171. Updated area charts showing which groups (“areas of involvement”) are open to Strategic Partners are available from: http://www.iata.org/membership/sp/areas/Pages/index.aspx

(Refer to “ Passenger Standards ”, “ Passenger Experience ”, “ Passenger Facilitation ”,

“ Baggage Services ”, “ Common Use ”, “ EMD/e-services ” and “ Travel Partners ”).

M2 Report - PADIS Board (PADIS)

172. Conference noted this report and agreed to establish the Expert Advisory Task Force (EATF) with terms of Reference as shown in

Attachment M

.

M2.1 PNRGOV Working Group

173. Conference noted this report.

M3 Report - Cargo Services Conference (CSC)

174. Conference noted this report.

M4 Report – Scheduling Services

175. Conference noted this report.

M4.1 Report - Schedules Information Standards Committee (SISC)

176. Conference noted this report and agreed to disband the SSIM Appendix A/D/F/I Task Force (ADFITF) with consequential changes to the

Terms of Reference for SISC as shown in Attachment N

.

M5 Report – Fraud Prevention Working Group (FPWG)

177. Conference noted this report and an onsite document providing a summary of a conference call from September 2011 with members of the

FPWG as shown in Attachment O

.33

M5.1 Circulation of Fraudulen t Emails under IATA’s Name

178. The Secretary reported that fraudsters had made attempts to collect money from users of IATA products and services. Accordingly all members were requested to take note of information and guidelines as shown in

Attachment N

.

M6 Report – BSP Data Interc hange Standards Group (BDISG)

179. Conference noted this report.

M7 Report – Strategic Partnerships

180. Conference noted this report.

M8 Report - Agency Solutions Te chnical Working Group (ASTWG)

181. Mr Tim Powell (Sabre) advised that his company believed that this group provided a good forum for GDSs to address technical issues with airlines and their agents. Conference noted the report and extended its mandate by a further 12 months.

M9 Rescinding AIRDES (RP 1737) and Reconfirmation Procedures (RP 1762)

182. The Secretary proposed to rescind RP 1737 (AIRDES) because this system no longer exists. He also proposed to rescind RP 1762 (Reconfirmation Procedures) because he believed that industry procedures were no longer required.

183. The PSC agreed to rescind RP 1737 as shown in the book of finally adopted Resolutions & RPs. However, members had not had sufficient time to study the effects of rescinding RP 1762 and so requested the ResCom to investigate this issue and report back to the next Conference.

ACTION: ResCom

Close of Meeting

184. The Chairman recognized that Mr Stephan Corking (Amadeus) was participating in his last JPSC meeting. She thanked him for his strong support of PSC activities, especially ResCom and RESWG activities, and wished him well in his new position. The Chairman closed the meeting at 17.15 hours.34JPSC/31 PSC/33 Oct 11Attachment: APage: 1 of 3Airline / Company Name First Name Last Name Job Title EmailAbacus International Kit Leong Director, Airline and Core Solutions Marketing kit@abacus.com.sgAbacus International Sow Fung Leong Director, PSDD sowfung_leong@abacus.com.sgAbacus International Pte Ltd Linda Chee Product Consultant linda_chee@abacus.com.sgAdria Airways Djanino Bubola Area Manager djani.bubola@adria.siAerolíneas Argentinas Marta Cristina Chiban BSP Travel Agencies Manager mchiban@aerolineas.com.arAir China Ltd. Weihong JiajingAir China Ltd. Hailong Yue Chief yuehailong@airchina.comAir France Helene Millet New Distribution Processes hearnaudmillet@airfrance.frAir Transport Association of America James Casey Vice President & Deputy General Counsel jcasey@airlines.orgAir Transport Association of America Patty Edwards Managing Director, Passenger Services pedwards@airlines.orgAlaska Airlines Rick NaggAll Nippon Airways Kuniko Hayakawa Assistant Manager ku.miyazaki@ana.co.jpAll Nippon Airways Mitsue Sato Assistant Manger, IT Strategy&Planning mitsue@ana.co.jpAll Nippon Airways Etsuko Tada Senior Manager e.tada@ana.co.jpAll Nippon Airways Sachie Terunuma Assistant Manager s.terunuma@ana.co.jpAll Nippon Airways Chiharu Tsuzuki Senior Manager c.tsuzuki@ana.co.jpAmadeus Marc Adam Product Definition Analyst - Ticketing marc.adam@amadeus.comAmadeus Stephen-Terence Corking Senior Manager, Development scorking@amadeus.comAmadeus Adrian Gorun Product Manager adrian.gorun@amadeus.comAmadeus Pascale Mansart Functional analyst pmansart@amadeus.comAmerican Airlines Karen Churchill Manager, Airports karen.churchill@aa.comARC (Airlines Reporting Corporation) Philip Myers Sr Product Manager pmyers@arccorp.comARC (Airlines Reporting Corporation) Philip Myers Sr Product Manager pmyers@arccorp.comARC (Airlines Reporting Corporation) Keith Venzke Senior Manager Industry Standards kvenzke@arccorp.comAustrian Airlines Marcus Lenk Head of Ticketing Steering marcus.lenk@austrian.comAXESS International Network Inc. Tomoko Igawa Senior Manager igawa.tomoko@axess.co.jpBritish Airways PLC Jerry Foran Product Delivery Manager, Revenue Managemejerry.foran@ba.comCathay Pacific Airways Ltd Judy Tam Worldwide Reservations & Ticketing Manager - judy_tam@cathaypacific.comDelta Air Lines Julie Bernard Project manager ETicketing julie.b.bernard@delta.comDelta Air Lines Stephanie Yen Manager - Industry Affairs stephanie.yen@delta.comEgyptair Hisham Magdy Manager Aviation Affairs Development hisham_magdy@egyptair.comEl Al Israel Airlines Ltd. Linda Grinfeld Deputy director IATA and Pricing linda@elal.co.ilFinnair Oyj Päivi Rautanen Product Manager paivi.rautanen@finnair.comHainan Airlines Guo Jiajing Specialist of International Pricing Jiaj_guo@hnair.comHainan Airlines Limin Tang Supervisor of International Pricing Lm_tang@hnair.comHP Lucia Gerber Product Manager lucia.gerber@hp.comIATA Lisa Angiolelli Product Manager, Passenger FacilitationANGIOLELLIL@iata.orgIATA Paul Behan Head, Passenger Experiencebehanp@iata.orgIATA Stephan Copart Project Manager, Fast Travelcoparts@iata.orgIATA Rosanna Iannantuono Manager, Mileage Products, PASS iannantuor@iata.orgIATA Daniel Kanter Senior Legal Counsel, LEGAL kanterd@iata.orgIATA Thomas Klein Product Manager, Passenger Segment Publicati kleint@iata.orgIATA Eric Leopold Director, Passengerleopolde@iata.orgIATA David McEwen Manager, Passenger Interline Standards, PASS mcewend@iata.orgIATA Mike Muller Head, Passenger Inteline Standardsmullerm@iata.orgIATA Andrew Price Nead, Baggage Servicespricea@iata.orgIATA Alban Sato Manager, Interline Tariffs, PASS satoa@iata.orgIATA Marie Zitkova Manager, Messaging Standards, PASS zitkovam@iata.orgIberia Airlines Concha De La Calle Manager Reservations & Distribution ccalle@iberia.esIberia Airlines Mary Jo Reviejo Reservations Analyst & Industry Relations mjreviejo@iberia.esInfini Travel Information, Inc. Ken Morita Assistant Manager morita0241@infini-trvl.co.jpJapan Airlines Eri Miyake Manager eri.miyake@jal.comJapan Airlines Hikaru Yamauchi Director hikaru.yamauchi@jal.comKenya Airways Agnes Kwanya Manager Interline and Tariffs Agnes.Kwanya@kenya-airways.comKLM Royal Dutch Airlines Johan Lodewijckx Manager IATA & Industry Affairs johan.lodewijckx@klm.comLOT Polish Airlines Elizabeth Dmowska IATA Rules and Regulations Adviser e.dmowska@lot.plLOT Polish Airlines Dorota Wronska Pricing Manager d.wronska@lot.plLufthansa Michelle Bryant Manager Distribution Systems and IATA Industrymichelle.bryant@dlh.deMalaysia Airlines Jaffar Derus Ahmad Vice President Airport Operations jderus@malaysiaairlines.comMalaysia Airlines Hayati Dato Ali Executive Vice President-Airport Operations hayati@malaysiaairlines.comMEA Salim Kharrat In Charge Agency & Procedure kharrats@mea.com.lbPSC Chairman Patricia George PSC Chairman pageorge@wanadoo.frSabre Holdings Tim Powell Director Industry Affairs tim.powell@sabre.comSAS Christina Falck Manager Industry Affairs christina.falck@sas.seSAS Elaine Rusén Manager Industry Affairs elaine.rusen@sas.seSaudi Arabia Airlines Ayed Alotaibi Snr.Specialist Airport Services Programs AALOTAIBI@SAUDIAIRLINES.COMSITA John Meeks Mgr, Business and Market Intelligence john.meeks@sita.aeroSouth African Airways madelein vorster manager: ticketing support madeleinvorster@flysaa.comSouthwest Airlines Carole Barnett Mgr/API Airport Solutions carole.barnett@wnco.comSwiss International Air Lines Ltd Patrick Graf Head of Revenue Management Solutions & Distpatrick.graf@swiss.comTCH (Transport Clearing House) Anna Golenkina Technology Department, Head Golenkina@tch.ruTCH (Transport Clearing House) Natalia Kisletsova External Relations Department, Head kisletsova@tch.ruThai Airways International Ohm Planichaya Director ohm.p@thaiairways.comThai Airways International Janpen Rana Chief, Sales and Marketing Procedures janpen.r@thaiairways.comTravelport Caroline Wilkinson Product manager caroline.wilkinson@travelport.comUnisys John Kunitz Manager john.kunitz@unisys.comUnited Airlines Rosalie Crabbe Mgr. Accesible Programs and Industry Affairs rosalie.crabbe@united.comUS Airways, Inc. Heather Hamel Senior Analyst - Airport Policies & Procedures HEATHER.HAMEL@USAIRWAYS.COMUS Airways, Inc. Deryl Purvis Senior Analyst DERYL.PURVIS@USAIRWAYS.COMVietnam Airlines Do Thi Nu VN executive ngocntm@vietnamairlines.comVietnam Airlines Nguyên Thi Munh NgrVietnam Airlines Uyen Vu Thi Deputy General Manager - Tariff & Ticketing uyenvt@vietnamairlines.comVirgin Australia Simon Pitt Manager Revenue Simon.Pitt@virginaustralia.comJPSC/31 PSC/33 Oct 11

Attachment: B Page: 1 of 4



### NEW TAX CODES

As of September 2011

CODE N A M E C O U N T R Y R E Q U E S T

E D

B Y D A T E P U R P O S E / D E T A I L S

-PU- AIRPORT

DEVELOPMENT LEVY GAMBIA BRUSSELS

AIRLINES 29/10/10 INVESTMENT IN EXPANSION AND

RENEWAL of AIRPORT

INFRASTRUCTURE.

-PX- AIRPORT SECURITY

CHARGE NICARAGUA TACA 03/11/10 PROVISION OF SECURITY

SERVICES.

-PD- AVIATION SECURITY

FEE PHILIPPINES SOUTH EAST

ASIAN AIRLINES (SEAAIR) 04/11/10 TO ENSURE ADEQUATE SECURITY

MEASURES TO PREVENT

HIJACKING AND ANTITERRORISM.

-PZ- PASSENGER SERVICE

CHARGE QATAR QATAR

AIRWAYS 08/11/10 PROVISION OF IMMIGRATION AN D

SECURITY SERVICES TO PRESERVE

AND ENHANCE FACILITATION AN D

SECURITY.

-QB- AIRPORT TAX ECUADOR LAN ECUADOR 20/12/10 USE OF TERMINAL FACILITIES AT

THE UIO AND GYE AIRPORTS..

-QI- AIRPORT AUXILIARY

FACILITY TAX ECUADOR LAN ECUADOR 21/12/10 USE OF AUXILIARY FACILITIES IN

THE TERMINAL AT THE UIO AND

GYE AIRPORTS.

-QD- AIR TRANSPORT LEVY AUSTRIA AUSTRIAN

AIRLINES 22/12/10 IMPOST OF THE AUSTRIAN

GOVERNMENT ON AIR

PASSENGERS TO PROVIDE TAX

REVENUES FOR THE EXCHEQUER.JPSC/31 PSC/33 Oct 11

Attachment: B Page: 2

1 Subsequently postponed -QF- SOLIDARITY TAX GABOM GABON

AIRLINES 22/12/10 TO CONTRIBUTE TO NATIONAL

SOLIDARITY FOR DEVELOPMENT

-QJ- SECURITY CHARGE ZAMBIA KENYA AIRWAY S 13/01/11 PROVISION AND DEVELOPMENT

OF SECURITY SERVICES.

-PQ- 1 SECURITY CHARGE MADAGASCAR AIR

MADAGASCAR 13/01/11 PROVISION OF SECURITY SERVICES

THE 8 MALAGASY AIRPORTS.

-TF- VALUE ADDED TAX SRI LANKA SRI LANKAN

AIRLINES 10/03/11 COLLECTION OF VAT.

-QQ - AIRPORT SECUIRTY FEE GUATEMALA AMERICAN

AIRLINES 25/03/11 PROVISION OF SECURITY SERVICES

AT THE GUATEMALA AIRPORTS.

-RR- AIRPORT TAX CONGO KENYA AIRWAYS 01/04/11 TO COVER THE COSTS OF

A.N.A.C. SERVICES.

-SS- 1 AVIATION

INFRASTRUCTURAL

DEVELOPMENT FUND LEVY FEE (DOMESTIC) ZIMBABWE AIR ZIMBABWE 04/04/11 FOR AN INFRASTRUCTURE

DEVELOPMENT AND EQUIPMENT

MODERNIZATION PROGRAM

BASED ON THE USER-TO-PAY

CONCEPT.

-RF- PASSENGER CHARGE SERBIA JAT 05/ 04/11 AIR TRANSPORT DEVELOPMENT.

-RY- SALES TAX YEMEN YEMENIA 18/04/11 DOMESTIC TAX TO RAISE

REVENUE FOR THE TREASURY.

-YT- PASSENGER SERVICE

CHARGE MAYOTTE AIR AUSTRAL 21/04/11 TO PROVIDE PASSENGER

FACILITIES AT THE AIRPORT.

-RP- AIRPORT

DEVELOPMENT

CHARGE SAINT LUCIA AMERICAN

AIRLINES 27/04/11 FOR THE PURPOSE OF MAKING

PAYMENTS FOR THE DEBT

SERVICE REQUIRED TO

IMPLEMENT AIRPORT FACILITY

IMPROVEMENT PROJECTS.

-SM- INFRASTRUCTURE

DEVELOPMENT

CHARGE TOGO AIR FRANCE 23/05/11 FINANCE EXPANSION AND

IMPROVEMENT OF THE

GNASSINGBE EYADEMA AND LOMÉ AIRPORT. IN ADDITION,

THE RDIA WILL BE USED TO

FINANCE THE RESEARCH

LOCATION FOR THE

CONSTRUCTION OF A NEW
AIRPORT AT LOMÉ.

-TE- SECURITY CHARGE NIGERIA AIR NIGERIA 01 /06/11 IMPROVE SECURITY SERVICES AT

NIGERIAN AIRPORTS.JPSC/31 PSC/33 Oct 11

Attachment: B Page: 3

-MM- PASSENGER SERVICE

CHARGE MYANMAR MYANMAR

AIRWAYS 14/06/11 TO IMPROVE AIRPORT TERMINAL

PASSENGER SERVICES

-TP- PASSENGER SECURITY

AND SAFETY FEE UNITED ARAB

EMIRATES EMIRATES

AIRLINES 27/06/11 COVER ADDITIONAL COSTS FOR

SECURITY AND SAFETY.

-VA- PASSENGER

CLEARANCE TAX PAPUA NIUGINI AIR NIUGINI 05/07/11 TO PREVENT THE ARRIVAL OF

UNWANTED DETRIMENTAL PLANT

AND ANIMAL PESTS, DISEASES

AND WEEDS.

-UC- PASSENGER AVIATION

SERVICE CHARGE JAMAICA AIR JAMAICA 13/07/11 TO FINANCE AIR NAVIGATION

SERVICES FOR OPERATIONS

ORIGINATING AND

TERMINATING IN JAMAICA AND

THE PROVISION OF REGULATORY

SERVICES.

-UM- SECURITY CHARGE SOUTH AFRICA SAA 09 /08/11 ACS CHARGE IS FOR SERVICES

RENDERED BY AVIATION COORDINATION SERVICES (PTY)

LTD TO PROVIDE / HOLD

BAGGAGE SCREENING

BAGGAGE RECONCILIATION

AND CUTE SERVICES AT SOUTH

AFRICAN AIRPORTS.JPSC/31 PSC/33 Oct 11

Attachment: B Page: 4



### CODES RESCINDED, WITH DRAWN OR EXPIRED

CODES REINSTATED

No codes were reinstated CODE NAME COUNTRY REQUESTED

BY DATE PURPOSE / DETAILS

-BS- TICKET TAX (INTERNATIONAL) BAHAMAS BAHAMASAIR

HOLDING LTD. 30 /10/11 LEVIED ON ALL TICKETS SOLD IN

THE BAHAMAS WITH A

DEPARTURE ENTITLING

PASSENGER TO TRAVEL OUTSIDE

THE BAHAMAS ON

INTERNATIONAL FLIGHTS.

-SS- AVIATION

INFRASTRUCTURAL

DEVELOPMENT FUND LEVY FEE (DOMESTIC) ZIMBABWE AIR ZIMBABWE 04/05/11 FOR AN INFRASTRUCTURE

DEVELOPMENT AND EQUIPMENT

MODERNIZATION PROGRAMME

BASED ON THE USER-TO-PAY

CONCEPT

-JO- TICKET SALES TAX (INTERNATIONAL) JORDAN ROYAL

JORDANIAN

AIRLINES 09/02/11 LEVIED ON EACH PASSENGER

DEPARTING JORDAN,

IRRESPECTIVE PLACE OF ISSUE

AND PAYMENT OF THE TICKET.

-PQ- SECURITY CHARGE MADAGASCAR AIR

MADAGASCAR 31/01/11 PROVISION OF SECURITY

FACILITIES AT THE 8 MALAGASY

AIRPORTS

# A road map to prepare **for tomorrow’s passenger**

Five goals towards sustainable profits

and better service

### Are you ready for tomorrow’s passenger?

Air transport is today an integral part of the global economy. The industry moves people and goods across the globe quickly and efficiently, fostering economic development, greater human understanding and international trade. In the future, as economic interdependence grows so will the need for fast and secure transport.

IATA’s Simplifying the Business program (StB), announced in 2004 in Singapore, was envisioned to address these challenges. And over the past seven years, it has demonstrated success, from the move to 100% electronic ticketing and 100% bar coded boarding passes to the widespread implementation of common-use self-service kiosks. This success was dependent on the mobilization of all industry stakeholders – including airlines, agents, airports, governments and ground handlers – towards a common goal of lowering cost and improving service and efficiency.

But the industry continues to face the twin challenges of profitability and customer satisfaction. Global shocks have become a constant in our business, from increasing fuel pr ices to natural disasters. And from the shopping experience to long lines at security, travelers face numerous pain points in their journey.

The graphs below illustrate the challenge for the industry, and, in particular, for airlines.

It’s time to build on the success of Simplifying the Business (StB) and define the next wave of projects that will allow the industry to save costs, improve service and prepare for tomorrow’ s passenger. This white paper outlines the work of the StB think tank, which has proposed five goals in the areas of airline distribution, airport experience and system interoperability. The think tank, facilitated by IATA, consists of representatives from both airlines and system providers: Air Canada, Air France/KLM, Air New Zealand, British Airways, Emirates, Hewlett-Packard, IBM, L.E.K Consulting, and Oracle.

We look forward to your input.

Eric Leopold Director, Passenger Source: IATA Source: IATA

### THE FIVE GOALS

Goal 1: Airline products can be sold through all channels, identifying customers, and personalizing offers and prices.

Planning travel should be an exciting experience. But from a sense of initial euphoria at the thought of travelling somewhere new, today’s consumer is quickly confused by the dizzying array of travel options available to her. Take the example of a business traveler journeying from London to Austin, Texas. She starts to plan out her journey, but quickly realizes she needs to visit multiple websites to do so, from
various airlines to hotels and car rental options. With 10 windows open on her computer to try and identify the best fare, services and coordinate timings, she sits back and wonders, “Why can’t I just find everything in one place?”

The Problem

In a recent IBM survey, none of the respondents indicated that they were able to complete their travel booking needs in one website visit. Travelers are bogged down by search and comparisons between
products and services across the travel market.

For example, how does a consumer know which airline offers door to door bag delivery? How can a consumer
choose personalized service levels across all airline offerings if they can’t easily see what is on offer at one single location?

Not surprisingly, the increased number of choices available to travelers requires significant time investment in pre-booking search.

On their most recent trip...

• Almost 20% of travelers spent 5 or more hours shopping and / or booking

• 25% of leisure travelers spent more than 4 hours shopping / booking

• Business travelers are more efficient, but ~40% of them spent more than 2 hours shopping / booking Beyond just taking a long time to book travel, there

is a more fundamental issue: the current distribution channels do not cater for the personalized service that

a 21 st century consumer has come to expect.

Instead, they drive commoditization of airline products. Price becomes top of list in terms of consumer preferences. This drives carriers to unbundle as many elements of the product as possible to have a low cost base product and then charging for many add-ons in
order to maintain margins.

Airline websites (direct channels) are more advanced, in terms of features and design, than systems used by agents (indirect channels). They enable the consumer to interact with the brand and experience the value of the product. For example corporate buyers can access customized options within their specific corporate deals.
Individual consumers can access personalized options, after being identified by a frequent flyer number for
example.

The indirect channel however does not offer personalization for individual consumers. Through the push of content to airline distribution systems, the ability to mix and match options for the sophisticated 21 st
century consumer is limited.

This misalignment between consumer buying preferences and the selling models used by airlines
and other travel distribution companies limits innovation.

Furthermore there is a lack of consumer related data and buying behavior patterns, which also restricts the ability of airlines to innovate based on consumer

demand.

The Solution

A consumer-centric approach that allows for more retail

driven sales and distribution.

Standards need to be developed to build an infrastructure that supports all travel industry related channels. That way, any airline website or agent system can display a complete range of services. Going back to
our traveler, that means that she would havea choice of multiple channels, each one proposing a complete range of end-to-end services based on her preferences and their own brand proposition.

For the industry, it will help to know who is buying the ticket so that personalized options can be presented to the consumer, regardless

of the channel used. This would allow airlines to package their products in a meaningful way, based on buying patterns. It could also allow them to make more sophisticated offers to the
consumer. Imagine the travel industry adopting the technology that online retail sales channels use in suggesting options to consumers based on their personal preferences. Airlines want to be able to launch fast new personalized offerings through

all sales channels.

Tracking who is interested in buying what, regardless of channel, also allows for innovation of new products and services.

According to L.E.K. merchandizing revenues will amount to up to US$75bn in 2015 from US$23bn
in 2010 estimated by Amadeus IdeaWorks. Airlines
need consistent product distribution across all

channels in order to achieve those results.

How we get there

Standards need to be developed in the areas of consumer data and interoperability of reservation systems. IATA could be in a position to facilitate the development of these standards amongst
industry stakeholders.

Goal 2: Passenger data is provided
by passengers and validated by
governments

Let us return to our business traveler from London. After spending several hours on various booking websites she has an itinerary in place. Prior to her journey, she now needs to submit advance passenger information, as required by the US government. But if she gets confused by the varying requirements and makes a mistake, she might end up being denied boarding at the gate – a very unpleasant surprise for

any passenger. The Problem

Today, harmonization between countries on the collection and distribution of passenger data is limited and, increasingly, required by more and more governments. Airlines are liable for fines when
passengers are deemed inadmissible due to missing data or documentation. Passengers are confused due to the inconsistency of the information required depending on different regulations.

In most cases airlines are required to collect relevant data before the passenger reaches the gate and this causes delays, slows the check in process, and, on occasion, results in denied boarding, as airlines may not be able to validate the information until the
passenger reaches the gate.

As a consequence, carriers have had to invest in their own computer systems to meet different government requirements, or contract with independent
data processors. This has resulted in additional costs

to carriers.

The Solution

Elements of the required passenger information
can be embedded into an electronic passport linked to biometrics and a visa validation service provided by governments, building one single data set. Ultimately the responsibility and ownership of data provision should be passed on to the passenger, and validated by governments.

Information for passengers on the different government
requirements could be held in a solution based on IATA Timatic which allows airlines and travel agents to check passenger immigration and health requirements, based on destination, transit points, nationality, residence and
departure.

All travel vendors would be responsible for the collection of an agreed set of passenger data that

is able to be sent on for verification to the relevant
government agency.

How we get there

The industry needs to lobby governments and the International Civil Aviation Organization for a
common approach on standards and liability issues. Infrastructure needs to be put in place to support and facilitate the distribution of passenger data on a global industry-wide basis. Governments should be persuaded to provide biometric and visa verification services as a responsibility of states.Goal 3: Passengers can access realtime information relating to operational information on flight status, wait times
and bags on any device in any location

So our passenger is ready to travel to Texas to take advantage of some warm winter weather. Twenty four hours before her scheduled departure time from London it starts to snow. She is receiving conflicting
information from the news channels on television, the airport website and the airline website. She tries to contact the airline, but after spending a long time on hold she gives up. Since she booked her travel with an agent, the airline cannot push information to her as it does not

have her contact details. She doesn’t know what to do. Should she show up at the airport or not?

The Problem

Passengers suffer from uncertainty and stress associated with flight delays, cancellations and bag mishandling. Optimization of modern technology could go a long way to ease the pain, by allowing access

to information in real-time.

Today the lack of consumer contact information creates further frustrations for passengers, airline, and airport staff when dealing with irregular operations. The need to collect an agreed level of passenger contact data is required in the first instance, in order to be able to
share the data and then provide value added solutions

back to the consumer.

Social media and smart phones deliver immediate information to passengers that is not necessarily available to airline and airport staff managing customer service and expectations. So in some cases the passenger is getting more information about what’s happening than airline or airport staff.

The Solution

A range of devices can be used to keep the customer informed. A message sent to a passengers’ smart/ mobile phone on flight delays or cancellations would allow the passenger to make reasonable decisions on their journey. Messages could also be sent on bag status. Finding out that your bag has not made the flight before you reach baggage claim manages expectations. Knowing that it will be delivered to your hotel translates to great customer service.

Touch screen kiosks at airports can be used to communicate more effectively with meaningful messages, relating to flight delays when unavoidable to due to extreme weather conditions for example. Easy wi-fi access in all airports would further
enable dynamic communication. How we get there

Harmonization on data sharing across all industry stakeholders would improve service throughout the system. The creation of a best practice on passenger information collection would lead to proactive customer
service and industry alignment. By reaching agreement and developing standards through negotiations with industry stakeholders, airlines, airports, security agencies, border control, and ground handlers on supporting infrastructure would serve as a solid base for future development.

Goal 4: The consumer ground experience is hassle free

Once the snow has cleared, our stressed-out passenger has managed to check-in for a flight to the US. But once she drops off her luggage, she proceeds to the security check to find a very long queue. Passengers are wondering if they need to take off their shoes or belts, or leave their laptops in their carry-on luggage. She wonders, “Why does this have to be so complicated?”

The Problem

The biggest pain point for passengers today is the hassle associated with airport controls. Passengers experience uncertainty and stress due to inconsistency of processes at airports which can be better integrated than they are today. There are long wait times, in addition to different procedures to be followed at different airports around the world.

The Solution

Passport, visa, customs and immigration issues could be solved at booking; and off-airport document
checks validated by governments could be similar to credit card validation. There are already existing standards for automated bag drop and check in – and using biometrics in conjunction with Checkpoint of the Future and immigration, the customer experience could be a simplified and hassle free experience.

The Checkpoint of the Future ends the one-size-fitsall concept for security. Passengers approaching the checkpoint will be directed to one of three lanes: ‘‘Known travelers’’, ‘‘Normal’’, and ‘‘Enhanced security’’.

The determination will be based on a biometric identifier in the passport or other travel document that triggers the results of a risk assessment conducted by government before the passenger arrives at the airport.

The three security lanes will have technology to check passengers according to risk. “Known travelers” who have registered and completed background checks with government authorities will have expeditedaccess. “Normal screening” would be for the majority of travelers. And those passengers for whom less information is available, who are randomly selected or

who are deemed to be an “Elevated risk” would have an additional level of screening.

Existing self-service options which are already in place should work with the Checkpoint of the Future and immigration, aiming to improve security screening and introduce faster processing, making more efficient use of passenger data.

How we get there

Governments, airports and airlines need to cooperate by sharing data with each other. The industry as a whole should start by lobbying governments on standards and infrastructure for data exchange. Airlines and airports need to work together to link all of the different components of processing the passenger through the airport and onto the aircraft to the final destination.

Goal 5: Seamless end to end customer journey through interoperability of travel
partners

Our traveler boards the plane and her flight takes off for New York, her first point of entry into the US.
When she lands in New York, she finds out that she needs to postpone her connecting flight to Austin for a day to attend a critical meeting in the city. Today, that means she needs to separately change her flight, hotel reservation, car rental reservation and any other experiences she may have booked in Austin.

The Problem

Today, the primary identifier of a customer is a booking reference. And not just one. There might be several booking references that don’t talk to each other. So if a traveler needs to make a change, or book something else through a different travel agent, the systems can’t talk to each other. There is no concept of a master PNR that encompasses all aspects of a travel experience. A booking reference given to a customer in a distribution system is not recognizable in the operating carrier’s host reservation system or through that airline’s customer facing systems. Increasing code share and interlining within airline alliances is increasing customer expectations for a seamless journey. With the growing importance of alliances, and the existence of many different proprietary airline host systems, the industry is missing standards for an inter-airline host
system communication to enable alliances and partners to service their joint customers from whichever airline touch point in the journey the customer has reached.

Customers cannot experience a seamless integrated journey with reduced stress if travel partners are not connected. When a flight is changed, for example, the airport pick-up service may not be notified. The
changes in the travel distribution landscape have forced many customers to assume the role of travel agents responsible for finding schedules that work well
across travel modes and also monitoring connections

between modes in transit.

The Solution

To alleviate the stress factor of customers and the
airlines that serve them, both could benefit from a

service that addressed the disconnected nature of travel today by providing assurances mid journey that everything was on track, and if not, assurances that the problem had been resolved. If airlines had

more information about the final destination of their passengers they would be in a better position to delight
the customer with more information, better service, and choices on how to adjust when things change.

Collaboration and connectivity are limited within segments of the travel industry, should a passenger

need to transfer from one airline to another due to a change of plans. At the airport, it is good to know the possible length of the delay. It would be even better if the traveler was confident that changes to their airport
pick-up had been made and that a late check-in at the hotel had been arranged.

How we get there

To achieve a seamless end to end customer journey through interoperability of travel partners, the industry needs standards for data exchange protocols. By reaching agreement through cooperation with travel partners, the future could be a single travel wallet for the entire journey, with all travel segments talking to each other, to the passenger, and being able to exchange information with the consumer at different
points during his trip. Checkpoint of the Future at IATA’s AGM in Singapore, 2011

### CONCLUSION

Despite the difficulties she encountered, our traveler reaches Austin safely, and has the chance to explore new business opportunities, gain exposure to new people and places, and enjoy a break from the
European winter.

Where do we go next?

These ideas have been crystallized over a few months of interaction among the StB Think Tank. It’s now your turn. Join us and shape the future direction of the industry as we prepare for tomorrow’s passenger. Let us know what you think and how you think you can contribute to these goals. Share these ideas amongst your stakeholders. The think tank will have a session dedicated for feedback at the IATA World Passenger Symposium, on Friday 14 October. In addition, ongoing

feedback is welcome and can be sent to passenger@
iata.org

.

As a next step and based on the feedback received, these ideas will be presented to the StB Steering Group and formulated into proposals for the December 2011 IATA Board of Governors meeting.

Tony Tyler, IATA’s Director General, believes passionately that “aviation is a force for good in the world, a force for progress, growth and wealth in both material and human spirit.” Let us work together to build a sustainable future for our industry.

### CONTRIBUTIONS

The following airline delegates are members of the StB Think Tank and were appointed to propose a way forward for Simplifying the Business.

Patrice Ouellette

Director Customer Solutions

& Innovations – Air Canada

Patrice Ouellette joined the e-Commerce/IT department
in 2004 after spending the first 10 years of his career at Air
Canada with the Airport department. He has performed many
roles during that period from an agent check-in to General
Manager Customer Service Eastern Canada, responsible

for all the Air Canada operations at more than 10 airports.

In 2005 he created the Customer Service Platform
within Air Canada taking the responsibility for the self

service applications and Customer facing Airport innovations.
His team has lead the introduction of many innovations like

mobile applications for smart phones, mobile check-in, the
electronic boarding pass and a complete re-architecting of the

Kiosk and Web Check-in Self Service product .The CSP team

introduced self tagging in selected stations and smart drop a

quick baggage drop off solution for airport.

He is currently Director Customer Solutions and Innovations
within the IT department. The role consists of developing new

and maintaining actual customer facing application and at the
same time promoting and often demonstrating the use of new

and innovative technologies direct into the business.

Matthias Koch

Director Research and

Development – Air France

Director Research and Development Passenger Ground
Experience in the Marketing Department of Air France
and KLM, has been working in the airline industry for over

twenty years. He has a strong background in the Marketing,
Sales, Revenue Management, Pricing and Ground Services

aspects of the airline business with a particular emphasis on

Innovation and Product Development.

Working today on new business solutions and the future

travel experience on the ground he is also a member of the Rob Broere
Vice President IT – Passenger
Services Systems & Passenger

Experience – Emirates

Rob Broere, who originates from the Netherlands, started
his career in 1981 at KLM working on the IT side of the RES/
DCS system. He has always been involved in the core airline
systems and during his career of over 30 years supported

many airlines across the world with their systems. He joined

Emirates in 1995 and is as Vice President IT – Passenger
Services Systems & Passenger Experience, responsible
for the running and expanding the Passenger systems and
driving forward the customer experience from an IT point of
view. He combines his knowledge of the Airline Industry with
the knowledge of what IT can do and uses that to support
the airline driving forward the customer experience. In 2010
he joined the IATA StB Steering Group and was appointed
Chairman of both the Steering Group and IATA StB Think
Tank with as aim driving forwards the industry.

Glen Morgan

Head of Service Transformation –

British Airways

Glenn is seen as a thought leader in the travel, aviation, &

technology sectors, plugged into emerging digital trends and
innovation in behavior and technology. If it's new, cutting edge
and interesting, Glenn can tell you how to exploit it. Glenn has
worked across range of industries where IT is a boardroom

issue, including telecommunications, utilities, oil and gas,

government, and airlines and prior to his current role, was
Technology & Service Partner at British Airways Plc.

As Head of Service Transformation, Glenn will develop and
refine the business strategy by understanding market trends,

develop external customer insight and business innovations,

seek opportunities for competitive differentiation and reengineer

and develop new sales and distribution channels. Prior to his

current role, Glenn worked in Dubai, UAE for Emirates Airline.
Glenn holds a Black Belt in Six Sigma from GE and is also a

specialist Lean Practitioner.IATA Simplifying the Business Steering Group and the recently

created IATA Think Tank. Based today in Paris, Matthias has
lived and worked in countries like Germany, Venezuela and

Mexico.

Todd Grace
Strategy Manager –

Air New Zealand

Todd is currently working as a Strategy Manager in the
area of Strategic Development at Air New Zealand. His role

focuses on our airport business, in particular operations,

service development and airport company commercial

relationships.

He is responsible for identifying areas for creating value
in airports through effective use of technology, strategic

partnerships and improved operating and customer service
processes. It also focuses on managing the commercial

relationship between the airline and the airports and inputting

into the charging process as required by legislation.

The role entails delivering travel solutions for our customers,

and developing a suite of innovative products and services

based on our customer’s needs. This has seen the development
and implementation of Air New Zealand’s self service product
for New Zealand airports including the use of mobile and NFC

technology.

Strategic Partners

The following delegates were appointed by their

companies, which are IATA Strategic Partners, to advise

IATA on the implementation of strategic initiatives.

Daniel Friedli

Hewlett Packard

Daniel Friedli, a Swiss and Canadian national, joined
the airline industry in 1998 as a TPF trainee for Atraxis,
the Swissair IT subsidiary. After several years of TPF

development in the Reservations and Ticketing areas, Daniel
himself led training for TPF developers in South Africa for

several months, passing on extensive domain knowledge.
Transitioning to EDS with the rest of Atraxis, he started working on strategic and pursuit related projects. In that time

, he also started his engagements in several IATA groups to
help define industry standards. In 2006, Daniel decided to
widen his domain knowledge and and move from the system
provider side to the airline. He joined Swiss International
Air Lines, albeit still on the IT side of things. At SWISS,
Daniel focused on large, strategic projects such as the

implementation of interline ETKT, Star Alliance collaboration

as well as developing strategies around mobile device usage
and the value and need of next generation PSS systems. In

2010, Daniel decided to take a challenging role with HP at
the forefront of defining HP’s new PSS product. In this role,
he currently also represents HP at industry conferences and
working groups such as the IATA StB Think Tank as well as
in customer facing roles supporting the existing HP airline

community as well as potential new business.

Eric Conrad

Leader IBM’s Global Travel &

Transportation Industry – IBM

Eric Conrad leads IBM’s Global Travel & Transportation
Industry comprising, Air Travel Related Services, Freight &

Logistics, and rail.

Across his 25+ year career, the last 16 of which have been
in Asia Pacific, Eric has gained extensive, direct experience
in creating business value for Travel & Transportation clients,
working across the United States, Europe, and in many Asian
economies such as Malaysia, Singapore, Indonesia, Thailand,
the Philippines, Vietnam, Korea, Japan, Hong Kong, China,

Australia and India.

Working with some of the most prestigious global airlines,
Eric has been able to create significant client benefits
through major multi-year partnerships with IBM focused
upon technology-driven transformation. His transformation
work has effectively linked strategic planning to business

and operational planning, all the way through to technology

deployment.

Eric has an MBA in International Business (1st in Class)
from the University of Connecticut, USA. He graduated with

a Bachelor of Science ( Business Administration) from the
University of Delaware, also in the USA .John Thomas

Vice President – LEK

John Thomas is a Vice President at L.E.K. Consulting
and heads L.E.K.’s global Aviation & Travel practice. John
has more than 21 years experience in strategy, financial,

commercial, operational and organizational consulting to
the aviation industry and has worked with most of the
leading airlines around the world (both legacy and LCC) on
a broad range of major issues e.g. he has been instrumental

in the adaptation of merchandising (ancillary revenue) to
the airline industry, and has advised on many of the major

merger and acquisition deals in the industry.

John Thomas has also worked with OEMs, CNS/ATMs,

airports, tour operators, travel destinations, cruise lines,

hotels, resorts, loyalty programs, caterers, as well as having
extensive experience in the GA and Corporate Aviation

industries. He has worked with clients in North and South
America, Europe, the Middle East and the Asia Pacific region. Vijay Anand

Senior Director, Industries

Business Unit – Oracle

Vijay Anand is the Senior Director at Oracle Corporation’s
Industries Business Unit and the Global Industry Lead for
Travel, Transportation & Logistics Industries. Vijay has over
20 years of experience across Transportation Industries IT
Solutions and Consulting. Prior to joining Oracle Corporation,
he was part of SITA for 8 years in the capacity of Solutions

Director.

Vijay has a graduate degree in Science specializing in
Physics (Applied Electronics) and MBA from Canadian
School of Management, in addition to Project Management
Professional (PMP) qualification. He is an active member
of the Project Management Institute, American Association
of Airport Professionals, Singapore Computer Society and

Singapore Quality Institute.

Copyright © 2011 Hewlett-Packard Development Company, L.P. In an instant-on world where everything is connected, the airline industry must elevate productivity and efficiency to remain competitive. With more than 9,000 travel and transportation industry specialists, HP keeps your business flying high. We provide a wide array of technology products and services to help airlines, airports, travel services, and hospitality companies—even freight and logistics businesses—take off in new directions.

hp.com/enterprise/transportation 

# LIFT

your airline business to new levels.

WELCOME TO

**I N** 

**STANT-ON A**  **IRLINES**

.to learn more, visit www.lek.com/industries/airlines 

# L.E.K. DELIVERS UNMATCHED VALUE

TO THE WORLD’S LEADING AIRLINES

Succeeding in aviation demands strategic vision, sound data and

superior execution.

L.E.K. Consulting is the leading strategic advisor to the global airline industry. We

understand the market’s unique challenges, and we don’t just advise. We partner with

our clients to help them address their big challenges and make the best decisions.

We provide solid strategic answers that you can count on. And we have a strong track

record of demonstrated success to prove it.

twitter.com/lek_consultingCopyright © 2009, Oracle. All rights reserved. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. 

# 2 0 of th e 2 0 

# Top Airlines

oracle.com/goto/airlines

or call 1.800.ORACLE.1 

## Get Better Results With Oracle 

# Oracle Travel & Transportation

IND_Tra_TopAirlines_2305

# www.iata.orgJPSC/31 PSC/33 Oct 11

Attachment: D Page: 1 of 1

Passenger Distribution Group (PDG)

Terms of Reference

The Passenger Distribution Group is established by the Passenger Services Conference (PSC) to with the following terms of reference.

Objectives

• Set a vision for multi-channel airline distribution

• Validate the strategy and industry business case and requirements

• Act as an industry voice on airline distribution

• Define key industry messages for distribution-related matters

• Review progress of IATA projects in distribution

• Act as a watch group on industry developments

• Be the central provider of industry informational and statistical data

Appointments

• This is a group comprised of IATA member airlines; non-member airlines may receive a special appointment by IATA SVP IDFS

• Delegates are airline director-level or above in charge of airline distribution or distribution system strategy; there are no alternates

• Industry stakeholders may be invited to attend meetings upon invitation by

IATA SVP IDFS

Schedule

• annual in-person meetings at IATA’s Head (Montreal), Executive (Geneva), or Regional offices

• Regular calls (monthly or quarterly)

• Meeting agendas shall be circulated in advance of each meeting for review and comments by delegates, the Chairmen of the PSC Steering Group and the StB Steering Group. Minutes shall be taken at each meeting and circulated among the delegates for review, comment, and approval.

Technical sub-groups 1. The PDG may create technical sub-groups to address specific issues and business requirements, for example requirements to develop new schemas or rules and tools. Such sub-groups will be coordinated with the secretariat of the PSC and/or the Passenger Agency Conference (PAConf).

Administrative

• The PDG will have a one year mandate (renewable as required) and will report to the PSC with any proposed technical improvements, recommendations and an industry standards implementation plan.

• During the year the PDG will provid e regular progress re ports to the PSC Steering Group and the StB Steering Group

• The group will coordinate its activities with other industry groups involved in

airline distribution

• The Secretary is the IATA Director Passenger ( leopolde@iata.org )JPSC/31 PSC/33 Oct 11

Attachment: E Page: 1 of 1

INVOLUNTARY REROUTING WORKING GROUP

TERMS OF REFERENCE

An Involuntary Rerouting Working Group (IRWG) is established with the following

Terms of Reference:

1. Perform a complete review of current IATA and ATA industry standards related to involuntary rerouting.

2. Identify outdated and/or conflicting processes, within the IATA and ATA standards and perform a comparison between them.

3. Identify the main differences to determine best practices from both resolutions

4. Liaise with other industry groups with potential impact for gaining intellect including (but not limited to) revenue accounting, tariffs, reservations, airports.

5. Develop a common approach for re-ticketing in the case of planned schedule changes.

6. Prepare agenda item(s) as necessary to promote quick and efficient involuntary rerouting processes both unplanned (i.e. Irregular operations) scenarios and planned schedule changes.

7. Report findings and/or proposals to the Ticketing Committee (JPTC).

PARTICIPANTS

Volunteers from the JPTC, RESWG and RAWG who have indicated their participation.

REPORTING STRUCTURE/MANDATE RESTRICTION

The working group will have a mandate for 1 year. All activity of the working group will be fully communicated to JPTC for disc ussion. A report will be submitted to the JPSC with recommendations and proposals.JPSC/31 PSC/33 Oct 11

Attachment: F Page: 1 of 1

AIRPORT SERVICES COMMITTEE (ASC) MEMBERSHIP 2012

Airport Services Committee (ASC) Membership 2012

Airline Traffic Conference Area Term of Office Expires

Air France 1 2012

Alitalia 2 2013

American Airlines 1 2014

British Airways 2 2012

Delta Airlines 1 2014

Egyptair 2 2013

El Al 2 2013

Iberia 2 2014

Japan Airlines 3 2013

KLM 2 2012

Lufthansa (Vice Chairman) 2 2012

South African Airways 2 2014

United Airlines 1 2012

vacant

vacant

vacant

vacant

VacantJPSC/31 PSC/33 Oct 11

Attachment: G Page: 1 of 1

ATA/IATA Baggage Working Group (BWG)

Terms of Reference

The Baggage Working Group (BWG) shall:

• report to the Airport Services Committee (ASC);

• Review and develop messages for baggage handling and bag tag construction (for example, but not limited to, Resolutions 740, 741,
742, 742a, 743, 743a, 746, and RPs 1740a, 1740b, 1740c, 1740d, 1740e, 1743d, 1743e, 1744, 1745, 1751, 1800);

• Note that procedures regarding self-service processes pertaining to baggage will be handled by the PEMG (RP 1701 series);

• Review and develop recommendations on baggage processes;

• Review and improve relevant Resolutions and RPs with respect to reducing interline baggage mishandling as regards to baggage messages, and bag tag construction as described in Resolution 740;

• Identify any cross-functional issues related to baggage messaging that need to be resolved outside the BWG, for example by the Passenger Experience Management Group (PEMG);

• Align and cooperate with other industry working groups relating to baggage messaging issues;

• Utilize electronic and/or other means of communication wherever possible and meet only when necessary. Such formal meetings should not exceed two per year;

• Forward proposed amendments to current ATA/IATA Resolutions and

Recommended Practices as well as new submissions to the ASC for adoption by the PSC;

• Consist of representatives from ATA/IATA carriers, airports participating in the IATA Airport Advisor Programme and participants in the IATA Strategic Partners programme with an interest in baggage
management.

The IATA contact for BWG matters is the IATA Head, Baggage Services (pricea@iata.org)JPSC/31 PSC/33 Oct 11

Attachment: H Page: 1 of 2

Baggage Steering Group (BSG)

Terms of Reference

The BSG is established by the PSC with the following terms of reference:

To develop, maintain and communicate a baggage vision, taking from and adding to the Vision 2050 work of IATA and working closely with the PEMG;

To be the owners of baggage processes, technology and data from the point of baggage acceptance by the airline (i.e. the point at which the airline takes physical control of the bag) to the point of return of the bag to the passenger;

To determine a plan for the delivery of that vision at an industry level;

To determine how industry wide measures and performance targets for baggage handling can be developed and captured.

The group shall meet 4 times per year, using technology as appropriate to minimize travel, but at least 1 meeting will be face-to-face.

Periods of membership

Airlines are invited to join the group by the PSC. This group is set up to be small and dynamic, and thus membership is limited to 10 airlines. The representatives of each airline must be senior members of their airline’s management team. Airlines join the group for a period of 2 years, after which they may be re-elected for a further periods of 2 years up to a maximum of 6 years.

Airports may be invited to join the group in an advisory capacity for a period of 2 years with the same renewal conditions. Airport members are chosen from the IATA Strategic Partnership Programme by IATA as necessary. Airport membership is limited to 3 airports.

Failure to attend more than 2 consecutive meetings will result in the representative being asked to step down, unless good cause is provided.

The IATA contact for Baggage Steering Gro up is the IATA Head, Baggage Services ( pricea@iata.org )JPSC/31 PSC/33 Oct 11

Attachment: H Page: 2

BSG Membership

Name Airline E

‐ Mail

Airlines

Darphin, Mikaël Air France midarphin@airfrance.fr

Rick Nagy Alaska Airlines Rick.Nagy@AlaskaAir.com

Harvey Tate British Airways harvey.tat@ba.com

Cunningham, Dede Continental Airlines dede.cunningham@coair.com

Hosford, D. Delta Airlines <david.hosford@delta.com>

Schut, Jaap KLM Jaap.Schut@KLM.COM

Michael Harwerth Lufthansa German Airlines micha.harwerth@dlh.de

Scott Speers Qantas Airlines sspeers@qantas.com

TBA South African Airways

Phil. Ryan US Airways <Phil.Ryan@USAirways.com>

Airport Advisors

Mark van Gaalen Amsterdam Schiphol Airport <gaalen@schiphol. nl>

John Shepperd British Airports Authority john_shepperd@baa.com

David Bourgon McCarran Las Vegas Airport <davidb@mccarran.com>JPSC/31 PSC/33 Oct 11

Attachment: I Page: 1 of 1

DCS Messages Working Group (DCSMWG)

Terms of Reference

Evolving standards that impact DCS messaging require that DCS experts meet with the following terms of reference, which set out the objectives and scope of the DCS Message Working Group (DCSMWG).

The Working Group will:

• review, amend, and synchronize DCS messages in Recommended Practices 1707-1719d with the work in other, associated IATA passenger and baggage working groups, such as the Reservations Committee and the Joint ATA/IATA Passenger Ticketing Committee;

• monitor and support industry security related activities to include APIS requirements and AVSEC/WG;

• continue to refine and update the documentation of DCS messages in Recommended Practices 1707-1719d to fully utilize the DCS Message Dictionary and Message Directory documented in Recommended Practices
1707, 1707a and 1707b;

• continue to review the editorial process of the DCS messages and continually edit them for precision;

• seek expanded airline participation in the DCSMWG by experts in all applicable channels;

• report their progress to the Airport Services Committee (ASC) once a year and seek approval of their work for subsequent submission to each year’s

PSC.JPSC/31 PSC/33 Oct 11

Attachment: J Page: 1 of 1

Multi-channel Merchandise Sales an d Delivery Task Force” (MMSDTF)

Terms of Reference

A new task force is established by the Passenger Services Conference (PSC). It is named the “IATA Multi-channel Merchandise Sales and Delivery Task Force” (MMSDTF). The objectives are to:

1. Identify the business requirements for maki ng sales of airline products and services (defined as “merchandise”) from multiple s ources, such as agents, kiosks, internet,
data devices, etc. 2. Create standards that facilitate the sales of merchandise by a carrier’s own representatives and by third-party sales c hannels, such as brokers or third-party ground handlers. 3. Consider functionality for product availability displays and product pricing. 4. Consider product sales and delivery fo r the host carrier and interline partners. 5. Create standards that facilitate the delivery of merchandise to all appropriate venues, including departure or arrival airports, in-fligh t, home delivery, or electronic fulfillment. 6. Consider procedures for sales with i mmediate delivery and those that have later delivery. 7. Consider procedures for sales and delivery that are flight-related (delivery on-board) and those that are not flight-related (delivery independent of a flight). 8. Create standards for proof of purchase and for proof of delivery. 9. Create standards for failure of delivery (incl uding irregular operations), with a process for refund, subsequent re-use, re-booking or compensation. 10. Create or modify standards for merchandizing lists (such as PNL/ADL, catering lists, store room, in-flight manifests) to advise appropriate offices/personnel for timely merchandise delivery and inventory control. 11. Utilize available communications modes (such as XML, EDIFACT, and teletype) with the EMD source-application, appropriate for each functional scenario in sales, delivery and reporting. 12. Utilize the industry’s structure for EMD (Electronic Miscellaneous Documents) as a

sales and revenue record. 13. Utilize the EMD as a tracking record for status and usage, such as ‘used, refunded, or expired’. 14. Be mindful of new and emerging technologi es and devices that can be utilized to

make sales of airline merchandise.

An invitation to participate in the MMSDTF sh all be extended to cross-disciplinary personnel from airlines and Partner Companies who are experts in every aspect of airline merchandizing, sales and delivery, including: 1. Departure control 2. Revenue management and accounting 3. Product marketing 4. EMD source-application (such as RES) 5. Airport operations

The MMSDTF directs the business practices and general execution of airline merchandizing. The MMSDTF liaises with other, related worki ng groups in the execution of new or amended standards and practices. Meetings take place at least twice a year, and more frequently, if needed. The group develops recommendations in the form of amended or new Resolutions and Recommended Practices. The MMSDTF reports directly to the Passenger Services

Conference.JPSC/31 PSC/33 Oct 11

Attachment: K Page: 1 of 1

TICKETING COMMITTEE (PFPC) MEMBERSHIP

Airline Traffic

Conference

Area Year Term of Office Expires at Conclusion of Passenger

Services Conference:

Air Canada 1 2014

Air France 2 2014
All Nippon Airlines 3 2014

American Airlines 1 2014 British Airways 2 2013

Continental 1 2014

Delta Air Lines 1 2012* Egyptair 2 2013

El Al 2 2014

Emirates 2 2013
Japan Airlines 3 2012*

KLM 2 2013

LAN 1 2012*

Lufthansa 2 2013

SAS 2 2012* South African Airways 2 2014

United Airlines 1 2014 US Airways 1 2013

* Expires at the conclusion of PSC 2012NameofProject112 January2012(JPSC 2011Attachment M)Expert Advisory TaskForceAdvancing IATA Messaging standards inthe passenger services areaObjectives and methodologyÊObjectivesÊDetermine the industry requirements,drivers and barriers fordata exchangestandardization activities, and recommendthe scope and the nature of standardsneeded and the priorities fortheir developmentÊtechnology, process, how deep, maintaining message schemas ordataobjects, airline orITvendordriven development, relations withotherstandards organizations..ÊMethodologyÊIATA staff to write a white paperhighlighting key questions andproposingindustry approach to addressing them, the white paperwill be complemented byan industry survey on key topics.ÊThe Task Force will review the whitepaperand, taking into account theinformation gathered during the survey, recommend actions and priorities.Expected timelines2011JPSC2012JPSCExpert viewsExpert viewsRecommendationsRecommendationsWhite paperWhite paperImplem. planImplem. plan29 December2011NameofProject309/1109/1110/1110/1111/1111/1112/1112/1101/1201/1202/1202/1203/1203/1204/1204/1205/1205/1206/1206/1207/1207/1208/1208/1209/1209/1210/1210/1211/1211/1212/1212/12ExpertAdvisoryTFPublicity&communicationsRecruitmentRecruitmentIndustrysurveyIndustrysurveyFormulatingstandards (content tbc)Formulatingstandards (content tbc)AnnouncesurveyAnnounceTFresults/governanceMeeting 1Meeting 2Meeting 3(tbc)StandardsdevelopmentMembership and skillsetsÊ5 airlinesÊTraditional network carrierÊLCCÊAsian (booming market)carrierÊ2 IT suppliersÊLegacy providerÊSubstantial but newcomerwith nolegacyÊ1-2 airportsÊ1-2 standards expertsÊInternet/web technology,ÊIndustry standardsÊAirframer?ÊAirline distribution commercial trendsÊAirline operations trends (i.e. EFB,slots, )ÊAirport operations trendsÊLegacy systems operationsÊLarge scaleÊStandards developmentÊInternet/web technology trendsÊIndustry standardsÊSESAR and NextGenDataArchitectureÊCorporate IT ArchitectureÊIndustry standards (OpenAXIS,OPENTRAVEL)ÊAircraft communications technologyJPSC/31 PSC/33 Oct 11

Attachment: N Page: 1 of 1

Schedules Information Standa rds Committee (SISC)

Terms of Reference

The Schedules Informati on Standards Committee (SISC) is established by the IATA Passenger Services Conference (PSC) with the following terms of reference:

• Develop and maintain a se t of common standards for t he exchange of schedule data, including industry standard code sets for a variety of schedule related data
elements;

• Review and propose amendments to SSIM Appendix A (ATA/IAT A Aircraft Types); Appendix D (Passenger Terminal Indicators); Appendix F (UTC — Local Time Comparisons) and Appe ndix I (Region Codes);

• Disseminate and encourage the use of common schedule data handling procedures and standard formats for the exchange of schedule information as published in the Sta ndard Schedules Inform ation Manual (SSIM);

• Liaise with other IATA committees and wo rking groups, in part icular the Schedule Policy Working Group (SPWG) as well as other organizations as appropriate to meet changing industry requirements and to further the objectives of the SISC;

• The Joint Schedules Advisory Group (JSAG) will ensure fo rmal liaison between the airport coordinator community and SISC;

• SISC will provide an annual report to the PSC comprising all proposed and adopted changes to SSIM. In addition a wr itten report of the work of SISC will be made to the Heads of Delegation Meeting of the regularly scheduled IATA Schedules Conferences;

• The PSC will be responsibl e for final endorsement of pr oposed changes to SSIM;

• Participation is by schedules specialists from IATA airlines and industry experts in the IATA Strategic Pa rtnership programme;

• A rapporteur will be established to provide liaison for non-IATA airlines participating in the Schedules Conference;

Airport Coordinators participating in the IATA Schedule Conference are invited to participate in SISC.JPSC/31 PSC/33 Oct 11

Attachment: O Page: 1 of 3

Executive Summary

FPWG – Fraud Preven tion Working Group Minutes of 21 September 2011 Conference Call

Theme ‘Redefining and Reengineering IATA’s Fraud Prevention Activity’

Member Participants: UA/CO, BA, LH, NZ, AA,

Partners: ARC IATA Staff from Passenger Interline Stan dards, Passenger Agen cy, Risk Management, Credit Card Services and Cargo.

Objective: Reason for the Call

It has been a considerable time since the FPWG had the oppor tunity to discuss industry

fraud issues and this has not gone unnoticed by our Members. Ma ny have felt frustrated by the lack of coordinated attention to fraud prevention activities at a global level. Since

the advent of 100% ET and the closure of the TICKETS database, IATA activity has focused mainly on credit card fraud prev ention which has been ha ndled by IATA Card

Services.

IATA’s senior managemen t has requested that we take a fresh look at redefining and re-energizing IATA's role in fraud prevention. Ultimately we may conclude that IATA's

role should sit more within our financial services area rather than the passenger

services area.

Main Outcome & Conclusions

Ò There has been no full time employee look ing after IATA’s fraud prevention activity for a number of years

Ò Perception in IATA that since 100% Elec tronic Ticketing fraud would go away which

is not true

Ò IATA is dealing with the credit card fraud issue quite well as there are resources for

that and IATA has also enco uraged use of the Perseuss system for cr edit card fraud information sharing

Ò So much more fraud that is not being dealt with which has become diverse and has many guises and methods of operation.JPSC/31 PSC/33 Oct 11

Attachment: O Page: 2

Ò Areas of fraud that are concerning Members at the moment are;

o Internet based crime and e-commerce

o Fake travel agency websites that purpo rt to sell travel (often against cash payment)

o Solicitation email scams (asking for tickets, payment of fake invoices)

o Internal employee fraud

o Frequent Flyer abuse and brokering schemes

o Agency fare abuse

o Cargo false claims, invoicing and air way bill tampering (falsifying weights)

o Falsified or bogu s baggage claims

Ò Feeling that the fraud prevention community is isolating itself and has no natural place to communicate and sh are issues on global basis

Ò Often internally different aspects of fraud are dealt with in th e relevant business

areas if at all.

Ò No information exchange, extranets out of date, self-defeating since there is a feeling that no one is posting anything so no one looks at it

Ò Biggest tool to prevent fraud is communi cation, alerts and information sharing and

whilst Members have done thin gs on regional basis, ther e has been no coordinated activity at the global level and Members felt they have largely been left on their own.

Ò Members felt it would be good as a base st ep to document differe nt types of fraud

and break them down in to separate distinct pieces, then determine who owns the

issue to be resolved.

Ò In the USA ARC reported th ey had seen a reduction in hacking and credi t card fraud in favor of accessing the ticketing systems and taking cash payments. They had

worked and continue to work with ticketing systems to prevent abuse. They also

have their forums to discuss ‘fraud from everywhere’

Conclusion It is evident that there are many different flav ors and guises of fraud with many different modes of operation. Fo r some fraud, such as in the credit card area, there is clearly some strong activity but in other types of fraud there are different levels of expertise required. For example having the knowledge to know how to go to banks, internet service providers, and email companies to get them to close the fraudsters down.JPSC/31 PSC/33 Oct 11

Attachment: O Page: 3

Profile of Future Activity

Ò Members acknowledged that fraud prevention does not sit well any where within the IATA governance st ructure but felt that finance was possibly one area where it would be best placed, particularly if there wa s to be a wider remit including cargo and baggage.

Ò IATA was asked if there was something that could be set up specific ally to deal with frequent flyer brokerage fr aud. There had been a sub group deal ing with these issues in the past.

Ò Fraud prevention n eeds to be coordinated with a global group and not just on regional basis. Gl obally the fraud prevention commun ity needs to get together to discuss issues such as those raised in this paper

Ò Someone needs to take the lead in coor dination and facilitation. It is IATA Member carriers that are being hurt and as such IATA should not think they cannot do anything because it is not affecting an IATA agent. As it is IATA’s Members that are being affected it is in IATA’s remit to coordinate these activities.

Ò Create a forum for the exch ange of ideas and experiences and to look at how this whole topic can be divided up into appropriate pieces which can then be allocated

within the IATA framework.

Ò Making a list of all t hese areas of fraud will give an overall scope and it will soon be clear which are the big topics (we have one of them with credit card), that way they will not get mixed up with other types of fraud

Ò A dedicated resource should be assigned to kick start the re-engineeri ng process. Up to now there has been no coordinati on and Members have been left on their

own.
Ò Profile of any indi vidual tasked with fraud preventio n should be someone who has a fraud prevention background. They should have the skills to quantify the fraud and

reach out to the different areas which then helps with defining what resources are

needed.

Ò The business case for resources can be dev eloped by looking at recent surveys that

have been published.

Conclusion

Members valued the start of this consultation process, in contrast to previous attempts at re-engineering. Fraud is varied and evolving and IATA needs to look at positioning

itself to coordinate and lead this activi ty with a dedicated resource and look at positioning this in the appropriate bu siness area.JPSC/31 PSC/33 Oct 11

Attachment: AA Page: 1 of 1

IATA Reservations Committee Membership

Airline TC area Year Term of Office Expires

Air France (AF) 2 2013

Air Canada 1 2013

All Nippon Airways (NH) 3 2012

British Airways (BA) 2 2014

Delta Air Lines (DL) 1 2012

Egyptair (MS) 2 2014

El Al (LY) 2 2012

Emirates (EK) 2 2014

Etihad (EY) 2 2014

Finnair (AY) 2 2012

Iberia (IB) 2 2014

Japan Airlines (JL) 3 2012

KLM (KL) 2 2012

Lufthansa (LH) 2 2013

Scandinavian Airlines System (SK) 2 2012

South African Airways 2 2014

United Airlines (UA) 1 2012

US Airways (US) 1 2014JPSC/31 PSC/33 Oct 11Attachment: BBPage: 1 of 1TopicProgressNext StepsAction byTarget Date1 AIRIMP Audit and Clean-up Ongoing itemPhase 1 is completeFuture RESWG and ResCom meetings asappropriate. Suggestions: email to IATA.All2 TSA Secure Flight Program Add passives section to AIRIMP KL JPSC3 Fixed Request FixedReply/Cancel as Free TextRESWG/14 agenda item 7 Secretary RESWG/174 SSRs Matrix Matrix updated to identify exceptions andnew section 3.24 establishedMore radical re-arranging of verbiage withinAIRIMP to be studied. Draft has beendeveloped by AmadeusSecretaryAmadeusJPSCRESWG/175 Additional services –increase number in partySubmitted to RESWG/14 by Amadeus Comments to be sent to Amadeus Amadeus RESWG/176 Bilateral SSRs Item finalized at RESWG/16 Secretary JPSC7 Credit Card as FOID Item finalized at RESWG/16 Secretary JPSC8 Service PNR Message RESWG/15 agenda item 12 was agreedSecretary JPSC9 Editorial Repairs to AIRIMP Item finalized at RESWG/16Secretary JPSC10 Self Service FlightRebooking for InvoluntaryReroutingRESWG/15 agenda item 14.The Fast Travel Group is developing a RPfor Self Service Flight Rebooking forInvoluntary Rerouting and requested inputfrom the Reservations Working GroupSITA to liaise with the 2 groups to assist in thedevelopment of the RPSITA JPSC 201111 Explanation in AIRIMP ofreceiving KK replymessages on SSRs forwhich no previous requestcould have been sentAmadeus/KLMJPSC12 Additional Services Changes to 3.21. to allow HS to be sentwithout a previously received KDSecretary JPSC13 Fixed arm rest characteristic– Seat maps and requestsResCom/23 developed the LY proposal Find outwhat LY wants to do and find out whatcode can be used. Can consider mail vote.El Al RESWG/1714 Re-write 3.19 – advanceboarding passesBA/1A RESWG1715 Add Military ID (M) Check with ICAO to see if this code isplanned for ICAO 9303IATA to check with ICAO SecretaryJPSC/31 PSC/33 Oct 11

Attachment: CC Page: 1 of 6

2.11.6.7 SSR Matrix and ATA 105.175

SSR Code Action Code Reply Automated

Format Free Text in Request Free Text in Reply/Cancel Reference

ADMD Not permitted Not permitted Not permitted Mandatory

See 3.1.23 Not permitted See 3.1.23

ADPI Mandatory Not Permitted Not Permitted Mandatory Not Applicable See 3.13.4

ADTK Not permitted Not permitted Not permitted Mandatory Not permitted Bilateral

See3.1.14

AOXY (4) Mandatory Mandatory Mandatory Optional Optional Bilateral See

3.7.7 ASVC Mandatory Mandator y Mandatory Mandatory

Fixed Request Mandatory

Fixed Reply/Cancel Bilateral See

2.11.6.6 and 3.21

ASVX Not permitted Not permitted Not permi tted Not permitted Not permitted See 9 AUTK Mandatory Required Not permitted Not permitted Optional Bilateral See

3.11 AVIH Mandatory Mandatory Mandatory Mandatory Optional

AVML (1) Mandatory Mandatory Mandatory Not permitted Not permitted

BBML (1) Mandatory Mandatory Mandatory Not permitted Not permitted

BIKE Mandatory Mandatory Mandatory Optional Optional

BLML (1) Mandatory Mandatory Mandatory Not permitted Not permitted

BLND Mandatory Mandatory Mandatory Optional Optional

BSCT Mandatory Mandatory Mandatory Not permitted Not permitted

BULK Mandatory Mandatory Mandatory Mandatory Optional

CBBG Mandatory Mandatory Mandatory Mandatory Optional

CHLD Mandatory Optional Not permitted Not permitted Optional See 3.17 CHML Mandatory Mandatory Mandatory Optional Optional

CKIN Optional Optional Optional Mandatory Optional See 1.5.5.1 and

1.5.5.2 and

3.24.1 CLID Mandatory Optional Not permitted Not permitted Optional Bilateral See

3.8.3 COUR Mandatory Optional Mandatory Optional Optional

CRUZ Mandatory Optional Mandatory Optional Optional Bilateral See

2.11.6.5 3.24.4 DBML Mandatory Mandatory Mandatory Not permitted Not permitted

DCRW Mandatory Optional Mandatory Optional Optional Bilateral See

3.22.3 DEAF Mandatory Mandatory Mandatory Optional Optional

DEPA Mandatory Mandatory M andatory Optional Optional

DEPU Mandatory Mandatory Mandatory Optional Optional

DOCA Mandatory Not permitted Optional Not permitted Not permitted See 3.13.3 DOCO Mandatory Not permitted Optional Not permitted Not permitted See 3.13.2 DOCS Mandatory Optional Optional Not permitted Not permitted See 3.13.1

DPNA Mandatory Mandatory Mandatory Mandatory OptionalJPSC/31 PSC/33 Oct 11

Attachment: CC Page: 2

EPAY Mandatory Mandatory Not permitted Optional Optional Bilateral See

3.14 ESAN Mandatory Mandatory Mandatory Mandatory Opti onal Bilateral ETLP Not permitted Not permitted Not permitted Not permitted Not permitted Reserved for

DCS RP1707b

3.24.2 RP1708

2.12.6.9

RP1719d 3.1 EXST Mandatory Mandatory Mandatory Mandatory Optional

FOID Mandatory Not Permitted Not Permitted Mandatory Not permitted Bilateral See

3.10

FPML (1) Mandatory Mandatory Mandatory Not permitted Not permitted

FQTR (3) Mandatory Optional Not permitted Optional Optional Bilateral See 3.8.1 – Option 1

FQTR (3) Mandatory Optional Mandatory Optional Optional Bilateral See 3.8.2 – Option 2

FQTS (3) Mandatory Optional Not permitted Optional Optional Bilateral See 3.8.1 – Option 1

FQTS (3) Mandatory Optional Mandatory Optional Optional Bilateral See 3.8.2 – Option 2

FQTU (3) Mandatory Optional Not permitted Optional Optional Bilateral See 3.8.1 – Option 1

FQTU (3) Mandatory Optional Mandatory Optional Optional Bilateral See 3.8.2 – Option 2

FQTV (3) Mandatory Optional Not permitted Optional Optional Bilateral See 3.8.1 – Option 1

FQTV (3) Mandatory Optional Mandatory Optional Optional Bilateral See 3.8.2 – Option 2 FRAG Mandatory Mandatory Mandatory Mandatory Mandatory

FRAV Mandatory Not permitted Not permitted Not permitted Not permitted See 3.1.8, 3.2.4

and 3.2.5

GFML (1) Mandatory Mandatory Mandatory Not permitted Not permitted

GPST Mandatory Mandatory Mandatory Optional Optional See 3.1.9 and

3.19.12 GRPF Optional Optional Not permitted Optional Optional See 1.5 GRPK Mandatory Optional Mandatory Mandatory Optional Bilateral GRPS Optional Optional Optional Optional Optional See 1.5, 3.2.8,

3.5 and 3.6 HNML Mandatory Mandatory Mandatory Not permitted Not permitted

INFT Mandatory Mandatory Mandatory Mandatory Optional See 2.6.15 and

3.16 IROP Mandatory Not permitted Not permitted Optional Not permitted Bilateral See

3.18 KSML Mandatory Mandatory Mandatory Not permitted Not permitted

LANG Mandatory Optional Mandatory Mandatory Optional See 3.24.2 LCML Mandatory Mandatory Mandatory Not permitted Not permitted

LFML (1) Mandatory Mandatory Mandatory Not permitted Not permitted

LSML (1) Mandatory Mandatory Mandatory Not permitted Not permitted

MAAS Mandatory Optional Mandatory Mandatory Optional

MCOA Mandatory Not permitted Optional Mandatory Not permitted Bilateral MEDA Optional Optional Not permitted Mandatory Optional See 3.7.7 MEQT Mandatory Mandatory Mandatory Mandatory Optional Bilateral See

2.11.6.3 and

2.11.6.4 MOML Mandatory Mandatory Mandatory Not permitted Not permittedJPSC/31 PSC/33 Oct 11

Attachment: CC Page: 3

NAME Not permitted Not permitted Not permitted Mandatory Not permitted See 3.5.2 and

3.6.3 NLML Mandatory Mandatory Mandatory Not permitted Not permitted

NOML Mandatory Optional Mandatory Not permitted Optional See 3.1.22 NRSB Mandatory Not permitted Not permitted Not permitted Not permitted Bilateral, See

3.22.1 NSSA Mandatory Mandatory Manda tory Not permitted Optional

NSSB Mandatory Mandatory Manda tory Not permitted Optional

NSSR Mandatory Mandatory Mandatory Optional Optional Bilateral NSST Mandatory Mandatory Mandatory Optional Optional

NSSW Mandatory Mandatory Mandatory Not permitted Optional

OTHS Optional Optional Optional Mandatory Optional See 2.11.6.2

3.24.2 PCTC Mandatory Not permitted Not permitted Optional Not permitted See 3.20 PETC Mandatory Mandatory Mandatory Mandatory Optional

POXY (4) Mandatory Mandatory Mandatory Optional Optional Bilateral See

3.7.7 PPOC Mandatory Mandatory Mandatory Optional Optional Bilateral RLOC Not permitted Not permitted Optional Mandatory Not permitted Bilateral See

8.10 or 8.12 RQST Mandatory Mandatory Mandatory Mandatory Optional

RVML (1) Mandatory Mandatory Mandatory Not permitted Not permitted

SEAT Mandatory Mandatory Mandatory Mandatory Mandatory See 3.19 SEMN Mandatory Optional Mandatory Mandatory Optional

SFML Mandatory Mandatory Mandatory Not permitted Not permitted

SLPR Mandatory Mandatory Mandatory Not permitted Not permitted

SMSA Mandatory Mandatory Mandatory Not permitted Optional

SMSB Mandatory Mandatory Mandatory Not permitted Optional

SMSR Mandatory Mandatory Mandatory Optional Optional Bilateral SMST Mandatory Mandatory Mandatory Optional Optional

SMSW Mandatory Mandatory Mandatory Not permitted Optional

SPEQ Mandatory Mandatory M andatory Mandatory Optional

SPML (1) Mandatory Mandatory Mandatory Mandatory Optional

STCR Mandatory Mandatory Mandatory Not permitted Optional

SVAN Mandatory Mandatory Mandatory Mandatory Opti onal Bilateral

TKNA (2) Mandatory Not permitted Mandatory Mandatory Not permitted Bilateral See
3.1.15, 3.1.19

and 8.12

TKNC (2) Mandatory Not permitted Mandatory Mandatory Not permitted Bilateral See

3.1.19 and 8.12 TKNE Mandatory Not permitted Mandatory Mandatory Not permitted Bilateral See

3.1.16 and 3.1.17 TKNM Mandatory Not permitted Mandatory Mandatory Not permitted Bilateral See

3.1.15 TKNR Mandatory Not permitted Mandatory Mandatory Not permitted See 3.1.15 and

3.1.19.5 TKNX Not permitted Not permitted Not permitted Not permitted Not permitted See 9 TKTL Mandatory Not permitted Not permitted Not permitted Not permitted See 3.1.11 and

3.1.12 TLAC Not permitted Not permitted Not permitted Optional Not permitted See 3.12 TWOV Mandatory Optional Mandatory Optional Optional

UMNR Mandatory Mandatory Mandatory Mandatory Optional See 2.6.20JPSC/31 PSC/33 Oct 11

Attachment: CC Page: 4

VGML (1) Mandatory Mandatory Mandatory Not permitted Not permitted

VJML Mandatory Mandatory Mandatory Not permitted Not permitted

VLML (1) Mandatory Mandatory Mandatory Not permitted Not permitted

VOML Mandatory Mandatory Mandatory Not permitted Not permitted

WCBD Mandatory Mandatory Mandatory Optional Optional Bilateral WCBW Mandatory Mandatory Mandatory Optional Optional Bilateral WCHC Mandatory Mandatory Mandatory Optional Optional WCHR Mandatory Mandatory Mandatory Optional Optional WCHS Mandatory Mandatory Mandatory Optional Optional WCLB Mandatory Mandatory Mandatory Optional Optional Bilateral WCMP Mandatory Optional Mandatory Optional Optional Bilateral WCOB Mandatory Mandatory Mandatory Optional Optional Bilateral
WEAP Mandatory Mandatory Mandatory Mandatory Optional See 3.1.21 XBAG Mandatory Mandatory Mandatory Mandatory Optional

.....JPSC/31 PSC/33 Oct 11

Attachment: CC Page: 5

AIRIMP and SIPP

3.24 EXCEPTIONAL SSR PROCESSING

3.24.1 Check-in Information

SSR CKIN may follow either the automated format rules (when passenger & segment associated) or the following formats may be used:

1. Where all members in the itinerary are requested to provide the service for all
segments

SSR CKIN YY HK/CHECK TRAVEL DOCUMENTS

As HK is included in the request, the member does not need to reply.

2. Targeting only 1 member but for all segments pertaining to that member

SSR CKIN BA CHECK TRAVEL DOCUMENTS

As no action/status code was included in the element, no reply can be sent

from the member.

Please also refer to 1.5.5.1/2 for details on cross referencing group bookings with

SSR CKIN.

3.24.2 Provide other information to the member or the booking source

SSR OTHS may either follow the automated format rules or may use one of the following formats:

1. Sending free text information to all members in the itinerary

SSR OTHS YY PASSENGER REFUSED TO PROVIDE PASSPORT DATA

As no action/status code is included in the message, no reply can be sent

from the member.JPSC/31 PSC/33 Oct 11

Attachment: CC Page: 6

2. Targeting all segments for one member:

SSR OTHS BA NN1 PASSENGER ESCORT

Should the request pertain to one or more (but not all) passengers in the itinerary, the following format would be used:

SSR OTHS BA NN1 PASSENGER ESCORT-1MANSART/PASCALE MRS

As the request includes an action code, the member should reply accordingly

SSR OTHS BA KK1 PASSENGER ESCORT

Or

SSR OTHS BA NO1 PASSENGER ESCORT/INVALID REQUEST

3.24.3 Languages spoken by the passenger

SSR LANG may either follow the automated format rules or may use the following

format:

SSR LANG UA HK/MIAJFK0026Y2 9OCT.PSGR SPEAKS ZULU ONLY

Should the request pertain to one or more (but not all) passengers in the itinerary, the following format would be used:

SSR LANG UA HK/MIAJFK0026Y29OCT

- 1MEEKS/JOHN MR.PSGR SPEAKS ZULU ONLY

In all cases, the number in party is replaced by an oblique.

3.24.4 Cruise Passenger

SSR CRUZ uses the following format:

SSR CRUZ DL HK/ATLMIA1125Y09MAY.CARNIVAL CRUISE

As the SSR is for all passengers in the itinerary, the number in party is replaced by the oblique character (/).JPSC/31 PSC/33 Oct 11

Attachment: DD Page: 1 of 3

2.10.6 Additional Services: Non-Segment-Associated

Requests and replies for additional serv ices (non-segment associated) will use auxiliary service element SVC. Additionally, auxiliary service element SVC can be

used to advise the member that an EMD has been issued for a service without having sent a previous request.

2.10.6.1 Element Construction — Request

Components Number and Type

of

Characters Examples

(a) Service Identifier 3 a SVC (b) Airline designator to whom the service is requested (3 character codes are preceded with an oblique) 2 an or 3 a BA

(c) Action code Refer to 3.21.1.2 2 a NN (d) Number of services requested 1 – 3 n 1 (e) Primary Location Code 3 a MAD (f) Secondary Location Code (Optional) 3 a BIO (See Chapter 3

Additional Services –Non-SegmentAssociated-Services) (f) (g) Service date 2 n 3 a 17OCT (g) (h) Reason for Issuance Code (RFIC) (1) (2) 1 an /H (h) (i) Reason for Issuance sub code (RFISC) (2) 3 – 15 an /E23 (i) (j) Commercial Name of Service (2) 1 – 30 an /LOUNGE ACCESS (j) (k) Name (preceded by NM-) Refer to name element paragraph 2.11.6.1(f) (2) /NM1BIGGIN/ANDREW (K) (l) EMD number including coupon number (if applicable) (2) As defined /0061234567890C1JPSC/31 PSC/33 Oct 11

Attachment: DD Page: 2

2.10.6.2 Construction — Reply

Components Number and Type

of

Characters Examples

(a) Service Identifier 3 a SVC (b) Airline designator 2 an or 3 a BA (c) Reply code Refer to 3.21.1.2 2 a KD (d) Number of services 1 – 3 n 1 (e) Primary Location Code 3 a MAD (f) Secondary Location Code (Optional) 3 a BIO (See Chapter 3

Additional Services –Non-SegmentAssociated-Services) (f) (g) Service date 2 n 3 a 17OCT (g) (h) Reason for Issuance Code (RFIC) (1) (2) 1 an /H (h) (i) Reason for Issuance sub code (RFISC) (2) 3 – 15 an /E23 (i) (j) Commercial Name of Service (2) 1 – 30 an /LOUNGE ACCESS (j) (k) Name (preceded by NM-) Refer to name element paragraph 2.11.6.1(f) (2) /NM1BIGGIN/ANDREW (K) (l) EMD number including coupon number (if applicable) (2) As defined /0061234567890C1

(l) (m) Free Text (preceded by a period) 1 – 90 an .LOUNGE AT GATE

43JPSC/31 PSC/33 Oct 11

Attachment: DD Page: 3

AIRIMP 3.21.2 (new examples)

Example 5 — Message from booking source to Member requesting non-flight related services for two passengers, with two locations codes in the SVC element.

MUCRM1A

.HDQRM1P

HDQ1P RT7D9K/8F6Q/38278505/ROM/1P/T/IT

1MULLER/MIKEMR 1EDWARDS/PATTYMRS

AF6107 J 10DEC TLSORY HK1

ARNK

AF0276 J 10DEC CDGNRT HK1

AF0275 J 20DEC NRTCDG HK1

ARNK

AF6156 J 20DEC ORYTLS HK1

SVC AF NN1 ORYCDG 10DEC/B/0BR/TRANSFER/NM-1MULLER/MIKEMR

SVC AF NN1 CDGORY 20DEC/B/0BR/TRANSFER/NM-1EDWARDS/PATTYMRS

Example 5(a) — Message from the Member to the booking source confirming the non-flight related services for one passenger with KD for one service as an EMD is required and with a KK for the other service as no EMD is required. Free text with additional information is included in the reply.

HDQRM1P

.MUCRM1A

HDQ1P RT7D9K

1MULLER/MIKEMR 1EDWARDS/PATTYMRS

AF6107 J 10DEC TLSORY HK1

ARNK

AF0276 J 10DEC CDGNRT HK1

AF0275 J 20DEC NRTCDG HK1

ARNK

AF6156 J 20DEC ORYTLS HK1

SVC AF KD1 ORYCDG 10DEC/B/0BR/TRANSFER/NM-1MULLER/MIKEMR

SVC AF KK1 CDGORY 20DEC/B/0BR/TRANSFER/NM1EDWARDS/PATTYMRS.COMPLEMENTARYJPSC/31 PSC/33 Oct 11

Attachment: EE Page: 1 of 1

AIRIMP and SIPP

3.21.1.2 Action/Reply/Advice/Status Codes

Action codes NN – Service Requested

HS – EMD issued for confirmed service (only to be used following KD)

XX – Service cancelledJPSC/31 PSC/33 Oct 11

Attachment: FF Page: 1 of 1

AIRIMP and SIPP

3.20 PASSENGER PROVIDED CONTACT INFORMATION

3.20.1 A passenger provided contact name and telephone number can be sent in an SSR as required . SSR PCTC should be used to record the name and telephone number of a person other than the passenger to be contacted in the event of an

emergency.

[...]

3.20.3 Passenger provided contact name may be an entity (such as a travel agency name) or a personal name. The contact should not be a person travelling on the covered flight.

...

3.20.8 When the passenger provided contact has been solicited but the passenger refuses to provide one or one is not available, put two slashes after the HK and end the element, however passenger name and/or free text fields can be added, if

needed.

3.20.9 Examples: (a) [...]

(b) element showing emergency contact

SSR PCTC AF HK/JOHN BAKER/FR33122334455.TO BE CONTACTED IN CASE

SSR PCTC AF///OF EMERGENCY

SSR PCTC BA HK/MARY SMITH/US18433445566-1SMITH/JOHN.TO BE

SSR PCTC BA/// CONTACTED IN CASE OF EMERGENCY

(b) (c) element showing passenger provided contact solicited, but not available or refused, with free text and/or passenger name [...]JPSC/31 PSC/33 Oct 11

Attachment: GG Page: 1 of 1

AIRIMP and SIPP

7.1.16.2 SSR DOCO CODES

7.1.16.2.1. Travel Document Type Codes Passenger Other Supplementary

Information Code

Passenger Visa Visa Number ...................................V

Redress Number....................................................R

Known Traveler Number .........................................KJPSC/31 PSC/33 Oct 11

Attachment: HH Page: 1 of 1

AIRIMP and SIPP

3.1.17.1 Where a Passive Segment Notification Agreement Exists (See 8.10)

.....

TYORMNH

. HDQRM1F 240827

HDQ1F MSOCKK/8HH6/16311116/TYO/1F/T/JP/JPY

1TAMURA/TADASHIMR

NH006T21DEC NRTLAX PK1/1705 0945

SSR TKNE NH HK1 NRTLAX0006T21DEC.2051761069389C1

SSR RLOC NH NRTLAX0006T21DEC.XXFFDDJPSC/31 PSC/33 Oct 11

Attachment: II Page: 1 of 1

AIRIMP and SIPP

8.4.6 Construction of SPR Messages

The sequence of elements is as follows:

(a) Address; (b) Communications Reference; (c) Message Identifier SPR; (d) Record Locator of this SPR sender; (e) (d) Record Locator of the SPN or SPM originator; (e) Record Locator of this SPR sender; (f) Record Locator of the SPN or SPM originator; (g) Record Locator of this SPR sender; (h) (f) Name(s); (i) (g) Air Segment(s); (j) (h) Auxiliary Segment(s); (k) (i) SSR(s); (l) (j) OSI(s).JPSC/31 PSC/33 Oct 11

Attachment: JJ Page: 1 of 2

AIRIMP and SIPP

2.11.6.7 SSR Matrix

SSR

Code Action Code Reply Automated

Format Free Text in Request Free Text in Reply/Cancel Reference

UMNR Mandatory Mandatory Mandator y Mandatory Optional See 2.6.20

UPGR Mandatory Not permitted Mandatory Optional Not Permitted See 3.8.2.4

Bilateral

3.8.2.4 Upgrade Advisory to Partner Airline

Bilateral agreements between airlines may contain provision for SSR UPGR to be exchanged between two members together with the cancel/rebook, when one member has upgraded a passenger on the other member’s flight. In the bilateral agreement between the two members it is stated that the member sending the message takes full responsibility of the upgrade. The SSR informs the operating member that this is not a regular cancel/rebook and allows for special processing. This advisory may be used for any upgrade based on partner agreement.

Example 1 Message illustrating passenger Patell has been upgraded by DL on a KL Flight. SSR UPGR included without free text.

Addressee ........................ MUCRM1A Originator ........................ .HDQRMDL 021715

Record Locator Sender ....... HDQDL HGTHZZ/MSP/15252635/MSP/DL/A/US

Name Element .................. 1PATELL/ROHNAMR Segment Element.............. KL652M30MAR IADAMS XX1 Segment Element.............. KL652C30MAR IADAMS LK1/1755 0740/1 Segment Element.............. KL651M01APR AMSIAD HK1 Supplementary Element ..... SSR UPGR KL HK1 IADAMS0652C30MAR

Example 2Message illustrating passengers Py lka and Mooers have been upgraded by KL on a DL Flight. SSR UPGR included with free text.

Addressee ........................ HDQRMDL Originator ........................ .MUCRM1A 091540

Record Locator Sender ....... MUC1A DH87E0/AMSKL0200/6958423/AMS/KL/A/NL

Name Element .................. 1PYLKA/BARBARAMRS 1MOOERS/SARAHMRS Segment Element.............. DL0239M30MAR AMSATL XX2 Segment Element.............. DL0239C30MAR AMSATL LK2/1020 1410 Segment Element.............. DL0238M01APR ATLAMS HK2 Supplementary Element ..... SSR UPGR DL HK2 AMSATL0239C30MAR.COMMERCIAL UPGRADE

3.8.2.4 5 Frequent Traveler Accrual – Service Recognition (FQTS)

.......JPSC/31 PSC/33 Oct 11

Attachment: JJ Page: 2

7.1.8.2 Special Service Requirement (SSR) Codes

Unaccompanied Minor UMNR Upgrade UPGR

7.2 Passenger Reservations Codes and Abbreviations (Decoding)

UPD Request to Member for an update of block parameters UPGR Upgrade

Secretary note : add SSR to PNL/ADL in RP 1708JPSC/31 PSC/33 Oct 11

Attachment: KK Page: 1 of 1

AIRIMP and SIPP

3.13.2.4 Examples

(a) Non-Automated Format (1)

A passenger requiring two Visa documents for this PNR:

SSR DOCO BA HK1//V/9891404/LONDON/14MAR03/USA-1STEVENSON/JOHNMR

SSR DOCO BA HK1//V/586D4FF/WASHINGTON/23AUG01/GBR

- 1STEVENSON/JOHNMR

SSR DOCO BA HK1//V/586D4FF/GB EMBASSY WASHINGTON/23AUG01/GBR-1STEVENSON/JOHNMR

.....JPSC/31 PSC/33 Oct 11

Attachment: LL Page: 1 of 1

AIRIMP and SIPP

3.13.1.1 Definitions

The Following Documents have been defined by ICAO 9303 as travel documents:

(editor: add in alphabetical sequence)

Military ID..................... .................................................................M

7.1.16.1.1 Travel Document Type Codes

(editor: add in alphabetical sequence)

Military ID....................................... ................................................M

7.2. PASSENGER RESERVATIONS CODES AND ABBREVIATIONS (Decoding)

(editor: add in alphabetical sequence)

M..........................................................................................Military IDJPSC/31 PSC/33 Oct 11

Attachment: MM Page: 1 of 1

AIRIMP and SIPP

3.13.1.5 Irregular Names

(a) Single-name passenger

In cases where the passenger has a single name, record that in the SSR DOCS as the “Travel Document Surname” and insert FNU (first name unknown) in the “Travel

Document First Given Name” field.

(b) Single-character name

The “Travel Document Surname” and/or the “Travel Document First Given Name” can be a single character.

(c) Hyphenated names

In cases where the passenger has a hyphenated name, replace the hyphen with a space in the “Travel Document Surname” and/or the “Travel Document First Given

Name”.

(d) Names with apostrophe

In cases where the passenger has an apostrophe in their name, delete the apostrophe when recording the name in the “Travel Document Surname” and/or the “Travel

Document First Given Name”.JPSC/31 PSC/33 Oct 11

Attachment: NN Page: 1 of 1

AIRIMP and SIPP

3.13.1 API — Passenger Travel Document Information

The elements Travel Document Surname, Travel Document First Given Name and

Travel Document Second Given Name must match the surname, first given name and second given name (if applicable) as shown in the official travel document. If the name is from the Machine Readable Zone (MRZ) of an official document, e.g. passport, the chevron character (<) in the MRZ should be interpreted as a space character. A double chevron (<<) should be interpreted as a change of field, e.g. from surname to given name. Spaces in the name fields of the SSR DOCS should not be removed and should be transmitted in messages to business partners and
governments.JPSC/31 PSC/33 Oct 11

Attachment: OO Page: 1 of 4

AIRIMP and SIPP ( Secretary note : this section is all new) 3.13.4 API – Passive Segments 3.13.4.1 Where a passive segment notif ication agreement exists (See 8.10)

SSR DOCS/DOCA/DOCO may be transmitted for Pa ssive segments. If these SSR’s are sent with the initial transmission of PK/PL segment(s ), the Action Code of the segment(s) will be PK or PL. If these SSR’s are sent after the initial transmission of PK/PL segments, the Action Code for these same segment(s) will be PU. If the Record Locator of the receiving system is known, it should be included as an OSI or SSR item, not in the Secondary Record Locator Line (See 2.5.2).

Example 1 — Message illustrating SSR DOCS (non-automated format) sent as the initial transmission of PK segment for the total party, record locator unknown:

Addressee ................................. ATLRMDL
Sender....................................... .HDQRM1S 240827

Record Locator Sender............. HDQ1S MSOCKK/8HH6/16311116/LAX/1S/T/US/USD

Name Element .......................... 1TAMURA/TADASHIMR Segment Element...................... DL2756T01NOV ATLJFK PK1/1705 0945 Supplementary Element............ SSR DOCS DL HK1/////01APR80/M//TAMURA/TADASHI/TAKEHIKO

Example 2 — Message illustrating SSR DOCS (automated format) sent as the initial transmission of PL segment for two pass engers within the party and the record locator using an SSR item:

Addressee ................................. ATLRMDL
Sender....................................... .HDQRM1S 240827

Record Locator Sender............. HDQ1S MSOCKK/8HH6/16311116/LAX/1S/T/US/USD

Name Element .......................... 2VALVERDE/JOSEMR/ALBERTOMR 1SANTOS/MARIAMRS Segment Element...................... DL2756T01NOV ATLJFK PL3/1705 0945 Supplementary Element............ SSR DOCS DL HK1

ATLJFK2756T01NOV/P/SIN/S78654087/SIN/12JUL64/M/23OCT14 Supplementary Element............ SSR DOCS DL ////VALVERDE/JOSE/JESUS-1VALVERDE/JOSEMR (Continuation Line) Supplementary Element............ SSR DOCS DL HK1

ATLJFK2756T01NOV/P/SIN/S78654051/SIN/01JUN81/M/10DEC15 Supplementary Element............ SSR DOCS DL ////VALVERDE/ALBERTO/RODRIGUEZ1VALVERDE/ALBERTOMR (Continuation Line) Supplementary Element............ SSR RLOC DL ATLJFK2756T01NOV.ABCDEF (Record Locator Addressee)

Example 3 — Message illustrating SSR DOCS (automated format) sent after the initial transmission of PK/PL segments for one passenger, record locator unknown:

Addressee ................................. ATLRMDL
Sender....................................... .HDQRM1S 240827

Record Locator Sender............. HDQ1S MSOCKK/8HH6/16311116/LAX/AA/T/US/USD

Name Element .......................... 1VALVERDE/ALBERTOMR Segment Element...................... DL2756T01NOV ATLJFK PU1 Supplementary Element ........... SSR DOCS DL HK1

ATLJFK2756T01NOV/P/SIN/S78654051/SIN/01JUN81/M/10DEC15 Supplementary Element............ SSR DOCS DL ////VALVERDE/ALBERTO/RODRIGUEZ1VALVERDE/ALBERTOMR (Continuation Line)JPSC/31 PSC/33 Oct 11

Attachment: OO Page: 2

Example 4 - Message illustrating SSR DOCS (non-automated format) and SSR

TKNE sent as the initial transmission of PK segment for the total party, record locator

unknown:

Addressee ....................... ATLRMDL
Sender............................. .HDQRM1S 240827

Record Locator Sender ... HDQ1S MSOCKK/8HH6/16311116/LAX/1S/T/US/USD

Name Element................. 1VALVERDE/ALBERTOMR Segment Element............ DL2756T01NOV ATLJFK PK1/1705 0945 Supplementary Element . SSR DOCS DL HK1

ATLJFK2756T01NOV/P/SIN/S78654051/SIN/01JUN81/M/10DEC15 Supplementary Element .. SSR DOCS DL ////VALVERDE/ALBERTO/RODRIGUEZ1VALVERDE/ALBERTOMR Supplementary Element . SSR TKNE DL HK1 ATLJFK2756T01NOV.2051761069389C1

Example 5 - Message illustrating SSR DO CO (automated format) and SSR TKNE sent after the initial transmission of PK/PL segments for one passenger, record

locator unknown:

Addressee ................................. ATLRMDL
Sender....................................... .MUCRM1A 240827

Record Locator Sender............. MUC1A RF87TG/CDGAF0200/1665874/PAR/AF/A/FR/EUR

Name Element .......................... 1ANTHONY/EDITHMRS Segment Element...................... DL0021T01NOV CDGATL PU1 Supplementary Element............ SSR DOCO DL HK1 CDGATL0021T01NOV//V/9891404/PARIS/20SEP10 Supplementary Element............ SSR DOCO DL ////US-1ANTHONY/EDITHMRS (Continuation Line) Supplementary Element............ SSR TKNE DL HK1 CDGATL0021T01NOV1ANTHONY/EDITHMRS.2055231982461C1

3.13.4.2 Where no passive segment notification agreement exists (See 8.10)

The message identifier PTN is used to al low the receiving system to recognize SSR DOCS/DOCA/DOCO and/or SSR TKNE has been sent for one or more passive segments in the message.

Example 1 — Message illustrating SSR DOCS (non-automated format) sent for a confirmed segment for the total pa rty, record locator unknown:

Addressee ................................. ATLRMDL
Sender....................................... .HDQRM1S 240827 Message Identifier..................... PTN
Record Locator Sender............. HDQ1S MSOCKK/8HH6/16311116/LAX/1S/T/US/USD

Name Element .......................... 1TAMURA/TADASHIMR Segment Element...................... DL2756T01NOV ATLJFK HK1/1705 0945 Supplementary Element............ SSR DOCS DL HK1/////01APR80/M//TAMURA/TADASHI/TAKEHIKOJPSC/31 PSC/33 Oct 11

Attachment: OO Page: 3

Example 2 — Message illustrating SSR DOCS (automated format) sent for a waitlisted segment for two passengers of the party and the record locator using an

SSR item:

Addressee ................................. ATLRMDL
Sender....................................... .HDQRM1S 240827 Message Identifier..................... PTN
Record Locator Sender............. HDQ1S MSOCKK/8HH6/16311116/LAX/1S/T/US/USD

Name Element .......................... 2VALVERDE/JOSEMR/ALBERTOMR 1SANTOS/MARIAMRS Segment Element...................... DL2756T01NOV ATLJFK HL3/1705 0945 Supplementary Element............ SSR DOCS DL HK1

ATLJFK2756T01NOV/P/SIN/S78654087/SIN/12JUL64/M/23OCT14 Supplementary Element............ SSR DOCS DL ////VALVERDE/JOSE/JESUS-1VALVERDE/JOSEMR (Continuation Line) Supplementary Element............ SSR DOCS DL HK1

ATLJFK2756T01NOV/P/SIN/S78654051/SIN/01JUN81/M/10DEC15 Supplementary Element............ SSR DOCS DL ////VALVERDE/ALBERTO/RODRIGUEZ1VALVERDE/ALBERTOMR (Continuation Line) Supplementary Element............ SSR RLOC DL ATLJFK2756T01NOV.ABCDEF (Record Locator Addressee)

Example 3 — Message illustrating SSR DOCS (automated format) sent for a confirmed segment for the total pa rty, record locator unknown:

Addressee ................................. ATLRMDL
Sender....................................... .HDQRM1S 240827 Message Identifier..................... PTN
Record Locator Sender............. HDQ1S MSOCKK/8HH6/16311116/LAX/AA/T/US/USD

Name Element .......................... 1VALVERDE/ALBERTOMR Segment Element...................... DL2756T01NOV ATLJFK HK1 Supplementary Element............ SSR DOCS DL HK1

ATLJFK2756T01NOV/P/SIN/S78654051/SIN/01JUN81/M/10DEC15 Supplementary Element............ SSR DOCS DL ////VALVERDE/ALBERTO/RODRIGUEZ-1

VALVERDE/ALBERTOMR (Continuation Line)

Example 4 - Message illustrating SSR DOCS (non-automated format) and SSR TKNE sent for a confirmed segment for the total party, record locator unknown:

Addressee ................................. ATLRMDL
Sender....................................... .HDQRM1S 240827 Message Identifier..................... PTN
Record Locator Sender............. HDQ1S MSOCKK/8HH6/16311116/LAX/1S/T/US/USD

Name Element .......................... 1VALVERDE/ALBERTOMR Segment Element...................... DL2756T01NOV ATLJFK HK1/1705 0945 Supplementary Element ........... SSR DOCS DL HK1

ATLJFK2756T01NOV/P/SIN/S78654051/SIN/01JUN81/M/10DEC15 Supplementary Element............ SSR DOCS DL ////VALVERDE/ALBERTO/RODRIGUEZ1VALVERDE/ALBERTOMR Supplementary Element ........... SSR TKNE DL HK1 ATLJFK2756T01NOV.2051761069389C1JPSC/31 PSC/33 Oct 11

Attachment: OO Page: 4

Example 5 - Message illustrating SSR DO CO (automated format) and SSR TKNE sent for a confirmed segment for the total party, record locator unknown:

Addressee ................................. ATLRMDL
Sender....................................... .MUCRM1A 240827 Message Identifier..................... PTN
Record Locator Sender............. MUC1A RF87TG/CDGAF0200/1665874/PAR/AF/A/FR/EUR

Name Element .......................... 1ANTHONY/EDITHMRS Segment Element...................... DL0021T01NOV CDGATL HK1 Supplementary Element............ SSR DOCO DL HK1 CDGATL0021T01NOV//V/9891404/PARIS/20SEP10 Supplementary Element............ SSR DOCO DL ////US-1ANTHONY/EDITHMRS (Continuation Line) Supplementary Element............ SSR TKNE DL HK1 CDGATL0021T01NOV1ANTHONY/EDITHMRS.2055231982461C1JPSC/31 PSC/33 Oct 11

Attachment: PP Page: 1 of 1

AIRIMP and SIPP

2.11.6.1 Automated Format

..... (k) Name(s) (if applicable) — enter ...... For infants not occupying a seat, the

name association for the SSR Element should be that of the adult on whose lap the infant will be seated. .....

.......

3.21.1.1 Rules of Usage

.... (xi) For infants not occupying a seat, the name association for the SSR Element should be that of the adult on whose lap the infant will be seated.JPSC/31 PSC/33 Oct 11

Attachment: QQ Page: 1 of 1

AIRIMP and SIPP

Change the reference in the following places:

2.10.6.1(j) ....Refer to name element paragraph 2.11.6.1(f) (k)

2.10.6.2(j) ....Refer to name element paragraph 2.11.6.1(f) (k)

2.11.6.6(k) ....Refer to name element paragraph 2.11.6.1(f) (k)

2.11.7.1(d) ......of names in SSR elements as described in 2.11.6.1(f) (k)

3.5.1.13 .......separate names associated SSR items (see 2.11.6.1(f) (k)

3.6.2.16 ......Unequal number of names/services (see 2.11.6.1(f) (k)

....JPSC/31 PSC/33 Oct 11

Attachment: RR Page: 1 of 1

AIRIMP and SIPP

2.11.6 Construction of SSR

.... 2.11.6.1 Automated Format

.... (e) Number in party of services (one, two or three digits without leading zeros): zeros)

.... (l) If applicable....

(e) Number in Party of services (without leading zeros) 1-3n 1

2.11.6.2 Non-Automated Format

.... (e) Number in party of services (a one, two or three digits without leading zeros): zeros)

.... Notes:

.... 2. Where specified....

(e) Number in Party of services (without leading zeros) 1-3n 1JPSC/31 PSC/33 Oct 11

Attachment: SS Page: 1 of 1

AIRIMP and SIPP

3.5.1.13 Unequal number of names/services

JONES/B and BAKER/C require separate names associated SSR items (see 2.11.6.1(f) “Construct ion and Sequence of Components: for rule).

3.5.1.13 Multiple number of services for a passenger

When a passenger requires a multiple number of the same service, the SSR contains the number of services; JONES/B and BAKE R/C require multiple XBAG and AVIH services, respectively. They require separate name-associated SSR items (see 2.11.6.1(k) for the rule.)

.....

3.6.2.16 Unequal number of names/services (see 2.11.6.1(f) “Construction and Sequence of Components”).

3.6.2.16 Multiple number of services for a passenger

When a passenger requires a multiple number of the same service, the SSR contains the number of services; JONES/B and BAKE R/C require multiple XBAG and AVIH services, respectively. They require separate name-associated SSR items (see 2.11.6.1(k) for the rule.)JPSC/31 PSC/33 Oct 11

Attachment: TT Page: 1 of 1

AIRIMP and SIPP

2.11.6.8 Standard and Bilateral SSR Definitions

Standard SSR codes must be able to be processed by any receiving member. This does not imply that the receiving member supports or accepts the service requested. When required, the appropriate advice code should be returned to the message

sender.

Bilateral SSR codes are those that are agreed to be exchanged only between two members, or a CRS and one or more members.JPSC/31 PSC/33 Oct 11

Attachment: UU Page: 1 of 3

AIRIMP and SIPP

2.11.6.4 Replies

2.11.6.4.1 Automated format

When replying to an automated format SSR Element, respond with appropriate Advice Code and repeat back the same components as received in the request message 2.11.6.1(a) through 2.11.6.1(k), as applicable. Component 2.11.6.1(l) (free text) may be returned or modified/added at the discretion of the sender. For “NSSA”, “NSSB”, “NSSW”, “SMSA”, “SMSB”, “SMSW”, with an Advice Code of “KK”, the component 2.11.6.1(l) is optional. When 2.11.6.1(l) is used, it must contain a seat number and when bilaterally agreed up to 5 zone and location codes can be added

after the seat number.

[...] 2.11.6.3 Examples of SSR Request Items (refer to 2.11.6.4 for appropriate reply)
(a) Automated Format Examples

[...]

Example 23a — (bilateral) A request for contiguous seats 30E and 30F requested

1RAULOT/MARION 1PEYRE/FREDERIC

IB101Y20MAR SVQMAD HK2

SSR RQST IB NN2 SV QMAD0101Y20MAR.30E30F

Example 23b — (bilateral) A request for non contiguous seats 50B and 100A with the SSR SEAT in the non smoking zone.

1RAULOT/MARION 1PEYRE/FREDERIC

UA0001Y25FEB ORDHNL HK2

SSR SEAT UA NN2 ORDHNL 0001Y25FEB.50BN100AN

Example 23c — (bilateral) A generic seat request for a non-smoking window seat

1RAULOT/MARION 1PEYRE/FREDERIC

UA0001Y25FEB ORDHNL HK2

SSR NSST UA NN2 ORDHNL 0001Y25FEB.W

[...]

2.11.6.4.3 Examples of SSR Replies (refer to 2.11.6.1 and 2.11.6.2 for appropriate request) (i) Automated Format [...]JPSC/31 PSC/33 Oct 11

Attachment: UU Page: 2

Example 23a — (bilateral) Confirmation of contiguous seats in the non smoking zone where 30E is a window, exit row and leg space seat and 30F is an aisle, leg space seat

1RAULOT/MARION 1PEYRE/FREDERIC

IB101Y20MAR SVQMAD HK2

SSR RQST IB KK2 SVQMAD0101Y20MAR.30ENWEL30FNAL

Example 23b — (bilateral) Confirmation of non contiguous seats in the non smoking section where 50B is a non smoking seat, bulkhead, leg space and exit row and 100A is a non smoking seat, aisle

and bulkhead seat.

1RAULOT/MARION 1PEYRE/FREDERIC

UA0001Y25FEB ORDHNL HK2

SSR SEAT UA KK2ORDHNL0001Y25FEB.50BNBLE100ANAB/RS

Example 23c — (bilateral) Confirmation of non contiguous seats in the non smoking section where 50A is a non smoking seat, window, leg space and exit row and 50B is a non smoking seat, aisle and

exit row seat.

1RAULOT/MARION 1PEYRE/FREDERIC

UA0001Y25FEB ORDHNL HK2

SSR NSST UA KK2ORDHNL0001Y25FEB.50ANWLE50BNAE

[...]



### 3.19 PRE-RESERVED SEAT SELE CTION AND BOARDING PASS

NOTIFICATION

[...]



### 3.19.4 Construction and Sequence of Components

(ii) when more than one seat number is included in the entry, the seat numbers will be included with no separation,

(iii) when confirming a pre-reserved seat request, following the seat request, seat number may be followed by location codes (bilaterally agreed)

(iii) (iv) when unable to confirm a pre-reserved seat request, following the seating request, include the reason preceded by an oblique (may not be used in conjunction with a Transaction Identifier) [...]



### 3.19.8 Reply Messages

[...]

3.19.8.4 When seats are confirmed, the Zone Code must follow each seat number and when bilaterally agreed can be followed by location code

[...] 3.19.8.6 Examples of Reply Items
[...]JPSC/31 PSC/33 Oct 11

Attachment: UU Page: 3

Example 8 — (By bilateral agreement) A confirmation for pre-reserved rear-facing seats on BA flight 4505, J class, on July 6, for all three Members of a PNR party, in the non-smoking section (Boarding pass inhibited):

SSR SEAT BA KK3 LGWNAS4505J06JUL.07CN07DN07EN/RS

Example 9 — (By bilateral agreement) A confirmation for pre-reserved seats on UA flight 0001, Y class, on FEB 25 in the non-smoking section for a bulkhead, leg space and exit row seat (boarding pass inhibited):

SSR SEAT UA KK1ORDHNL0001Y25FEB.50BNBLE/RSJPSC/31 PSC/33 Oct 11

Attachment: VV Page: 1 of 1

AIRIMP and SIPP

3.21.1.4 Examples of Request and Reply Messages for Pre-Reserved seats in SSR SEAT elements in conjunction with SSR ASVC elements

.....

Example 7 (a) – Message from the booking sour ce to the member advising a seat has been confirmed through an interactive conversation.

MUCRM1A

.SWIRM1G

BPR

SWI1G XDWGS2/H34Z/99999992/LON/1G/T/GB

1DRAKE/STEVEMR

BA0285K10JUN LHRSFO HK1

BA0284J20JUN SFOLHR HK1

SSRSEATBALK1 LHRSFO 0285K10JUN.29A/RS

SSRSEATBALK1 SFOLHR 0284J20JUN.28C/RS

Example 7 (b) – Message from the member to the booking source. The SSR SEAT is not included as the seat is already confirmed. SSR ASVC is sent with KD as EMD-A is required.

SWIRM1G

.MUCRM1A

SWI1G XDWGS2

1DRAKE/STEVEMR

BA0285K10JUN LHRSFO HK1

BA0284J20JUN SFOLHR HK1

SSRASVCBAKD1 LHRSFO 0285K10JUN.A/0B5/SEAT/CHARGEABLE SEAT

SSRASVCBAKD1 SFOLHR 0284J20JUN.A/0B5/SEAT/CHARGEABLE SEATJPSC/31 PSC/33 Oct 11

Attachment: WW Page: 1 of 1

AIRIMP and SIPP

2.11.6.6 Unsolicited Reply Messages

A member may send a Reply Message to the booking source, without a previous received request message from the booking source. This way the member can synchronize the data directly entered into the members PNR with the booking source. This also applies to SSR Codes where replies are not permitted according to the SSR Matrix.

Example 1 – Passengers contacts UA directly advising UA of the mandatory Secure Flight Data. The Ticket will be issued by a Travel Agent. An unsolicited Reply Message is sent by UA informing the booking source about this data in order for them to be able to issue the

ticket.

HDQRM1S

.HDQRMUA

HDQ1S HDI84J

VONWUPPERTAL/HEINO MR

UA0944Y10JUN ORDFRA HK1

UA0945Y20JUN FRAORD HK1

SSRDOCSUAKK1/////10SEP53/M//VONWUPPERTAL/HEINO

Example 2 – Passengers contacts UA directly to book a seat and to request a vegetarian meal. An Unsolicited Reply message is sent by UA to booking source.

HDQRM1S

.HDQRMUA

HDQ1S HDI84J

VONWUPPERTAL/HEINO MR

UA0944Y10JUN ORDFRA HK1

UA0945Y20JUN FRAORD HK1

SSRNSSTUAKK1 ORDFRA0944Y10JUN.10A

SSRNSSTUAKK1 FRAORD0945Y20JUN.12F

SSRVGMLUAKK1 ORDFRA0944Y10JUN

SSRVGMLUAKK1 FRAORD0955Y20JUN

2.11.6. 6 7 Additional Services: Segment-Associated

2.11.6. 7 8 SSR MatrixJPSC/31 PSC/33 Oct 11

Attachment: XX Page: 1 of 1

AIRIMP and SIPP

3.13.1.4 Examples

(a) Non-Automated Format (1)

Mr. John Stevenson is travelling with an United States Permanent Resident Card number

D A 23145890 issued to a citizen from Singapore.

Note: This example has been split into two lines as the first line exceeds the maximum limit

of

69 characters. Refer to section 2.11.5 — General Construction Rules.

SSR DOCS AA HK1/ I C /USA/ D A 23145890/USA SGP /12JUL64/M/12JUL04/STEVENSON/

SSR DOCS AA ///JOHN/RICHARD-1STEVENSON/JOHNMR

Automated Format (2)

Mr. John Stevenson is travelling with an United States permanent resident card

number D A 23145890 and a Singaporean Passport number S78654091.

Note: These example have been split into two lines as the first line exceeds the maximum limit of

69 characters. Refer to section 2.11.5 — General Construction Rules.

SSR DOCS BA HK1MADLHR0455Y28JUN/P/ SIN SGP /S78654091/ SIN SGP /12JUL64/M/23OCT05/

SSR DOCS BA ///STEVENSON/JOHN/RICHARD-1STEVENSON/JOHNMR

SSR DOCS BA HK1LHRLAX0269Y01JUL/ I C /US/ D A 23145890/ US SG /12JUL64/M/12JUL04/

SSR DOCS BA ///STEVENSON/JOHN/RICHARD-1STEVENSON/JOHNMR

SSR DOCS BA HK1LAXAKL7302Y03JUL/P/ SIN SGP /S78654091/ SIN SGP /12JUL64/M/23OCT05/

SSR DOCS BA ///STEVENSON/JOHN/RICHARD-1STEVENSON/JOHNMR

### M E M O R A N D U M

PSC/RESO/ 151 bis

To: All Members, Passenger Services Conference

- Accredited Representatives

Copy: IATA Strategic Partners

From: Head, Interline and Intermodal

Date: 4 July 201 3

Subject: “PASSENGER WEEK 20 1 1 ”

BOOK OF FINALL Y ADOPTED RESOLUTIONS & RPs

3 1 st Joint ATA/IATA Passenger Services Conference (JPSC)

3 3 rd IATA Passenger Services Conference (PSC) Singapore

, 12

- 13 October 20 1 1

Attached are the resolutions & recommended practices (RPs) which were adopted at the above

me ntioned Conference (except for RP 1708a)

. The Minutes of the Conference are issued separately under Memorandum PSC/MINS/038 dated 23 February 2012.

The resolutions and RPs were originally circulated under cover of memorandum PSC/RESO/151

dated 23 Febru ary 2012. Subsequently they were filed with Governments, where required, except

for the United States Department of Transportation (D o T)

. The intended effective date was 1 June

2012

.

The delay in filing these resolutions and RPs with the DoT was in reco gnition of new procedures to

create a “self

- assessment ” environment for PSC agreements. These new procedures were finally

revealed at the PSC meeting in October 2012 (refer to agenda item P5 in the Minutes circulated

under Memorandum PSC/MINS/042 dated 28 January 2013).

The DoT Order 2012

- 4

- 18 provides for a three

- tiered system for filing and implementation of PSC agreements. This memorandum will be filed with the DoT using procedures for “Tier 1” . The changes for RP 1708a will be filed separately using the procedures for “Tier 2”.

Mike Muller

International Air Transport Association

Route de l'Aeroport 33

PO Box 416

CH

- 1215 Geneva 15 Airport

Switzerland

Tel: +41 22 770 2 731

Fax: +41 22 770 2896

### OUTLINE OF CONTENTS

RESOLUTIONS & RECOMMENDED PRACTICES

ADOPTED AT:

3 3 rd PASSENGER SERVICES CONFERENCE (PSC)

INTENDED EFFECTIVE DATE: 1 JUNE 20 1 2

Resolution/RP Title

PSC(33) 003 STANDARD RECISS ION RESOLUTION

PSC(33) 720a

**[OST**

**- 2012** 

**- 0058]**  PASSENGER TICKET AND BAGGAGE CHECK

ISSUANCE AND HONORING PROCEDURES (amending)

PSC(33) 722

**[OST**

**- 2012** 

**- 0058]**  TRANSITIONAL AUTOMATED TICKET (TAT) (amending)

PSC(33) 722f

**[OST**

**- 2012** 

**- 0058]**  ELECTRONIC TICKET

– AIRLINE (amending)

PSC(33) 722g

**[OST**

**- 2012** 

**- 0058]**  ELECTRONIC TICKET

– NEUTRAL (amending)

PSC(33) 722h

**[OST**

**- 2012** 

**- 0058]**  ELECTRONIC TICKET

– GROUND HANDLING ( amending)

PSC(33)725 a

**[OST**

**- 2012** 

**- 0058]**  MISCELLANEOUS CHARGES ORDER (MCO)

– ISSUANCE AND HONO URING PROCEDURES BY

MEMBERS (amending)

PSC(33)725 b

**[OST**

**- 2012** 

**- 0058]**  MISCELLANEOUS CHARGES ORDER (MCO)

– ISSUANCE AND HONOURING PROCEDURES (AGENTS) (amending)

PSC(33)725d AUTOMATED MISCELLANEOUS CHARGES ORDER (MCO) NEUTRAL (COUPON

- BY

- COUPON) (ame nding)

PSC(33)725f

**[OST**

**- 2012** 

**- 0058]**  ELECTRONIC MISCELLANEOUS DOCUMENT

– AIRLINE (amending)PSC(33)725g

**[OST**

**- 2012** 

**- 0058]**  ELECTRONIC MISCELLANEOUS DOCUMENT

– NEUTRAL (amending)

PSC(33)725h

**[OST**

**- 2012** 

**- 0058]**  ELECTRONIC MISCELLANEOUS DOCUMENT

– GROUND HANDLING (amending)

PSC(33)726e

**[OST**

**- 01** 

**- 9575]**  MULTIPLE PURPOSE DOCUMENT (MPD)

– NEUTRAL, CARBONISED, MANUAL (amending)

PSC(33)728

**[OST**

**- 2012** 

**- 0058]**  CODE DESIGNATORS FOR PASSENGER TICKET

AND BAGGAGE CHECK (amending)

PSC(33)762 AIRLIINE DESIGNATORS (amending)

PSC(33)763 LOCATION IDENTIFIERS (amending)

PSC(33)767 ASSIGNMENT OF AIRLINE ACCOUNTING CODES

AND AIRLINE PREFIXES (amending)

PSC(33)780e

**[OST**

**- 2012** 

**- 0058]**  IATA INTERLINE TRAFFIC PARTICIPATION

AGREEMENT

– PASSENGER (amending)

PSC(33) 792 BAR CODED BOARDING PASS (BCBP)

– VERSION 4

VERSION 5 (amending)

PSC(33)1701 a PASSENGER DATA HARMONIZATION **( new**  **)**

PSC(33)1701d SELF SERVICE AUTOMATED DOCUMENT CHECK (amending)

PSC(33)1701h SECURITY CHECKPOINT ACCESS AND EGRESS **(new)**

PSC(3 3)1701i INTERNATIONAL TRAVELER SCHEME **(new)**

PSC(33)1701j

**[OST**

**- 2012** 

**- 0058]**  AUTOMATED AND SELF

- SERVICE FLIGHT

REBOOKING FOR IRREGULAR OPERATIONS **(new)**

PSC(33)1701k SELF BOARDING (amending)PSC(33)1706 FUNCTIONAL SPECIFICATION FOR STANDARD

DEPART URE CONTROL SYSTEM (amending)

PSC(33)1706c COMON USE SELF SERVICE (CUSS) (amending)

PSC(33)1707 a

**[OST**

**- 01** 

**- 9575]**  DATA FIELD DIRECTORY FOR DCS PASSENGER

MESSAGES (amending)

PSC(33)1707b

**[OST**

**- 01** 

**- 9575]**  DATA ELEMENT DIRECTORY FOR DCS PASSENGER

MESSAG ES (amending)

PSC(33)1708

**[OST**

**- 0** 

**2**

**- 13807**  **]** PASSENGER NAME LIST (PNL) AND ADDITIONS AND DELETIONS LIST (ADL) (amending)

PSC(33)1715 **[OST**

**- 0** 

**2**

**- 11798**  **]** PASSENGER SERVICE MESSAGE (PSM) (amending)

PSC(33)1719 **[OST**

**- 01** 

**- 9575]**  PASSENGER FINAL SALES MESSAGE (PF S) (amending)

PSC(33)1719b **[OST**

**- 0** 

**2**

**- 13807**  **]** PASSENGER RECONCILE LIST (PRL) (amending)

PSC(33)1720a STANDARD THIRTEEN

- DIGIT NUMBERING SYSTEM

FOR TRAFFIC DOCUMENTS ( amending )

PSC(33)1728 RESERVATIONS AND TICKET CODING DIRECTORY (amending)

PSC(33)17 39 PASSENGER/ BAGGAGE RECONCILIATION

PROCEDURES (amending)

PSC(33)1740c RADIO FRQUENCY IDENTIFICATION (RFID)

SPECIFICATIONS FOR INTERLINE BAGGAGE (amending)

PSC(33)1745 **[OST**

**- 0** 

**2**

**- 13807**  **]** BAGGAGE INFORMATION MESSAGES (amending)

PSC(33)1790 **[OST**

**- 2012** 

**- 0**  **058]** ADDITIONAL SERVICES (amending)

PSC(33)1797

**[OST**

**- 2012** 

**- 0058]**  COMMON USE PASSENGER PROCESSING SYSTEMS (CUPPS) (amending)

### SUMMARY OF CHANGES

RESOLUTIONS/RECOMMENDED PRACTICES FINALLY ADOPTED AT:

3 3 rd PASSENGER SERVICES CONFERENCE (PSC)

INT ENDED EFFECTIVE DATE:

1 ST JUNE 20 1 2

Resolution/

Recommended

Practice Summary of

Resolution/RP Summary of Amendment

RESOLUTION 003

STANDARD

RECISSION

RESOLUTION Resolution rescinds a previously adopted

Resolution

. RP 1737

– Automated Interline

Revenue Date Exchange System (AIRDES) rescinded in view that this service no longer exists

RESOLUTION 720a

PASSENGER TICKET

AND BAGGAGE

CHECK

– ISSUANCE

AND HONOURING

PROCEDURES Provides governing rules on
how to issue a ticket, and applicable conditions for the honoring and re

- issuance of

tickets. Clarifies that the combined tax code

‘XT’ must not be used for the
transmission of tax, fee, charge data in

electronic tickets.

RESOLUTION 722

TRANSITIONAL

AUTOMATED TICKET (TAT) Provides governing rules on how to pr oduce an “automated” ticket issued by airlines. It also provides the technical specifications and applicable conditions for the honoring of such tickets. Ticketing of surcharges is revised to reflect new ways of filing single and multiple segment surcharg es. Examples are added on how to ticket multiple surcharges.

Clarifies that the combined tax code

‘XT’ must not be used for the transmission of tax, fee, charge data in

electronic tickets.

RESOLUTION 722f

ELECTRONIC

TICKET

– AIRLINE Provides governing r ules and technical specifications on how to produce an Electronic Ticket (ET) issued by airlines. This allows ticketing to be performed without the issuance of paper tickets.

Also included are the applicable conditions for the issuance and honoring of

such tickets. Various definitions for EMD, coupon status codes and messages are

revised.

Clarifies that the combined tax code ‘XT’ must not be present in the fare

calculation of the ticket.

Procedures are added to clarify what should happen to an electronic ticket when an associated EMD is present.

Various data elements are added and

amended.

Various amendments to the data

elements matrix.Resolution/

Recommended

Practice Summary of

Resolution/RP Summary of Amendment

RESOLUTION 722g

ELECTRONIC

TICKET

– NEUTRAL Provides governing rules and technical specifications on how to produce a n Electronic Ticket (ET) issued by travel agents. This allows ticketing to be performed without the issuance of paper tickets.

Also included are the applicable conditions for the issuance and honoring of

such tickets

. Definitions for EMD and coupon status

codes are revised.

Clarifies that the combined tax code ‘XT’ must not be present in the fare

calculation of the ticket.

Various data elements are added and

amended.

Various amendments to the data

elements matrix.

RESOLUTION 722h

ELECTRONIC

TICKET

– GRO UND

HANDLING Provides governing rules and technical specifications to be followed for the third party ground

- handling of electronic tickets (E T s). This allows

airlines to have their electronic tickets handled by third party ground handlers. Various defini tions are revised.

Clarifies that the combined tax code ‘XT’ must not be present in the fare

calculation of the ticket.

Various data elements are added and

amended.

Various amendments to the data

elements matrix.

RESOLUTION 725 a MISCELLANEOUS

CHARGES O RDER (MCO)

– ISSUANCE

AND HONOURING

PROCEDURES BY

MEMBERS Provides governing rules on

how to issue and honor a Miscellaneous Charges Order (MCO) issued be airlines

. Procedures for completing a fee

calculation on an EMD are added.

RESOLUTION 725b

MISCELLA NEOUS

CHARGES ORDER (MCO)

– ISSUANCE

AND HONOURING

PROCEDURES (AGENTS) Provides governing rules on

how to issue and honor a Miscellaneous Charges Order (MCO) issued be agents. Procedures for completing a fee

calculation on an EMD are added.

RESOLUTION 72 5d

AUTOMATED

MISCELLANEOUS

CHARGES ORDER (MCO)

– NEUTRAL (COUPON

- BY

COUPON) Provides technical specifications and print line specifications for the

issuance of Miscellaneous Charges Order ‘automated’ issued by agents The provision that this resolution shal l expire 31 December 201 3 is added.Resolution/

Recommended

Practice Summary of

Resolution/RP Summary of Amendment

RESOLUTION 725f

ELECTRONIC

MISCELLANEOUS

DOCUMENT

– AIRLINE Provides governing rules for

the issuance and use of

Electronic Miscellaneous Documents (EMD) by airlines.

The EMD is an electronic

method to document the sa le and usage of charges associated to various usage, e.g. excess baggage charges. Various definitions for EMD, coupon status codes and messages are

revised.

Clarifies that the combined tax code ‘XT’ must not be present in the fare

calculation of the tick et.

Procedures are added to clarify what should happen to an EMD

- A when control is requested from a carrier who is not the operating carrier.

A new Unsolic i ted Billing message is added to support codeshare.

Various data elements are added and

amended.

Various amendments to the data

elements matrix. RESOLUTION 725g

ELECTRONIC

MISCELLANEOUS

DOCUMENT

– NEUTRAL Provides governing rules for

the issuance and use of

Electronic Miscellaneous Documents (EMD) by agents. Various definitions for EMD, coupon

statu s codes and messages are

revised.

Various data elements are added and

amended.

Various amendments to the data

elements matrix.

RESOLUTION 725h

ELECTRONIC

MISCELLANEOUS

DOCUMENT

– GROUND HANDLING Provides governing rules and technical specifications to b e followed for the third party ground

- handling of electronic

miscellaneous documents (EMDs). This allows airlines

to have their EMDs handled by third party ground

handlers. Various definitions for coupon status codes and messages are revised.

Various dat a elements are added and

amended.

Various amendments to the data

elements matrix.

RESOLUTION 726e

MULTIPLE PURPOSE DOCUMENT (MPD)

– NEUTRAL, CARBONISED,

MANUAL Provides governing rules on how to issue a Multiple Purpose Document (MPD) by
agents. The pr ovision that this resolution shall expire 31 December 201 3 is added.Resolution/

Recommended

Practice Summary of

Resolution/RP Summary of Amendment

RESOLUTION 728

CODE

DESIGNATORS FOR

PASSENGER TICKET

AND BAGGAGE

CHECK Provides various coding structures in order to identify the type of fare and other

conditions of travel for ticket s
and other documents. The reporting form for taxes, fees and charges is deleted since this will be supplied directly by the IATA Ticket

Tax Box Service.

Payment card listings are revised and the Bank Identification Number (BIN) numbering system is delet ed.

RESOLUTION 762

AIRLINES

DESIGNATORS Provides the governing rules for the assignment and use of airline designators for the

entire airline and travel and tourism industry. Various editorial amendments to reflect more accurately the current code assig nment procedures. Also a change to criteria for ULD owners in recognition of the disbandment of the Interline ULD Control User Group (IULDUG).

RESOLUTION 763

LOCATION

IDENTIFIERS Provides rules for the assignment of unique three

letter codes to identify specific locations and metropolitan areas Various editorial amendments to reflect more accurately the current code assignment procedures.

RESOLUTION 767

ASSIGNMENT

CRITERIA FOR

AIRLINE

ACCOUNTRING

CODES AND AIRLIN E

PREFIXES Provides governing rules fo r the assignment and use of airline accounting codes and airline prefixes. Various editorial amendments to reflect more accurately the current code assignment procedures.

RESOLUTION 780e

IATA INTERLINE

TRAFFIC

PARTICIPATION

AGREEMENT

–

PASSENGER Provides the standard text for

multi

- lateral interline traffic agreements where only one

airline is able to issue tickets. New provision to allow an airline to provide advance notice to its interline partners that it will no longer accept paper tickets.

RESOLUTIO N 792

BAR CODED

BOARDING PASS (BCBP)

– VERSION 4

VERSION 5 Provides the governing rules and technical specifications

for the issuance of a Bar

Coded Boarding Pass (BCBP). Added a new element in the 2D bar code to manage passenger eligibility

for “fast trac k” lanes at airports

.

RP 1701a

PASSENGER DATA

HARMONIZATION One of the “passenger experience standards” that provides guidelines for the exchange of passenger data to enhance border security Establishment of a global framework for aircraft operators to p rovide passenger data to States

.

RP 1701d

SELF SERVICE

AUTOMATED

DOCUMENT CHECK One of the “passenger experience standards” that provides guidelines for self

service document check capability Updating of guidelines for self service document checking by p assengers

.Resolution/

Recommended

Practice Summary of

Resolution/RP Summary of Amendment

RP 1701h

SECURITY

CHECKPOINT

ACCESS AND

EGRESS One of the “passenger experience standards” that provides best practice suggestions for airports regarding procedures at security checkpoints Establishment of guidelines for the

consideration of a irports for security access and egress (act of exiting)

.

RP 1701i

INTERNATIONAL

TRAVELER SCHEME One of the “passenger experience standards” that encourages Governments to harmonize their registered

traveler schemes Establishment of guidelines to promote the adoption of commonalities between national registered traveler schemes

.

RP 1701j

AUTOMATED AND

SELF

- SERVICE

FLIGHT REBOOKING

FOR IRREGULAR

OPERATIONS One of the “passenger experience standards” that provides guidelines for self

service re

- booking in cases of irregular operations Establishment of guidelines for airlines

to use on their own self

- service

machines or in a common use

environment to facilitate self

- service re

booking at airports

.

RP 1701k

SELF BOARDING One of the “passenger experience sta ndards” that provides guidelines for self boarding Updating of guidelines for self

- service boarding by passengers

.

RP 1706

FUNCTIONAL

SPECIFICATION FOR

STANDARD

DEPARTURE

CONTROL SYSTEM Defines user requirements to assist airlines, manufacturers, airport authorities or vendors who provide standard Departure Control Systems (DCS) E ditorial update

RP 1706c

COMON USE SELF

SERVICE (CUSS) Provides a recommended practice outlining specification

and standard for members who plan to operate shared

self service devices in a

common environment. Various editorial updates to clarify procedures including truncation of

credit card numbers when used as a form of identification to comply with

PCI

- DSS requirements

RP 1707a

DATA FIELD

DIRECTORY FOR

DCS PASSENGER

MESSAGES Provides definitions and

formats for the automatic creation, transmission, receipt and interpretation of this group of messages. Update to allow DCSs to correctly calculate the timeframe between flights to facilitate vetting by US authorities

RP 1707b

DA TA ELEMENT

DIRECTORY FOR

DCS PASSENGER

MESSAGES Provides specifications and rules governing the use of DCS Passenger Messages. These messages are used to provide various pieces of information that support the

“seamless” interline transportation of passeng ers. Update to allow DCSs to correctly calculate the timeframe between flights to facilitate vetting by US authorities.

Addition of element to allow unique identifier for passengers.

Various editorial updates to clarify proceduresResolution/

Recommended

Practice Summary of

Resolution/RP Summary of Amendment

RP 1708

PASSENGER NAME LIST (PNL) AND

ADDITIONS AND

DELETIONS LIST (ADL) Provides the definitions, formats and procedures for
the creation, transmission and interpretation of Passenger Name Lists Messages and

Additions/Deletion Lists Messages associated with the passenger data produced by an airline reservations
system. Update to allow DCSs to correctly calculate the timeframe between flights to facilitate vetting by US authorities

Addition of element to allow unique identifier for passengers

Various editorial updates to cl arify procedures

RP 1715

PASSENGER

SERVICE MESSAGE (PSM) Provides guidance on how to

inform downline stations of disembarking and transiting passengers who require assistance or special handling Update to allow DCSs to correctly

calculate th e timeframe between flights to facilitate vetting by US authorities

RP 1719

PASSENGER FINAL

SALES MESSAGE (PFS) The PFS message gives

information to reservations systems about the final

counts loaded on an aircraft at the departure station. List

contains a numeric summary of passenger counts and may contain passenger names Addition of element to allow unique identifier for passengers

RP 1719b

PASSENGER

RECONCILE LIST (PRL) The PRL is a list containing all passenger check

- in details

for actual boarded

pas sengers of a flight departure. Update to allow DCSs to correctly calculate the timeframe between flights to facilitate vetting by US authorities.

Addition of element to allow unique identifier for passengers

RP 1720a

STANDARD

THIRTEEN

- DIGIT

NUMBERING

SYS TEM FOR

TRAFFIC

DOCUMENTS Provides guidelines regarding the numbering systems for airline and travel agent traffic

documents Updates to provide IATA with several new form codes to satisfy the rapid

increase in use of electronic tickets

and electronic misc ellaneous

documents.Resolution/

Recommended

Practice Summary of

Resolution/RP Summary of Amendment

RP 1728

RESERVATIONS

AND TICKET

CODING

DIRECTORY Guidelines to encourage airlines to publish via the industry “Single Source RBD

Service” the reservations booking designator and the class of service code they

want to be used in their services in conjunction with a given fare basis code Updated to reflect that ATPCO is the source of the ‘Single Source RBD

Service’.

RP 1739

PASSENGER/

BAGGAGE

RECONCILIATION

PROCEDURES Guidelines to ensure that baggage is transported with the passenger on board Editorial update

RP 1740c

RADIO FRQUENCY

IDENTIFICATION (RFID)

SPECIFICATIONS

FOR INTERLINE

BAGGAGE Provides specifications for the development of radio frequency identification (RFID) technology to more efficiently handle (e.g.
sortation, reconc iliation, etc.) baggage, utilizing the license plate concept defined in

Resolution 740. Editorial update

RP 1745

BAGGAGE

INFORMATION

MESSAGES Provides the definitions, formats and specifications for all of the messages used in the baggage handling

proces s. Various editorial updates to clarify procedures

RP 1790

ADDITIONAL

SERVICES Guidelines to facilitate the
reservations, sales and delivery of airline additional

services Definitions for the EMD are revised.

References to ‘Sundry Charges’ are

deleted.

RP 1797

COMMON USE

PASSENGER

PROCESSING SYSTEMS (CUPPS) Provides guidelines for CUPPS systems that enable

airlines to share check

- in desks or gate podiums for boarding processes Various editorial updates to clarify procedures including truncation of

credit card numbers when used as a form of identification to comply with

PCI

- DSS requirementsRESOLUTION 003

STANDARD RECISSION RESOLUTION

PSC(33)003 Expiry: 2 June 2012 Type: B

M9

Resolved that, effective 1 June 2012, the following RP is rescinded:

RP 1737

- Automa ted Interline Revenue Data Exchange System (AIRDES)

Filing Period: Effective Date:

1 March

- 1 June 2012 13 April 2012RESOLUTION 720a

PASSENGER TICKET AND BAGGAGE CHECK

— ISSUANCE AND

HONOURING PROCEDURES (am ending)

PSC( 32 33 )720a Expiry: Indefinite Type: B

T2.12/P

....

15. TAX/FEE/CHARGE BOX 1

15.2.5 If there are not enough tax/fee/charge boxes on the ticket to accommodate all tax, fee and charge entries, combine as many amounts as necessary into one amount. Enter the amount in one tax/fee/charge box preceded or followed by the code “XT”. Detail the combined taxes, fees and charges in the fare calculation area after the fare calculation entries or, optionally, in the “Endorsement/Restrictions” box. Effective no

later than 1 February 2009 the tax code “XT” shall not be used for transmission of tax/fee/charge data in electronic tickets. This change shall not apply to electronic tickets issued prior to the date of system implementation.

Filing Period: Effective Date:

1 March

- 1 June 2012 13 April 2012RESOLUTION 722 TRANSITIONAL AUTOMATED TICKET (TAT) (amending)

PSC( 32 33 )722 Expiry: Indefinite Type: B

T2.31/P

3.16.7 Surcharge **(other than stopover and/or transfer charge)** 

3.16.7.1 Single Segment

When a surcharge (other than stopover and/or transfer charge) is applicable to a specific segment, imprint ‘Q’ followed by the amount immediately after the segment to which it applies. The same pr ocess shall be followed for documenting a surcharge on an unticketed point contained within the specific segment.

Example:
NYC_LH_FRA_Q15.00AZ_ROM

The above example also applies when LON is a surcharged unticketed point between

NYC and FRA.

T2.30/P

.. .

3.16.7.2 Multiple Segments

When a surcharge (other than a stopover and/or transfer charge) is applicable to

several consecutive or non

- consecutive segments, imprint ‘Q’ followed by the first and last cities of the segments to which the surcharge appli es, in the direction of travel, and

the amount. When the surcharge crosses multiple fare components, T t his entry shall be made at the end of the itinerary preceding the total amount in NUCs. When the surcharge is contained within a single fare component, t his entry shall be made at the end of the fare component to which the surcharge applies, preceding the fare component amount in NUCs.Example:
WAS_AF_PAR_AF_LON_BA_BAH M780.00Q_WASBAH156.00NUC936.00

Example (within one fare component):
WAS_AF_PAR_AF_ LON_BA_BAH_Q_WASBAH156.00M780.00NUC936.00

The above example may have been priced as:

WAS to BAH = 156.00 Or WAS to PAR equipment and LON to BAH equipment = 156.00

Example (crossing fare components):
WAS_TG_BKK_M1000.00_TG_WAS_M1000.00Q_WASWAS156.00NUC215 6.0

0

**Note:** Sleeper/berth surcharge may optionally be collected on an MCO.

3.16.7.3 Multiple Surcharges

3.16.7.3.1 Where more than one surcharge applies to a single segment

, they shall be shown separately directly after the segment to which they app ly

.

Example:

LON BB BKK Q75.00Q25.00CC TYO Q75.00M1000.00NUC1150.00

3.16.7.3.2 Where more than one surcharge applies on consecutive sectors imprint each separate ‘Q’ followed by the first and last ticketed cities, in the direction of travel, of

each sec tor to which the surcharges apply followed by the amount. When the surcharge crosses multiple fare components, this entry shall be made at the end of the itinerary preceding the total amount in NUCs. When the surcharge is contained within a single

fare com ponent, this entry shall be made at the end of the fare component to which the surcharge applies, preceding the fare component amount in NUCs.

Example (within one fare component):

LON BB FRA BB BKK M1000.00CCFRA CC LON Q BKKLON100.00Q

BKKLON75.00M1000.00 NUC2175.00END

Example (crossing fare components):
LON BB FRA BB BKK M1000.00CCFRA CC LON M1000.00Q_
LONLON100.00Q_LONLON75.00NUC2175.00ENDT2.12/P

....

3.19 TAX/FEE/CHARGE 1

3.19.1.5 If there are not enough “Tax/fee/charge” boxes on the ticket to acc ommodate all tax, fee and charge entries, combine as many amounts as necessary into one amount. Imprint the amount in one “Tax/Fee/Charge” box preceded or followed by the code “XT”. Detail the combined taxes, fees and charges in the fare calculation area a fter the fare calculation entries or, optionally, in the “Endorsements/Restrictions” box.

Effective no later than 1 February 2009 the tax code “XT” shall not be used for transmission of tax/fee/charge data in electronic tickets. This change shall not apply to electronic tickets issued prior to the date of system implementation.

.....

Filing Period: Effective Date:

1 March

- 1 June 2012 13 April 2012RESOLUTION 722f

ELECTRONIC TICKET

— AIRLINE (amending)

PSC( 32 33 )722f Expiry: Indefinite Type: B

T2.10/P

Section 3

– Definitions

...

3.5 ELECTRONIC MISCELLANEOUS DOCUMENT (EMD)

- An electronic record issued by a Member or its authorized agent, in accordance with applicable tariffs, for

residual value or f or the collection of miscellaneous charges. An EMD must be either

an EMD

- A or an EMD

- S.

T2.3/P

.....

Section 5

– Technical Specifications

....

5.4 COUPON STATUS INDICATORS

....

5.4.2 C Checked

- In

– Indicates the passenger is entitled to board. has mad e his/her presence known to the Marketing or Operating Carrier personally or via electronic means ( e i. g e. a self

- service device). It may indicate that the customer has checked baggage and/or secured a boarding pass. The carrier holding airport control shal l forward coupon status updates or return control to the Validating Carrier within 72 hours following the scheduled departure date/time for flight coupons with a current or future travel date, or within 72 hours following the date/time

control is obtained for flight coupons with a past travel date.

.....T2.13/P

5.4.8 N Coupon Notification

— Indicates coupon data for a coupon(s) not showing a
final status of E, F, G, P, J, R, or X , or Z and for which control of the coupon is not provided.

T2.16/P

S ection 5

– Technical Specifications

...

5.5 MESSAGES

...

5.5.3.5 Unsolicited Airport Control

– A message generated by the Validating Carrier to the Marketing /Operating Carrier providing airport control of an ET flight coupon(s). This message may also be sen t by the Operating Carrier, by including the Billing Carrier
Indicator, to advise the Billing Marketing Carrier of the Flown Ticket/Coupon(s) information. Response acknowledges receipt and may provide s “ Response Comments ” regarding the ET flight coupon(s ) , or denies the request

.

.....

T2.8/P

5.5.3.9 System Update

— A request from a carrier to associate or disassociate an

EMD

- A coupon(s) to or from an ET coupon . Response either ackno wledges or denies the request.

.....

T2.12/P

6.1.2 Tax and Special Fees/ Charges codes shall be used as published in the IATA Airline Coding Directory, section titled “ISO Codes and IATA Currency Codes and Ticket Codes for Taxes, Fees and Charges”. The tax/fee/charge code “XT” shall not be used for transmission of tax/fee/charg e data in electronic tickets and shall not be present in the

fare calculation of the ticket.

.....T2.15/P

Section 6

- Procedures

...

6.4 CONTROL

.....

6.4.6 Change of Status

When a carrier is being notified of a change of coupon status, only co upon(s) being changed shall be included in the ‘Change of Status’ message.

When the carrier holding control of the ET flight coupon(s) notifies the Validating Carrier of Coupon Status Indicator updates to FLOWN/USED via a ‘Change of Status’ message, the same Coupon Status Indicator shall be sent via a separate ‘Change of Status’ message for the corresponding EMD

- A value coupon(s).

The intent of the association between the ET flight coupon(s) and the EMD

- A value coupon(s) is to ensure the usage of the cou pons is synchronized.

If an EMD

- A coupon is not to be used, it shall be disassociated from the corresponding ET coupon using a System Update message for disassociation prior to sending a

‘C c hange of S s tatus ’ message to ‘FLOWN/USED’, for the corresponding ET coupon.

...T2.5/P 6.4.7 Request Airport Control

The Marketing or Operating Carrier shall request Airport Control from the Validating Carrier via a “Request Airport Control” message using Transaction Action “B”.

When a carrier obtains control of an ET flight coupon(s) indicating a corresponding

EMD

- A value coupon(s), that carrier shall also request Airport Control of the corresponding EMD

- A value coupon(s) from the Validating Carrier of the EMD

- A via a “Request Airport Control” message using Transac tion Action “B”.

T2.2/P

6.4.7.1 The Validating Carrier shall include in the “Response” message all sold coupon data, and current coupon data when different from sold, associated to the ticket, including conjunction tickets. Coupon data for which “Airport control” is not provided shall be included. (...)

6.4.7.1.1 When the carrier requesting control of an ET flight coupon(s) associated to an

EMD

- A value coupon(s) is not the Operating Carrier of the requested coupons, the Validating Carrier of the ET, if rel inquishing control, shall disassociate the EMD

- A value coupons from the ET flight coupon(s)

.

...

6.4.8 Unsolicited Airport Control

...

6.4.8.3 Only the Validating Carrier can relinquish control of an ET flight coupon to another carrier. A carrier may ret urn control only to the Validating Carrier.

6.4.8.4 If control of an ET flight coupon(s) which has an EMD

- A value coupon(s) associated to it is being passed to a carrier which is not the Operating Carrier of the requested coupons , the Validating Carrier o f the ET shall indicate the associated EMD

A value coupon(s) as disassociated in the "Unsolicited Airport Control" request. If the "Unsolicited Airport Control" request is accepted by the carrier, or if no response is received, the Validating Carrier shall disassociate the EMD

- A value coupon(s) from the ET flight coupon(s).

Note: Subsequent paragraphs to be renumbered.T2.16/P

6.4.10.5.1 The Operating Carrier may also send an Unsolicited Airport Control message to the Marketing Carrier, when the Mark eting Carrier is not the Billing Carrier, to provide flown coupon information.

...

T2.4/P

6.8 PRINT

...

6.8.2 Upon initiating a Print transaction, the carrier shall send a ‘System Update’ message to disassociate any remaining associated EMD

- A value coupo n(s) to the Validating Carrier of the EMD.

6.9 PRINT EXCHANGE

...

6.9.11 Upon initiating a Print Exchange transaction, the carrier shall send a ‘System Update’ message to disassociate any remaining associated EMD

- A value coupon(s) to the Validating Carrier of the EMD.

6.10 EXCHANGE/REISSUE

...

6.10.5 Upon initiating an Exchange/Reissue transaction, the carrier shall send a ‘System Update’ message to disassociate any remaining associated EMD

- A value coupon(s) to the Validating Carrier of the EMD.

6.11 REFUN D

...

6.11.4 Upon initiating a Refund transaction, the carrier shall send a ‘System Update’ message to disassociate any remaining associated EMD

- A value coupon(s) to the Validating Carrier of the EMD.T2.14/P

... 6.17 SYSTEM UPDATE

...

6.17.4 When the corresponding ET flight coupon(s) are other than final or suspend status, the receiving system shall not deny the System Update request. When the corresponding ET flight coupon(s) are at final or suspend status, the receiving system shall deny the system update request for association

.

RESOLUTION 722f

Attachment ‘A’

ELECTRONIC TICKET AND MISCELLANEOUS DOCUMENTS

DATA ELEMENTS GLOSSARY

T2.23/P

...

ADDITIONAL SERVICES ATTRIBUTE GROUP

– 3 ALPHANUMERIC (Applicable to 725f, 725g and 725h only)

A val ue which specifies the high

- level group applicable to the service at the coupon level as defined by ATPCO .

ADDITIONAL SERVICES ATTRIBUTE SUB GROUP

– 3 ALPHANUMERIC (Applicable to 725f, 725g and 725h only)

A value which specifies the Sub Group (within the specified Group) applicable to the service at the coupon level as defined by ATPCO.

...

ADDITIONAL SERVICES INDUSTRY CARRIER INDICATOR

– 1 ALPHANUMERIC (Applicable to 725f, 725g and 725h only)

An indicator which specifies whether the service uses an industry

- defined or carrier

defined Reason for Issuance Sub Code

I = Industry

C = Carrier...

ADDITIONAL SERVICES SERVICE TYPE

– 1 ALPHANUMERIC (Applicable to 725f, 725g and 725h only)

A value which specifies whether the service is for baggage al lowance, baggage charges, flight, merchandise, reissue/refund or ticket.

A = Baggage Allowance

C = Baggage Charges

F = Flight

M = Merchandise

R = Reissue Refund

T = Ticket

Blank = no application

T2.29/P

CARRIER FEE DATA

A series of data element s representing...

...

Carrier Fee Tax Amount

– 1 2 ALPHANUMERIC The amount of the tax applied.

T2.21/P

T2.22/P

...

CONSUMED AT ISSUANCE INDICATOR

— 1 ALPHANUMERIC (Applicable to EMD

- S only) (Applicable to 725g only)

Indicates a coupon(s) of an EMD

- S shall be considered ‘Flown/Used’ at issuance time as defined by the Marketing/Operating Carrier for an additional service

.

Y Consumed at Issuance

N Not Consumed at Issuance

Blank Not applicable

T2.19/P

...

COUPON VALUE

— 9 ALPHANUMERIC (applicable t o 725f, 725g and 725h only) (Shall not apply be present for any coupon in

the document when Fare Calculation a A rea, f F are c C alculation a A rea n N et a A mount

, or
f F are c C alculation s S ell a A mount data is present).

...

FARE CALCULATION AREA

— 87 ALPHANUMERIC (R epeatable field) (Shall not apply be present in the document when Coupon Value data is present)T2.20/P

...

PRODUCT CHARACTERISTIC TYPE

– 35 ALPHANUMERIC (applicable to 725f, 725g and 725h) (repeatable field)

Designates an optional service product char acteristic type (e.g. T

- shirt size, color or pre

reserved seat number)

PRODUCT CHARACTERISTIC VALUE

– 70 ALPHANUMERIC (applicable to 725f/g/h) (repeatable field)

Text that describes the product sold (e.g. large, blue) for corresponding Product

Characteri stic Type.

T2.26/P

...

REASON FOR ISSUANCE CODE

— 1 ALPHANUMERIC (applicable to 725f/20.63, 725g/20.64 and 725h/20.66 only), (Refer RP1790/10.90), (stored in passenger name record)

A Primary single character code, which defines the reason for issuanc e. Defined

Reason for Issuance Codes are listed below.

A Air Transportation

– to be used for all air transportation related sub

- codes (for example these include, but not limited to Charter, Involuntary Downgrading, Upgrading)

B Surface Transportation/Non Air Services

– to be used for all surface transportation/non air services related sub

- codes (for example these include, but

not limited to Bus, Car Hire)

C Baggage

– to be used for all baggage related sub

- codes (for example these
include, but not limited t o Angling Equipment, Biking Equipment)

D Financial Impact

– to be used for all financial impact related sub

- codes (for example these include, but not limited to Booking Reservation Change Fee, Refundable Balances)

E Airport Services

– to be used for all a irport services related sub

- codes (for example these include, but not limited to Check

- in, Lounge Access)

F Merchandise

– to be used for all merchandise related sub

- codes (for example
these include, but not limited to T

- shirt)

G Inflight Services

– to be u sed for all inflight services related sub

- codes (for example these include, but not limited to Sleeper Berth, Beverage)

...T2.18/P

REASON FOR ISSUANCE SUB

- CODE DESCRIPTION

– 70 ALPHANUMERIC (Repeatable field) (applicable to 725f, 725g, and 725h only )

Description of the service on the EMD at the coupon level. This description may differ

based on the associated Reason for Issuance Code and the Fee Owner Airline Designator.

Note: this element must only contain characters which are alpha or numeric or a combination of both. Characters such as /,

- , and . are not permitted.

T10

**...**

TAXES/FEE/CHARGE DATA AT THE TICKET COUPON LEVEL

....

Airport Code

- 5 ALPHA (Repeatable field)

The airport code identifying the airport to which the coupon tax applies

A pplicable Amount

– 11 ALPHANUMERIC (Repeatable field)

The tax amount applicable to the coupon as published in the IATA TTBS or other applicable filing mechanism.. This amount is expressed in the Coupon Tax Currency Type

.... Currency Type

– 4 ALPHANUMERIC (R epeatable field)

The ISO currency code representing the currency code in which the Coupon Tax Applicable Amount was published or filed in

...

Reported Amount

– 11 ALPHANUMERIC (Repeatable field) The tax amount applicable to a coupon expressed in the curre ncy of payment. This is the reported amount converted from the Coupon Tax Applicable Amount at applicable daily Bank Exchange Rate

... Segment Tax Airport Codes

- 6 ALPHA (Repeatable field)

The origin and destination airport codes identifying multiple segme nt taxes.**...**

TOTAL TICKET/DOCUMENT AMOUNT

– 12 ALPHANUMERIC T2.27/P

The sum of the base fare amount plus all applicable tax/fee/charge amount(s) preceded by the applicable ISO Currency Code or BT/IT.

The sum of the base or equivale nt fare (or fee for EMD) amount as applicable plus all tax/fee/charge amounts preceded by the ISO Currency Code. The field may contain BT/IT preceded by the ISO Currency Code. Refer to PSC Resolution 722 for further

information. The stated amount is exclus ive of Carrier Fees (for example, OA/OB/OC/OD).

TOTAL TICKET/DOCUMENT NET AMOUNT

– 12 ALPHANUMERIC The sum of the base net fare amount plus all applicable tax/fee/charge amount(s) preceded by the applicable ISO Currency Code or BT/IT.

The sum of the bas e or equivalent net fare (or fee for EMD) amount as applicable plus all tax/fee/charge amounts preceded by the ISO Currency Code. The field may contain BT/IT preceded by the ISO Currency Code. Refer to PSC Resolution 722 for further

information. The stated amount is exclusive of Carrier Fees (for example, OA/OB/OC/OD).

TOTAL TICKET/DOCUMENT SELL AMOUNT

– 12 ALPHANUMERIC The sum of the base net fare amount plus all applicable tax/fee/charge amount(s) preceded by the applicable ISO Currency Code or BT/IT.

The sum of the base or equivalent sell fare (or fee for EMD) amount as applicable plus all tax/fee/charge amounts preceded by the ISO Currency Code. The field may contain BT/IT preceded by the ISO Currency Code. Refer to PSC Resolution 722 for further

info rmation. The stated amount is exclusive of Carrier Fees (for example, OA/OB/OC/OD).RESOLUTION 722f

Attachment ‘B’

MESSAGE CONSTRUCTION MATRIX

– AIRLINE MESSAGES

T8

ELEMENT

DESCRIPTION

Transaction CHAR.
A, N

OR

A/N DISPLAY UNSOLI CITED

AIRPORT

CONTROL (INFORMATION

– ATA ONLY) HISTORY

DISPLAY REQUEST

AIRPORT

CONTROL CHANGE

OF STATUS REDIRECT

AIRPORT

CONTROL RESERVATION

CHANGE EMERGENCY

LOCK SYSTEM

UPDATE

Action Code

--

- > D, J T (I

– ATA

ONLY H B C N A M U

RESOLUTION

722 f REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP

... Carrier Fee Expiry Date (Applicable 722g) 4 A/ N

... Carrier Fee

Tax on Tax Currency Code (Applicable 722g) 3 A / N

...T10

ELEMENT DESCRIPTION

Transaction NO CHAR. A, N OR A/N DISPLAY UNOLICITED

AIRPORT

CONTROL HISTORY

DISPLAY REQUEST

AIRPORT

CONTROL CHANGE OF

STATUS REDIRECT

AIRPORT

CONTROL RESERVATION

CHANGE EM ERGENCY

LOCK SYSTEM

UPDATE

Action code

- > D,J T (I

- ATA only) H B C N A M U

RESOLUTION 722f REQ RES

P REQ RE

SP REQ RE

SP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP

... Tax/Fee/Charge Data at the Ticket Coupon Level

... Coupon Tax Airport Code 5A C C C Coupon Tax Reported Amount 11A / N C C C Coupon Tax Currency Type 4AN C C C Coupon Tax Applicable Amount 11A / N C C C Segment Tax Airport Codes 6A C C C

Filing Period: Effective Date:

1 March

- 1 June 2012 13 April 2012RESOLUTION 722g

ELECTRONIC TICKET

— NEUTRAL (amending)

PSC( 32 33 )722g Expiry: Indefinite Type: B

T2.10/P

Section 3

– Definitions

... 3.6 ELECTRONIC MISCELLANEOUS DOCUMENT (EMD)

- a A n electronic record issued by a Member or its authorized agent, in accordance with applicable tariffs, for

refundable value or for the collection of miscellaneous charges. An EMD must be either

an EMD

- A or an EMD

- S.

.... T2.3/P

.....

Section 5

– Technical Specifications

....

5.4 COUPON STATUS INDICATORS

.... 5.4.2 C Checked

- in

– Indicates the passenger is entitled to board. has made his/her presence known to the operating carrier personally or via electronic means ( e i. g e. a self

- service device). It may indicate that the customer has checked baggage and/or secured a boarding pass.

T2.12/P

....

Section 6

— Procedures

6.1 GENERAL

....

6.1.2 Tax and Special Fees/Charges codes shall be used as publi shed in the IATA Airline Coding Directory section titled “ISO Codes and IATA Currency Codes and Ticket Code for Taxes, Fees and Charges”. The tax/fee/charge code “XT” shall not be used for transmission of tax/fee/change data in electronic tickets and shall not be present in the

fare calculation of the ticket.T11

6.9 VOID ORIGINAL ISSUE OR EXCHANGE/REISSUE

...

6.9.3 Void Exchange/Reissue

...

6.9.3.5 When the Validating Carrier receives a Void message to cancel an ‘ET to EMD

S Exchange/Reissue’ request an d the EMD

- S is already at used status as a result of the presence of the Consumed at Issuance Indicator in the Issuance request , the Validating Carrier shall update the Coupon Status Indicator of the EMD

- S value coupon from ‘F’ to ‘V’ for Void and change t he coupon status of the exchanged/reissued ET flight coupon to ‘O’ for ‘Open for Use’ and transmit a Settlement Authorization Code or deny the
request.

.....T10

RESOLUTION 722g

Attachment ‘ B ’

ELECTRONIC TICKET MESSAGE CONSTRUCTION MATRIX

– NEUTRAL MESS AGES

....ELEMENT DESCRIPTION

Transaction NO CHAR. A, N OR

A/N ISSUANCE (INFORMATION

ATA ONLY) DISPLAY HISTORY

DISPLAY EXCHANGE/RE

ISSUE REFUND RESERVATION

CHANGE SYSTEM

CANCEL REFUND

CANCEL VOID

Action code

- > S (I

- ATA ONLY) D H E R A X,Y Z V,W

RESOLUTION 722g/20.61 REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP

... Tax/Fee/Charge Data at the Ticket Coupon Level

........................................................... Coupon Tax Airport Code 5A C C C Coupon Tax Reported Amount 11A / N C C C Coupon Tax Currency Type 4AN C C C Coupon Tax Applicable Amount 11A / N C C C Segment Tax Airport Codes 6A C C CT8

ELE MENT

DESCRIPTION

Transaction CHAR.
A, N

OR

A/N ISSUANCE

(INFORMATION

– ATA ONLY) DISPLAY HISTORY

DISPLAY EXCHANGE/

REISSUE REFUND RESERVATIONS

CHANGE SYSTEM

CANCEL REFUND

CANCEL VOID

Action Code

--

- > S(I

- ATA ONLY) D H E R A X,Y Z V,W

RESOLUTION

722 G REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP

... Carrier Fee

Amount 12 A/N C C C

Carrier Fee Application

Code 2 A/N C C C

Carrier Fee Approval C ode (Credit Card) 6 A/N C C C

Carrier Fee

Code 3 A/N C C C

Carrier Fee

Commercial

Name 30 A/N C C C C

...

Carrier Fee

Tax on Tax Currency Code 3 A /N C C C

Carrier Fee To

Air

port/City

Code 5 A/N C C C

...

T2.9/P

ELEMENT DESCRIPTION

Transaction NO CHAR
A, N OR A/N DISPLAY

Action code

--- > D

RESOLUTION 722 G REQ RESP

... In Connection With Coupon Number 1 N C

In Connecti on With Document Number 14 13 A/N C

In Connection With Qualifier 1 N C

......

Filing Period: Effective Date:

1 March

- 1 June 2012 13 April 2012RESOLUTION 722h

ELECTRONIC TICKET

– GROUND HANDLING (amending)

T2.3/P

PSC( 32 33 )722h Expiry: Indefinite Type: B

..... Section 3

– Definitions

....

3.2 COUPON STATUS INDICATORS

....

3.2.2 C Checked

- In

– Indicates that a the passenger is entitled to board. has been allocated a seat or accepted for standby on a specific f light, either in person by the Operating Carrier/Ground Handler or via electronic means e.g., self

- service device. It may indicate that the passenger has checked baggage and/or secured a boarding pass.

.... T2.13/P

3.2.8 N Coupon Notification

— Indicates c oupon data for a coupon(s) not showing a final status of E, F, G, P, R, or X , or Z and for which control of the coupon is not provided.

.... T2.10/P

Section 3

– Definitions

...

3.5 ELECTRONIC MISCELLANEOUS DOCUMENT (EMD)

- An electronic record issued by a Member or its authorized agent, in accordance with applicable tariffs, for

residual value or for the collection of miscellaneous charges. An EMD must be either

an EMD

- A or an EMD

- S.

.... T2.8/P

Section 5

– Technical Specifications

...

5.3 MESSAGES

...

5 .3.3.7 System Update

— A request from a Ground Handler to an Operating Carrier or from an Operating Carrier to a Ground Handler to associate or disassociate an EMD

- A coupon(s) to or from an ET coupon . Response either acknowledges or denies the
request.RESOLUTION 722h

Attachment ‘B’

MESSAGE CONSTRUCTION MATRIX

– GROUND HANDLING MESSAGES

T8

ELEMENT DESCRIPTION

Transaction CHAR.
A, N

OR

A/N DISPAY AIRPORT

CONTROL

REQUEST

– GROUND HANLDLING) CHANGE OF

STATUS REDIRECT EMERGENCY

LOCK UNSO LICITED

AIRPORT

CONTROL

–

GROUND

HANDLING SYSTEM

UPDATE

Action Code

--- > D G C N M K U

Resolution 722 h REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP

... Carrier Fee Expiry Date (Applicable 722g) 4 A/ N

... Carrier Fee Tax on Tax Currency Code (Applicable 722g) 3 A /N

... T10

ELEMENT DESCRIPTION

Transaction CHAR.
A, N

OR A/N DISPLAY AIRPORT CONTROL

REQUEST

– GROUND

HANDLING CHANGE OF STATUS REDIRECT AIRPORT

CONTROL EMERGENCY LOCK UNSOLICITED AIRPORT

CONTROL

– GROUND

HANDLING

Action code

- > D G C N M A

RESOLUTION 722h REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP

... Tax/Fee/Charge Data at the Ticket Coupon Level

................. Coupon Tax Airport Code (Applicable 722f/722g) 5A

Coupon Tax Reported Amount (Applicable 722f/722g) 11A

N Coupon Tax Currency Type (Applicable 722f/722g) 4AN

Coupon Tax Applicable Amount (Appl icable 722f/722g) 11A

N Segment Tax Airport Codes (Applicable 722f/722g) 6A

Filing Period: Effective Date:

1 March

- 1 June 2012 13 April 2012RESOLUTION 725 a MISCELLANEOUS CHARGES ORDER (MCO)

– ISSUANCE AND HONOURING PROCEDURES BY MEMBERS (amending) PSC( 24 33 )725 Expiry: Indefinite Type: A

T4

..... Section 5

– Electronic Miscellaneous Documents

5.1

. ELECTRONIC MISCELLANEOUS DOCUMENT (EMD) FEE CALCULATION

5.2 Fee Calculation shall be provid ed on an EMD for the entire EMD itinerary when there is no Coupon Value data element present.

5.3 All amounts shall be in the currency of payment

5.4 When equipment constraints prohibit the parentheses, an asterisk(s) may be

used.

5.5 Routing Sequence shall be shown as follows:

5.5.1 L ist city codes and carrier codes in alternating order, separated by a space.

Example:
LON_AF_PAR_LH_FRA

**Note 1:** The underlining shows where spaces are to occur, but the underlining shall not appear on the ticket.

**Note 2:**  Three

- letter airline designators shall appear in the Fee Calculation as set forth in Resolution 722, Attachment ‘C’, Key, paragraph 3.

**Note 3** : The carrier in the Fee Calculation should be the Marketing Carrier

5.5. 2 Show all routing points that represe nt the beginning or end of a segment;

5.5 .3 When multiple identical services apply for one coupon/portion of travel, the total for this coupon/portion of travel shall be shown in the Fee Calculation. In the below example there are 1 service charge of EUR 66.00 on LHR

- SIN coupon and 2 service charges of EUR66.50 each on SIN

- SYD coupon.

Example:
LON_6X_SIN66.00_6X_SYD133.00EUR199.00 END

5.5 .4 Separate EMDs shall be issued when multiple non

- identical services apply for one coupon/portion of travel. Service i tineraries expressed in the Fee Calculation shall be shown sequentially.

5.6 P recede by the symbol “X/” any point on the routing at which no stopover is permitted.T4

5.7 When there is a break in the service itinerary, replace the carrier code with a n oblique and a hyphen “/

- ”.

Example:
BOS_BB_NYC66.00/

- WAS_CC_FRA100.00END

5.8 W hen a fee covers multiple segments which include a surface sector, replace the carrier code with two obliques “//”.

Example:
BOS_BB_NYC//WAS_CC_FRA100.00END

5.9 Show the total sum of the Fee Calculation entries as the last entry, preceded by the ISO currency code of the currency of payment.

5.10 END

- denotes end of the Fee Calculation.

5.11 Items shall be separated by spaces except where alphabetic characters are

foll owed by numerics or signs or vice versa. A space shall, however, be maintained between a location identifier and an airline designator whether or not the airline designator is a numeric

- alpha designator. At such time as three

- letter airline designators

ar e implemented, the space preceding these designators shall be replaced by a period.

5.12 Fee Calculation Examples

The following examples demonstrate the intended use of the Fee Calculation on an

Electronic Miscellaneous Document.

This example shows two fees priced, one per segment:

LON

_ 6X

_ SIN66.00

_ 6X

_ SYD100.00EUR166.00END

This example shows one fee priced over more than one segment:

LON

_ 6X

_ SIN

_ 6X

_ SYD166.00EUR166.00END

This example shows two fees, both priced over more than one segment on a return

itin erary: LON_6X_SIN_6X_SYD166.00_6X_SIN_6X_LON166.00EUR332.00END

This example shows a break in service between two fees:
LON_6X_FRA100.00/

- SIN_6X_SYD166.00EUR266.00END

This example shows a break in service between two fees sequentially priced over more

tha n one segment (LON

- SIN

- SYD appears twice in the passenger itinerary):

LON 6X SIN 6X SYD100.00/

- LON 6X SIN 6X SYD50.00GBP150.00END

Filing Period: Effective Date:

1 March

- 1 June 2012 13 April 2012RESOLUTION 725 b

MISCELLANEOUS CHARGES O RDER (MCO)

– ISSUANCE AND HONOURING PROCEDURES (AGENTS) (amending) PSC( 24 33 )725 b Expiry: Indefinite Type: A

T4

..... Section 5

– Electronic Miscellaneous Documents

5.1. ELECTRONIC MISCELLANEOUS DOCUMENT (EMD) FEE CALCULATION

5.2 Fee Cal culation shall be provided on an EMD for the entire EMD itinerary when there is no Coupon Value data element present.

5.3 All amounts shall be in the currency of payment

5.4 When equipment constraints prohibit the parentheses, an asterisk(s) may be

used

.

5.5 Routing Sequence shall be shown as follows:

5.5.1 L ist city codes and carrier codes in alternating order, separated by a space.

Example:
LON_AF_PAR_LH_FRA

**Note 1:** The underlining shows where spaces are to occur, but the underlining shall not

app ear on the ticket.

**Note 2:** Three

- letter airline designators shall appear in the Fee Calculation as set forth in Resolution 722, Attachment ‘C’, Key, paragraph 3.

**Note 3** : The carrier in the Fee Calculation should be the Marketing Carrier

5.5.2 Show all rou ting points that represent the beginning or end of a segment;

5.5.3 When multiple identical services apply for one coupon/portion of travel, the total for this coupon/portion of travel shall be shown in the Fee Calculation. In the below example there are 1 service charge of EUR66.00 on LHR

- SIN coupon and 2 service charges of EUR66.50 each on SIN

- SYD coupon.

Example:
LON_6X_SIN66.00_6X_SYD133.00EUR199.00 END

5.5.4 Separate EMDs shall be issued when multiple non

- identical services apply for one coupon/port ion of travel. Service itineraries expressed in the Fee Calculation shall be shown sequentially.

5.6 P recede by the symbol “X/” any point on the routing at which no stopover is permitted.T4

5.7 When there is a break in the service itinerary, replace the carrier code with an oblique and a hyphen “/

- ”.

Example:
BOS_BB_NYC66.00/

- WAS_CC_FRA100.00END

5.8 W hen a fee covers multiple segments which include a surface sector, replace the carrier code with two obliques “//”.

Example:
BOS_BB_NYC//WAS_CC_FRA1 00.00END

5.9 Show the total sum of the Fee Calculation entries as the last entry, preceded by the ISO currency code of the currency of payment.

5.10 END

- denotes end of the Fee Calculation.

5.11 Items shall be separated by spaces except where alphab etic characters are followed by numerics or signs or vice versa. A space shall, however, be maintained between a location identifier and an airline designator whether or not the airline designator is a numeric

- alpha designator. At such time as three

- lette r airline designators are implemented, the space preceding these designators shall be replaced by a period.

5.12 Fee Calculation Examples

The following examples demonstrate the intended use of the Fee Calculation on an

Electronic Miscellaneous Document.

This example shows two fees priced, one per segment:

LON

_ 6X

_ SIN66.00

_ 6X

_ SYD100.00EUR166.00END

This example shows one fee priced over more than one segment:

LON

_ 6X

_ SIN

_ 6X

_ SYD166.00EUR166.00END

This example shows two fees, both priced over more than one segment on a return itinerary:
LON_6X_SIN_6X_SYD166.00_6X_SIN_6X_LON166.00EUR332.00END

This example shows a break in service between two fees:
LON_6X_FRA100.00/

- SIN_6X_SYD166.00EUR266.00END

This example shows a break in service between two fees sequentia lly priced over more than one segment (LON

- SIN

- SYD appears twice in the passenger itinerary):

LON 6X SIN 6X SYD100.00/

- LON 6X SIN 6X SYD50.00GBP150.00END

Filing Period: Effective Date:

1 March

- 1 June 2012 13 April 2012RESOLUTION 7 25d AUTOMATED MISCELLANEOUS CHARGES ORDER (MCO)

— NEUTRAL (COUPON

- BY

- COUPON) (amending)

PSC( 32 33 )725d Expiry: Indefinite 31 December 2013 Type: B

T2.32/P

RESOLVED that:

Applicable to IATA BSPs: the provisions of this resolution shall apply in respect of imprinting on blank card or plain paper. No exchange value coupon is produced. The provisions of this resolution shall expire 31 December 2013.

Filing Period: Effective Date:

1 March

- 1 June 2012 13 April 2012RESOLUTION 725f

ELECTRONIC MISCELLANEOUS DOCUMENT

— AIRLINE (amending)

PSC( 32 33 )725f Expiry: Indefinite Type: B

T2.10/P

Section 3

– Definitions

...

3.5 ELECTRONIC MISCELLANEOUS DOCUMENT (EMD)

- An electronic record issued by a Member or its authorized agent, in accordance with applicable tariffs, for

residual value or for the collection of miscellaneous charges. An EMD must be either

an EMD

- A or an EMD

- S.

.....

T2.3/P

T2.24/P

Section 5

– Technical Specifications

...

5.4 COUPON STATUS I NDICATORS

5.4.1 A Airport Control

- Indicates a carrier or Ground Handler has secured the EMD value coupon(s) prior to use.

.... 5.4.2 C Checked

- In

– Indicates that the service (s) associated to an ET flight coupon has been recognized or acknowledged. the passenger has presented an EMD to the Marketing or Operating Carrier. ( O o nly applicable to EMD

- A)

.

...

5.4.6 I Irregular Operations

- Indicates the carrier holding control is extending control beyond the normal 72 hour period provided for under Airp ort Control, Checked

- In or

Lifted/Boarded status. This extension may not exceed 7 days from original scheduled departure of the associated ET flight coupon (only applicable to EMD

- A).

...5.4.10 R Refund ed

- Indicates the unused value of the EMD v alue coupon(s) has been returned/remitted to the passenger/purchaser.

...

5.4.12 U Unavailable

- Indicates the Validating Carrier has determined the EMD value coupon(s) is no longer available for use as issued.

5.4.13 V Void

- Indicates cancellat ion of the entire EMD sale or exchange/reissue transaction within the Validating Carrier’s reporting period.

5.4.14 Y Refund Taxes/Fees/Charges Only

- Indicates the Validating Carrier has

determined the EMD value coupon(s) is no longer available for u se as issued ticketed

.

.... T2.8/P

Section 5

– Technical Specifications

...

5.5 MESSAGES

... 5.5.3 The following are EMD Messages:

... 5.5.3.4 System Update

— A request from a carrier to associate or disassociate an

EMD

- A coupon(s) to or from an ET coupon . Response either acknowledges or denies the request.

T2.25/P

5.5.3.5 Unsolicited Billing

– A message generated by the Operating Carrier to advise the Billing Carrier of the Flown/Used EMD/Coupon(s) information when a special settlement agreement exist s. This shall provide the Billing Carrier the information needed to settle the EMD/Coupon(s) with the Validating Carrier.

T2.11/P

Section 6

- Procedures

... 6.1 GENERAL

...6.1.10 EMD

- Associated

... 6.1.10.3 Prior to Upon coupon status updates to Closed, Exc hanged/Reissued, Refund

, Suspend or Void of an associated EMD

- A record value coupon(s) , the EMD

- A record value coupon(s) shall be disassociated from the corresponding ET record flight coupon(s) using a System Update message for disassociation.

T2. 1/ P

T2 .2/P

6.5 CONTROL

... 6.5.7 EMD

- Stand

- alone

6.5.7 When a carrier requesting control of an EMD

- A value coupon(s) associated to ET an flight coupon(s) is not the Operating Carrier of the requested coupon(s), the Validating Carrier, if relinquishing control , shall disassociate the EMD

- A value coupon(s) from the associated ET flight coupon(s)

6.5.7.1 Any carrier may request control of an EMD value coupon(s) from the Validating Carrier in accordance with EMD bilateral agreements.

6.5.8 EMD

- Associated

6.5. 8.1 Any carrier holding control of an ET flight coupon(s) may request control of the corresponding EMD value coupon(s) from the Validating Carrier in accordance with EMD bilateral agreements.

Note: Subsequent paragraphs to be renumbered.T2.25/P

...

6.5.11 Code Share

6.5.11.1 For special settlement arrangements where the Billing Carrier will settle the

Flown /Used coupon(s) with the Validating Carrier, the Operating Carrier must include the Billing Airline Designator in the Change Of Status message to the Validating Carrier.

...

6.5.11.3 When the Operating Carrier receives the response message for the Change of Status Message including the Settlement Authorization code for the Billing Carrier, they

will send an Unsolicited Airport Control Billing messa ge to the Billing Carrier including the Settlement Authorization code received from the Validating Carrier. The Coupon Statuses shall be as received by the Operating Carrier and the EMD/Coupon(s) to be

settled shall have F status and the Settlement Authori zation code included. The Transaction Action is “L” for Unsolicited Billing message as shown in the Message

Construction Matrix in Attachment B.

....T2.25/P

RESOLUTION 725f

Attachment ‘B’

ELECTRONIC MISCELLANEOUS DOCUMENT MESSAGE CONSTRUCTION

MATRIX

— AIRLINE MESSAGEST2.23/P

ELEMENT

DESCRIPTION

Transaction CHAR.
A, N

OR

A/N DISPLAY REQUEST AIRPORT

CONTROL CHANGE

OF STATUS SYSTEM

UPDATE

Action Code

--- > D, J B C U

RESO LUTION 725f REQ RESP REQ RESP REQ RESP REQ RESP

... Additional Services Attribute Group 3 A/N O O

Additional Services

Attribute Sub

- Group 3 A/N O O

... Additional Services Industry Carrier

Indicator 1 A/N O O

... Additional Services Service Type 1 A/N O O

...

T8

ELEMENT

DESCRIPTION

Transaction CHAR.
A, N

OR

A/N DISPLAY REQUEST AIRPORT

CONTROL CHANGE

OF STATUS SYSTEM

UPDATE

Action Code

--- > D, J B C U

RESOLUTION 725 f REQ RESP REQ RESP REQ RESP REQ RESP

... Carrier Fee Code (Applicable 725g) 3 2 A/N

... Carrier Fee Expiry Date (Applicable 725g) 4 A/ N

Carrier Fee Fare Component Number (Applicable 725g) 2 A/N

Carrier Fee Fare Component Rule Code (Applicable 725g) 3 A/N

Carrier Fee Fare Component Rule Matching Fare Class (Applicable 725g) 8 A/N

Carrier Fee Fare Component Rule

Number (Applicable 725g) 4 A/N

Carrier Fee Fare Component Tariff

Number (Applicable 725 g) 3 N

... Carrier Fee Form of Payment Credit Card

Vendor Code (Applicable 725g) 2 A /N

... Carrier Fee Owner (Applicable 725g) 3 A/N

... Carrier Fee Tax on Tax Currency Code (Applicable 725g) 3 A /N

...T10

ELEMENT DESCRIPTION

Transaction NO CHAR.
A, N OR A/N DISPLAY REQUEST AIRPORT CONTROL CHANGE OF STATUS SYSTEM UPDATE

Action code

- > D B C U

RESOLUTION 725f REQ RESP REQ RESP REQ RESP REQ RESP

... Tax/Fee/Charge Data at the Ticket Coupon

Level

................................................ Coupon Tax Airport Code 5A C C Coupon Tax Reported Amount 11AN C C Coupon Tax Currency Type 4AN C C Coupon Tax Applicable Amount 11AN C C Segment Tax Airport Codes 6A C CT2.20/P

ELEMENT DESCRIPTION

Transaction CHAR.

A, N

OR

A/N DISPLAY REQUEST AIRPORT

CONTROL CHANGE

OF STATUS SYSTEM

UPDATE

Action Code

--- > D B C U

RESOLUTION 725f REQ RESP REQ RESP REQ RESP REQ RESP

... Pr

oduct Characteristic Type 35 A/N O O

Product Characteristic

Value 70 A/N O O

...

Filing Period: Effective Date:

1 March

- 1 June 2012 13 April 2012RESOLUTION 725g

ELECTRONIC MISCELLA NEOUS DOCUMENT

— NEUTRAL (amending)

PSC( 32 33 )725g Expiry: Indefinite Type: B

T2.10/P

Section 3

– Definitions

...

3.7 ELECTRONIC MISCELLANEOUS DOCUMENT (EMD)

- An electronic record issued by a Member or its authorized agent, in accordance with a pplicable tariffs, for

refundable value or for the collection of miscellaneous charges. An EMD must be either

an EMD

- A or an EMD

- S.

....

T2.3/P

Section 5

– Technical Specifications

...

5.4 COUPON STATUS INDICATORS

5.4.1 A Airport Control

- Indi cates a carrier or Ground Handler has secured the EMD value coupon(s) prior to use.

5.4.2 C Checked

- In

– Indicates that the service (s) associated to an ET flight coupon has been recognized or acknowledged. the passenger has presented an EMD to the

Mark eting or Operating Carrier. ( O o nly applicable to EMD

- A)

.

T2.24/P

5.4.3 E Exchanged/Reissued

- Indicates the value of the EMD value coupon (s) has

been used as in payment for a new transaction.

5.4.4 F Flown/Used

- Indicates the EMD value coupon has been used and is now eligible for billing/revenue reporting . Status to be set by the carrier holding control only.

5.4.5 I Irregular Operations

- Indicates the carrier holding control is extending control beyond the normal 72 hour period provided for under Airport Control, Checked

- In or

Lifted/Boarded status. This extension may not exceed 7 days from original scheduled departure of the associated ET flight coupon (only applicable to EMD

- A).5.4.7 O Open For Use

- Indicates the EMD value coupon(s ) is available for use eligible for all coupon status updates

.

5.4.8 R Refunded

- Indicates the unused value of the EMD value coupon(s) has been

returned /remitted to the passenger/purchaser.

5.4.9 S Suspended

- Indicates the Validating Carrier has restricted the use of the

EMD value coupon(s)

.

5.4.10 U Unavailable

- Indicates the Validating Carrier has determined the EMD value coupon(s) is no longer available for use as issued ticketed

.

5.4.11 V Void

- Indicates cancellation of the entire EM D sale or exchange/reissue transaction within the Validating Carrier’s reporting period.

5.4.12 Y Refund Taxes/Fees/Charges Only

- Indicates the Validating Carrier has

determined the EMD value coupon(s) is no longer available for use as issued tickete d

.

....

T2.29/P

T11

Section 6

- Procedures

...

6.6 VOID

...

6.6.9.1 EMD

- Stand

- alone

...

6.6.11 When the Validating Carrier receives a Void message to cancel an ‘EMD to

EMD

- S Exchange/Reissue’ request and the EMD

- S is already at used status as a resu lt

of the presence of the Consumed at Issuance Indicator i n the Issuance request , the Validating Carrier shall update the Coupon Status Indicator of the EMD

- S value coupon from ‘F’ to ‘V’ for Void and change the coupon status of the exchanged/reissued EMD value coupon to ‘O’ for ‘Open for Use’ and transmit a Settlement Authorization Code or deny the request.

...

6.7 REFUND CANCEL

...

6.7.3 The data elements to be included in the ‘Refund Cancel’ message are shown in the Message Construction Matrix in IATA R esolution 722, Attachment ‘B.

...6.8 SYSTEM CANCEL

...

6.8.2 The data elements to be included in the ‘System Cancel’ message are shown in the Message Construction Matrix in IATA Resolution 722, Attachment ‘B’.

...

6.8.7 EMD

- Stand

- alone

6.8.7.1 When t he Validating Carrier receives a system cancel request and the EMD is already at used status as a result of the presence of the ‘Consumed at Issuance

Indicator’ in the issuance request the Validating Carrier shall update the Coupon Status

Indicator from ‘F ’ to ‘V’ for Void. If the original request was an ‘Exchange/Reissue’ EMD message, the Validating Carrier shall update the Coupon Status Indicator of the exchanged/reissued EMD value coupon with ‘O’ for ‘Open For Use’, and if applicable, update the Coupon S tatus Indicator of the new EMD from ‘F’ to ‘V’ for Void.

....

RESOLUTION 725g

Attachment ‘B’

ELECTRONIC MISCELLANEOUS DOCUMENT MESSAGE

CONSTRUCTION MATRIX

— NEUTRAL MESSAGES

T2.23/P

ELEMENT

DESCRIPTION

Transaction CHAR.
A, N

OR

A/N ISSUAN CE DISPLAY HISTORY

DISPLAY EXCHANGE/

REISSUE REFUND SYSTEM

CANCEL REFUND

CANCEL VOID

Action Code

--

- > S D H E R X,Y Z V,W

RESOLUTION

725 G REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP

... Additional

Services Attribute Group 3 A/N O O O O O O

Additional

Services

Attribute Sub

Group 3 A/N O O O O O O

... Additional

Services Industry

Carrier

Indicator 1 A/N O O O O O O

... Additional

Servi ces Service Type 1 A/N O O O O O O

...T8

ELEMENT

DESCRIPTION

Transaction CHAR.
A, N

OR

A/N ISSUANCE DISPLAY HISTORY

DISPLAY EXCHANGE/

REISSUE REFUND SYSTEM

CANCEL REFUND

CANCEL VOID

Action Code

--

- > S D H E R X,Y Z V,W

RESOLUTION

725 G REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP

... Carrier Fee

Code 3 2 A/N

... Carrier Fee

Fare Component

Number 2 A/N C C C

C arrier Fee

Fare Component

Rule Code 3 A/N C C C

Carrier Fee

Fare Component Rule Matching

Fare Class 8 A/N C C C

Carrier Fee

Fare Component

Rule Number 4 A/N C C C

Carrier Fee

Fare Component

Tariff Number 3 N C C C

... Carrier Fee

Owner 3 A/N C C C

... Carrier Fee

Tax on Tax Currency Code 3 A /N C C C

Carrier Fee To Airport City

Code 5 A/N C C C

...T11

ELEMEN T

DESCRIPTION

Transaction CHAR.

A, N

OR

A/N ISSUANCE DISPLAY HISTORY DISPLAY EXCHANGE/

REISSUE REFUND SYSTEM

CANCEL REFUND

CANCEL VOID

Action Code

--

- > S(I

- ATA ONLY) D H E R X,Y Z V,W

RESOLUTION

725 G REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP

... Consumed At

Issuance

Indicator 1 A/N C C C

...

T10

ELEMENT DESCRIPTION

Transaction NO CHAR.
A, N OR A/N ISSUANCE DISPLAY HISTORY DISPLAY EXCHAN GE/REISS

UE REFUND SYSTEM CANCEL REFUND CANCEL VOID

Action code

- > S D H E R X,Y Z V,W

RESOLUTION 725g REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP

... Tax/Fee/Charge Data at the Ticket Coupon Level

........................................................... Coupon Tax Airport Code 5A C C C Coupon Tax Reported Amount 11AN C C C Coupon Tax Currency Type 4AN C C C Coupon Tax Applicable Amount 11AN C C C Segme nt Tax Airport Codes 6A C C CT2.9/P

ELEMENT DESCRIPTION

Transaction NO CHAR
A, N OR A/N

Action code

--- >

RESOLUTION 725G

...

In Connection With Document Number 14 13 A/N

......

T2.20/P

ELEMENT

DESCRIPTION

Transa ction CHAR.
A, N

OR

A/N ISSUANCE DISPLAY HISTORY

DISPLAY EXCHANGE/

REISSUE REFUND SYSTEM

CANCEL REFUND

CANCEL VOID

Action Code

--

- > S D H E R X,Y Z V,W

RESOLUTION

725 G REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RE SP

... Product

Characteristic Type 35 A/N O O O O O

Product

Characteristic

Value 70 A/N O O O O O

...

T2.17/P

ELEMENT

DESCRIPTION

Transaction CHAR.
A, N

OR

A/N ISSUANCE DISPLAY HISTORY DISPLAY EXCHANGE/

REISSUE REFUND SYSTEM

CANCEL REFUND

CANCEL VOID

Action Code

---

> S(I

- ATA ONLY) D H E R X,Y Z V,W

RESOLUTION

725 G REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP

... Reason for

Is

suance Sub

Code 3 A/N M M C M M M C

...

Filing Period: Effective Date:

1 March

- 1 June 2012 13 April 2012RESOLUTION 725h

ELECTRONIC MISCELLANEOUS DOCUMENT

— GROUND HANDLING (amending)

PSC( 32 33 )725h Expiry: Indefinite Type: B

T2.3/P

Section 3

– Definitions

...

3.2 COUPON STATUS INDICATORS

3.2.1 A Airport c C ontrol

- Indicates a carrier or Ground Handler has secured the EMD value coupon(s) prior to use.

3.2.2 C Checked

- In

– Indicat es that the service (s) associated to an ET flight coupon has been recognized or acknowledged. the passenger has presented an EMD to the Marketing or Operating Carrier and the delivery of the service has been accepted

. ( O o nly applicable to EMD

- A).

T2.24/P

3.2.3 E Exchanged/Reissued

- Indicates the value of the EMD value coupon(s) has been used in payment for a new transaction.

3.2.4 F Flown/Used

- Indicates the value associated with the EMD value coupon has been used and is now eligible for billing/ revenue reporting. Status to be set by the carrier holding control only.

...

3.2.12 U Unavailable

- Indicates the Validating Carrier has determined the EMD value coupon(s) is no longer available for use as issued ticketed

.

3.2.13 V Void

- Indic ates cancellation of the entire electronic sale record EMD sale or exchange/reissue transaction within the Validating Carrier’s reporting period.

3.2.14 Y Refund Taxes/Fees/Charges Only

- Indicates the Validating Carrier has

determined the EMD value c oupon(s) is no longer available for use as issued ticketed

.

5.4.15 3.2.15 Z Closed

- Indicates the Validating Carrier has determined that the EMD

value coupon(s) is not available for use.T2.10/P

Section 3

– Definitions

...

3.5 ELECTRONIC MISCELL ANEOUS DOCUMENT (EMD)

- An electronic record issued by a Member or its authorized agent, in accordance with applicable tariffs, for

residual value or for the collection of miscellaneous charges. An EMD must be either

an EMD

- A or an EMD

- S.

....

T2.8/P

Section 5

– Technical Specifications

...

5.3 MESSAGES

...

5.3.3.4 System Update

— A request from a Ground Handler to an Operating Carrier or from an Operating Carrier to a Ground Handler to associate or disassociate an EMD

- A coupon(s) to or from an ET coupo n . Response either acknowledges or denies the
request.

....

RESOLUTION 725h

Attachment ‘B’

ELECTRONIC MISCELLANEOUS DOCUMENT MESSAGE

CONSTRUCTION MATRIX

— GROUND HANDLING

T2.23/P

ELEMENT DESCRIPTION

Transaction CHAR.
A, N

OR

A/N DISPAY AIR PORT

CONTROL

REQUEST

– GROUND HANLDLING) CHANGE OF

STATUS SYSTEM

UPDATE

Action Code

--- > D G C U

Resolution 725 h REQ RESP REQ RESP REQ RESP REQ RESP

... Additional Services Attribute Group 3 A/N O O

Additional Services

Attribute Sub

- Group 3 A/N O O

... Additional Services Industry

Carrier Indicator 1 A/N O O

... Additional Services Service Type 1 A/N O O

...T8

ELEMENT DESCRIPTION

Transaction CHAR.
A, N

OR

A/N DISPAY AIRP ORT

CONTROL

REQUEST

– GROUND HANLDLING) CHANGE OF

STATUS SYSTEM

UPDATE

Action Code

--- > D G C U

Resolution 725 h REQ RESP REQ RESP REQ RESP REQ RESP

... Carrier Fee Code (Applicable 725g) 3 2 A/N

... Carrier Fee Tax on Tax Currency Code (Applicable 725g) 3 A /N

...T10

ELEMENT DESCRIPTION

Transaction NO CHAR.
A, N OR A/N DISPLAY AIRPORT CONTROL REQUEST

– GROUND

HANDLING CHANGE OF STATUS SYSTEM UPDATE

Action code

- > D G C U

RESOLUTION 725h REQ RESP REQ RESP REQ RESP REQ RESP

... Tax/Fee/Charge Data at the Ticket Coupon

Level

... Coupon Tax Airport Code (applicable 725f and 725g) 5A

Coupon Tax Reported Amount (applicable 725f and 725g) 11AN

Coupon Tax Currency Type (applicable 725f and 725g) 4AN

Coupon Tax Applicable Amount (applicable 725f and 725g) 11AN

Segment Tax Airport Codes (applicable 725f and 725g) 6A

T2.20/P

ELEMENT

DESCRIPTION

Transaction CHAR.
A, N

OR

A/

N DISPLAY REQUEST AIRPORT CONTROL

GROUND HANDLING CHANGE

OF STATUS SYSTEM

UPDATE

Action Code

-  D G C U

RESOLUTION 725

h REQ RESP REQ RESP REQ RESP REQ RESP

... Product Characteristic Type 35 A/N O O

Product

Characteristic

Value 70 A/N O O

...

Filing Period: Effective Date:

1 March

- 1 June 2012 13 April 2012RESOLUTION 726e MULTIPLE PURPOSE DOCUMENT (MPD)

— NEUTRAL, CARBONISED, MANUAL (amending)

PSC( 32 33 )726e Expiry: Indefinite 31 December 2013 Type: B

T2.32/P

RESOLVED that: In countries/Areas where a Billing and Settlement Plan (BSP) has been impleme nted the provisions of this resolution shall apply only in respect of MPDNMs supplied in a virtual

format version distributed and issued via IATA BSP link

. The provisions of this resolution shall expire 31 December 2013.

Filing Pe riod: Effective Date:

1 March

- 1 June 2012 13 April 2012RESOLUTION 728

CODE DESIGNATORS FOR PASSENGER TICKET AND BAGGAGE CHECK (amending)

PSC( 32 33 )728 Expiry: Indefinite Type: B

T9

RESOLVE D that:

....

4.2 Special Fees and Charges Codes Special Fees and Charges Codes are assigned to identify taxes, fees and charges which are collected at the time of ticket issuance, entered in the “TAX/FEE/CHARGE” box, and are paid or payable to government ag encies and airport authorities. When applying to IATA for a new Special Fees and Charges Code or applying to use an ISO code, or advising IATA about amendments to an existing code, the Application Form in

Attachment “B” supplied separately by the IATA Tick et Tax Box Service (TTBS) shall be used. Only one code will be assigned for the same type Special Fee or Charge for multiple airports within a country. If the same type of Special Fee or Charge has different rules for domestic/international, separate Speci al Fees or Charges Codes may be assigned by IATA. For a full listing of ticket codes, refer to the IATA Airline Coding Directory.T2.35/P

...

4.2.1 Format for Code Assignment

. Members and System Providers shall be ready to receive and proces s alphanumeric TFCs codes in accordance with the provisions of this resolution no later than 30 June

2012.T5

...

7. FORM OR PAYMENT CODE (mandatory)

...

CREDIT CARD CODES (APLPHA) 1, 3

...

Commercial Company Credit Cards International Payment Cards

Ac cess Air ZA American Express /Optima Card AX 2

Australian Bankcard AB

Bank of Boroda “Bobcard” BB

Bank of Hawaii BH Bank Card of Japan BC

Canara Bank “Cancard” CD

Carte Aurore AU

Carte Blanche CB 2

Citizens and Southern National Bank CS Cofinoga Credit Card CG

Comites ID Connecticut Bank and Trust Company CU

Diamond Credit MD

Discover Card DS

Diners Club /American Torch Club/Sun Diners Club DC 2

Empire Card MT

Fédération Nationale de l'Industrie Hotelière FH HiperCard HC Japan Credit Bureau JC 2

Masterc ard CA 2

Million Credit Service MC

Nativa NT

OTB Card OT

Presto PR

Select Credit SR Shoppers Charge SCTrust Card TC

Union Credit UD

United Debi t Credit Center UI

VISA International VI 2

Walker Bankcard WB

Airline Credit Cards

Air New Zealand Travel Card NZ 2

Alia Personal Credit Card RJ 2

Aloha Airlines Credit Card TS

American Airlines Person al Credit Card AA 2

China Airlines “Dynasty Travel Card” DT

Delta Air Lines Credit Card DL

Garuda Executive Credit Card GA 2

Japan Airlines JALCARD JL 2

Lufthansa Senator Card LH 2
Qantas Airways Charge Card QF 2

Univ ersal Air Travel Plan (UATP) TP Merchandising and Banking Cards

Bankcard New Zealand BZ 2

Discover Card/Bravo Card/Private Issue Card

— issued by Novus Card Produ cts DS 2

...

Airline Industry Issued Card(s)

— Industry Identifier “1”

1XXX Universal Air Travel Plan (UATP) (XXX is numeric airline code of contractor

19XX AirPlus

— licensee of Air Travel Card (XX is airline identifier)

1800 PassAge Credit Card

— licensee of Air Travel Card (issued by Japan Air Lines)

Airline Issued Personal Cards

- Industry Identifier “2”

2001 American Airlines Personal Credit Card

2006 Delta Air Lines Credit Card

2081 Qantas Airways Charge Card

2086 Air New Zealand Travel Card

2126 Garuda Executive Credit Card

2131 Japan Airlines JALC ARD

2151 Alia Personal Credit Card

2220 Lufthansa Senator Card

Travel and Entertainment Cards

— Industry Identifier “3”

300000 to Diners Club

305999

309500 to

30959934XX American Express 35XX Japan Cre dit Bureau

360000 to Diners Club/Carte Blanche

369999 37XX American Express/Optima Card

380000 to Diners Club/Carte Blanche

399999 3889 Diners Club Cards issued to GSA Federal Agent Agencies Banking Industry Cards

— Industry Identifier “4” 4XXX HiperCard

4XXX VISA International Banking Industry Cards, Expansion

— Industry Identifier “5” 5XXXXX Access (Master Card)

5602 Bankcard New Zealand Merchandising and Banking Cards

— Industry I dentifier “6”

601100 to 601199

– 644000 to 659900 Discover Card/Private Issue Card

— Issued by

Novus Card Products Petroleum Industry

— Industry Identifier “7” Telecommunications and Other Future Industry

— Industry Identifier “8” Industry Identifier “0” and “9”

— reserved for future assignment by ISO

**Note:** Industry credit card identifier codes vary in length from two to six digits and the number of Xs following the initial code indicate the number of variable digits which may

be used.Payment instruments, domestic usage only

Credito Directo payment AM BSP Mexico domestic voucher Cards issued by BC BC BSP Korea specific 2

Cabal CL BSP Argentina, domestic card Cards issued by Kookmin CN BSP Korea specific 2

Cards issued by KEB EB BSP K orea specific 2

Cards issued by Hyundai HD BSP Korea specific 2

Reserved for future use KA BSP Korea specific 2

Reserved for future use KB BSP Korea specific 2

Cards issued by Lotte LC BSP Korea specific 2
Cards issued by Nonghyub NH BSP Korea specific 2

Visa Naranja NV BSP Argentina, domestic card

OCA OC BSP Uruguay, domestic card Domestic payment voucher OV BSP Spain domestic voucher Domestic payment voucher OY BSP Spain domestic voucher Domestic payment voucher PC BSP Spain domestic voucher

Reserved for future use PR BSP Chile specific Paga Todo payment PT BSP Mexico domestic voucher Domestic payment voucher RC BSP Spain domestic voucher Cards issued by Shinhan SH BSP Korea specific 2

Cards issued by HANA SK BSP Korea specific 2

Cards issued by Samsung SW BSP Korea specific 2

Tierra del Fuego TF BSP Argentina, domestic card Tarjeta Naranja TN BSP Argentina, domestic card

Nativa NT BSP Argentina domestic card

Reserved for future use HC BSP Brazil specific

_________________________ _____________________________________________

_ 2 In South Korea, cards are not accepted by merchants on the basis of the card brand but on the basis of the issuer's name. Hence a merchant has to sign a card acceptance agreement with every issuer.

Fi ling Period: Effective Date:

1 March

- 1 June 2012 13 April 2012RESOLUTION 762

AIRLINE DESIGNATORS (amending)

P3

PSC( 30 33 )762 Expiry: Indefinite Type: B

RESOLV ED that, the following rules shall apply to the assignment and use of airline designators for the entire airline and travel and tourism industry:

For the purposes of this Resolution,

“AIRLINE” means: an enterprise operating aircraft for commercial purpos es which (i) performs scheduled or non

- scheduled air transport services, or both, which are available to the public for carriage of passengers, mail and/or cargo and (ii) is certified for such purposes by the civil aviation authority of the state in which it is established.

“PUBLISHED SCHEDULE” means: a listing of the timing of air services and other schedule information available to the public in standard air transport industry guides.

1. USE OF AIRLINE DESIGNATORS

1.1 Those companies assigned an airli ne designator are to use such designator for reservations, schedules, timetables, telecommunications, ticketing, cargo documentation, legal, tariffs and/or other commercial/traffic purposes. Codes for use in baggage handling applications are defined in Res olution 769.

1.2 Notwithstanding anything in this Resolution to the contrary, where an airline's cargo division becomes a subsidiary company and an agreement is made whereby that subsidiary cargo company will purchase/utilize allocated space on its parent passenger aircraft for cargo; the cargo company may also use the two

- character designator of the parent company, if agreed by both parties.

2. USE OF TWO

- CHARACTER AND THREE

- LETTER DESIGNATORS

Carriers and CRSs recognize the necessity of processing thr ee

- letter airline/CRS designators at some future date. All organizations having an IATA assigned two character designator shall continue to use such designator until such time as ATA and IATA Members agree on a conversion date for the use of three

- letter designators by such organizations. All organizations airlines receiving an IATA assigned two

- character designator, shall notify IATA of their desired assigned three

- letter ICAO designator, and subsequently IATA will reserve an available that designator.It is also recognized that IATA will deplete all available two

- character designators and

that three

- letter designators will need to be also processed. Therefore, when IATA exhausts the available supply of two

- character designators, airlines/CRSs will be placed on a waiting list for an available two

- character designator. Until such time as a two

character designator becomes available, the airline/CRSs will use its assigned three

letter designator for the purposes defined in paragraph 1. When a two

- charact er designator becomes available the airline/CRS will have the option of using the two

character designator or three

- letter designator, but not both. If the airline/CRS chooses

not to use the two

- character designator, it will become available for reassignme nt. The

airline/CRS must decide whether it wishes to use the two

- character designator within thirty days of it becoming available. The Joint ATA Passenger Council/IATA Passenger

Services Conference (JPSC) shall annually review the airline industry require ments for airline designators.

3. USE OF AIRLINE DESIGNATORS BY RAILWAY, FERRY AND BUS COMPANIES

Railway, ferry, and bus companies with requirements for a designator for passenger transportation, for use in reservations, schedules, timetables or

, tariff publishing, may be assigned a three

- letter designator. Until such time as three

- letter designators can be handled by airlines and computer reservations systems, such non airline companies shall also be assigned a duplicated two

- character numeric

- alpha desi gnator in a

controlled environment (see paragraph 5) drawn from designators assigned to non

scheduled passenger or cargo airlines.

4. ASSIGNMENT CRITERIA FOR NEW APPLICANTS

4.1 The following new applicants for Airline designators shall be assigned as a t wo

character (two

- letter alpha

, if available , or numeric

- alpha, alpha

- numeric) designator to:

and a three

- letter designator :

4.1. 1 2 airlines which are parties to the ATA Interline Traffic Agreement

— Passenger (Resolution 5.65), the IATA Interline Traffi c Agreement

— Passenger (Resolution 780/780e), or the IATA Interline Traffic Agreement

— Cargo (Resolution 660) However, if such airline does not intend to conclude an interline traffic agreement within 90 days of assignment, the two

- character designator shall be recalled and it shall be assigned a

three

- letter designator; until such time as three

- letter designators can be handled by airlines and Computer Reservation Systems, such airlines shall also be assigned a duplicated airline designator in a control led environment;

or

4.1. 2 1 airlines publishing and operating scheduled air service in accordance with the

definition of a scheduled air service contained in IATA Recommended Practice 1008 in standard air transport guides. However, if such airline does n ot intend to conclude an interline traffic agreement within 90 days of assignment, the two

- character designator shall be recalled and it shall be assigned a three

- letter designator; until such time as

three

- letter designators can be handled by airlines and Computer Reservation Systems, such airlines shall also be assigned a duplicated airline designator in a controlled

environment.4.1.3 airlines not qualifying under 4.1.1 or 4.1.2, with a requirement for an airline designator to participate in an airlin e industry shared telecommunication facility shall be assigned a Banded Code for message addressing and a three

- letter designator.

4.1.4 a new entrant which does not yet meet the definition of “airline” for purposes of this Resolution may be granted a pro visional airline designator code assignment when written notification is received from the civil aviation authority of the state in which it is established advising that the enterprise is substantially meeting the state's requirements

for the issuance of a licence to operate commercial air transport services;

4.1.4.1 such provisional assignment shall be valid for a non

- renewable period of six (6) months. Failure of the enterprise to meet the definition of “airline” for purposes of this

Resolution within si x (6) months of provisional assignment of the airline designator code

will result in the formal recall of the code. A non

- refundable processing charge shall apply to requests for provisional assignments of airline designator codes, in addition to

all fees otherwise applicable.

4.2 Non

- scheduled passenger or non

- scheduled cargo airlines not qualifying under

4.1.1

, or 4.1.2 as of 1 June 2012 or 4.1.3 with a requirement for an airline designator shall be assigned a three

- letter designator; until such time as three

- letter designators can be handled by airlines and Computer Reservation Systems, such airlines shall also be assigned a duplicated airline designator in a controlled environment.

P4.1

4.3 Non

- airline Unit Load Device (ULD) owners who participate in the Interline ULD Control User Group (IULDUG) ULD area of the IATA Strategic Partnership Program (two

- letter controlled duplication and a three

- letter beginning with “X”) . Non

- airline ULD owners who do not participate in the IULDUG ULD area of the IATA Str ategic Partnership Program will not be eligible for a unique or controlled duplicate (see paragraph 5) code but shall be assigned a Banded Code and a three

- letter code beginning with “X”)

.

4.4 Computer Reservations Systems (CRS) suppliers with a requireme nt for participation in airline industry shared telecommunication facilities . Such CRS suppliers shall only be assigned two

- character numeric

- alpha or alpha

- numeric designators using the figure “1” and letters “A

– Z”. Such designators can be used in interli ne reservations messages. They shall not be used to publish and operate air services, nor shall they be

used for the interline transmission of PTAs, nor shall they be used for any other ticketing purpose, (except for the optional identification of the CRS controlling the PNR. This identification should be shown in the “Airline Data/Booking Reference/PNR” box on the ticket). These codes shall not be duplicated (see paragraph 5).

4.5 The two

- character and three

- letter airline designators shall be used for th e purposes outlined in Paragraph 1, (except where expressly stated otherwise in this Resolution), and in accordance with the instruction issued by IATA. Notwithstanding anything in this
Resolution, three

- letter designators will not be used by airlines unti l such time as the Joint ATA Passenger Council/IATA Passenger Services Conference (JPSC) reaffirms the requirement for the use of such three

- letter designators.5. CONTROLLED DUPLICATION 1

5.1 During the interim period, two

- character designators may be duplicated in a

controlled environment.

5.1.1 The following criteria shall apply to controlled duplicate designators:

The same code will not be duplicated if the companies:

• publish passenger schedules; or

• publish cargo schedules; or

• participate in the industry shared telecommunication facilities except under Banding as defined in RP 1008; or

• at the time of assignment, it is known by IATA that the companies serve the same general geographic area.

5.1.2 In the event that one of the companies with a dupli cated designator changes its status, and falls into one of the criteria listed above, the company which had the designator first shall continue to have the use of the code and IATA will change the designators of the other companies which shared the designa tor.

5.2 If an airline has nominated a predesignated point that airline's two

- character designator will not be duplicated.

1 Duplication means to assign the same designator to two or more companies.

6. DESIGNATORS NOT AVAILABLE FOR ASSIGNMENT

The fo llowing combinations shall not be assigned to individual airlines or companies qualifying for airline designator:

6.1 these designators are to be used for communications purposes only:

Commercial Category Designator

a. Car Rental Companies/ CR

Miscellaneous

b. Hotel/Motel Companies HL

c. Aeronautical Radio, Inc. (ARINC) XA

d. International Air Transport XB Association (IATA)

e. Air Transport Association of XD America (ATA)

f. Special Ground Handling Service XH

g. Internation al Aeradio Ltd. (IAL) XI

h. SITA XSi. Government Civil Aviation YA

Authorities j. General Addressing YY

k. Computer Tests ZZ

l. Miscellaneous (reserved for industry 2X, 6X, use) 7X, 8X

m. non

- scheduled Air Transpor tation X2, X6 (Reserved for Banding

— see Paragraph 4.1.3)

n. General Aviation GN

6.2 When IATA starts assigning three

- letter codes, the following combinations shall not be assigned to individual airlines or companies qualifying for an airline de signator:

6.2 .1 three

- letter designators

— CAF, COR, DPC, EEE, EXO, HDQ, NAC, NIL, PAN, PDM, QAA, QAB, QFP, QMK, QQQ, QTA, QTB, QTE, RDT, RET, RPT, RQR, RTA, RTC, RTP, RTX, SOS, STP, SVC, UNO, XCR, XHL, XXD, XXH, YXA to YZZ and ZXA to ZZZ, ATX, CAR, CCR, HHL, HTL, OSI, PTA, SSR, SUR, TTO, TUR, YYY, WWW ;

6. 3 .2.2 three

- letter combinations with CZ, NN or ZC;

6. 4 2.3 an airline's or CRS's three

- letter designator shall not be the same as the location

identifier for that airline's or CRS's head office locat ion.

7. SUBMISSION OF REQUEST S FOR INFORMATION AND APPLICATION FORMS

Companies requesting the assignment of a designator or a change to an existing designator shall submit a request (using the application form which is published separately) to the IATA O ffice, as shown on the application form.

Information on application forms regarding code assignment is available from IATA as
shown below, or download forms from http://www.iata.org/whatw edo/passenger/Pages/coding

Code Administration Co

- ordinator International Air Transport Association

800 Place Victoria

P.O. Box 113 Montreal, Quebec

Canada H4Z 1M1 Tel: +1 (514) 874 0202 Fax: +1 (514) 390 6773 Email: airlinecoding@iata.org

7.1 Publica tion of Codes

Information regarding valid codes can be found in the IATA Airline Coding Directory. This can

be ordered from the IATA online store at: www.iataonline.com

For individual enquiries regarding coding and de

- coding of airline designators, refe r to: www.iata.org/codes8. PROCESSING OF REQUEST

Upon receipt of a request for the assignment of an airline designator, the IATA Office

will:

8.1 determine the eligibility of the applicant and, if eligible , will assign and authorize the use of an airline designator, coordinating assignments to avoid possible uncontrolled duplications;

8.2 introduce an effective date provide notification for the use of the airline designator so assigned by means of a circul ar letter an industry message to ATA/ IATA Members,

CRSs and to the Airline Guides CRSs, data aggregators and subscribers of the IATA Coding Directory ;

8.3 publish all assignments in the IATA Airline Coding Directory.

8.4 The order of priority in assigni ng two

- character airline designators is as follows:

8.4.1 an airline which requires a change to its designator because of an operational problem caused by the designator it has been assigned, including conflicts associated with controlled duplicate design ators;

8.4.2 an airline which has been assigned a three

- letter airline designator and who has been placed on a waiting list for a two

- character designator in accordance with Paragraph 2, will be offered a two

- character designator according to the date the airline requested to be placed on that waiting list established for this purpose. If the airline refuses to accept the first two

- character airline designator which becomes available, that airline will move to the bottom of this waiting list;

8.4.3 an air line which does not currently have an airline designator;

8.4.4 an airline which requests a voluntary change to its airline designator. Assignments will be made from a waiting list in order of the date the airline requested to be placed on

this list.

9. CHANGES TO AIRLINE DESIGNATOR ASSIGNMENTS

9.1 Except as provided in Paragraph 9.2, airline designators shall not be changed without strong justification, including changes made in accordance with Paragraph 2 and with regard to the priority as specified in Paragraph 8.

9.2 Two or more airlines already holding a unique two

- character designator, except controlled duplicate designators, may voluntarily exchange such airline designators using IATA as an intermediary. IATA may establish fees for acting as an in termediary. When an airline designator is assigned or changed, IATA will establish its effective date

and undertake to co

- ordinate this assignment or change with all parties concerned.9.3 The effective date of any change (except additions and deletion s) to current airline designators, except controlled duplicate designators, shall not be less than ninety (90) days following the date on which the change is agreed.

9.4 When making a request for changes, airlines and CRSs shall ensure that such request i s sent to the IATA Office shown on the Application form (which is published separately).

10. EXTENSION OF TWO

- CHARACTER DESIGNATOR SYSTEM ANNUAL REVIEW

10.1 To encourage airlines who do not need a unique two character designator for operational reasons to surrender it, or to encourage airlines to move to banding, there will be an annual review process to determine continued eligibility for an airline accounting code and/or airline prefix, for which ATA and IATA may assess a fee in addition to any applica tion or administration fee. IATA may assess a fee as part of the annual review process in addition to any assignment or administration fee . This fee shall apply to all non

- IATA, non

- ATA companies, except to members of the IATA Registered Supplier Strate gic Partnerships Programme , IATA Travel Partners Programme and airlines assigned a Banded Code.

10.2 Failure to complete and return the annual review form and/or pay any airline designator fee shall result in that airline designator being recalled by IA TA for reassignment.

11. RECALLING OF AIRLINE DESIGNATORS

11.1 If at any time it is determined by ATA or IATA that an airline or non

- airline company no longer qualifies for a designator under the criteria established in paragraph 4 of this
Resolution, th e designator will be recalled. A company will cease to use the designator upon notification by ATA or IATA of the recall of the designator.

11.2 The IATA Secretariat will advise the IATA/ATA Members, CRSs and other interested parties by way of a circular letter and in the regular transmittal of the IATA Airline Coding Directory of any changes in airline designators. provide notification of the airline designator so recalled by means of an industry message to CRSs, data aggregators and subscribers of the IA TA Coding Directory. Recalled airline designators should not be reassigned for a minimum period of at least sixty (60) days.

11.3 An airline designator is not considered the property of the airline to which it is assigned. Once an airline no longer meets the criteria for the assignment of an airline designator, that designator is recalled. After 60 days from the date of recall, the designator may be reassigned. Should the carrier which has had its designator recalled demonstrate within 60 days of the reca ll that it does meet the criteria for an airline designator, that designator will be reallocated to it. If the carrier demonstrates that it satisfies the criteria for an airline designator more than 60 days from the date of the recall of its airline design ator, it shall be considered a new applicant and IATA will assign an available airline designator. In these circumstances IATA can not guarantee to assign the original airline designator to the applicant.For a copy of an application form for an airlin e designator contact the:

Code Administration Co

- ordinator International Air Transport Association

800 Place Victoria

P.O. Box 113 Montreal, Quebec

Canada H4Z 1M1 Tel: +1 (514) 390 6773 Fax: +1 (514) 874 9633 Tty: YMQTIXB Email: codes@iata.org

www.iata.or g/codes

12. ASSIGNMENT OF ADDITIONAL AIRLINE DESIGNATORS

12.1 When the commercial requirements of an airline are likely to lead to the exhaustion of its available range of flight numbers (including numbers used for code share flights marketed but not op erated by such airline) within a forthcoming year, (an) additional airline designator(s) may be assigned to that airline by IATA Management for a specified period. In these circumstances, controlled duplicates cannot be used.

12.2 Applications for additio nal designators shall be submitted to the IATA office as per Paragraph 7 with a detailed justification to support the application.

**GOVERNMENT RESERVATIONS**

UNITED STATES

Order 77

- 12

- 32 dated 5 December 1977:

Resolution 762 is approved provided that AT A and IATA include interested non

- member

U.S. certificated air carriers in their administration of the two

- letter airline designator
system.

Filing Period: Effective Date:

1 March

- 1 June 2012 13 April 2012RESOLUTION 763

LOCAT ION IDENTIFIERS (amending)

PSC( 32 33 )763 Expiry: Indefinite Type: B

P3

RESOLVED that:

Members Airlines and CRSs shall use the location identifiers published in the IATA Airline Coding Directory. Assigned three

- letter location identifiers are c onsidered permanent. They shall not be duplicated with any other physical location . They shall not be changed without strong justification primarily concerning air safety. The following procedures shall apply for the assignment of three

- letter location id entifiers (city/airport codes) for airlines' purposes, other than Air Traffic Services 1 1 applications. The following codes are not available for assignment: CPY, DDL, DPC, HDQ, IAT, NIL, NUC, QAA, QAB, QAF, QEN, QES, QQQ, QSP, QTA, QTB, QTQ, QTV, QUK, QXA, QXL, QXM, QXN, QXS, QXT, QXU, QZY, QZW, SOS, WWW, XXX, ZZW,
ZZX, ZZY, ZZZ. The following codes are reserved for use as a fictitious points only in the text of a Schedule Exchange Data Message according to the IATA Standard

Schedules Information Manual: Q MX, QMY, QPX, QPY, QZX, XUD.

The following codes are reserved as fictitious points for use in Charge Card and Credit Card billings: XAA, XAE, XAF, XAO, XDF, XCA, XOT, XPC, XPE, XTD and XUP.

1. CRITERIA

1.1 Members Airlines and CRSs may only request the assignment of a unique three

letter code to identify one of the following locations:

1.1.1 an airport receiving scheduled air services by a Member an airline;

1.1.2 an airport receiving charter air services by a Member airline;

1.1.3 an alternate airpo rt available for use by Member airlines;

1.1.4 an airline headquarters when HDQ or an existing city/airport code cannot be used;

1.1.6 1.1.2 a location which must be identified and published for intermodal transportation, served by a railway, ferry or bus company having an intermodal agreement with an airline. For the purposes of this Resolution, intermodal transportation means transportation provided by an airline and one or more other modes of transportation, documented on a single accountable traffi c document, with a reservation, and distributed via an airline reservation system and/or CRS. Code assignment requests received from a CRS for railway, ferry or bus companies will may be subject to a charge set by IATA (except IATA Strategic Partners).1.1.5 1.1.3 a location which must be identified for airline communications routing or airline scheduling purposes or airline schedule exchange data messages and for which no existing airport or city code is available

1.2 To satisfy the criteria listed under 1.1.1, 1.1.2

, and 1.1.3, 1.1.4 and 1.1.5, the following shall apply:

1.2.1 for scheduled service airport location identifiers, consult the current issue of the IATA Airline Coding Directory in order to avoid requesting an identifier which is alrea dy
in use;

1.2.2 as a first choice, select an unassigned mnemonic using the first three letters of
the location name;

1.2.3 as a second choice, select an unassigned mnemonic preferably starting with the

first letter of the location name.

1.3 Codes ar e assigned under 1.1.1, 1.1.2 and 1.1.3 as follows:

1.3.1 if only one airport serves an area, only one code will be assigned to both the airport and the area;

1.3.2 when an area is served by more than one airport, each airport will be assigned an

indiv idual code. The area will may be assigned a metropolitan area code which may be

the same as the code of one of its airports or an a unique individual code; provided that the above criteria is without prejudice to currently existing unique metropolitan area codes as published in the IATA Airline Coding Directory.

1.4 An airport will not be listed in or de

- listed from the IATA Airline Coding Directory under a metropolitan area location identifier unless a specific request for such action is

submitted to the IATA or ATA Head Office, as appropriate.

1.5 Creation/dismantling of a metropolitan area location identifier, or the listing/de

- listing of an airport under a metropolitan area location identifier shall only be actioned if it is established by the IATA or ATA Secretariat that:

1.5.1 the operators of the airports concerned support such action;

1.5.2 a majority of responses from a poll of airlines operating scheduled air transport services serving all the airports concerned support such action. For the pur pose of determining which airlines serve such airports, the IATA or ATA Secretariat as appropriate will consult the airport authorities concerned. For the purposes of compiling the list of airlines, the airport authorities are to include the teletype addre ss and/or e

mail address of the airlines presently operating scheduled air transport ser

- vices or which have operated to the airport during the previous 12 month period.1.5.3 In the event a majority of airlines do not support the proposed action to li st an additional airport to an existing metropolitan area, IATA will inform the relevant national aeronautical authority. In such case the national aeronautical authority may, at its discretion, overturn the vote by advising IATA accordingly in writing and in that case the airport will be listed in the existing metropolitan area. If no reply is received within 90 days it will be assumed that the national aeronautical authority supports the results of the poll.

1.6 For the purposes of conducting a poll, the following criteria shall apply:

1.6.1 the poll will be conducted not more than once per year for a given airport;

1.6.2 the poll will be sent by teletype and/or by e

- mail to:

1.6.2.1 the Passenger Services Conference Accredited Representative of IATA M ember airlines or the interline contact of Member airlines participating in the MITA but not represented in the Passenger Service Conference,

1.6.2.2 the interline contact for non

- IATA airlines which are party to the IATA Multilateral Interline Traffic Ag reements,

1.6.2.3 the chief executive (head office teletype address and/or by e

- mail) of any other airline(s) indicated as concerned by the airport authority(ies) concerned;

1.6.2.4 all Accredited Representatives of the Passenger Services Conference and the Composite Tariffs Conference for their information;

1.6.3 a majority shall be considered as a simple majority of airlines responding to the poll, with non

- responses and abstentions not counting in the poll.

1.6.4 Requests received from non

- IATA and n on

- ATA airlines for listing an airport under a metropolitan area location identifier will be subject to a charge set by IATA.

1.7 The location name will be spelled using the “conventional” English name as published by the US Board on Geographic Names (BG N). If this does not exist, the BGN “approved” spelling will be used (refer to: http://geonames.usgs.gov/ ) Alternatively use the spelling of the national Civil Aviation Authorities of the country concerned.2. NEW LOCATIONS OR CHANGES REQUESTS FOR INFORMATION AND

APPLICATION FORMS

Members and CRSs requiring the assignment of a code for a new location or requiring a change to an existing code, shall submit a request using the application form (published

sepa rately, see below) to the IATA or ATA Head Office, as appropriate.

The location name will be spelled using the conventional English name. If this does not exist, the spelling will be as published by the US Board on Geographic Names (BGN).

Information on rules and criteria regarding code assignment is available from IATA as
shown below, or download forms from http://www.iata.org/whatwedo/passenger/Pages/coding

Code Administration Co

- ordi nator International Air Transport Association

800 Place Victoria

P.O. Box 113 Montreal, Quebec

Canada H4Z 1M1 Tel: +1 (514) 874 0202 Fax: +1 (514) 390 6773 Email: airlinecoding@iata.org

2.1 Publication of Codes

Information regarding valid codes can be f ound in the IATA Airline Coding Directory.

This can be ordered from the IATA online store at: www.iataonline.com

For individual enquiries regarding coding and de

- coding of location identifier codes,

refer to: www .iata.org/codes

3. PROCESSING OF REQUESTS FOR NEW LOCATIONS OR A CHANGE OF

AN EXISTING LOCATION PUBLICATION OF CODES

Upon receipt from a Member an airline or a CRS of a request for the assignment of a new location identifier or for a change o an exist ing location identifier, the appropriate

Secretariat of the IATA or ATA Head Office will:

3.1 co

- ordinate recommended changes or additions to location identifiers with ATA or IATA, as the case may be, o determine availability and to ensure conformity with the
criteria shown in 1.2;

3.2 For new location identifiers, ATA and/or IATA will:

3.2.1 assign an available code,3.2.2 establish an implementation date for each new location identifier that shall not be less than thirty (30) days from the date of assignment,

3.2.3 advise the new location identifier to all Members, CRSs and the Airline Guides CRSs, data aggregators and subscribers of the IATA Airline Coding Directory

.

3.3 For a change to an existing location identifier, ATA and/or IATA will:

3.3. 1 assign the requested code for the location identifier,

3.3.2 establish an implementation date for a change of location identifier that normally shall not be less than thirty 30) days from the date of the notice to be issued by ATA
and IATA,

3.3.3 advis e the change of location identifier to all Members, CRSs and the Airline

Guides CRSs, data aggregators and subscribers of the IATA Airline Coding Directory

.

3.4 include all such amendments in the next issue of the IATA Airline Coding Directory.

Informati on regarding valid codes can be found in the IATA Airline Coding Directory.

This can be ordered from the IATA online store at: www.iataonline.com

4. EMERGENCY ASSIGNMENT AND TEMPORARY AMENDMENT OF

LOCATION DENTIFIERS

Notwithstanding any Paragraph in t his Resolution 763, IATA or ATA management, as appropriate, may immediately assign new or amended location identifiers or may list/de

list airports under existing metropolitan area location identifiers in the event that air safety, government action or a c hange in government policy strongly justifies such assignment or amendment. Such assignment or amendment must be supported and endorsed by the appropriate operator(s) of the airport(s), and shall become effective fourteen (14) days after its authorization by means of circular letter to all Members and

CRSs and to the Airline Guides CRSs, data aggregators and subscribers of the IATA Airline Coding Directory . The implementation date will be specified in the circular. The appropriate Secretariat of the IATA or ATA Head Office, as appropriate, will include such assignment or amendment in the next issue of the Airline Coding Directory.

For a copy of an application form see www.iata.org/codes or send an email to: airlinecoding@iata.org

5. REQUESTS FROM NON

- MEM BERS FOR ASSIGNMENT

Upon receipt of a request from a non

- Member operating scheduled air services for the assignment of a location identifier, the appropriate Secretariat of the ATA/IATA Head Office shall do so in accordance with the provisions of this Res olution.6 5

. EFFECTIVENESS OF CHANGES ASSIGNMENTS

At any given time for any location, airlines should use only the one identifier which is

effective on the date of travel to/from that location. The first date on which the new

location identifier must be used for reservation purposes will be advised by IATA, but never less than sixty (60) days before the actual date of effectiveness of the changed location identifier. When making a recommendation for such changes, Members shall

ensure that such notice is sent to the appropriate Secretariat of the IATA or ATA Head Office at least seventy (70) days before such effective date.

When airlines and CRSs request new assignments they shall ensure that such notice is sent to the appropriate Secretariat of the IA TA or ATA Head Office at least seventy (70) days before such effective date. IATA systems will be updated with immediate effect on the requested effective date, and notification will be circulated to the airline industry no later than ten (10) days thereaf ter via an industry message to CRSs, data aggregators and subscribers of the IATA Coding Directory.

7 6

. CANCELLATION OF CODES

When recommending the cancellation of an existing code, Members airlines and CRSs shall submit the proposal to the IATA or ATA Head Office, as appropriate, giving

reasons to substantiate the recommendation. Co

- ordinating action shall may be taken by IATA or ATA Head Office which shall authorise such cancellation by the same procedure as outlined in Paragraph 3 upon review of the proposal

.

8 7 . USE OF LOCATION IDENTIFIER CODES

A location identifier code is the property of IATA and not the airport to which it is assigned or of the company that requested the assignment. The assignment by IATA of

a location identifier code shall not confer upon the recipient of such assignment any proprietary, intellectual property or commercial rights which are independent of or inconsistent with the purpose of this Resolution 763. Any commercial use of a location identifier code not authorized by I ATA is strictly prohibited.

**GOVERNMENT RESERVATIONS**

ITALY In accordance with the sentence and judgement No. 5668/02 of the “Tribunale Amministrativo Regionale del Lazio” (TAR), the Italian CAA requires that, in Italy, in case of a request for the

de

- listi ng of an airport from a metropolitan area consisting of only two airports and for the subsequent dismantling of such area, the following amended procedure applies:

1) Article 1.5.1 is modified insofar as the agreement of the operator of the airport for wh ich de

listing is requested shall suffice for appropriate action to be undertaken by IATA.

2) Article 1.5.3 is modified insofar as the “poll” to be undertaken by IATA shall be limited to the carriers having served the airport for which de

- listing is reque sted during the previous 12

- month period.

Filing Period: Effective Date:

1 March

- 1 June 2012 13 April 2012RESOLUTION 767

ASSIGNMENT OF AIRLINE ACCOUNTING CODES AND AIRLINE PREFIXES (amending)

PSC( 30 33 )767 Expiry: Indefinit e Type: B

P3

RESOLVED that: The following rules shall apply to the assignment and use of airline accounting codes and airline prefixes for the airline and travel and tourism industries.

For the purposes of this Resolution,

“AIRLINE” means: an enterpri se operating aircraft for commercial purposes which (i) performs scheduled or non

- scheduled air transport services, or both, which are available to the public for carriage of passengers, mail and/or cargo and (ii) is certified for such purposes by the civi l aviation authority of the state in which it is established.

“PUBLISHED SCHEDULE” means: a listing of the timing of air services and other schedule information available to the public in standard air transport industry guides.

1. USE OF AIRLINE ACCOUNT ING CODES AND AIRLINE PREFIXES

1.1 Airline accounting codes and airline prefixes are essential for the identification of passenger and cargo traffic documents, processing of passenger accounting transactions, cargo transactions and other commercial/traffi c purposes.

1.2 The airline accounting code shall be used on all passenger traffic documents as the first three digits of the document number. This identifies the document as being issued by or on behalf of an airline or non

- airline company other than a C RS. The airline accounting code shall also be used in accordance with the ATA and IATA instructions,

Resolutions and Recommended Practices.

1.3 The airline prefix shall be used on all cargo traffic documents as the first three digits

of the document numbe r and form part of the shipment identification. This identifies the document as being issued by or on behalf of an airline. The airline prefix shall also be
used in accordance with the ATA and IATA instructions, Resolutions and

Recommended Practices.

1.4 Codes for use in all baggage handling applications are defined in Resolution 769.

1.5 Notwithstanding anything in this Resolution to the contrary, where an airline's cargo division becomes a subsidiary company and an agreement is made whereby that

subsidi ary cargo company will purchase/utilize allocated space on its parent passenger aircraft for cargo; the cargo company may also use the airline prefix of the parent company, if agreed by both parties.2. ASSIGNMENT CRITERIA FOR AIRLINE ACCOUNTING CODES AND AIRLINE

PREFIXES

2.1 Three numeric airline accounting codes or airline prefixes shall be assigned for the purposes described in Paragraph 1 to:

Computerized reservations system companies which provide ticketing services for the airline industry;

Ai rlines which have an interline traffic agreement with another airline and issue
accountable interline traffic documents;

Airlines which are party to any of the following industry agreements/plans:

IATA Multilateral Interline Traffic Agreement

– Passenger

,

IATA Multilateral Interline Traffic Agreement

– Cargo,

IATA Interline Traffic Participation Agreement

– Passenger

– Issuing Airlines only,

ATA Interline Traffic Agreement

– Passenger,

ATA Interline Air Cargo Procedures Agreement,

IATA Billing and Se ttlement Plan (BSP) , and issue Standard Interline Traffic
Documents,

Airlines Reporting Corporation (ARC) , and issue Standard Interline Traffic
Documents,

IATA Cargo Accounts Settlement Systems (CASS) , and issue air waybills,

Universal Air Travel Plan ( UATP) UATP Agreement, as a Contractor Party **;**

Airlines having bilateral interline traffic agreements with another airline and issue
accountable interline traffic documents;

Airlines which have authorized forwarders to issue air waybills on their behalf;

Non

- airline Unit Load Device (ULD) owners who participate in the Interline ULD Control User Group (IULDUG);

Computerized reservations system companies which provide ticketing services for the airline industry;

IATA Travel Partners which are participatin g carriers in airline computer reservations systems (CRSs) or IATA Billing and Settlement Plan (BSP) or Airlines Reporting Corporation (ARC) as of 1 July 1995, and issue accountable traffic documents.2.2 When all three numeric airline accounting codes or airline prefixes are exhausted, new companies which qualify for an airline accounting code or airline prefix shall be assigned a three

- letter airline accounting code or airline prefix in accordance with the provisions set forth under Paragraph 4 hereto . Companies which have been assigned

three

- letter airline accounting codes or airline prefixes, shall be placed on a waiting list

for three

- numeric airline accounting codes or airline prefixes which become available.

Until such time as a three

- numeric airl ine accounting code or airline prefix becomes available, the airline/company will use its assigned three

- letter airline accounting code or airline prefix for the purposes defined in Paragraph 1. When a three

- numeric airline accounting code or airline prefi x becomes available, the airline/company will have the option of using the three

- numeric or three

- letter airline accounting code or airline prefix, but not both. The airline/company must decide whether it wishes to use the three

numeric airline accounting code or airline prefix within sixty days of its becoming available. If the airline/company chooses not to use the three

- numeric airline accounting code or airline prefix, it will become available for reassignment to another airline/company.

The three

- lett er airline accounting code or airline prefix will be the same as the three

letter airline designator assigned/reserved by IATA under the provisions of Resolution

762.

Notwithstanding anything in this Resolution, three

- letter accounting codes will not be

u sed by airlines until such time as the Joint ATA Passenger Council/IATA Passenger Services Conference reaffirms the requirement for the use of such three

- letter accounting codes.

3. CLEARING HOUSE SUBSIDIARY LEDGER COMPANIES

With respect to the non

- airli ne companies which participate in the IATA Clearing House or Airlines Clearing House ‘Subsidiary Ledger’, such companies shall be assigned, by the IATA Clearing House or Airlines Clearing House, a three character alphanumeric (not three

- numeric or three

- le tter) accounting code. Such companies may not use the alpha

- numeric accounting code for the purposes described in Paragraph 1.

4. ASSIGNMENT OF AIRLINE ACCOUNTING CODES AND AIRLINE PREFIXES

Airline accounting codes and airline prefixes shall be assigned by the Director

– Revenue Accounting of the Air Transport Association of America (ATA) or the IATA's Global Head, Passenger of the International Air Transport Association (IATA). ATA shall assign airline accounting codes and airline prefixes to airlines an d non

- airline parties whose headquarters are in the U.S.A., and IATA shall assign airline accounting codes and airline prefixes to airlines and non

- airline parties whose headquarters are outside

the U.S.A.5. AIRLINE ACCOUNTING CODES AND AIRLINE PREFIX ES NOT AVAILABLE FOR

ASSIGNMENT

5.1 The following airline accounting codes shall not be assigned to individual airlines or

non

- airline companies qualifying for an airline accounting code for use on passenger

traffic documents:

Code Assignee

777 BSP

— Tour Operators/Hotels/Courier Companies/Insurance Companies

792 BSP

— Car Rentals

793 BSP

— Ships/Hovercraft

794 BSP

— Bus Lines

799 BSP

— Railways

888 Scheduled Airlines Traffic Offices Inc.

889 ARC

890 ARC

950 SITA

952 BSP

— IATA Remitt ance and Settlement Adjustments

953 BSP

954 BSP

955 BSP

956 BSPlink agent

5.2 The following airline prefixes shall not be assigned to individual airlines for use on cargo traffic documents:

Code Assignee

888 Scheduled Airlines Traffic Offices Inc.

889 ARC

890 ARC

950 SITA

953 CASS

954 CASS

6. REQUESTING AN AIRLINE ACCOUNTING CODE OR AIRLINE PREFIX

REQUESTS FOR INFORMATION AND APPLICATION FORMS

6.1 An airline or non

- airline company requesting assignment of an airline accounting

co de for passenger traffic purposes only, shall send a written request using the application form which is published separately to ATA or IATA, as appropriate, and provide documentary evidence that it is eligible to receive an airline accounting code

under t he provisions of Paragraph 2. Such application shall include a statement to the effect that the code shall not be used as an airline prefix for cargo traffic documents.6.1.1 Upon receipt of a request for assignment of an airline accounting code and/or airline prefix, ATA or IATA, as the case may be, shall:

verify the eligibility of the applicant;

be certain the applicant has not previously been assigned an airline accounting code and/or airline prefix by either ATA or IATA;

assign an airline account ing code and/or airline prefix from the available banks of airline accounting codes and airline prefixes, and notify the applicant in writing, of the code and/or prefix so assigned.

6.2 An airline requesting assignment of an airline prefix for cargo traff ic purposes only, shall send a written request using the application form which is published separately to ATA or IATA, as appropriate, and provide documentary evidence that it is eligible to receive an airline prefix under the provisions of Paragraph 2. S uch application shall include a statement to the effect that the prefix shall not be used as an airline accounting code for passenger traffic documents.

6.3 An Application fee in an amount to be determined by ATA and IATA, is required

from airlines or non

- airline companies requesting an airline accounting code or airline prefix assignment from ATA or IATA. Applicants shall therefore include a cheque for the applicable amount with their application.

Information on rules and criteria regarding code assignme nt is available from IATA as
shown below, or download forms from http://www.iata.org/whatwedo/passenger/Pages/coding

Code Administration Co

- ordinator International Air Transport Associat ion

800 Place Victoria

P.O. Box 113 Montreal, Quebec

Canada H4Z 1M1 Tel: +1 (514) 874 0202 Fax: +1 (514) 390 6773 Email: airlinecoding@iata.org

6.4 Publication of Codes

Information regarding valid codes can be found in the IATA Airline Coding Directory

. This can be ordered from the IATA online store at: www.iataonline.com

For individual enquiries regarding coding and de

- coding of airline accounting codes/airline prefixes, refer to: www.iata.org/codes7. AC TION BY ATA OR IATA ANNUAL REVIEW 7.1 Upon receipt of a request for assignment of an airline accounting code and/or airline prefix, ATA or IATA, as the case may be, shall:

verify the eligibility of the applicant;

be certain the applicant has not previous ly been assigned an airline accounting code and/or airline prefix by either ATA or IATA;

assign an airline accounting code and/or airline prefix from the available banks of airline accounting codes and airline prefixes, and notify the applicant in writing , of the code and/or prefix so assigned.

7. 2 .1 To encourage airlines or non

- airline companies who do not need or no longer qualify for an airline accounting code and/or airline prefix, there will be an annual review process to determine continued eligibi lity for an airline accounting code and/or airline prefix, for which ATA and IATA may assess a fee in addition to any application or administration fee. This annual review and fee shall apply to all non

- ATA and non

- IATA companies and non members of the IAT A Registered Suppliers/Industry Associates Strategic Partnership Programme and IATA Travel Partners Programmes , except the

non

- airline companies which participate in the ATA or IATA Clearing Houses ‘Subsidiary Ledger’ covered in Paragraph 3.

7. 3 .2 Failu re to complete and return the Annual Review form and pay the annual fee for the airline accounting code and/or airline prefix, shall result in that airline accounting code and/or airline prefix being recalled by ATA or IATA.

8. RECALL OF AIRLINE ACCOUNTIN G CODES NUMBERS AND AIRLINE

PREFIXES

8.1 If at any time, it is determined by ATA or IATA that an airline or non

- airline company no longer qualifies for an airline accounting code and/or airline prefix under the criteria established in Paragraph 2 of this Resolution, the airline accounting code and/or airline prefix shall be recalled. Such airline or non

- airline company shall cease to use such airline accounting code and/or airline prefix upon receipt of notification by ATA or IATA. IATA will provide notif ication of the accounting code and/or airline prefix so recalled by means of an industry message to CRSs, data aggregators and subscribers of the IATA Coding Directory.

8.2 Airline accounting codes and airline prefixes shall normally not be reassigned fo r at

least a minimum period of 12 months after the date of recall or from the date interline traffic documents ceased to be issued, whichever is earlier. This does not apply to the alpha/numeric accounting codes assigned to Subsidiary Ledger companies par ticipating in the IATA Clearing House.

8.3 If an airline or non

- airline company later demonstrates that it again meets the criteria for an airline accounting code and/or airline prefix more than 12 months from the date of recall of its airline accounting code and/or airline prefix, it shall be considered as a new applicant. In these circumstances ATA or IATA cannot guarantee to assign the original airline accounting code and/or airline prefix.9. NOTIFICATION OF AIRLINE ACCOUNTING CODE AND AIRLINE PREF IX

ASSIGNMENTS/CANCELLATIONS PUBLICATION OF CODES

9.1 On the first day of each month immediately after assignment or recall of an airline accounting code or airline prefix, ATA or IATA, as the case may be, shall take the following action:

9.1.1 IATA shal l notify ATA and the airline guides publishers of the codes and prefixes assigned or recalled;

9.1.2 ATA shall notify IATA and the airline guides publishers of the codes and prefixes assigned or recalled;

9.1.3 IATA shall publish all codes and prefixes a ssigned or recalled by ATA and IATA in the IATA Airline Coding Directory, at the time of the next regular edition, and issue monthly amendment bulletins;

9.1.4 ATA shall, at appropriate intervals, notify its Members of the airline accounting

codes and air line prefixes assigned or recalled by ATA and IATA.

Information regarding valid codes can be found in the IATA Airline Coding Directory.

This can be ordered from the IATA online store at: www.iataonline.com

10. CHANGE IN CORPORATE STATUS

In the event of change in the corporate status of an airline or non

- airline company which has been assigned an airline accounting code and/or airline prefix, such as a name change, merger with another airline or company, etc. the airline or non

- airline company

so affe cted shall immediately notify ATA or IATA, as appropriate, so the published lists of code assignments can be amended accordingly. In the event of a merger of two or

more airlines or non

- airline companies which all have been assigned airline accounting

code s and/or airline prefixes, the surviving airline or non

- airline company shall use only one code and/or prefix, and the other code and/or prefix shall be recalled in accordance with Paragraph 8, upon notification from the surviving airline or non

- airline co mpany.

11. OWNERSHIP OF AIRLINE ACCOUNTING CODE AND AIRLINE PREFIX

An airline accounting code or airline prefix is not considered to be the property of the company to which it is assigned. Once the company no longer meets the criteria for the

airline a ccounting code or airline prefix, that code or prefix shall be recalled in accordance with Paragraph 6 hereof.

Filing Period: Effective Date:

1 March

- 1 June 2012 13 April 2012RESOLUTION 780e

IATA INTERLINE TRAFFIC PARTICIPATI ON AGREEMENT

- PASSENGER (amending)

PSC( 29 33 )780e Expiry: Indefinite Type: B

P8.1

...

Article 2

– Issuance of Tickets and MCOs

...

2.2.6 Whereas certain parties to this agreement issue paper tickets as defined in IATA
Resolutions 720, 720a, 7 20b, 722, 722a, 722c and 722e, any Participating party which concurs with the Issuing Airline may refuse such paper tickets. However, the refusing party will provide at least 12 months notice to interline partners. The refusing party shall notify the IATA Director Passenger of which other party's paper tickets it refuses to accept, any specific exclusions to its policy (e.g. irregular operations, staff travel, non

ET eligible itineraries) and will provide an effective date. The IATA Director, Passenger

shal l publish in the MITA Manual a list of such refusals and the corresponding effective

dates.

Filing Period: Effective Date:

1 March

- 1 June 2012 13 April 2012RESOLUTION 792

BAR CODED BOARDING PASS )

- VERSION 4 VERSION 5 (amending)

PSC( 32 33 )792 Expiry: Indefinite Type: B

P6.3.9

RESOLVED that:

Members may issue, either for online or interline carriage, a Boarding Pass with version

4 version 5 of the Boarding Pass standard as described herein. All of the following specifications define the required characteristics of the elements and format of the Bar Code on the Boarding Pass or electronic (mobile) device or stored on the NFC chip.

....

1.1.2 USE OF ELECTRONIC (MOBILE) DEVICE BOARDING PASS

The data can be stored either in a Bar Code or in an NFC chip. The Bar Codes presented here are designed for use on an electronic (mobile) boarding pass. The NFC format presented here is designed for use on an NFC mobile device. Airport Boarding

Gate Read ers should be able to read the mobile Boarding Pass, either Bar Code symbologies or NCF NFC chip.

...RESOLUTION 792

Attachment ‘A’

BCBP M FORMAT VERSION 4 VERSION 5

New Item

number Element Description Field

Size Unique /

Repeated Data Type Formatting Ref no(s)

 1 Format Code 1 U f M is always used to represent either one or multiple segments a

5 Number of Legs Encoded 1 U N b

11 Passenger Name 20 U f Left justified and trailing blanks 14

253 Electronic Ticket Indicator 1 U f 65

7 Operating Carrier PNR Code 7 R f Left justified and trailing blanks c

26 From City Airport Code 3 R a 56

38 To City Airport Code 3 R a 56

42 Operating Carrier Designator 3 R f Left justified and trailing blanks

 43 Flight Number 5 R NNNN[a] Leading zeros on numerics, followed by an alpha or a blank

46 Date of Flight (Julian date) 3 R N Leading zeros 4

71 Compartment Code 1 R a 17

104 Seat Number 4 R NNNa Leading zeros on numerics

 107 Check-In Sequence Number 5 R NNNN[f] Leading zeros on numerics and alpha or blank on last digit u

113 Passenger Status 1 R f 16

 6 Field Size of variable size field (Conditional + Airline item 4) 2 R f Right justified leading zeros. Represented in Hexadecimal value d

8 Beginning of version number 1 U > sign

 9 Version Number 1 U f Currently at 5 ...but extensible beyond 10 by using A to Z if needed f

 10 Field Size of following structured message – unique 2 U f Right justified leading zeros. Represented in Hexadecimal value g

15 Passenger Description 1 U f 49

12 Source of Check-in 1 U f h

14 Source of Boarding Pass Issuance 1 U f i

22 Date of Issue of Boarding Pass (Julian Date) 4 U N First digit for the year then 3 digits with leading zeros 4

16 Document Type 1 U f j

21 Airline Designator of Boarding Pass issuer 3 U f Left justified and trailing blanks o

23 Baggage Tag License Plate Number (s) 13 U f The 10 digit bag tag number, as per BSM specifications, Reso 740 and 3 digits
identifying the number of consecutive tags p

31 1 st Non-Consecutive Baggage Tag License Plate Number 13 U f The 10 digit bag tag number, as per BSM specifications, Reso 740 and 3 digits
identifying the number of consecutive tags p

32 2 nd Non-Consecutive Baggage Tag License Plate Number 13 U F The 10 digit bag tag number, as per BSM specifications, Reso 740 and 3 digits
identifying the number of consecutive tags p

 17 Field Size of Following Structured Message – repeated 2 R N Right justified leading zeros. Represented in Hexadecimal value k

142 Airline Numeric Code 3 R N Right justified leading zeros

143 Document Form/Serial Number 10 R f Right justified leading zeros

18 Selectee Indicator 1 R f i

108 International Documentation Verification 1 R f 22

19 Marketing Carrier Designator 3 R f Left justified and trailing blanks m

20 Frequent Flyer Airline Designator 3 R f Left justified and trailing blanks n

 236 Frequent Flyer Number 16 R f Depends on carriers and alliances, left justified and trailing blanks 42

89 ID/AD Indicator 1 R f 53

118 Free Baggage Allowance 3 R f 59

 254 Fast Track 1 R f t

4 For individual airline use Var R e

25 Beginning of Security Data 1 U ^ sign

28 Type of Security Data 1 U f

 29 Length of Security Data 2 U f Right justified leading zeros. Represented in Hexadecimal value q

30 Security Data Var U f rConditional ItemsSecurityMandatory ItemsRESOLUTION 792

Attachment ‘B’

 EXAMPLE 1 - M1 USING MANDATORY ELEMENTS ONLY M1 USING MANDATORY ELEMENTS AND SECURITY FIELDS

New Item

number Element Description Field

Size Unique /

Repeated 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Notes

1 Format Code 1 U M

5 Number of Legs Encoded 1 U 1

11 Passenger Name 20 U D E S M A R A I S / L U C

253 Electronic Ticket Indicator 1 U E

7 Operating Carrier PNR Code 7 R A B C 1 2 3

26 From City Airport Code 3 R Y U L

38 To City Airport Code 3 R F R A

42 Operating Carrier Designator 3 R A C

43 Flight Number 5 R 0 8 3 4

46 Date of Flight (Julian date) 3 R 3 2 6 326 = November 22nd (2011 Calendar)

71 Compartment Code 1 R J

104 Seat Number 4 R 0 0 1 A

107 Check-In Sequence Number 5 R 0 0 2 5

113 Passenger Status 1 R 1

6 Field Size of variable size field (Conditional + Airline item
4) 2 R 0 0

0 in Decimal = 00 in Hexadecimal

8 Beginning of version number 1 U

9 Version Number 1 U

10 Field Size of following structured message – unique 2 U

15 Passenger Description 1 U

12 Source of Check-in 1 U

14 Source of Boarding Pass Issuance 1 U

22 Date of Issue of Boarding Pass (Julian Date) 4 U

16 Document Type 1 U

21 Airline Designator of Boarding Pass issuer 3 U

23 Baggage Tag License Plate Number (s) 13 U

31 1 st Non-Consecutive Baggage Tag License Plate

Number 13 U

32 2 nd Non-Consecutive Baggage Tag License Plate

Number 13 U

17 Field Size of Following Structured Message – repeated 2 R

142 Airline Numeric Code 3 R

143 Document Form/Serial Number 10 R

18 Selectee Indicator 1 R

108 International Documentation Verification 1 R

19 Marketing Carrier Designator 3 R

20 Frequent Flyer Airline Designator 3 R

236 Frequent Flyer Number 16 R

89 ID/AD Indicator 1 R

118 Free Baggage Allowance 3 R

 254 Fast Track 1 R

4 For individual airline use Var R Airline specific

25 Beginning of Security Data 1 U ^

28 Type of Security Data 1 U 1

29 Length of Security Data 2 U 6 4 100 in Decimal = 64 in Hexadecimal

G I W V C 5 E H 7 J N T 6 8 4 F V N J 9

1 W 2 Q A 4 D V N 5 J 8 K 4 F 0 L 0 G E continued from previous row

Q 3 D F 5 T G B N 8 7 0 9 H K T 5 D 3 D continued from previous row

W 3 G B H F C V H M Y 7 J 5 T 6 H F R 4 continued from previous row

1 W 2 Q A 4 D V N 5 J 8 K 4 F 0 L 0 G E continued from previous row Security Data VarConditional ItemsMandatory Items

30 USecurity EXAMPLE 2

- 1 SEGMENT, ALL CONDITIONAL AND OPTI ONAL DATA FILEDS FIELDS POPULATED

New Item

number Element Description Field

Size Unique /

Repeated 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Notes

1 Format Code 1 U M

5 Number of Legs Encoded 1 U 1

11 Passenger Name 20 U D E S M A R A I S / L U C

253 Electronic Ticket Indicator 1 U E

7 Operating Carrier PNR Code 7 R A B 1 2 C 3

26 From City Airport Code 3 R Y U L

38 To City Airport Code 3 R F R A

42 Operating Carrier Designator 3 R A C

43 Flight Number 5 R 0 8 3 4

46 Date of Flight (Julian date) 3 R 3 2 6 326 = November 22nd (2011 Calendar)

71 Compartment Code 1 R J

104 Seat Number 4 R 0 0 3 A

107 Check-In Sequence Number 5 R 0 0 2 7

113 Passenger Status 1 R 1

 6 Field Size of variable size field (Conditional + Airline item
4) 2 R 6 7

103 in Decimal = 67 in Hexadecimal

8 Beginning of version number 1 U >

 9 Version Number 1 U 5

10 Field Size of following structured message – unique 2 U 3 2 50 in Decimal = 32 in Hexadecimal

15 Passenger Description 1 U 1

12 Source of Check-in 1 U W

14 Source of Boarding Pass Issuance 1 U W

22 Date of Issue of Boarding Pass (Julian Date) 4 U 1 3 2 5 1325 = November 21st 2011

16 Document Type 1 U B

21 Airline Designator of Boarding Pass issuer 3 U A C

23 Baggage Tag License Plate Number (s) 13 U 0 0 1 4 1 2 3 4 5 6 0 0 2

31 1 st Non-Consecutive Baggage Tag License Plate

Number 13 U

0 0 1 4 1 2 3 4 6 7 0 0 1

32 2 nd Non-Consecutive Baggage Tag License Plate

Number 13 U

0 0 1 4 1 2 3 4 7 8 9 0 1  17 Field Size of Following Structured Message – repeated 2 R 2 A

42 in Decimal = 2A in Hexadecimal

142 Airline Numeric Code 3 R 0 1 4

143 Document Form/Serial Number 10 R 1 2 3 4 5 6 7 8 9 0

18 Selectee Indicator 1 R Not applicable on that flight

108 International Documentation Verification 1 R 1

19 Marketing Carrier Designator 3 R A C

20 Frequent Flyer Airline Designator 3 R A C

236 Frequent Flyer Number 16 R 1 2 3 4 5 6 7 8 9 0 1 2 3

89 ID/AD Indicator 1 R

118 Free Baggage Allowance 3 R 4 P C

 254 Fast Track 1 R Y Fast Track elligible

4 For individual airline use Var R L X 5 8 Z Airline specific

25 Beginning of Security Data 1 U ^

28 Type of Security Data 1 U 1

29 Length of Security Data 2 U 6 4 100 in Decimal = 64 in Hexadecimal

G I W V C 5 E H 7 J N T 6 8 4 F V N J 9

1 W 2 Q A 4 D V N 5 J 8 K 4 F 0 L 0 G E continued from previous row

Q 3 D F 5 T G B N 8 7 0 9 H K T 5 D 3 D continued from previous row

W 3 G B H F C V H M Y 7 J 5 T 6 H F R 4 continued from previous row

1 W 2 Q A 4 D V N 5 J 8 K 4 F 0 L 0 G E continued from previous rowMandatory ItemsConditional Items - Flight Segment # 1Security 30 Security Data Var UEXAMPLE 3

- 1 SEGMENT, PARTIALLY POPULATED

New Item

number Element Description Field

Size Unique /

Repeated 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Notes

1 Format Code 1 U M

5 Number of Legs Encoded 1 U 1

11 Passenger Name 20 U G R A N D M A I R E / M E L A N I E

253 Electronic Ticket Indicator 1 U E

7 Operating Carrier PNR Code 7 R A B C 1 2 3

26 From City Airport Code 3 R G V A

38 To City Airport Code 3 R C D G

42 Operating Carrier Designator 3 R A F

43 Flight Number 5 R 0 1 2 3

46 Date of Flight (Julian date) 3 R 3 3 9 339 = December 5th (2011 Calendar)

71 Compartment Code 1 R C

104 Seat Number 4 R 0 0 2 F

107 Check-In Sequence Number 5 R 0 0 2 5

113 Passenger Status 1 R 1

 6 Field Size of variable size field (Conditional + Airline item
4) 2 R 3 0

48 in Decimal = 30 in Hexadecimal

8 Beginning of version number 1 U >

 9 Version Number 1 U 5

10 Field Size of following structured message – unique 2 U 0 0 0 in Decimal = 00 in Hexadecimal

15 Passenger Description 1 U

12 Source of Check-in 1 U

14 Source of Boarding Pass Issuance 1 U

22 Date of Issue of Boarding Pass (Julian Date) 4 U

16 Document Type 1 U

21 Airline Designator of Boarding Pass issuer 3 U

23 Baggage Tag License Plate Number (s) 13 U

31 1 st Non-Consecutive Baggage Tag License Plate

Number 13 U

32 2 nd Non-Consecutive Baggage Tag License Plate

Number 13 U

 17 Field Size of Following Structured Message – repeated 2 R 2 A

42 in Decimal = 2A in Hexadecimal

142 Airline Numeric Code 3 R 0 5 7

143 Document Form/Serial Number 10 R 1 2 3 4 5 6 7 8 9 0

18 Selectee Indicator 1 R

108 International Documentation Verification 1 R

19 Marketing Carrier Designator 3 R A F

20 Frequent Flyer Airline Designator 3 R A F

236 Frequent Flyer Number 16 R 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6

89 ID/AD Indicator 1 R

118 Free Baggage Allowance 3 R

 254 Fast Track 1 R Y Fast Track elligible

4 For individual airline use Var R Airline specific

25 Beginning of Security Data 1 U ^

28 Type of Security Data 1 U 1

29 Length of Security Data 2 U 64 100 in Decimal = 64 in Hexadecimal

G I W V C 5 E H 7 J N T 6 8 4 F V N J 9

1 W 2 Q A 4 D V N 5 J 8 K 4 F 0 L 0 G E continued from previous row

Q 3 D F 5 T G B N 8 7 0 9 H K T 5 D 3 D continued from previous row

W 3 G B H F C V H M Y 7 J 5 T 6 H F R 4 continued from previous row

1 W 2 Q A 4 D V N 5 J 8 K 4 F 0 L 0 G E continued from previous row Security Data VarMandatory ItemsConditional Items - Flight Segment # 1Security 30 UEXAMPLE 4

- 2 SEGMENTS, ALL CONDITIONAL AND OPTIONAL DATA FILEDS FIELDS POPULATED

New Item

number Element Description Field

Size Unique /

Repeated 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Notes

1 Format Code 1 U M

5 Number of Legs Encoded 1 U 2

11 Passenger Name 20 U D E S M A R A I S / L U C

253 Electronic Ticket Indicator 1 U E

7 Operating Carrier PNR Code 7 R A B C 1 2 3

26 From City Airport Code 3 R Y U L

38 To City Airport Code 3 R F R A

42 Operating Carrier Designator 3 R A C

43 Flight Number 5 R 0 8 3 4

46 Date of Flight (Julian date) 3 R 3 2 6 326 = November 22nd (2011 Calendar)

71 Compartment Code 1 R J

104 Seat Number 4 R 0 0 3 A

107 Check-In Sequence Number 5 R 0 0 2 7

113 Passenger Status 1 R 1

 6 Field Size of variable size field (Conditional + Airline item
4) 2 R 5 A

90 in Decimal = 5A in Hexadecimal

8 Beginning of version number 1 U >

 9 Version Number 1 U 5

10 Field Size of following structured message – unique 2 U 2 5 37 in Decimal = 25 in Hexadecimal

15 Passenger Description 1 U 1

12 Source of Check-in 1 U W

14 Source of Boarding Pass Issuance 1 U W

22 Date of Issue of Boarding Pass (Julian Date) 4 U 1 3 2 5 1325 = November 21st 2011

16 Document Type 1 U B

21 Airline Designator of Boarding Pass issuer 3 U A C

23 Baggage Tag License Plate Number (s) 13 U 0 0 1 4 1 2 3 4 5 6 0 0 2

31 1 st Non-Consecutive Baggage Tag License Plate

Number 13 U

0 0 1 4 1 2 3 4 6 7 0 0 1

32 2 nd Non-Consecutive Baggage Tag License Plate

Number 13 U

 17 Field Size of Following Structured Message – repeated 2 R 2 A

42 in Decimal = 2A in Hexadecimal

142 Airline Numeric Code 3 R 0 1 4

143 Document Form/Serial Number 10 R 1 2 3 4 5 6 7 8 9 0

18 Selectee Indicator 1 R Not applicable on that flight

108 International Documentation Verification 1 R 1

19 Marketing Carrier Designator 3 R A C

20 Frequent Flyer Airline Designator 3 R A C

236 Frequent Flyer Number 16 R 1 2 3 4 5 6 7 8 9 0 1 2 3

89 ID/AD Indicator 1 R

118 Free Baggage Allowance 3 R 3 P C

 254 Fast Track 1 R Y Fast Track elligible for this segment

4 For individual airline use Var R L X 5 8 Z Airline specific

7 Operating Carrier PNR Code 7 R D E F 4 5 6

26 From City Airport Code 3 R F R A

38 To City Airport Code 3 R G V A

42 Operating Carrier Designator 3 R L H

43 Flight Number 5 R 3 6 6 4

46 Date of Flight (Julian date) 3 R 3 2 7 327 = November 23rd (2011 Calendar)

71 Compartment Code 1 R C

104 Seat Number 4 R 0 1 2 C

107 Check-In Sequence Number 5 R 0 0 0 2

113 Passenger Status 1 R 1

 6 Field Size of variable size field (Conditional + Airline item
4) 2 R 2 E

46 in Decimal = 2E in Hexadecimal  17 Field Size of Following Structured Message – repeated 2 R 2 A

42 in Decimal = 2A in Hexadecimal

142 Airline Numeric Code 3 R 0 1 4

143 Document Form/Serial Number 10 R 0 9 8 7 6 5 4 3 2 1

18 Selectee Indicator 1 R Not applicable on that flight

108 International Documentation Verification 1 R 1

19 Marketing Carrier Designator 3 R A C

20 Frequent Flyer Airline Designator 3 R A C

236 Frequent Flyer Number 16 R 1 2 3 4 5 6 7 8 9 0 1 2 3

89 ID/AD Indicator 1 R

118 Free Baggage Allowance 3 R 3 P C

 254 Fast Track 1 R N Fast Track NOT elligible for this segment

4 For individual airline use Var R W Q Airline specific

25 Beginning of Security Data 1 U ^

28 Type of Security Data 1 U 1

29 Length of Security Data 2 U 6 4 100 in Decimal = 64 in Hexadecimal

G I W V C 5 E H 7 J N T 6 8 4 F V N J 9

1 W 2 Q A 4 D V N 5 J 8 K 4 F 0 L 0 G E continued from previous row

Q 3 D F 5 T G B N 8 7 0 9 H K T 5 D 3 D continued from previous row

W 3 G B H F C V H M Y 7 J 5 T 6 H F R 4 continued from previous row

1 W 2 Q A 4 D V N 5 J 8 K 4 F 0 L 0 G E continued from previous rowMandatory ItemsConditional Items - Flight Segment # 1Security 30 Security Data 100 UMandatory Items - Flight Segment # 2Conditional Items - Flight Segment # 2EXAMPLE 5

- 2 SEGMENTS, PARTIALLY POPULATED

New Item

number Element Description Field

Size Unique /

Repeated 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Notes

1 Format Code 1 U M

5 Number of Legs Encoded 1 U 2

11 Passenger Name 20 U G R A N D M A I R E / M E L A N I E

253 Electronic Ticket Indicator 1 U E

7 Operating Carrier PNR Code 7 R A B C 1 2 3

26 From City Airport Code 3 R G V A

38 To City Airport Code 3 R C D G

42 Operating Carrier Designator 3 R A F

43 Flight Number 5 R 0 1 2 3

46 Date of Flight (Julian date) 3 R 3 3 9 339 = December 5th (2011 Calendar)

71 Compartment Code 1 R C

104 Seat Number 4 R 0 0 2 F

107 Check-In Sequence Number 5 R 0 0 2 5

113 Passenger Status 1 R 1

6 Field Size of variable size field (Conditional + Airline item
4) 2 R 3 0

48 in Decimal = 30 in Hexadecimal

8 Beginning of version number 1 U >

 9 Version Number 1 U 5

10 Field Size of following structured message – unique 2 U 0 0

15 Passenger Description 1 U

12 Source of Check-in 1 U

14 Source of Boarding Pass Issuance 1 U

22 Date of Issue of Boarding Pass (Julian Date) 4 U

16 Document Type 1 U

21 Airline Designator of Boarding Pass issuer 3 U

23 Baggage Tag License Plate Number (s) 13 U

31 1 st Non-Consecutive Baggage Tag License Plate

Number 13 U

32 2 nd Non-Consecutive Baggage Tag License Plate

Number 13 U

 17 Field Size of Following Structured Message – repeated 2 R 2 A

42 in Decimal = 2A in Hexadecimal

142 Airline Numeric Code 3 R 0 5 7

143 Document Form/Serial Number 10 R 1 2 3 4 5 6 7 8 9 0

18 Selectee Indicator 1 R Not applicable on that flight

108 International Documentation Verification 1 R

19 Marketing Carrier Designator 3 R A F

20 Frequent Flyer Airline Designator 3 R A F

236 Frequent Flyer Number 16 R 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6

89 ID/AD Indicator 1 R

118 Free Baggage Allowance 3 R 2 0 K

 254 Fast Track 1 R Y Fast Track elligible for this segment

4 For individual airline use Var R

7 Operating Carrier PNR Code 7 R D E F 4 5 6

26 From City Airport Code 3 R C D G

38 To City Airport Code 3 R D T W

42 Operating Carrier Designator 3 R N W

43 Flight Number 5 R 0 0 4 9

46 Date of Flight (Julian date) 3 R 3 3 9 339 = December 5th (2011 Calendar)

71 Compartment Code 1 R F

104 Seat Number 4 R 0 0 1 A

107 Check-In Sequence Number 5 R 0 0 0 2

113 Passenger Status 1 R 1

 6 Field Size of variable size field (Conditional + Airline item
4) 2 R 2 C

44 in Decimal = 2C in Hexadecimal  17 Field Size of Following Structured Message – repeated 2 R 2 A

42 in Decimal = 2A in Hexadecimal

142 Airline Numeric Code 3 R 0 1 2

143 Document Form/Serial Number 10 R 0 9 8 7 6 5 4 3 2 1

18 Selectee Indicator 1 R 0

108 International Documentation Verification 1 R 1

19 Marketing Carrier Designator 3 R

20 Frequent Flyer Airline Designator 3 R

236 Frequent Flyer Number 16 R

89 ID/AD Indicator 1 R

118 Free Baggage Allowance 3 R 2 P C

 254 Fast Track 1 R Fast Track eligibility is not qualified

4 For individual airline use Var R

25 Beginning of Security Data 1 U ^

28 Type of Security Data 1 U 1

29 Length of Security Data 2 U 6 4 100 in Decimal = 64 in Hexadecimal

G I W V C 5 E H 7 J N T 6 8 4 F V N J 9

1 W 2 Q A 4 D V N 5 J 8 K 4 F 0 L 0 G E continued from previous row

Q 3 D F 5 T G B N 8 7 0 9 H K T 5 D 3 D continued from previous row

W 3 G B H F C V H M Y 7 J 5 T 6 H F R 4 continued from previous row

1 W 2 Q A 4 D V N 5 J 8 K 4 F 0 L 0 G E continued from previous row USecurity 30 Security Data 100Mandatory ItemsConditional Items - Flight Segment # 1Mandatory Items - Flight Segment # 2Conditional Items - Flight Segment # 2RESOLUTION 792

Atta chment ‘C’

REFERENCES

**Secretary note** : the lines with 

###  in front have been amended; the lines with  in front have been added.

No Description Notes Set of Values 

### 

m Marketing carrier Designator Airline code of the marketing carrier (can be same as operating carrier) Both two IATA caracter code or three IATA letter code can be used

No Description Notes Set of Values



### 
o Airline Designator of Boarding pass issuer Identifies the origin of the data encoded in the airline individual use

field Both two IATA caracter code or three IATA letter code can be used

No Description Notes Set of Values



### 

s Fast Track Indicates if the passenger is elligible to Fast Track 'Y'': Yes, ''N'': No , Blank means it is unqualified
(Field is omitted if not used)

No Description Notes Set of Values


###  t Operating Carrier Designator Airline code of the operating carrier Both two IATA caracter code or three IATA letter code can be used

No Description Notes Set of Values


### 

u Check-In Sequence Number References obtained from the operating carrier for the flight Usually appears as 4 numerics and an optional alpha or a blank. However,
"Infants" are a known exception where Alphanumerical (full ASCII set)
values may appear, depending on individual Host Systems.

No Description Notes Set of Values



### 

42 Frequent Flyer Number 2 characters of 3 letters airline designator followed by up the 13
numerics or alphanumerics, or 16 numerics if the FFN is 16 digits.
Up to 16 Numerics or Alphanumeric's Depends on carriers and alliances, left justified and trailing blanks wit a
maximum of 16 Alphanumeric'sRECOMMENDED PRACTICE 1701a

PASSENGER DATA HARMONIZATION (new)

P6.3.1

PSC(33)1701a

RECOMMENDED that Aircraft Operators, States and Airports work together to exchange Passenger Data to enhance national, aviation and border security , and passenger fac ilitation

.

1. INTRODUCTION

States have long recognized that passenger data supplied by Aircraft Operators is a critical element of the State’s border control and risk management processes. A growing number of States require Aircraft Operators to provide Passenger Data related to certain travel and reservation information held in an Aircraft Operator’s reservation and/or departure control system. Various Passenger Data exchange requirements, often in different message formats, has resulted in the prolifera tion of sometimes conflicting national requirements.

2. SCOPE

This Recommended Practice on Passenger Data Harmonization is intended to provide a global framework on agreed Passenger Data elements and a standard way to transmit the Passenger Data elements b etween States and Aircraft Operators systems.

This Recommended Practice is not intended to cover the following aspects:

 Laws or Regulations

 Data Transmission protocol and/or timing

 Data Processing

 Filtering of Data

 Storage of Data

 Data Protection

These a spects are covered by ICAO Doc 9944, and are managed through a bilateral arrangement between the States and Aircraft Operators as defined by national legislation.3. PURPOSE

The purpose of this Recommended Practice is to standardize Passenger Data

collecti on and transmission to:

 minimize cost to the industry

 improve the quality of Passenger Data that States receive

 facilitate the identification of potentially high

- risk passengers with the objective to improve national, aviation and border security

 facilita te the clearing of low risk travelers

The recommendations also seeks to assist States in determining data requirements and developing procedures in order to minimize unilaterally imposed data transfer that differs substantially from one State to another ( or “that differ substantially between States”).

4. PASSENGER DATA ELEMENTS

For States requesting Passenger Data in addition to specific travel document details, it is recommended that the message structure and content of PNRGOV developed by the PADIS Boar d and to be endorsed by ICAO in its Document 9944 be adopted. The PNRGOV message is designed to provide a consistent approach for all Aircraft Operators required to provide PNR information to States. In an effort to standardize the PNRGOV message structure , the PADIS Board has developed the “Principles, Functional and Business Requirements” document, which is intended to provide guidance to Aircraft Operators, system suppliers and States that are implementing the PNRGOV message. The information contained in the document should be utilized in conjunction with the PNRGOV EDIFACT Implementation Guide.

4.1 PNRGOV Message Modifications

Under an agreement between IATA and the World Customs Organization (WCO), maintenance of the PNRGOV message format, and contro l over the authorization of modifications to that message structure, will be assumed by the WCO. Coordination of actual amendments of the message structure itself will fall under the remit of the WCO API Contact Committee which is comprised of the WCO, IAT A and ICAO Secretariats, as well as interested States. Any interested party may recommend modifications to the PNRGOV message structure by use of the existing WCO Data Modification Request (DMR). The change process is described in the Message

Modifications Approved Revision Process PNRGOV Document.

Filing Period: Effective Date:

1 March

- 1 June 2012 13 April 2012RECOMMENDED PRACTICE 1701d

SELF

- SERVICE AUTOMATED DOCUMENT CHECK (amending)

PSC( 32 33 )1701d

P6.3.2

**Secretary n ote**  : the following text completely replaces the current text of RP 1701d

RECOMMENDED that, when Members offer automated Document Check capability in a dedicated or common environment, for the purposes of individual airline processes, the specification a nd standards as described in this Recommended Practice (RP) are applied.

1. INTRODUCTION

Airlines need to obtain and verify passenger data from Travel Documents in order to:

1. Perform a Positive ID check to verify that the passenger is who they present

thems elves to be

2. Verify that the passenger has the correct travel documents to be admitted to the country(s) they are travelling to or transiting through

3. Collect (or verify previously obtained) passenger data to be provided to government organizations in advanc e of the passengers arrival (API)

2. SCOPE

Document Check describes the specification and standards for Travel Document Data Capture and Document Check Applications to fulfill point 2 and facilitate point 3

of the above.

Member airlines, handling agents an d airports will implement a Document Check process and/or facilities to include, but not be limited to, Document Check functionality. Future developments may include other functions, both business and

technical.

This Recommended Practice is solely concer ned with Machine Readable Travel Documents where the passenger’s data can be extracted electronically by a device.

While the Recommended Practice is not intended to cover the management and verification of other travel document requirements (i.e. non da ta requirements) the Document Check solution should identify these exceptions. These can include:• Travel Documents (Visas in particular) where the data cannot be extracted automatically, for example where the document is hand written

• Where a specified number of blank pages are required in the passport for
entry

• Certain countries do not allow admission if there are entry stamps from

others

• Certain countries require translation of the visa in multiple languages

• Manual, secondary inspections to verify fra udulent passport may be an airline process or state’s requirement

• Babies / minors travelling on parent / guardian passports

• Marriage name / aliases that require manual verification

• Countries that require proof that passengers meet health requirement such as vaccination certificates.

Such exclusions need to be recognized and managed separately as part of any implementation of a self

- service solution.

3. PURPOSE

The purpose of Document Check is to automate the Passenger Travel Document Compliance Check proc ess, thereby:

• minimizing improperly documented passenger fines

• saving staff and infrastructure costs associated with current manual process

• increase the penetration of self service kiosk check

- in for complex route

– nationality combinations

It is recom mended that passengers travel document be captured during the self service check in process be used to automatically check that the passenger has correct Travel Documents to satisfy requirements for the departure, destination or

transit countries. Airline s have a requirement to validate that each passenger has the correct documentation. This requirement is enshrined in most States’ legislation or immigration regulations. Where a passenger is carried who does not have correct

travel documents for the tran sit or destination country, the airline will normally be fined and will have to carry the passenger back to the point of departure at the airlines own expense.

The passengers data can also be transmitted to the relevant authorities where required for API purposes. Increasingly, states are requiring Aircraft Operators to transmit passenger manifest and other relevant information to the destination country in advance of the aircraft arrival. However even when passenger’s data is

transmitted to the relevant authorities and a positive response is returned, it does not replace the requirement to check that the passenger is in possession of the required

Travel Documents.

The Document Check process is designed to enable the automatic capture of passengers’ data from their Travel Documents in a single process.The major benefits of Document Check are:

• Identify all improperly documented passengers thereby reducing associated fines and repatriation costs.

• Reduce passenger documentation compliance process and ma nagement

costs.

• Reduce Passenger Service/operational staff and infrastructure required.

• Reduce staff training costs.

• Streamline and simplify boarding process, reducing flight delays

• Reduce system development and maintenance costs.

• Support the increased pen etration of self

- service check

- in.

• Reduce passenger compensation for incorrect refusal to board.

• Enhance customer experience.

4. BUSINESS CASE

The financial benefit of implementing a Document Check solution will be different for each airline and will depend on:

• Number of international travelers carried by the airline.

• Route/nationality combinations.

• Efficiency of current passenger document compliance processes.

• Frequency and value of fines.

• Scope of the implementation.

• Cost of implementing Document Check sol ution.

While the many benefits of Document Check solution are detailed in the previous section, we have quantified the following factors in the business case:

1. Reduced passenger travel document compliance check costs

2. Reduced improperly documented passenge r fines.

3. Increased penetration of self service kiosk check

- in

5. DEFINITIONS

For the purposes of this Recommended Practice, the following definitions apply;

5.1. Travel Document

An official identity document issued by a state or organization, which may be used b y the rightful holder for international or domestic travel. Travel documents are normally Passports, National Identity Cards, and Visas, but can include a wide range of other documents such as: Driving Licences, Residence Cards and Refugee

Documents.

5.2. Mach ine Readable Travel Document (MRTD)

Machine Readable Travel Document (e.g., passport, visa). Official document issued by a State or Organization which is used by the holder for international or domestic travel (e.g. passport, visa, official document of ide ntity). The MRTD contains mandatory visual (eye readable) data and a separate mandatory data summary, intended for global use, reflecting essential data elements capable of being machine

read. MRTD is defined in ICAO DOC 9303.5.3. Self Service Data Capture

T he action by which a passenger presents a Machine Readable Travel Document to the capture device for the purposes of automatically capturing Travel Document

data.

5.4. Positive ID

Where the passenger presents their government issued ID to the aircraft operator agent for verification.

5.5. Passenger Authentication

This is performed by comparing the data on the Boarding Token with that on the

Travel Document

5.6. Document Check

Document Check ensures that the passenger has correct Travel Documents to satisfy the immigrati on requirements of the departure, destination and transit countries. The Document Check is based upon data extracted from the passengers Travel Document and itinerary details contained within the airlines systems.

5.7. Document Check Application

An application which automates Document Check

5.8. Document Data Registration

The process by which a passenger provides the airline with travel document data in any other method than Self Service Data Capture (e.g. keying the information on the airline web site, spelling th e document information on the phone, etc..). This data can be used for Document Check and/or API purposes.

5.9. Passport

An official government document that certifies a traveler’s identity and citizenship with a right to protection while abroad and a right to return to the country of citizenship.

5.10. API

- Advance Passenger Information.

Advanced Passenger Information or API as it is normally referred to, consists of passenger data which must be collected by airlines and communicated to the

destination/transit co untry authorities. This data is communicated to the authorities using an Advanced Passenger Information System (APIS). This data normally consists of elements included in the passengers Travel Documents and itinerary, although some countries require addi tional information such as address where the passenger will be staying. Many countries require API and have their own proprietary APIS systems such as APP, AQQ, ESTA etc...

5.11. Self Service Check

- In Application

An application used by the passenger to perform the check

- in process at a self

service device. This application is connected to the airline host systems.

5.12. Secure zone / airside check point

The point at which the check is made for the entitlement to enter the secure zone /

airside

.5.13. Boarding token

Means the token used by the passenger to board the aircraft, for example BCBP (bar

- coded boarding pass on paper or mobile), Machine Readable Travel Document (Passports, Visas, ID Cards), passenger biometrics, frequent flyer cards, etc.

5.14. Visa

An official entry in a Passport or other Travel Document made by an official of a government to indicate that the bearer has been granted authority to enter or re

enter the country or region concerned.

6. DOCUMENT CHECK PROCESS

6.1. Eligibility

Only passengers holding Machine Readabl e Travel Documents are eligible to use

Document Check.

6.2. Prerequisite

To use Document Check, the airline system / DCS, should include the functionality to keep track of the Document Check status. Passengers whose documents have been checked as per definition under 4.5, by a trusted source should be noted in the
system.

6.3. Document Check Process Description

The standard process for Document Check can comprise three elements:

• Document Data Registration

• Data Capture

• Document Check.

6.3.1. Self Service Document Data Re gistration

The process by which a passenger provides the airline with travel document data in any other method than Machine Readable capture (e.g. keying the information on the airline web site, spelling the document information on the phone, etc..).

6.3.2. Doc ument Data Capture

The process by which a passenger presents their Machine Readable Travel Documents at a device to capture the data. This process should be required by the airline for each journey.

It is recommended that full page document readers are u sed for that purpose. The device should also be RFID/NFC capable or upgradeable for potential future requirements such as e

- Passports which utilize new data storage technologies.

Should Document Data Registration be offered, the registered data should b e compared with the data captured during Data Capture and both sets of data should be identical. Should the data not match, the Data Capture data should be used.6.3.3. Document Check

The process by which the MRTD captured data is processed along with the re levant itinerary data by a Document Check Application.

The Document Check Application is an automated system that checks whether the passenger has sufficient Travel Documents to satisfy the immigration requirements of the departure, destination and trans it countries.

The possible results of Travel Data Check are:

• ‘Yes’ the passenger has correct travel document

• ‘No’ the passenger does not have correct travel documents because...

• ‘Conditional’, it is not possible to determine whether the passenger has

corre ct documentation. Check ...

In the second two cases manual intervention is required by the airline or agent.

In any case, the system should immediately present an appropriate service message to the passenger.

6.4. API Process Description

The passengers Travel Document and itinerary data can also be used for API

purposes

7. DOCUMENT CHECK PROCESS POINTS

7.1. Kiosk Check

- In Passengers

It is recommended that the Document Check process is offered to passengers checking

- in at a kiosk during the check

- in transaction. The c heck

- in kiosk should be equipped with an MRTD capture device and a relevant application to perform an

automated Document Check

If the Document Check process (including travel data check) is successful, then the status of the passenger should be updated in to the airline host system.

The appropriate field in the BCBP could also be updated according to IATA Resolution 792. However, airline host data should always supersede BCBP data.

7.2. Capability at airport for Off Airport Checked

- In Passengers

It is recom mended that self service Document Check capability is offered to passengers already checked

- in off airport (e.g. online check

- in and mobile check

- in) by:• Providing a self service process point, which may be a kiosk or another device for that purpose on ly, either landside or airside (depending on airlines and local regulation processes) but prior to the boarding point.

• At boarding as part of an automated process (e.g. Self Boarding) including both Document Check and boarding processes.

• Passengers checki ng bags could also have their data verified at the Fast Bag Drop location

7.3. Signage

It is recommended that the following signage/icons are used by member airlines, airports or handling agents to advertise the simplified process availability at the airport. This will create awareness, consistent passenger experience and help drive penetration of the Document Check globally.

8. TECHNICAL AND INFRASTRUCTURE ENVIRONMENT

8.1. Product Functionality

To facilitate the Document Check proces s, it is recommended that the equipment deployed:

• should integrate an interactive screen to present instructions and information to the passenger

• must integrate an Machine Readable Travel Document capture device which can capture data from travel document s

• should integrate 2D Bar Code capability to read the BCBP

• must utilize an appropriate application or module to perform Data Capture and

Document Check

• should be interfaced to the airline host system to update the passenger

status.

• could integrate a captu re device to support other technologies such as RFID chip and NFC chip.

• could integrate a biometrics reader to perform Passenger Authentication when the passenger utilizes an e

- Passport or a biometrics registration token.8.2. Ergonomics

It is recommended to use a flat bed full page reader for Machine Readable Travel Document data capture. It is also recommended to use a single device capable of reading both MRTD and BCBP.

8.3. Data to be used for Document Check

Data required to perform a Document Check as desc ribed in 5.3.3 should be extracted from the Travel Document and the itinerary data held with the airline systems or on the BCBP

To maximize positive results from the data verification system, it is recommended that where possible the following data is cap tured and used for the Document Check.

Different data elements are required by different countries. If an element is missing, then the Document Check Solution may still be able to produce a positive response without manual intervention. Key elements wh ich are normally required by all countries include Destination country, Nationality, Duration of Stay, Age/Date of Birth, Document Held, Document Expiry Date.

Data required to perform a Document Check

Parameter Description Available from

MRZ or BCBP

De stination Country Final country/airport where the passenger will complete their journey 

Departure Country Country/airport where the passenger began their trip 

Arrival Date Date on which the passenger will arrive in the destination country 

Departur e Date Date on which the passenger departs from the departure country Duration of Stay The amount of time that the passenger will be spending in the destination country 

Operating Carrier Two

- letter code of the operating

carrier the 

Return Onward

T icket Whether the passenger has a return or onward ticket for all segments of the itinerary Stay Type Purpose of stay

Destination Visa Whether passenger is holding a valid visa for destination country

Transit Points

- Only if transiting Country(s)/ai rport(s) through which the traveler transits on the way to destination. Max 5 transit points

Transit Arrival Date & Time (if transiting) Transit country arrival date/time

Transit Departure Date & Time (if transiting) Transit country departure date/timeTransit Visa (if transiting) Whether the passenger has a valid visa for transit country

Countries visited last 6 days Countries Visited in the last 6 Days. Only required for Health regulations Document Type Details of the passenger’s passport or
passport

- replacing travel document 

Issue Date Date on which the travel document

was issued

Expiry Date Date on which the travel document expires 

Issuing Country Country that issued the travel

document 

Nationality Nationality country code 

Gender Gender 

Date of Birth Date of birth 
Passport Series Alpha characters of Passport Number 

Document

Feature Biometric, Digital Photo, or Machine

Readable document features which impact regulations. Country of Birth Country of birth code

Cou ntry of

Residence Country in which the passenger resides, either permanently or temporarily Residency

Document Residency document held if traveler lives in a country different to their nationality Grey = strongly recommended so as to maximize Yes/No re sponses.

8.4. Off line travel data check

As most of the data needed to perform Document Check are located in both passengers Machine Readable Travel Document and BCBP, the Document Check process could be performed off

- line where there is no direct access t o the airline host system. In such cases the document requirements are verified locally and a message sent to the airline host system to update the passenger status using the messaging interface described in 7.4.1.

8.4.1. Messaging and Interface to airlines’ sys tems
Should a Document Check Application be used outside of the airline system environment, it is recommended that the interface between such system and the airline host system is handled through the IATA XML and EDIFACT existing

standards.

Filing Peri od: Effective Date:

1 March

- 1 June 2012 13 April 2012RECOMMENDED PRACTICE 1701h

SECURITY CHECKPOINT ACCESS AND EGRESS

(new)

PSC(33)1701h

P6.3.3

All the content of this document is intended to be used as guidance materi al, to be considered by airports when applicable, subject to local requirements:

1. INTRODUCTION

 The recommendations that appear on this document are intended to be a useful reference for airport terminal design and management of the passenger

flow aroun d security checkpoint.

 The information provided comes from airports where the mentioned best

practices have been implemented successfully.

 This document is not intended to be part of any regulation or mandate

 This document is a joint effort of ACI and IA TA.

2. SCOPE

The main focus of this best

- practice guidance will be for security checkpoint access and egress.

2.1 Security checkpoint access:

 Pre

- screening preparation zone and queuing space

 Divest tables and zones

 Tray feeding systems

2.2 Security chec kpoint egress:

 Composure tables and zones

 Egress seating area

 Tray recovering systems3 GEOMETRICAL CONFIGURATION

3.1 Assumption

Default security checkpoint configuration:

• Configuration “2 X

- RAYS to 1 WTMD” (Walk

- Through Metal Detector)

• Centralized screening area

 The standard “2 X

- RAYS to 1 WTMD” security checkpoint configuration has been pre

- selected as best practice configuration, as it is widely used in average centralized airport screening areas all around the world, providing great efficiency and flexibility

 Airports that have implemented other Security checkpoint configurations (i.e. gate screening) may use the following information as an overall reference benchmark, depending on their local arrangements.

 It is important to mention that, for airports developing the one stop security concept for connecting passengers, the centralized security checkpoint area is the most efficient way to implement that concept.

3.2 Diagram3.3 Dimensions

Following the previous schema, the ‘best practice‘ p articipant airports have the following dimensions

– in centimeters (cm):

AVERAGE LOWER

LIMIT

A Pre

- screening and queuing 737 400

B Divest 247 100

C Composure 281 100

D Egress Seating 375 200

E 196 100

F 413 400

4 ACCESS

4.1 Pre

- screening and q ueuing

4.1.1 2D Bar code scanning to provide access

2D bar code scanning is recommended to be conducted before entering the queue to determine passenger eligibility to access restricted area and/or segregated line.

4.1.2 Information on screening procedures

Information point, containing:

 Poster on regulation,

 Video explaining the process

 Information flyers available for passengers

 1 officer supervising the information procedures

4.1.3 Segregation of lines

Segregation of lines in at least two groups:

 Premium passengers / Frequent travelers

 Occasional travelers / Families with children

4.1.4 Queuing arrangements

 Provide tensa

- barrier flexible queuing system

 1 supervisor / queuing manager on duty during peak times4.1.5 Staff allocated to help passenger in p re

- screening

 Customer Service ambassador to help and advise passengers

4.2 Divest tables and zones

4.2.1 Rectangular roller beds aligned with X

- RAY feeding

 Roller beds could accommodate at least 3 passengers

4.2.2 Roller beds overlapped with tensa

- barrier queuing

 Enable passenger divesting while moving along the queue

4.2.3 Staff allocated to control divesting and X

- RAY feeding

 1 loader per X

- RAY in

- feed.



4.3 Tray feeding

Provide a mechanical system, integrated in the checkpoint infrastructure, for trays t o be rolled back efficiently.

5 EGRESS

5.1 Composure tables and zones

5.1.1 Rectangular roller beds aligned with X

- RAY out belt

 Provide roller beds and tables aligned

– to accommodate at least 5 Passengers

 Secondary search table at 90° not to interfere with the flow

5.1.2 Staff allocated to assist passengers

 2 Searchers

– opposite sex

– right behind the WTMD

 Private booths available for secondary search

5.2 Egress seating area

 Tables for passengers to repack their hand luggage

 Seating possibilities to accommodate at least 2 passengers per X

- RAY

5.3 Tray recovery

Provide a mechanical system, integrated in the checkpoint infrastructure, for trays to be rolled back efficiently.6. OTHER CONSIDERATIONS

6.1 Ambience

It is very important to provide a good ambience, focusing at least on the following
aspects:

 Cleanliness

 Light

 Temperature

6.2 Recommendations when shoe inspection is required

 Plastic slippers

 Soft floor covering

6.3 Courtesy and friendliness of staff

 Customer Service Training

 Language tr aining

 Basic greetings: ”Good morning.. have a good flight”

6.4 Information on processing time

 It is very useful to inform the passenger about a standard waiting time, to gain predictability and reduce stress/hassle

7 MEASUREMENT OF PASSENGER PERCEPTION

It is highly recommended to measure the passenger perception of the security screening process, covering at lest these two aspects:

 Courtesy of security staff and perceived time at security

8 MEASUREMENT OF QUEUING TIME PERFORMANCE

It is highly recommend ed to have a performance indicator measurement process, to measure at least security checkpoint waiting tines and throughput, for security management to be able to allocate staff efficiently, according to the flow distribution.

Filing Period: Effective Date:

1 March

- 1 June 2012 13 April 2012RECOMMENDED PRACTICE 1701 i

INTERNATIONAL TRAVELER SCHEME (new)

PSC(33)1701 i

P6.3.6

RECOMMEND that Governments work together to develop commonalities between national registered trav eler schemes to facilitate joining these together within wider multilateral initiatives. Where Governments offer registered traveler schemes, airlines underpin Government promotional activities and the facilities offered by airport operators support these schemes.



### 1. INTRODUCTION

1.1 A number of countries world

- wide have established, or are in the process of establishing national, bilateral and multilateral registered traveler schemes.

1.2 The concept of a registered traveler scheme is to provide pre

- as sessed low

risk travelers with expedited passage through border controls.

1.3 These schemes deploy an automated process to:

• Check that the passenger is in possession of a genuine, valid travel document

or token

• Verify the passenger’s biometric data agains t the travel document or token or

a pre

- existing biometric identifier supplied by the passenger during enrolment to ensure the travel document is presented by the rightful owner.

• Grant or deny admission according to pre

- established specification.



### 2. SCOPE

2.1 Whilst each registered traveler scheme is unique, commonalities do exist; It is

recommended that:

2.1.1 Operationally

• Registered traveler schemes may be separately developed and operated by a Government or jointly developed and operated between Gove rnment and Industry.

• Where a charge is levied, the scheme should offer travelers a more bespoke
service, i.e., web

- based application including forms and the ability to schedule

interviews

• The scheme should facilitate an increased efficiency in traveler cl earance
times

• Procedurally and practically clear for travelers to understand and operate2.1.2 Eligibility

• The scheme should be open to nationals from more than one country

• Age restrictions may apply

• Membership should to be time limited, invariably li nked to the length of the

travel document.

• Continued eligibility requires passing regular background checks.

2.1.3 Enrolment

• Enrolment is voluntary in all schemes

• All registered traveler schemes should collect biographic data and may request supplementar y data

• Each scheme will capture a minimum of one biometric

2.1.4 Background checks

• Regular background checks are conducted against national databases

• These may include biometric data and criminality checks.



### 3. PURPOSE

The purpose of a Registered Trave ler Scheme is to allow travelers expedited passage through automated border controls following successful background checks and the recording of biometric data.

Governments should benefit from initiating a registered traveler scheme by enhancing security of the border through the use of biometrics, reducing illegal immigration, allowing more effective deployment of resources towards potentially higher

- risk travelers and being able to obtain additional advanced information on travelers. Governments may also benefit in that additional sources of information may be utilized that they would not normally have access to in the identification of

low

- risk travelers.

Airlines may indirectly benefit from the additional vetting of travelers within the
scheme, which o ffers greater security on the identity of the traveler and their admissibility by border control authorities. Where schemes incorporate direct transit points, airlines should additionally benefit from on

- time departures where a passenger is transiting an a irport and is required to make a border crossing, leading to cost efficiencies and the provision of better customer service.

Airport operators should expect a reduction in queue length and times which will facilitate a more efficient use of space and a po ssible deferment of infrastructure requirements and costs.

The vision is to ultimately create an International Traveler scheme which will bring registered traveler schemes together under one overall initiative. An International

Traveler Scheme should enha nce a passenger’s travel experience by granting them access to a range of registered traveler programs operated by participating countries

where access would be otherwise unavailable. The Traveler should also benefit from a standardized application process , access to expedited automated border crossings and the creation of a more seamless journey.

The recommendations also seek to assist Governments and Industry in designing data requirements for the implementation of a registered traveler scheme which may facilitate multilateral agreements.

### 4. DEFINITIONS

For the purposes of this Recommended Practice, the following definitions apply;

4.1 Admission The permission granted to a passenger to enter a State by the public authorities of

that State in accord ance with its national laws.

4.2 Automated Border Control (ABC) An automated control system that authenticates travel documents and/or tokens and permits, or denies, admission to a traveler according to a pre

- established specification. The ABC may additio nally verify the passengers’ biometric data against the travel document and/or token or a pre

- existing database containing biometric data. It may also register the entry or exit of the country.

4.3 Biometrics Biometrics are any means by which a person can be uniquely identified by evaluating one or more distinguishing biological traits. Unique identifiers include fingerprints, hand geometry, iris, retina, facial image, hand vein geometry, voice waves, DNA, and signatures.

4.4 International Traveler Scheme An umbrella initiative that seeks to bring countries existing registered traveler schemes together.

4.5 Registered Traveler Scheme A registered traveler scheme allows pre

- assessed low

- risk travelers expedited passage through automated border control syst em following successful background checks and the recording of biometric data.

4.6 Token A personalized secure credential that permits the authorized traveler to gain admission via automated border controls, subject to passing background checks
and, in so me instances, producing a valid travel document.

4.7 Travel Document A passport or other official document of identity issued by a State or organization, which may be used by the rightful holder for international travel.



### 5. DATA FIELDS

In an effort to facilitate multilateral agreements the following represents a composite list of the information Governments may request for the Registered Traveler Scheme application process. This list is not exhaustive.Biographic Information

• Last, First and Middle n ames

• Gender

• Date of birth

Governments may additionally request;

• Surname or Academic title, prefix or suffix

• Maiden Name

• Alias

• Height

• Eye Color

• Town/State/Province of birth

Nationality and Citizenship

• Country of birth

• Country of Citizenship

• Immigration Status

• Nationality

Travel Document

• Travel Document type and number

• Expiry date

• Date of issue

Governments may additionally request;

• Government issuing the document

• Visa information

• Information on other travel documents

Contact Details

The following c ontact fields are primarily utilized to contact fee

- paying applicants;

• Country of primary residence

• Address if different from primary residence

• Commencement date for current address

• Full current address details

• Previous address history where the above cov ers less than 5 years

• Mailing address if this differs from the current address

• Home, Business and Mobile Telephone Numbers

• Email Address

• Invoice Address

• Preferred language and method of communication whether email or mailEmployment

The following inf ormation may be requested to inform background checks;

• Employment status and commencement date

• Occupation

• Employer name, address and telephone number

• Additional employment history where the above covers less than 5 years

Travel History

Governments may additionally request;

• Boarding Pass available at time of enrolment

• Average number of flights per year

• Travel history over a specified period

Criminality, Immigration and Customs Offences

Whilst the following information is not widely requested, it is u tilized by Governments to inform background checks;

• Criminal conviction details

• Waiver of Inadmissibility details

• Customs offences

• Immigration offences

Membership and Payment Details

Those Governments operating fee

- paying registered traveler schemes ma y seek to

establish:

• Where Governments offer varying levels of membership, the type of membership the applicant requires

• Payment method and bank details

Terms and Conditions

• All Governments seek to ascertain that the applicant understands the terms

an d conditions of the scheme before proceeding.

Filing Period: Effective Date:

1 March

- 1 June 2012 13 April 2012RECOMMENDED PRACTICE 1701j

AUTOMATED AND SELF

- SERVICE FLIGHT REBOOKING FOR IRREGULAR

OPERATIONS (new)

PSC(33)170 1j

P6.3.5

RECOMMENDED that, when Members plan to offer Self

- Service Flight Rebooking for Irregular Operations capability in a dedicated or common use environment, for the purposes of individual airline processes, the specification and standards as

descr ibed in this Recommended Practice are applied.

1. PURPOSE

Automated and self

- service flight rebooking focuses on how irregular operations can be improved from a passenger processing perspective by introducing

automated and self

- service options.

It is a pre

- requisite to use good management practices and tools in order to implement any service recovery measures particularly through self

- service options. The resulting benefits include improved customer service for all passengers and

decreased costs for airline s.

This Recommended Practice is meant to complement, but not supersede, currently agreed

- upon industry standards (e.g. AIRIMP, IATA Resolutions 735d/735e/766,

A 4 A 120.20) or other bilateral agreements and arrangements between or among

airlines or alliance s.

2. SCOPE

This Recommended Practice addresses only Irregular Operations. The timeframe and conditions for Irregular Operations are defined by individual airline policy.

This Recommended Practice is limited to automated flight rebooking systems that

prov ide self

- service options to passengers. These flight rebooking systems can be either fully automated to the extent possible (no manual intervention) or partially automated with the objective to minimize passenger contact with airline ground

staff.

3. GLOSSA RY

a. Automated Rebooking System

– Fully or partially automated system meant to rebook passengers impacted by delayed or cancelled flights, especially during Irregular Operations. Automated rebooking systems enhance airline efficiency and

enable more consis tent passenger processing.

b. Interline

– Used in conjunction with another word to describe anything involving two or more airlines, such as interline itinerary, interline reservation, interline stopover, interline point, interline transaction, etc.c. Irreg ular Operations (IRROPS)

– Irregular Operations (IRROPS) is identified by an airline or ground handler acting on behalf of an airline when a disruption causes a planned flight schedule to become inoperable or delayed affecting both passengers and resources . An Irregular Operation (IRROP) may be, but not limited, to a flight delay, cancellation, diversion due to weather, mechanical problem, landing restriction, air traffic congestion, accident/ aircraft damage, security concern, immigration issue, boarding delay, crew or other staff issues.

d. ITBA

– Interline ticket and baggage agreement.

e. Online

– Used in conjunction with another word to describe anything involving carriage over the services of one airline to another service of the same airline, such

as an on

- line itinerary, on

- line reservation, on

- line stopover, on

- line connection, etc.

f. SSD

– Self Service Device.

4. BILATERAL AGREEMENTS

This document recommends that carriers, where applicable, should follow procedures as outlined in IATA Resolutions 735d/ 735e/766, AIRIMP and A 4 A Resolution 120.20. Bilateral or alliance agreements may exist that supersede the above Resolutions. These bilateral or alliance agreements may offer airlines additional flexibility to their automated and manual rebooking systems by offering seamless availability; direct sales and access; and interactive sales in order to establish firm confirmations for passengers.

5. CARRIER NOTIFIED OF IRREGULAR OPERATIONS

a. Carriers may be notified of Irregular Operations in the following ways:

i. I nternally, by automatically receiving flight status information for both potential

and confirmed disruptions, delays and cancellations.

ii. Externally, by leveraging alliance/codeshare functionality and/or bilateral flight

status notices. E.g. Type B message s, XML, etc.

6. IRREGULAR OPERATIONS MANAGEMENT:

The following table is an overview of how certain elements during Irregular Operations may be managed. Where applicable, distinctions between online, interline, delays, cancellations, and misconnects, will be made. Airlines may choose to follow these steps in accordance with their individual business rules.Irregular Operations process Note: Unless noted otherwise, the processes below apply to the following irregular operations

conditions: 1) Online Delay 2) Online Cancellation 3) Online Misconnect 4) Interline Delay 5) Interline

Cancellation 6) Interline Misconnect

Note: Automatically load operational status of the flight into RES/DCS system Appropriate notices, according to airline procedure, should also be given to various partners (e.g. airport authorities, codeshare/alliance partners, etc.)

PNR transferred to the carrier automated rebook system. Consideration should be given to separate RES and DCS systems as well as ground handlers according to individual air line policy PNR transferred of passengers in jeopardy or who will misconnect (business rule to define priorities) Rebook the passenger on the best available flight according to the airline’s individual business rules Rebooking may be prioritize and/o r optimized through various methods:

• Routing

– Non

- stop versus connecting itinerary, domestic versus international, originating versus connecting

• Journey time

– Using the shortest possible routing

• SSRs

– Certain SSRs may be handled differently or man ually (special attention should be given that certain SSRs are properly associated with new itinerary)

• Frequent flyer program

– Depending on airline, certain tiers may be prioritized

• Class of service

– e.g. First class may be prioritized before economy

• Booking code

– e.g. Y may be prioritized

before M

• Ticket value (fare paid)

• Groups

– May need to be handled differently or manuallyIrregular Operations process Note: Unless noted otherwise, the processes below apply to the following irregular operations

conditions: 1) Online Delay 2) Online Cancellation 3) Online Misconnect 4) Interline Delay 5) Interline

Cancellation 6) Interline Misconnect

Note:

• Booking channel

– Passengers who booked through various booking channels may need to be handled differently or manua lly based on certain

restrictions

• Passenger record checked/validated for

MCT

Document Check

– Ensure the passenger’s travel documents permits travel via the new routing booked to avoid passenger inconvenience and

carrier fines Check flight status pri or to booking to ensure flight is on time or operable. Note: This step may not be possible for interline

- booked itineraries Notify passenger of new routing ( see Passenger

communication 7 )

Reinstatement

– Consideration needs to be made in case a flight is reinstated or reverts back to original ETD

— system may either have an “undo” function or could be handled manually Automated reinstatement may only be possible for online itineraries only. Other airline segments may need to be manually processed.

Pass enger’s record (PNR or DCS) should indicate it has been handled or rebooked by automated rebook system (according to airline’s business rules) Indicator may be possible for online itineraries only and not carry over to other airline segments. Passenger’s record (PNR or DCS) needs to be ready for use through a self

- service channel (e.g.

self

- service device, kiosk, online, mobile) This step may not be possible for interline

booked itineraries. Passenger’s record may be made ready for use by: E

- ticket synchr onization, matching, re

association, etc. This step may not be possible for interline

booked itineraries.

Ticket reissuance Where applicable, refund or process for ancillary, optional, additional, baggage charges and compensation according to government regulation

should be considered This step may not be possible for interline

booked itineraries.Irregular Operations process Note: Unless noted otherwise, the processes below apply to the following irregular operations

conditions: 1) Online Delay 2) Online Cancellation 3) Online Misconnect 4) Interline Delay 5) Interline

Cancellation 6) Interline Misconnect

Note: Need to make provisions for sending government security messages (e.g. Flight cancellation, AQQ, Secure flight, etc.) according to the appropriate government’ s requirements

Save seats

– System may save seat preference (from DCS or PNR) during or after automated rebooking process This step may not be possible for interline

booked itineraries.

Check

- in

– System may automatically check

- in passengers after reboo king process is complete. Consideration may need to be made for scenarios requiring through check

- in This step may not be possible for interline

booked itineraries.

Check

- in

– Passengers may be required to check

in after rebooking process is complete. D uring

check

- in, passengers may be offered additional rebooking opportunities This step may not be possible for interline

booked itineraries.

Baggage should be rerouted or processed ( see Baggage movements 11 ) During rebooking process, affected or duplica ted flight segments should be cancelled. It’s the airline’s individual business policy to determine duplicate flight segment handling (“protection”). E.g. Additional segments booked for delayed flights, alternate routings, etc.

Note: Rebook passenger o n interline itinerary if applicable. There may need to be a special bilateral agreement required to allow automatic rebook of interline itineraries (as provided in AIRIMP). Preference should be given to alliance carrier rebook (as detailed in company pol icies and alliance agreements).

Note: Evaluate availability and apply business rules based on passenger status to make a decision on the rebooking choice (own or other airline). It is recommended to contact the new operating carrier to secure space.Irregular Operations process Note: Unless noted otherwise, the processes below apply to the following irregular operations

conditions: 1) Online Delay 2) Online Cancellation 3) Online Misconnect 4) Interline Delay 5) Interline

Cancellation 6) Interline Misconnect

Note:

N ote: Request availability from other airline through various established methods (e.g. seamless availability; direct sales; direct access; interactive sales) in order to get firm confirmation of the availability. (Need to follow rules as defined by IATA Re solutions 766/735d, A 4 A Resolution 120.20 and AIRIMP or as provided in procedures outlined through bilateral agreements).

7. PASSENGER COMMUNICATION

During Irregular Operations, and especially after rebooking occurs, every effort

should be made to notif y passengers of flight changes.

If a customer is rebooked on an interline itinerary, consideration should be made that not all carriers share the same rules regarding handling or ancillary charges. Where possible, or mandated by regulation, notification should be made available to customer regarding these differences.

Messages should be sent to passengers during, but not limited to, the following

scenarios:

a. Passenger rebooked to an earlier than scheduled departure.

b. Passenger rebooked to a later departur e.

c. Flight cancellations.

Government requirements, regulations, or commercial agreements need to be observed where applicable (e.g. some governments require verbal or electronic updates at specified intervals).Some delay types may require additional o r special notification:

a. Weather/Air Traffic Control (ATC)

i. Advise the passenger of the reason for delay.

ii. May need to advise passenger to check

- in within original cut

- off times due to delay volatility.

b. Mechanical/inbound aircraft delay:

i. Advise passenge rs of the reason for the delay.

ii. Advise passengers that ETD is subject to change frequently and additional rebooking processes may be required.

8. MESSAGING TYPES

a. If available, passengers should be contacted via their preferred method:

i. Email; phone; aut omated phone calls; interactive voice response (IVR); kiosk (SSD)/ SMS, etc.

b. Government privacy regulations should be observed as applicable.

c. Content of message should be as specific as possible and give direction on next steps and options including wher e to proceed for processing and check

in.

9. INTERNAL COMMUNICATIONS

a. Every effort should be made to communicate delays and cancellations with internal departments/stakeholders (e.g. gate agents) prior to passenger

notification.

i. Ensures better preparation and alignment of resources (allows airlines

to develop their “game plan”).

ii. Optimizes automated rebooking process.

iii. Enhances customer service by assuring that airline resources can anticipate the passenger’s issue.10. SELF SERVICE DELIVERY

a. Passengers whose PNRs have been rebooked and are in a check

- in ready
state, should be able to check

- in via:

i. Common use or proprietary original carrier self

- service device, mobile

or web.

ii. OA self

- service device, mobile or web.

iii. Phone (Interactive Voice Response

– IV R).

b. Self

- service devices could be located in various strategic locations to maximize passenger convenience (e.g. transit, airside areas).

11. BAGGAGE MOVEMENTS

In some cases, baggage will be accepted prior to passenger encountering a delay

or cancellation . During these circumstances, every attempt should be made to ensure passenger and baggage stay together (see IATA Recommended Practice 1745/1800, A4A Recommended Practice 30.45/30.49, IATA Resolutions 735d/743a for further information).

12. MISCELLANEOUS

Miscellaneous considerations regarding, but not limited to, meal vouchers; overnight accommodations; CRM (Customer Relationship Manager) updates with passenger inconvenience info; privacy policies, etc., will be determined by individual airline policies or government regulations.

Filing Period: Effective Date:

1 March

- 1 June 2012 13 April 2012RECOMMENDED PRACTICE 1701k

SELF BOARDING (amending)

PSC( 32 33 )1701k

**Secretary note** : the following text completely replaces t he current text of RP 1701k

P6.3.4

RECOMMENDED that, when Members plan to operate Self Service Boarding in a dedicated or common use environment, for the purposes of individual airline processes the specification and standards as described in this Recom mended Practice are applied.

1. INTRODUCTION/SCOPE

Self Boarding describes the specifications and standards for Self

- Service boarding devices. Member airlines will implement a Self Boarding process to include, but not
be limited to, self

- boarding functional ity. Future developments may include other functions, both business and technical.

2. PURPOSE

The Self Boarding concept is to provide passengers with the possibility to board the aircraft without agent assistance.

The major benefits of Self Boarding are:

• Extending customer control throughout the journey,

• Faster processing time at the gate,

• Allows agents to add value by focusing on exceptions and passengers with special needs,

• Leads to optimum use of airline and airport facilities,

• Shared running costs (whe n operated as common use)

3. DEFINITIONS

For the purposes of this Recommended Practice, the following definitions will apply;

3.1. Self Boarding Process

An airline offering the ability for a passenger to self

- scan their boarding token to gain entry to the air craft in a controlled manner. Additional / Related Services: Offering the capability for flights requiring passenger

authentication and/or document checks.3.2. Controlled Manner The method of control by which a passenger boards an aircraft. Those are listed in the following and may be applied as well in combination.

3.3. Automated barrier An automated barrier is an access control device equipped with physical obstacles (doors, flaps, turnstile, etc.) and flow control functions (pictograms, displays, etc.).

3.4. Agen t control An agent supervising the boarding process

3.5. Visual / Audible indicators Visual and audible indicators provide the passenger with information about the validity check of the boarding token at the boarding point.

3.6. Self Scanning The action by which a passenger presents a boarding token to the boarding device for the purpose of self service boarding.

3.7. Passenger Authentication This is performed by comparing the data on the boarding token with accepted forms of identification carried by the passenger and verified by an agent.

3.8. Verified identification The process step whereby the passenger presents their government

- issued ID for

verification.

3.9. Document Check Document check means the inspection step to verify that a passenger’s travel documents a comply wit h government requirements allowing entry to a destination country or passage through a transiting country.’.

3.10. Boarding Application This is the computerized application used by the airline to perform the boarding

process.

3.11. Passenger Boarding Token

The Self Boarding device may read different types of tokens, for example: BCBP (bar

- coded boarding pass on paper or mobile phone), machine readable travel documents (passports, visas, ID cards), passenger biometrical data, frequent flyer
cards, etc.

4. SELF BOARDING PROCESS

4.1. Eligibility

All passengers holding an electronic ticket with boarding token, not requiring additional processing at the gate are eligible to use the Self Boarding process.4.2. Exceptions and Special Treatment

• There are exceptions from the above stated group of eligible passengers such

as:

• Unaccompanied minors

• Passengers with special seat assignments

• Infants

• Disabled passengers requesting assistance

• Passengers requiring a document check that should normally have been performed before the boardin g process.

• Regulatory compliance that require additional checks prior to approved boarding

• Passengers with coupons to be collected

4.3. Process Description

The Self Boarding process is described in detail below. Principally, the process may be designed to be controlled by an agent, or alternatively with the use of automated barriers incorporating passenger detection.

4.3.1. Self Boarding with agent control

• Self

- boarding device is initialized and connected to the boarding application of the respective airline

• Devic e readiness indicated to passenger

• Passenger scans their own boarding token

• Boarding token information is captured and sent to the airline system

• Result of boarding token check is sent to the Self Boarding device

• Device indicates the result to the passenge r (boarding approval/rejection communicated via display, pictograms, etc.)

4.3.2. Self Boarding with automated barrier and passenger detection

• Self Boarding device is initialized and connected to the boarding application of the respective airline

• Device readine ss indicates to passenger

• Passenger scans their own boarding token

• Boarding token information is captured and sent to the airline’s systems

• Result of boarding token check is sent to the Self Boarding device

• Device indicates the result to the passenger (boa rding approval/rejection communicated via display, pictograms, etc.) and allows passenger to pass through the barrier and board the aircraft.

• After confirmation that the passenger has crossed the barrier passenger’s

status is set to “boarded” in the boardi ng application

Note: The use of an automated barrier should not mandate any modification at the DCS level of the airline and the self boarding device should behave in a similar way to a BGR (Boarding Gate Reader). If DCS does not recognize the status answ er given by the Self Boarding device then the automated barrier should handle the detection and alarm control internally.4.3.3. Exceptions from the standard process

• There are several exceptions to the standard process. Those are listed in the following toget her with the appropriate advice to handle each situation.

• Infants, Unaccompanied Minors and disabled passengers requesting assistance may be handled within the pre

- boarding phase. Hence it is recommended that at least one traditional boarding position sta ffed by an agent is maintained at the gate.

• In case passengers are holding coupons to be collected by boarding staff at the gate. To guarantee the collection of all coupons an electronic means, such as electronic miscellaneous documents, should be implemen ted for the collection of excess baggage coupons

• Passengers trying to get oversized hand luggage through the Self Boarding point should be intercepted by boarding staff.

• Regarding the process with use of an automated barrier the following exceptions from the standard process might apply:

o In case of rejection due to an invalid ticket boarding should not be allowed, the agent will be alerted and agent intervention is required.

o In case of a fraud attempt e.g., two passengers trying to board using

one boardi ng token should not be allowed. The agent will be alerted and agent intervention is required.

o Optional: In case of a seat change at short notice or in absence of the passenger, the passenger may be provided with a seat

- assignment print at the Self Boarding point. This applies as well for situations such as waiting list acceptance and upgrades. This may be implemented by integrating a printer in an automated barrier or other device.

o Regulatory compliance requiring additional checks such as exit row seating q ualifications.

4.3.4. Self Boarding without Passenger Authentication

The above described processes apply for flights that do not require a passenger authentication at the gate.

4.3.5. Self Boarding with Passenger Authentication

In case of a flight requiring a name / document reconciliation (Passenger Authentication) one of the following procedures should be performed:

• Verification of the passenger’s biometrics at the boarding point,

• Agent assisted Passenger Authentication at the boarding point (e.g.,. at the jett y entrance),

• Agent assisted Passenger Authentication at a central check point before the boarding point.5. TECHNICAL ASPECTS AND INFRASTRUCTURE

5.1. Product functionality

5.1.1. Functional requirements

The Self Boarding device should contain the following modules:

Boarding token reader including 2D barcode reading capability. Clear Visual Instructions: To support a continuous and fast passenger flow, it is

essential to offer well

- thought

- out passenger guidance. Depending on the situation the passenger should be in formed and supported by graphical displays and/or pictograms leading him into the desired direction or to desired actions (for example, to go contact an agent)..

Note: In general, regarding response times the Self Boarding process should not last longer than the manual process. In addition the devices should be flexible so that a carrier can easily expand the number of Self Boarding lanes.

5.1.2. Optional functional requirements

There are several optional requirements that may be considered when designing a

Se lf Boarding device.

5.1.2.1. Automated barrier with detection algorithm

A barrier is recommended in case the Self Boarding device is operated without dedicated agent supervision. Detection algorithms provide a uniqueness check to

insure:

• A boarding token is only used once

• Only one passenger can pass through the boarding point with a single boarding pass.

5.1.2.2. Receipt printer for boarding slips

As mentioned above a printer should be integrated to provide the passenger with new seat information in case of changes at short notice. When using an automated barrier, the barrier should open as soon as the seat assignment print has been retrieved by the passenger.

5.1.2.3. Passport scanner

Should a passport scanner be required, a full page flatbed scanner is recommended.

5.1.3. Gate e rgonomics

The self boarding device should allow easy access for passengers carrying hand luggage.5.2. Airport and Technical Infrastructure within a Common Use

Environment

Self Boarding devices may be used by several carriers in a common use

environment . To facilitate such use the devices should conform to common use standards. Reusability, scalability, and ease of integration are the primary criteria. Use of open and established standards such as XML, J2EE and Web services as well as SOA (Service Orient ed Architectures) is strongly recommended. In a common use environment, the ability to switch from automated Self Service Boarding to traditional BGR mode and vice versa is necessary.

The Self Boarding initiative targets the use of Self Boarding devices b y different carriers with different DCS/boarding applications. This enables airlines at airports

with non

- exclusive gate areas to offer Self Boarding to their customers.

5.2.1. Closed / Open gate area

Self Boarding devices may be used both at open and closed ga te areas.

6. SIGNAGE

The signage for Self Boarding devices should be promoted at all sites. It is recommended that this signage includes the words “Self Boarding”.

It is recommended that proper signage is visible to instruct customers on the proper placeme nt of their boarding token over the token reader/scanner to ensure efficient customer flow through the self boarding gate.

It is recommended that the following signage/icons are used by member airlines, airports or handling agents to advertise the simpli fied self

- service process availability at the airport. This will create awareness, consistent passenger experience and help penetration of the service globally.

Filing Period: Effective Date:

1 March

- 1 Ju ne 2012 13 April 2012RECOMMENDED PRACTICE 1706

FUNCTIONAL SPECIFICATION FOR STANDARD DEPARTURE CONTROL

SYSTEM (amending)

PSC( MV78 33 )1706

B7.2/P

....

8. DOCUMENTATION

.....

8.2 Messages

.....

RQM Request Information Message (AHM 783)

BIM B aggage Information Messages (Recommended Practice 1745)

Filing Period: Effective Date:

1 March

- 1 June 2012 13 April 2012RECOMMENDED PRACTICE 1706c COMMON USE SELF SERVICE (CUSS) (amending)

PSC( 27 33 )1706 c

P6.3.7

**Secretary note** : the following text completely replaces the current text of RP 1706c

RECOMMENDED that , when Members plan to operate shared Self Service Devices in a Common environment, such as an airport, for the purposes of individual airlin e processes, the specifications and standards as described in this Recommended Practice are applied.

1. INTRODUCTION/SCOPE

Common Use Self Service (CUSS) describes the specifications and standards for multiple airlines sharing one physical self

- service Kiosk. Member airlines will develop

a Common Use Self

- Service Platform to include, but not be limited to, check

- in functionality. Future developments may include other functions, both business and

technical.

2. PURPOSE

The basic idea of the CUSS concept is to enable airlines to provide passenger

services at a shared Kiosk.

The major benefits of CUSS are:

o customer interaction with airline application at a single point of contact

o security of access

o optimum use of airline facilities with no need to dedicat e special areas for

different airlines

o shared running costs

o permits delivery of a proprietary check

- in product, thus the airlines are not required to use systems provided by airport authorities or handling agents which might not be compatible with their ho st computer systems

o airports only have to provide space for the common Kiosk thus reducing the amount of space an airport needs to set aside for airline Kiosks.

3. DEFINITIONS

For the purposes of this Recommended Practice, the following definitions will apply;3.1 Application Provider

An entity that is responsible for the provision and management of their applications accessible from a CUSS Kiosk, e.g. an airline.

3.2 Application Supplier

An entity that writes the application software for the Applic ation Provider.

3.3 Architecture

This is the structure that will be employed to deliver CUSS, and to ensure consistency of operation (refer to the Technical Specifications published separately from this Recommend Practice in the “CUSS Manual”).

3.4 Comm on Software

This software provides an interface between Hardware devices and the Kiosk/airline applications which use them. This will be referred to as middleware. It includes several layers, the top layer of which will be the Standard Interface Layer.

3.4.1 CUSS Passenger Documents

The Kiosks may contain (as appropriate):

Blank ATB Card Type 4 stock with a magnetic stripe and without a binding stub (Refer to IATA 722c and 722e/ A4A 20.51 and 20.201/)

General Purpose Printer (GPP) stock (Refer to /IA TA 1706d A4A RP 30.102)

Blank baggage tag stock (Refer to IATA Resolution 740/ A4A 30.35)

3.5 CUSS Platform

This defined environment supports applications for one or more airlines and

conforms to the standards as described in this Recommended Practice.

3.6 CUSS Application (See also, "Kiosk Application")

A single certified business application that will run on multiple CUSS certified

Platforms3.7 Kiosk Application (See also, "CUSS Application")

The Kiosk Application is the essential part of the K iosk system. It provides the functionality the Kiosk offers to the customers. It depends on the Kiosk Application

whether a Kiosk can be used for check

- in, ticketing, as a ticket vending machine or virtually anything else. There is no limitation about what and how many Kiosk Applications can be offered on a Kiosk system.

3.8 Platform Provider

This is the entity that is responsible for ongoing provision and management of the

Platform.

3.9 Platform Supplier(s) This is the entity who provides any component of the Platform

3.10 Relationship Among Entities Involved in the CUSS System

3.11 Selection Interface Screen

This is the initial screen a customer will interact with prior to selecting an airline application. This will be provide d by the Platform Provider.

3.12 Service Provider(s)

This is the entity that is responsible for maintaining the operational service performance of the Platform. Application Provider

Application Provider

Applica tion Provider

Platform Provider Application Supplier

Platform Supplier

Service Provider Service Level Agreement3.13 Kiosk Enclosure

The physical assembly and ergonomics of the kiosk including devices an d components, screens, millwork and/or encasement, mounting, service doors, and physical security and access controls.

4. CUSS PRODUCT STRATEGY

The CUSS product strategy is to deliver a common self service Platform to support individual airline processes at a shared Kiosk, e.g. check

- in.

The key to the product strategy is an Open Architecture. This means that it should be possible to use any Hardware or software that conforms to CUSS standards included in the Technical Specifications published in the “C USS Manual”.

This open strategy enables airlines to maintain their individual identity in terms of product offering.

The functionality described is not exclusive. Any future products and/or applications may be introduced as business needs change and will be subject to review and approval by the Passenger Experience Management Group (see section 6 titled “Passenger Experience Management Group”).

Initially this strategy is focused for implementation at airports but could be carried

forward to other environ ments, e.g. bus terminals and railway stations.

The development of the CUSS product will initially be done with the cooperation of Member airlines, airport authorities and Software/Hardware manufacturers.

5. KIOSK PLATFORM/CUSS PRODUCT FUNCTIONALITY

The Kiosk Platform comprises, at minimum, the Hardware specified in Section 11.1 titled “Minimum Kiosk Components”.

The CUSS product functionality shall be bilaterally agreed upon between the individual airline(s) and the Platform Provider and must adhere to the Certification process outlined in the “Certification Document”. This is published in the “CUSS Manual” separately from this Recommended Practice.

The Kiosk is envisaged to support a comprehensive range of airline processes and

services.

The support of a specific process and services for any airline is dependent on the software provided by the airline Application Provider.

Initial focus of the product will be on passenger check

- in. Devices within a Kiosk shall only be used by applications initiated and operated within the Kiosk or diagnostic software.

All physical components shall be equally accessible to all participating airlines according to bilateral agreements between airlines and Platform Providers.5.1 Data Security

This Recommend Pract ice and the CUSS Technical Specification recognize and acknowledge that the CUSS standard should facilitate, and not prevent, the PCI Data Security Standard compliance of the Kiosk provider as well as of the Application Providers. Just a few of the ways th at can prevent compliance follow.

1. Storage of magnetic stripe data and/or equivalent data on the chip in the
customer's network after authorization;

2. Applications that require customers to disable other features required by the PCI Data Security Standard, l ike anti

- virus software or firewalls, in order to get the payment application to work properly; and

3. Vendors’ use of unsecured methods to connect to the application to provide support to the customer.

Secure kiosk enclosures and components, when implemente d in a PCI DSS

compliant environment, will minimize the potential for security breaches leading to compromises of full magnetic stripe data, card verification codes and values (CAV2, CID, CVC2, CVV2), PINs and PIN blocks, and the damaging fraud resulting f rom
these breaches.

See the References paragraph for more information on PCI

- DSS.

5.2 Form of Identification (FOID)

An addendum to the CUSS Technical Standard called “Separation of Card Reader Payment and Form of Identification Data” was published June 2011.

This addendum modifies the CUSS specification to restrict how CUSS applications read payment card data from the kiosk. Card issuer operational regulations state:

**A Merchant must not request or use a Primary Account Number (PAN) for any purpose ot**  **her than as payment for goods and services.**

The CUSS specification is amended to provide special access to payment card data. CUSS applications retain full access to the card data in cases where it is needed for payment processing. For all card transactio ns that are not for payment, the content of the payment card is truncated (obscured) so that it retains essential information such as the name, but no longer has a Primary Account Number and is hence not considered a payment card.

The adoption of this add endum is critical for card issuers, as a condition for continuing to accept payments at airline self

- service kiosks. Implementing and deploying the changes specified in this Addendum are required for adherence to this

Recommended Practice.6. PASSENGE R EXPERIENCE MANAGEMENT GROUP

A Passenger Experience Management Group (refer to Resolution 706 [ATA 30.200] comprised of airlines will be responsible for managing the certification process and amending CUSS standards as published separately from this Reco mmended Practice, e.g. Technical Specifications published in the CUSS Manual.

7. CUSS PRODUCT OPERATION

The product may operate in the following way:

Typical Check

- in Flow

• Selection from Interface Checks airline links

screen Checks Hardware

• Passenger s elects airline Airline application started via

touch screen and Kiosk Application

• Airline application launched Check passenger(s) in to flight (via airline host) other airline services

• Airline application prints Travel documentation issued

• Airline application cleans up Calls back Selection Interface

Screen

• Selection Interface Screen Checks tidy up

Checks Hardware OK

For details refer to the Technical Specifications in the “CUSS Manual”.

7.1 Statistical Information

General rules:

• No data to be maintained on the Kiosk.

• No Proprietary Data to be retained by the Platform/Service Provider

• No Application Provider’s Proprietary Data to be accessed or made available to any other party

• The following types of statistical data will need to be provided :

- sufficient data to support and control a billing process for both Platform and Application Providers.

- general data available for all airlines using the Kiosk (deliverance, uptime, etc.)

- all data required by a Service Provider to complete their fun ction8. OWNERSHIP

The interface descriptions (as described in Technical Specifications) are owned by

IATA and A4A and are maintained by the Passenger Experience Management Group (see Section titled “Passenger Experience Management Group”).

9. SERVICE LEVEL AGREEMENTS (SLAs) AND RESPONSIBILITIES

This section addresses various aspects of the Service Level Agreement (SLA) document where the Service Levels to be provided by the Platform Provider of CUSS and the Service Levels provided by the Application Provider are mutually agreed. The SLA will also include change management procedures. As a guideline, a sample SLA template is shown in the “CUSS Manual”.

9.1 Platform Provider’s Responsibility

The Platform Provider will, as defined in the SLA, ensure t hat:

• the CUSS Kiosk is operational and serviceable during the specified operational

hours

• the CUSS Platform is functioning and certified according to CUSS standards

• software levels and version control of the Platform are maintained at that site

• statistica l and management information is available

• they notify the Application Provider of faults that cannot be resolved

• they have the ability to turn off an application if it is deemed to be causing other applications and/or the CUSS Kiosks to malfunction. If thi s is the case they will endeavor to inform the Application Provider in advance

• Kiosk locations are locally and mutually agreed

The Platform Provider will also demonstrate that its Kiosk Enclosure and Kiosk Platform comply with any applicable regulations or standards that apply to the site where the kiosk is deployed, including relevant Access, Data Privacy, and Data Security standards.

In addition, the Provider must deploy a platform that complies with and implements

the CUSS FOID Addendum as described a nd by the date set in paragraph 5.2.

9.2 Application Provider’s Responsibility

The Application Provider is responsible for the application code, which must follow and pass the Certification process.

If the Application Provider decides to use a dedicate d Application Server, either at the CUSS site or a location that is under the control of the Application Provider, then that Application Provider is responsible for the maintenance and the upkeep of the

Server.The Application Provider is responsible for any communication lines to and from the Application Provider’s mainframe or Server location.

The Application Provider must provide the correct protocol and interfaces to allow connection at the CUSS site as mutually and bilaterally agreed between the Platform Provider and the Application Provider.

The Application Provider shall ensure that when a Payment Card is read for any purpose other than payment, such as Form of Identification (FOID), the application shall include only the first 6 and the last 4 digits of the credit card number. All remaining digits shall be replaced with an X. E.g. 123456XXXXXX7890."

This behavior follows the FOID Addendum to the CUSS Specification described in Paragraph 5.2 and allows compliance with Card Scheme Operating R egulations and

IATA Resolutions 722

- f

- g

- h & 725

- f

- g

- h.

The Application Provider will also demonstrate that its Kiosk Application complies with any applicable regulations or standards that apply to the site where the kiosk is deployed, including relevant A ccess, Data Privacy, and Data Security standards.

9.3 Service Levels

Minimum Service Levels that the Platform Provider should provide will be locally and mutually agreed. All airlines involved at each site must be able to ensure that agreed

standards do not compromise levels of customer service they have already built up or to which they aspire.

9.4 Management Information and Availability Figures

The Platform Provider should be able to supply all Application Providers the Availability figures and acce ss to the management tool used for real time status of

the CUSS installation.

9.4 Additional Responsibilities

The Platform Provider and Application may have additional local or site responsibilities not listed here.

10. SIGNAGE

The signage for Kiosks to be promoted at all sites will include the words “Self

Service”.11. KIOSK SPECIFICATIONS

11.1 Kiosk Components.

The following is the minimum specification for a CUSS Kiosk:

A computer

A card reader

Touch screen

Facilities to support a keyboard and pointing device

Printer, which may be one or more of the following if the airlines at the location require them:

ATB reader/ATB printer with an Escrow and the latest AEA PECTAB and PECTAB extensions (refer to the Technical Specifications in the

“CUSS M anual” published separately from this Recommend Practice).

General Purpose Printer with bar code printing capability.

Bag tag printer with specified fonts (refer to the Technical Specifications published separately from this Recommend Practice in the “CUSS Manual”).

Note: Further details including optional components to be found in the Technical Specifications published in the “CUSS Manual”.

11.2 Data Privacy

Recommended Practice 1774 (Protection of Privacy and Transborder Data Flows of

Personal Data us ed in International Air Transport of Passengers and Cargo) is incorporated by reference herein.

Additional local or site Data Privacy regulations may also apply.

11.3 Kiosk Ergonomics

Screen design

The Selection Interface Screen will be designed with an overall common navigation, look and feel. This interactive design utilizes suitable fonts and is graphically intuitive (refer to the Technical Specifications published in the “CUSS Manual”).

Hardware Design and Kiosk Enclosure Considerations

The Kios k must be designed in compliance with local laws. The devices should be easily visible and as close to the screen as possible. The design and placement of the Kiosk Enclosure and its integrated devices and components should comply with any applicable Data Privacy, Data Security, Accessibility, and other standards and regulations (see Paragraph 5.)

11.4 Data Security

Additional local or site Data Security regulations may also apply.12. CERTIFICATION

The Platforms and applications must be certified in accordance with the procedures in the Certification Document published in the “CUSS Manual”.

13. CUSS MANUAL

IATA shall produce, update, and make available the CUSS Manual in electronic format which shall set forth, among other things, CUSS standard s and Technical Specifications. As a condition to certification, Application and Platform Providers, shall be required to maintain a current subscription to the CUSS Manual. To enable it to defray the costs incurred in developing and maintaining the CUSS Manual, IATA shall establish an annual subscription fee for the CUSS Manual. Access to the CUSS Manual, and the fee to be charged, will be non

- discriminatory, i.e., all interested parties, whether or not members of IATA, will be afforded access to the CUS S Manual on the same terms, and will pay an equal fee for such access.

14. GLOSSARY OF TERMS

AEA PECTAB

– Parametric table as specified by the latest edition of the Association of European Airline (AEA) joint technical specifications. A parametric table defines the print and magnetic strip locations for the IATA ATB documents (or other documents in ATB format).

APPLICATION PROVIDER

- See paragraph 3 “Definitions”

APPLICATION SUPPLIER

- See paragraph 3 “Definitions”

ARCHITECTURE

- See paragraph 3 “D efinitions”

AVAILABILITY

– The percentage of time, during kiosk hours of operation, where a kiosk is able to fulfill its functionality, and is available for operational use. There are some outages which affect availability of the CUSS kiosk that the Servi ce Provider will not have control over. These outages will not be classed as an operational outage which will be penalized against the Service Provider

COMMON ENVIRONMENT e.g. an airport as defined in IATA RP 1797.

CUSS APPLICATION

- See paragraph 3 “Definitions”

PASSENGER EXPERIENCE MANAGEMENT GROUP

- A Passenger Experience Management Group (PEMG) comprised of airlines will be responsible for managing the certification process and amending CUSS standards.GPP

– General Purpose Printer

KIOSK, K IOSK ENCLOSURE

– The common term used to describe the repository of the hardware. See paragraph 3 “Definitions”

OPEN ARCHITECTURE

- Means that it is possible to use any Hardware or software

that conforms to CUSS standards.

PLATFORM

- Comprises common Har dware, software and networking infrastructure required to run the CUSS Applications.

PLATFORM PROVIDER

- See paragraph 3 “Definitions”

PLATFORM SUPPLIER (S )

- See paragraph 3 “Definitions”

PROPRIETARY DATA

– Data that originates from an Application Pr ovider.

SERVICE PROVIDER (S)

- See paragraph 3 “Definitions”

SELECTION INTERFACE SCREEN

- See paragraph 3 “Definitions”

SERVICE LEVEL AGREEMENT (SLA)

– A document where the service levels to

be provided by the Platform Provider of CUSS and the servic e levels provided by the Application Provider are mutually agreed. See paragraph 9 "SLAs"

SOFTWARE

- Code used to deliver specific functionality.

PCI

- DSS

– Payment Card Industry Data Security Standard- REFERENCES

IATA Passenger Services Conference a nd A 4 A Passenger Council Resolutions

IATA A 4 A

------ 20.12 Automated Ticket/Boarding Pass

– Version 1 (ATB1)

------ 20.13 Automated Ticket/Boarding Pass Version 1 (ATB1) Agents and Corp Travel

722c 20.51 Automated Ticket/Boarding Pass

– Version 2 ( ATB2)

722d 20.52 Off Premise Automated Ticket/Boarding Pass

– Version 2 (OPATB2)

---- A 4 A Agents and Corp. Travel

722f 20.60 Electronic Ticket/Electronic Miscellaneous Documents

– Airline 722g 20.61 Electronic Ticket/Electronic Miscellaneous Documents

– Neutral

724 20.03 Passenger Ticket

– Notice and Conditions of Contract

728 110.16 Code Designators for Passenger Ticket and Baggage

Check

740 30.35 Form of Interline Baggage Tag

791 20.204 Specifications for Airline Industry Integrated Circuit Card ( ICC)

Recommended Practices

IATA A 4 A

1008 100.15 Glossary of Commonly Used Air Passenger Terms

1706

------ Functional Specification for Standard Departure Control System

1706a

1706c 30.200

30.100 Functional Specification for Passenger Self Service Systems

Common Use Self

- Service (CUSS)

1706d

1706e

1720 30.101

30.102

----- Non

- ATB Document Specifications for Common Use Self

Service Kiosks

Paper Specifications

– Documents to be Printed by a General Purpose Printer (GPP) In A Common Use Self

S ervice (CUSS) Kiosk

Seat Assignment Parameters

1724 20.03 General Conditions of Carriage (Passenger and Baggage)

1774

----- Protection of Privacy and Transborder Data Flows of Personal Data Used in International Air Transport of Passengers and Cargo

17 78

----- Corporate Client Identification Service

1784 A 4 A

Electronic Marketplace

Committee

RP Electronic Reservation Services Providers (ERSPs)

1797

------ Common Use Terminal Equipment (CUTE) systemsIATA Passenger Agency Conference /Airlines Repor ting Corporation (ARC)

Resolutions/Governing Body

IATA

800z

----- Electronic Ticketing

898a Electronic Reservation Services Providers

Other

Electronic Reservation Services Providers Implementation guide Electronic Ticketing Implementation G uide Integrated Circuit Card Implementation Guide

PCI

- DSS at http://www.pcisecuritystandards.org

Filing Period: Effective Date:

1 March

- 1 June 2012 13 April 2012RECOMMENDED PRACTICE 1707a

DATA FIELD DICTIONARY FOR DCS PASSENGER MESSAGES (amending) PSC( 30 33 )1707a

B7.1/P

RECOMMENDED that:

....

Data Field Name Example Format/Reference

... arrival time 1100 see time (can be followed by date variation)

. . . date of birth 26MAY46 see date/full date variation (negative) /M1 /Mn date variation (positive) /1 /n departure time 1400 see time

...

Filing Period: Effective Date:

1 March

- 1 June 2012 13 April 2012RECOMMENDED PR ACTICE 1707b

DATA ELEMENT DICTIONARY FOR DCS PASSENGER MESSAGES

PSC( 32 33 )1707b

B7.8/P

1.3 STANDARD ELEMENTS USED IN DCS PASSENGER MESSAGES

Element

ID Ref in

1707b Element Title 1708

PNL 1708

ADL 1719

PFS 1719b

PRL ...

... .T/ 3.30 (not in use)

re served for E.T.

.U/ 3.31 (not in use ) Unique

passenger per segment identifier O O O O

.V/ 3.32 (not in use)

...

...

B7.1/P

3.13 .I INBOUND CONNECTION ELEMENT

.....

3.13.2 flight information:

.....

if date variation is used; otherwise optional)

- 1 /M1 date variation date variation (conditional: mandatory

if arrival date of Inbound connection is different from the departure date of the

inbound connection. Not allowed when the date is the same. May be a value of minus 1, plus 1 or plus 2

- 1, +1, or +2.)

- 1 /M1 date variation

reservations status HK status

Example:

.I/SR559F07MUC

.I/BA226Y09LHR1100

.I/NZ040X27AKL0651

- 1HK /M1HK3.21 .O/ ONWARD CONNECTION(S) ELEMENT

....

Construction Example Data Field Name

3.21.2 flight i nformation:

flight LH001 flight

..... departure time (optional) 1400 time

arrival time (conditional: 0630 time mandatory if date variation exists; otherwise optional )

date variation (conditional : mandatory if arrival date is different from departure date

of the onward connection. Not allowed when the date is the same. May have a value of minus 1, plus 1 or plus 2.) /M1 date variation

reservations status (optional) KL status

Exa mples:

.O/BA012C26LHR1500HK

.O2/NW001C27JFK1400HK

.O3/AA123Y27ATL

.O/CO0964Y15NRTGUM20500125/1HK

.O2/CO0002Y16GUMHNL06301755/M1HK

.O/NZ0038Y29LHRAKL21050900/2HK

....

3.31 .U/ (NOT IN USE) PASSENGER SYSTEM IDENTIFIER PER SEGMENT (bilateral agreement)

This element conveys a unique passenger system identifier for each flight segment. The identifier is assigned by the sending system for purposes of data collection and statistical analysis.

It is composed of the following information:

 Unique passenger syste m identifier

– a unique identifier is assigned to a passenger for each flight segment.

 Infant indicator

– to indicate an infant (not occupying a seat); passenger ID on this element is for the adult accompanying this infant.

Once established, this unique reference will be the key to identify the passengerConstruction Example Data Field Name

3.31.1 element ID .U/ element ID

3.31.2 unique reference A98745632145678Z m[..25]

3.31.3 oblique / information separator

3.31.4 infant indic ator I I

3.31.5 passenger identification

- 1HOLTON/TOMMR passenger ID Examples:

.U/A456789A56478

.U/B12345698Z765889Q/I

- 1MONCEL/MARC

B7.4/P

....

3.40.1 API DOCS Element

This element lists Passenger primary travel documents. Where the compone nts of a DOCS element are not provided, an oblique (/) is inserted to indicate an element is missing. This is not required when no further components are provided. The Passenger Identification Element may follow the final element entered.

The elements Tra vel Document Surname, Travel Document First Given Name and

Travel Document Second Given Name must match the surname, first given name and second given name (if applicable) as shown in the official travel document. If

the name is from the Machine Readable Zone (MRZ) of an official document, e.g. passport, the chevron character (<) in the MRZ should be interpreted as a space character. A double chevron (<<) should be interpreted as a change of field, e.g. from surname to given name. Spaces in the name fiel ds of the SSR DOCS should not be removed and should be transmitted in messages to business partners and
governments.

B7.7/P

....

Section 4

— Implementation Guidelines

This section is a compilation of guidelines to assist in the understanding of the

pur pose and use of DCS messages. The remarks in this section are contributed by individual IATA Members and by the DCSMWG (the IATA DCS Message Working Group). The items appear in no specific order, and the position of an item in this

section does not reflect its importance or priority. Keywords can be referenced in RP

1707a and RP 1707b.4.1 A passenger name on any DCS message shall appear in the same format as it first appeared on the PNL/ADL. Names cannot be broken over one line of 64

characters. Therefo re, if a complete Name Element cannot fit on one line of a DCS message, it can be truncated according to individual message RP rules. Names

cannot be re

- formatted (such as using only a first initial instead of a full first name).

4.2 A Name Element and a ll of its related elements are not to be broken over Parts in any DCS message.

4.3 A Party/Group Identification (See RP 1707, 2.9.2) is assigned uniquely for one DCS message, for one use. The Identification for a “set” of names can be different

on each s ubsequent list (such as first D2, then M2, then A2). The Identification's purpose is to keep names associated for their appearance on just one message. Furthermore, if a “set of names” appears more than once on one message, each appearance of the “set of n ames” is to have a unique Party/Group Identification. Example: when a “set of names” appears on one ADL in the section for Deletes and then again for Adds, such as:

ADL

.... DEL

1JONES/ARTHUR

- D3 .L/382U22

1MILLER/JON

- D3

1MILLER/JON

- D3

1SMITH/ANN

- D3

..... ADD

1MILLER/JON

- E2 .L/382U22

1SMITH/ANN

- E2

....

This example shows clearly that a PNR of three (D3) are associated for the Delete, and that a PNR of two (E2) remains for the Add.

4.4 When adding a Group PNR to a PNL or ADL, the size of the group and the total number of named individual group members must be equal. The number used in the party/group identifier must be equal on the Group Name Element and each of the Name Element(s) for the individual group members. For example, on the PNL/ADL, a Group PNR o f 50 must have a total of 50 individual names (and NONAMES), and the party/group identifier must be 50 for the Group Name Element and each of the

individual Name Elements.

4.1 The discount codes of ID, DG. RG designate a passenger who is travelling on a

f ree or deeply discounted ticket. The codes are amended with a number 1 or 2, such ID1 or RG2, with “1” meaning that the passenger is entitled to a firm booking and “2” meaning that the passenger is travelling on a space

- available (SA) basis. Eight

industr y discount codes are identified in the IATA Passenger Services Conference (PSC) Manual in RP 1788 and are defined in the IATA Passenger Agency Resolution Manual. Only three have been adopted for use on the PNL/ADL:

ID

— Industry Discount passenger, such a s an airline employee;

DG

— Discounted Government passenger, such as an official or military;

RG

— Free or reduced fare transportation for IATA Passenger Sales Agents.4.2 The acronym “PAD” means “Passenger Available for Disembarkation”. This

refers to a passenger who is a candidate to be off

- loaded if another passenger of a higher category or priority appears for boarding. Examples of PAD passengers is an ID2, DG2, or RG2

— reduced fare passengers who are travelling on a space

available basis

— such as a company employee on leisure travel. On a near

- full flight, PAD passengers might not be accepted to board the aircraft until all revenue passengers are boarded, and when boarded, also can be asked to de

- board if a late revenue passenger appears for board ing.

4.3 The construction rules for DCS messages say to include compartments or fare classes (RBD) in “descending order”. This means in “descending commercial value”,

best

- to

- worst, such as first class, then business class, then economy class. The
concept of “descending order” does NOT relate to alphabetical order or the physical seating position on the aircraft.

4.4 The elements included behind a passenger's name on any DCS message have

no pre

- set order for inclusion, unless specified in the RP for a sp ecific DCS message. However, logic dictates a natural order in some cases, such as a .O/ followed by a .O2/, then a .O3/, etc., and a .R/ followed by a .RN/.

4.5 The DCS R ecommended Practices use “local date”, meaning the calendar date at the station in q uestion for a particular action, or when a flight is scheduled to land or depart at that station. The local date for a flight at any given station is independent of the date that the flight departed from any upline station or will land at any downline

stat ion, or the date at the computer site of the DCS.

4.6 A code share flight operation is a commercial agreement between partners that designates one carrier as the airline that actually provides the aircraft for the flight and is known as the “operating car rier” (OC) and sells seats under their own carrier code, and one or more other carriers who have an agreement to sell seats on the operating carrier under their own carrier code(s) and are known as the “marketing carrier(s)” (MC). In DCS, each passenger is checked

- in for their marketing carrier flight number, but are added to the passenger load of the operating carrier. When each marketing carrier requires a DCS message with just the passengers booked on their marketing flight, this is called a “targeted me ssage”. When the operating carrier requires all passengers booked on the operating flight, this is called a “complete message”.

4.7 A name element and all of its related elements are not to be broken over Parts in any DCS message.

4.8 The PNL includes pa ssengers who have a status/advice code for the PNL flight of only confirmed, waitlisted, or space available, according to the codes listed in the IATA AIRIMP, Sections 7 and 8. A passenger on the PNL is assumed by DCS to be confirmed, unless a .WL/, .ID2/, .RG2/, or .DG2/ Element appears with the passenger entry. This rule for status/advice codes applies also to the .I/, .O/, and .M/ Elements. Cancelled passengers can appear in the Delete (DEL) category, if they had been included in a previous PNL/ADL as a confirmed, waitlisted or space available passenger.4.9 DCS messages are constructed on the basis of either compartment or fare class/RBD (see RP 1707a), according to bilateral agreement when a Recommended

Practice’s construction rules allow a choice.

4.10 The IATA Airline Coding Directory lists the Standard Communications Service codes (CSC) and the Standard Message Identifier codes (SMI) which can be used with type

- B messages, including DCS passenger messages. When both codes are required on one messa ge, the CSC must appear first, on its own line, followed by the

SMI on the next line.

Example: Original Message Follow

- on Correction Message

.... .... ETL COR

.... ETL

....

4.11 A passenger name on any DCS message shall appear in the sam e format as it first appeared on the PNL/ADL. Names cannot be broken over one line of 64 characters. Therefore, if a complete Name Element cannot fit on one line of a DCS message, it can be truncated according to individual message RP rules. Names

cannot be re

- formatted (such as using only a first initial instead of a full first name).

4.12 A Party/Group Identification (See RP 1707, 2.9.2) is assigned uniquely for one DCS message, for one use. The Identification for a “set” of names can be different

on e ach subsequent list (such as first D2, then M2, then A2). The Identification's purpose is to keep names associated for their appearance on just one message. Furthermore, if a “set of names” appears more than once on one message, each appearance of the “set of names” is to have a unique Party/Group Identification. Example: when a “set of names” appears on one ADL in the section for Deletes and then again for Adds, such as:

ADL

.... DEL

1JONES/ARTHUR

- D3 .L/382U22

1MILLER/JON

- D3

1SMITH/ANN

- D3

..... ADD

1MILLE R/JON

- E2 .L/382U22

1SMITH/ANN

- E2

....

This example shows clearly that a PNR of three (D3) are associated for the Delete, and that a PNR of two (E2) remains for the Add.

4.13 A Name Element and all of its related elements are not to be broken over Parts

i n any DCS message.4.14 When adding a Group PNR to a PNL or ADL, the size of the group and the total number of named individual group members must be equal. The number used in the party/group identifier must be equal on the Group Name Element and each o f the Name Element(s) for the individual group members. For example, on the PNL/ADL, a Group PNR of 50 must have a total of 50 individual names (and NONAMES), and the party/group identifier must be 50 for the Group Name Element and each of the

individual N ame Elements.

B7.3/P

...

4.15 Whenever possible follow the booking rules for multiple services defined in AIRIMP to clearly identify the receiving passenger. During the construction of a PNL/ADL reservations systems may encounter PNRs where the intended recipient of multiple services is not clearly identified. This will happen when a PNR has an SSR element with a service count that is not equal to the number of names in the PNL/ADL surname element and there is no passenger

identification on the SSR eleme nt. Example: a PNR with 1SMITH and an SSR

HK2 or a PNR with 2SMITH 1JONES and an SSR HK4

Construct the PNL/ADL entries for such cases with these rules:

(a) in the case where a PNR has an SSR with no passenger identification and the PNR has only one pa ssenger surname element, create a .R/ element with

the count as it is found in the SSR element. Example1: a PNR with 1SMITH/A and an SSR SFML HK2 goes on the PNL/ADL

as: 1SMITH/A .R/SFML HK2

Example2: a PNR with 2JONES/A/B and an SSR SFML HK3 goes on the

PNL/ADL as: 2JONES/A/B .R/SFML HK3

(b) in the case where a PNR has an SSR with no passenger identification and the PNR has multiple surname elements and the count of services in the SSR is equal to the total number of names, create the .R/ elements with individual counts equal to the individual surname counts. Example: a PNR with 2SMITH/A/B 1WILKES/C and an SSR SFML HK3 goes on

the PNL/ADL as: 2SMITH/A/B .R/SFML HK2 and 1WILKES/C .R/SFML HK1

(c) in the case where a PNR has an SSR element with no passe nger identification and the PNR has multiple surname elements and the count of

services in the SSR is greater than the total count of surnames, create the .R/ elements with counts equal to each surname’s count, with all remaining counts going to the first surname.

Example: a PNR with 2SMITH/A/B 1WILKES/C and an SSR SFML HK4 goes on

the PNL/ADL as 2SMITH/A/B .R/SFML HK3 and 1WILKES/C .R/SFML HK1

Filing Period: Effective Date:

1 March

- 1 June 2012 13 April 2012RECOMMENDED PRACT ICE 1708

PASSENGER NAME LIST (PNL) AND ADDITIONS AND DELETIONS LIST (ADL)

(amending)

PSC( 32 33 )1708

B7.1/P

....

2.10.7 Example ......

....

2BROWN/JOHNMR/PRISCILLAMRS

- A3 .I/SR559F07MUC

2SMITH/SAMUALMR/BARBARAMRS .I/BA021C07LHR01200+1HK /1HK

1SORENSON/RONMR . I/BA123Y07LHRCDG1100HK

...

2.11.7 Examples:

2 BROWN/JOHNMR/PRISCILLAMRS

- A3 .I/SR559F26MUC .O/BA439F27LHR

1SMITH/CAROLINA .O/BA012C26LHRLAX1510 1820 HK

1STEENMEYER/HAROLD .O/LH001Y26HAM

. . . 1STRAND/JANEMISS

- A3

1ZIMMERMAN/ANDREWMRS .O/BA012C26CDGLHR1500HK

.O/ AF0276Y26CDGNRT13300910/1HK

. . . 2.11.8.2 Examples of multiple Onward Connection Elements:

1MANNING/MARKMR .O/BA021C07LHR1200HK .O2/PA001J07JFK1400HK

1WAGGONER/PAULMR .O/CO2345Y06SEA .O2/EF3456Y06NRT

.O3/GH9990Y07MNL

.O4/IJ5678Y08XMA

1ZAHL/MOLLY .O/A F1234Y28CDGAMS14001530HK

.O2/KL621Y28AMSATL16301950HK

.O3/DL213Y28ATLMSP23000115/1HKB7.6/P

....

2.12.6.2 Remarks Element for Frequent Traveler Information

2.12.6.2(a) The Remarks Element for frequent traveler information uses the AIRIMP

standard code s for frequent traveler, such as FQTV, FQTR, FQTU, and FQTS. However FQTU should be used only for upgrade to frequent flyers whereas other upgrades should use UPGR.

B7.9/P

**.....**

2.12.6.10 Remarks Element for Checked

- in Information (bilateral agreement)

2 .12.6.10(a) This element is conditional, being used for already checked

- in

passengers.

2.12.6.10(b) The Remarks Element for Checked

- in Information uses the code CHKD.

2.12.6.10(c) Construction rules

Field Example Data Field Name (see RP 1707a/b)

element ID .R/ element ID

checked

- in code CHKD code

space → information separator

status code and number HK1 status code

space → information separator sequence number 1234 n[..4]

space → information sep arator infant indicator (not occupying seat) I I passenger ID

- 1TAYLOR/SIMONMR passenger ID

Note 1: If the infant indicator is not used, the space before the infant indicator is omitted. Note 2: The appropriate seat .R/ element must be included if a seat has been allocated.

Example 1:

.R/SEAT HK1 21A

- 1TAYLOR/SIMONMR

.R/CHKD HK1 5678

- 1TAYLOR/SIMONMR

Example 2:

.R/CHKD HK1 5678

- 1TAYLOR/SIMONMR

Example 3: Passenger travelling with infant not occupying a seat.

.R/SEAT HK1 21A

- 1TAYLOR/SIMONMR

.R/C HKD HK1 9101 I

- 1TAYLOR/SIMONMR

.R/INFT HK1 29MAR11 TAYLOR/KATIE

- 1TAYLOR/SIMONMRB7.6/P

.....

2.12.7 Table of SSR Codes

The following SSR codes from the IATA AIRIMP are used in DCS messages in .R/ Remarks Elements. They are shown in this table in alphabet ical order by code.

SSR Code See Description

Note

Number

AOXY Airline Supplied Oxygen

..... UMNR Unaccompanied minor

UPGR Upgrade

B7.7/P

..... WCLB 2 Wheelchair

– Lithium ion battery to be transported by a passenger which will require a dvance notification/preparation. Weight and dimensions may be specified. Wheelchair and battery must be claimed and rechecked at each interline transfer point (by bilateral agreement)

B7.8/P

**.....**

2.25 .U/ PASSENGER SYSTEM IDENTIFIER PER SEGMENT (bilateral agreement)

2.25.1 This element is optional and is included only when bilaterally agreed.

2.25.2 Only one passenger system identifier per passenger (including infants) may be included in a DCS message.

2.25.3 For construction rules, see RP 1707b, Unique p assenger system identifier per segment element Examples:

.U/A4567Q8956478

.U/B6549ZD874156564789LC

- 1MONCEL/MARC

.U/C66398VCD6574584156/I

- 1VINCENT/GERARD

2.25 2.26 END ELEMENT

2.25.1 2.26.1 This element is mandatory

2.25.2 2.26.2 For construction rule s, see RP 1707b, End Element.

2.25.3 2.26.3 The Passenger Name List (PNL) ends with ENDPNL.

2.25.4 2.26.4 The Additions/Deletions List (ADL) ends with ENDADL.B9

.....

Section 3

– Examples

.....

3.1.2 PNL Message Example (Part 2)

.....

2THOM/JANED R/DEREKMR.L/DF9323

1VANDALEN/LIAMMR

- E2 .R/SVC HK1 AGPQRL/B/9R7/SURFACE BUS/0742468246833C1

3VANDENHEUVEL/LIEFMR/PRITHVIMRS/WILLIEMMISS

- F28

.....

3.1.3 PNL MESSAGE SORTED BY FARE CLASS EXAMPLE (Part 1 and Part 2)

1ANDERSON/RICHARDMR .L/K6F3DU .I/NW0038M20 BOS0705 /1 HK

.R/SPML HK1 SERVE EVRY TWO HOURS LOW CALORIE LOW SODIUM HIGH

.RN/ FIBRE

- 1ANDERSON/RICHARDMR

.R/TKNE HK1 0121174084542/2

- 1ANDERSON/RICHARD

.R/FQTV NW 577418472

- 1ANDERSON/RICHARD

1ARDON/ARJANMR .L/7MPUVU .O/ LH3502Q21ORD1325HK

.O2 /LH4666Q21 AMS NRT 1 740 /1 HK

.R/TKNE HK1 0748331382698/1

- 1ARDON/ARJANMR

ENDPART1

= NNNNAMSKMKL

.HDQRMKL 211421

PNL

KL1779/21DEC AMS PART2

- HAM010T

1BIENEMAN/ANJAMRS

- D2 .L/4VZPUU .I/KL0652M20IAD0655 /1 HK

.R/INFT HK1 09MAR07 BIENEMAN/LUKAS A

.R/TKNE HK1 0122106022870/2

- 1BIENE MAN/ANJAMRS

.R/CKIN PN1 REISSUE ET

- INFANT TO PAPER TKT FOR WHOLE JOURNEY

.R/FQTV NW 100300416602

1BIENEMAN/CHRISTOPHERGMR

- D2

.R/TKNE HK1 0122106026463/2

- 1BIENEMAN/CHRISTOPHERGMR

.R/CKIN PN1 REISSUE ET

- INFANT TO PAPER TKT FOR WHOLE JOURNEY

.R/FQTV NW 225477 512
1GERMANOVICH/KSENIAMISS .L/JVKQED .I/KL1000M21LHR0905HK

.R/TKNE HK1 0742462066629/2

- 1GERMANOVICH/KSENIAMISS

1MAJOR/BENJAMINMR .L/5TN62U .I/KL0662M20IAH0800 /1 HK

.R/TKNE HK1 0121086429725/2

- 1MAJOR/BENJAMINMR

1KRUSE/BJORNMR .L/A3ZNWU .I/NW0038H20BOS0705 /1 HK

.R/TKNE HK1 0121175220869/2

- 1KRUSE/BJORNMR

1KRUSE/MICHAELJOHANNMR .L/Z8CNTU .I/NW0038H20BOS0705 /1 HK

.R/TKNE HK1 0121175222481/2

- 1KRUSE/MICHAELJOHANNMR

.R/PCTC/JENS KRUSE/XX7812379523

.R/SEAT PN1 N /RS REQUEST NOTED FOR CHECK

- IN

1MCDONOUGH/JOHNMR .L/47PV FD .I/KL1072M21MAN0830HK

.R/TKNE HK1 0748374236287/2

- 1MCDONOUGH/JOHNMR

1VANLEEUWEN/LISETTEMRS .L/QV3DXD .O/KL1778M22AMS0855HK

.R/TKNE HK1 0748399183138/1

- 1VANLEEUWEN/LISETTEMRS

.R/FQTV KL 1543463185/2

- HAM003V

- PAD002

1CHUECA/ENRIQUE .L/JJQNNU .I/KL1664M21B CN0900HK

.R/TKNE HK1 0748379890174/2

- 1CHUECA/ENRIQUE

.R/NSST PN1 A REQUEST NOTED FOR CHECK

- IN

1CULL/PHILIPMR .L/IRF7HU .I/KL1420M21BHX0825HK

.O/KL1776M22AMS0650HK .O2/KL1423M22BHX0950HK

.R/TKNE HK1 0748374281416/2

- 1CULL/PHILIPMR

1DESWAL/YASHWANTMRS .L/4F27 GU .I/KL0872C21DEL0600SA

.ID2/IDZM5R2/2095 C/M

1EICHNERVOGT/EBERHARD

- H2 .L/VTZKFU .I/NW0034H20SEA0750 /1 HK

.R/TKNE HK1 0122110765010/2

- 1EICHNERVOGT/EBERHARD

1RAMCHARAN/SANTOSHMR .L/3CT8GD .I/KL0872C21DEL0600SA .ID2/F2

- HAM000W

ENDPNL

= NNNN

Filing Perio d: Effective Date:

1 March

- 1 June 2012 13 April 2012RECOMMENDED PRACTICE 1715 PASSENGER SERVICE MESSAGE (PSM) (amending)

PSC( 32 33 )1715

B7.6/P

....

2.6 SSR/OSI/AUX CODES AND COUNTS ELEMENT

2.6.1 This element is cond itional.

.....

2.6.5 Following are the allowable SSR/OSI/AUX codes for the PSM (as taken from RP 1708, PNL/ADL):

ASVC Additional Services

— Segment

- associated (See AIRIMP for format)

..... UMNR Unaccompanied minors

UPGR UpgradeB7.1/P

....

Sectio n 3

— Examples

3.1 EXAMPLE OF PSM MESSAGES SENT FOR A FLIGHT ORY

- GVA

- ATH 3.1.1 PSM from ORY sent to GVA including SSR/OSI/AUX items and SI text

GVAKRAF

.ORYKMAF 272215

PSM

....

MAAS

- ATH 3PAX/6SSR

BLND 000F 002Y

MAAS 000F 002Y

MEDA 000F 001Y

STCR 000F 0 01Y

F CLASS NIL

Y CLASS 3PAX/6SSR

1BROWNE/TEDMR 14D

MAAS TWO BROKEN LEGS. NURSE NELSON. PLEASE TRY TO CLEAR

AMBULANCE TO MEET AIRCRAFT AIRSIDE

MEDA

STCR

1GREEN/MARILYNMRS 28D

SQ1234W28ATHNRT23251800/1HK

BLND

1GREEN/ROBERTMR 28C

BLND SEEING EYE DOG NAMED CH ARLIE

MAAS

SI

ATTN HANDLING/PAX COMPLAINTS TO BE EXPECTED AT ARRIVAL DUE

DISEMBARKING AIRCRAFT TWICE AFTER BOARDING BECAUSE OF TEC

PROBLEMS/ SEND STAFF TO GATE TO MEET PAX

ENDPSM

= NNNN

Filing Period: Effective Date:

1 March

- 1 June 2 012 13 April 2012RECOMMENDED PRACTICE 1719 PASSENGER FINAL SALES MESSAGE (PFS) (amending)

PSC( 30 33 )1719

B7.8/P

....

1.4 COMPONENTS

... Security Information Continuation Element .SN/MORE INFORMATION Unique pa ssenger system identifier per segment element .U/B654789QS45R12

End element ENDPART11

....

2.19 .U PASSENGER SYSTEM IDENTIFIER PER SEGMENT (bilateral agreement)

2.19.1 This element is optional and is included only when bilaterally agreed.

2.19.2 O nly one passenger system identifier per passenger (including infants) may be included in a DCS message.

2.19.3 For construction rules, see RP 1707b, passenger system identifier per segment element Examples:

.U/A4567Q8956478

.U/B6549ZD874156564789LC

- 1MONCEL /MARC

.U/C66398VCD6574584156/I

- 1VINCENT/GERARD

**Secretary Note:** please renumber accordingly next elements

Filing Period: Effective Date:

1 March

- 1 June 2012 13 April 2012RECOMMENDED PRACTICE 1719b

PASSENGER RECONCILE LI ST (PRL) (amending)

PSC( 30 33 )1719b

B7.8/P

....

1.4 COMPONENTS

...

Security Information Continuation Element .SN/MORE INFORMATION Unique passenger system identifier per segment element .U/B654789QS45R12

End element ENDPART11

**.....**

2.20 .U PA SSENGER SYSTEM IDENTIFIER PER SEGMENT (bilateral agreement)

2.20.1 This element is optional and is included only when bilaterally agreed.

2.20.2 Only one passenger system identifier per passenger (including infants) may be included in a DCS message.

2.20. 3 For construction rules, see RP 1707b, passenger system identifier per segment element Examples:

.U/A4567Q8956478

.U/B6549ZD874156564789LC

- 1MONCEL/MARC

.U/C66398VCD6574584156/I

- 1VINCENT/GERARD

**Secretary Note:** please renumber accordingly next elementsB7.1/P

...

Section 3

— Examples

3.1 EXAMPLE OF A PRL; PART ONE OF A MULTI

- PART PRL

QK ATLLSNW HDQRMNW MKCZKNW

.CDGKMAF NW/231429 GAT

PRL

....

1TOCHER/LMR

.L/2UILIZ

.I/AF5553C23ABZ CDG22350515/1HK

.R/DOCS HK1/P/GBR/093083698/GBR/09APR58/M/05JAN15/TOCHER/ GORDON

.R/DOCA HK1/R/GBR

.R/DOCA HK1/D//HOTEL DOLCE/NORWALK/CONNECTICUT

.R/FQTV AF8574212845/P

.R/SEAT HK1 04A

- DTW265Y

1BOOT/RICHARDJ

.L/NQUF8O

.W/K/1/20

.N/AF214975/1/ SFO NRT

.O/NW347Y 30 24DTW SFO 15551810

.O2/NW015Y24SFONRT19202210/1HK

.R/DOCS

HK1/P/GBR/706 013638/GBR/12APR74/M/13APR16/BOOT/RICHARDJOHN

.R/DOCO HK1//V/011905166

.R/DOCA HK1/R/USA

.R/DOCA HK1/D/USA/471 38TH STREET AVE APT C/SANTA CRUZ/CALIFORNIA

.R/FQTV NW100203546936 .R/TKNE HK1 0122134872230/1

.R/SEAT HK1 18C

Filing Period: E ffective Date:

1 March

- 1 June 2012 13 April 2012P5.1

RECOMMENDED PRACTICE 1720a

STANDARD THIRTEEN

- DIGIT NUMBERING SYSTEM FOR TRAFFIC

DOCUMENTS

(amending)

PSC( 32 33 )1720a

....

Stock Provider Party Type of Form No. of Coupons IATA

Resolution /

Recommended

Practice ATA A4A

Resolution Airline

Code

1 2 3 Form Code

4 5 6 Serial Number

7 8 9 10 11

12 13 Number

of Digits in

Serial

Number Method of Check Digit

Calculation (see below)

... A gency (BSP)

1,2 Multiple Purpose

Document

Off

- Premise

Electronic

Miscellaneous

Document (OPEMD) 2 Coupon

_ 726b 725g 190 7 2

3

Agency (BSP

1,2 Virtual Multiple Purpose

Document

Off

- Premise

Electronic

Miscellaneous

Document (OPEMD) Coupon

by

Coupon (Paperless )

_ 725g 261 7 2

3

Agency (BSP

1,2 Virtual Multiple Purpose

Document

Off

- Premise

Electronic

Miscellaneous

Document (OPEMD) Coupon

by

Coupon (Paperless )

_ 725g 271 7 2

3

Reserved for future industry

allocatio n Agency (BSP) 1, 2 Not assigned

Off

- Premise

Electronic Ticket (OPET) 722g 302 7 Not assigned

3

Reserved for future industry

allocation Agency (BSP) 1, 2 Not assigned

ATB

Miscellaneous Charges Order 725d 304 7 Not assigned

3

A gency (BSP

1,2
Agency (US ASP) 1, 2 Multiple Purpose

Document

Electronic

Miscellaneous

Document 1 Coupon

_ 726e

- 20.64 306 7 1

3

Agency (BSP

1,2
Agency (US ASP) 1, 2 Multiple Purpose

Document

Electronic

Miscellaneous

Document 2 Coupon

_ 72 6b

- 20.64 308 7 1

3P5.2

Stock

Provider Party Type of Form No. of Coupons IATA

Resolution/

Recommended Practice ATA A4A

Resolution Airline

Code

1 2 3 Form

Code

4 5 6 Serial Number

7 8 9 10 11 12 13 Number of Digits in

S erial umber Method of Check Digit Calculation (See below)

Agency (CCS

- TCH) 7 Various Tickets Various

- - - - - 61

- - - - - - - 8 Various

Agency (CCS

- TCH) 7 Off

- Premise Electronic Ticket (OPET) – 722g

- - - - 610

- - - - - - - 7 3

Agency (CCS

- TCH) 2, 7 Passenger Ticket 2 Coupon 721

- - - - 611

- - - - - - - 7 1

Agency (CCS

- TCH) 7 Off

- Premise Electronic Ticket (OPET) – 722g

- - - - 612

- - - - - - - 7 3

Agency (CCS

- TCH) 1, 2, 7 O ff

- Premise Transitional Automated Ticket (OPTAT) 4 Coupon 722a

- - - - 613

- - - - - - - 7 2

Agency (CCS

- TCH) 7 Off

- Premise Electronic Ticket (OPET) – 722g

- - - - 614

- - - - - - - 7 3

Agency (CCS

- TCH) 7 Off

- Premise Electronic Miscellaneous Document (OPEMD) – 725g

- - - - 615

- - - - - - - 7 3

Agency (CCS

- TCH) 7 Off

- Premise Electronic Miscellaneous Document (OPEMD) – 725g

- - - - 616

- - - - - - - 7 3

Agency (CCS

- TCH) 2, 7 Passen ger Ticket 2 Coupon 721

- - - - 617

- - - - - - - 7 1

Agency (CCS

- TCH) 7 Off

- Premise Electronic Miscellaneous Document (OPEMD) – 725g

- - - - 618

- - - - - - - 7 3

Agency (CCS

- TCH) 2, 7 Miscellaneous Charges Order 1 Co upon 725

- - - - 619

- - - - - - - 7 1

**Method of check digit calculation:**

1. METHOD 1 IS FOR PRE

- NUMBERED DOCUMENTS and includes the coupon number and 10

- digit form code and serial number. Does not include the airline code.

2. METHOD 2 IS FO R COMPUTER NUMBERED TAT AND MPD DOCUMENTS and includes only the 10

- digit form code and serial number. Does not include the coupon number or the airline code.

3. METHOD 3 IS FOR COUPON

- BY

- COUPON DOCUMENTS and includes the coupon number, airline code and 10

- dig it form code and serial number.

____________________________________________________________________________________________________ 1 Computer generated ticket serial number. All other Passenger Traffic Documents have a preprinted ticket serial number.

2 Standard neutral ticket. Airline name and code are not preprinted.

7 CCS

- TCH

– The Control Council of Settlement

- Transport Clearing HouseStock Provider Party Type of Form No. of Coupons IATA

Resolution /

Recommended

Practice ATA A4A

Res olution Airline

Code

1 2 3 Form Code

4 5 6 Serial Number

7 8 9 10 11

12 13 Number

of Digits in

Serial

Number Method of Check Digit

Calculation (see below)

Reserved for future industry

allocation Agency (BSP) 1, 2 Not assigned

Off

- Premise

Electronic Ticket (OPET) 722g 550 7 Not assigned

3

Agency (BSP) 2

Airline Miscellaneous

Document (Domestic Only)

Electronic

Miscellaneous

Document Various

_ 725f 20.63 553 7 3

Agency (BSP) 2

Airline Mis cellaneous

Document (Domestic Only)

Electronic

Miscellaneous

Document Various

_ 725f 20.63 555 7 3

Agency (BSP) 2

Airline Miscellaneous

Document (Domestic Only)

Electronic

Miscellaneous

Document Various

_ 725f 20.63 556 7 3

Agenc y (BSP) 2

Airline Miscellaneous

Document (Domestic Only)

Electronic

Miscellaneous

Document Various

_ 725f 20.63 557 7 3

Reserved for future industry

allocation Agency (BSP) Not assigned

Off

- Premise

Electronic Ticket (OPET) 722g 906 7 Not

a ssigned

3

Reserved for future industry

allocation Agency (BSP) Not assigned

Off

- Premise

Electronic Ticket (OPET) 722g 952 7 Not assigned

3

Filing Period: Effective Date:

1 March

- 1 June 2012 13 April 2012RE COMMENDED PRACTICE 1728

RESERVATIONS AND TICKET CODING DIRECTORY (amending)

PSC( 20 33 )1728

T2.34/P

WHEREAS, the relationship between the fare basis code, the reservation booking designator and the class of service code is complex.

IT IS RECOMMENDED t hat:

In order to ensure correct interline pricing , reservation and

, ticket coding, and revenue accounting , Members publish via the industry “Single Source RBD Service” (also known as the ATPCO Chart 1 and Chart 2), the reservations booking designator and the class of service code they want to be used in their services, in conjunction with a given fare and rule applied to a fare component within an itinerary.

The “Single Source RBD Service” will provide s daily up to hourly updates for distribution

to autom ated booking systems subscribing to ATPCO’s product , and is also available as a paper product on a monthly basis. A copy of the booking code charts and an explanation of how to read the information contained therein is published separately. A guide to ins tructing information in ATPCO’s Chart 1 and Chart 2 and the data application for subscribers to process the data is also published separately. More

information on t T he “Single Source RBD Service” can be contacted at teletype

GVARZXB found at http://www.atpco.net/atpco/products/rbd_dc.shtml

.

Filing Period: Effective Date:

1 March

- 1 June 2012 13 April 2012RECOMMENDED PRACTICE 1739

PASSENGER/BAGGAGE RECO NCILIATION PROCEDURES (amending)

PSC( MV78 33 )1739

B8.8/P

RECOMMENDED PRACTICE 1739

Attachment ‘E’

PASSENGER/BAGGAGE RECONCILIATION PROCEDURES

COMMON AUTOMATION METHODS ARE UNDER DEVELOPMENT

Common automation methods for passenger and baggage secur ity reconciliation are

described in RP 1800 and RP 1745.

Split table and Insert spaces

Reconciliation System Assumptions Definitions Baggage Association Assumptions

...

Split table and Insert spaces

Various Methods to Associate Passengers to Bagg age in Reconciliation Systems Various Methods... Various Methods...

...

Filing Period: Effective Date:

1 March

- 1 June 2012 13 April 2012RECOMMENDED PRACTICE 1740c RADIO FREQUENCY IDENTIFICATION (RFID) SPECIFICATIONS FOR I NTERLINE

BAGGAGE (amending)

PSC( 29 33 )1740c

B8.13/P

14. REFERENCES

RP 1800 Automated Baggage Handling based on the IATA Licence Plate Concept (pending PSC approval in November 2005)

Filing Period: Effective Date:

1 M arch

- 1 June 2012 13 April 2012RECOMMENDED PRACTICE 1745

BAGGAGE INFORMATION MESSAGES (amending)

PSC( 32 33 )174 5

B8.12/P

1.2 COMMUNICATIONS

Depending on the protocol used, the communications portion of the message may

contain an Ad dress Element and a Communications Reference element. While many Members use Type

- B messages, especially for in

- house communications, when interfacing to 3rd party systems or where data is required to be received more quickly, it may be necessary to transm it messages using other protocols such as Type

- A, Edifact,
X.25, etc. In these situations the IATA manual, 'Systems and Communications Reference' should be consulted along with direct dialogue between the airline and the operator of the automated baggage s ystem. In these situations a direct dialogue between the airline and the operator of the automated baggage system is

recommended.

.....

1.2.2 Communications Reference Element

This element identifying the sender of the message, is governed by the IATA's S ystems

and Communications Reference manual. If the message is a Type

- B, the date and time is usually included by the communication software. Messages sent using other protocols will be dependent on whether the protocol requires a communications

element.

Ex ample of a Type

- B:

HDQKMUS 231800B8.5/P

2.2

... BMM

...

Table in section 2.2

S Reconciliatio

n Data S/Y/23/A/C/234/333/Y/Y

/A N/

A C C C N/

A N/

A N/

A N/

A N/

A N/

A O N/

A N/

A

...

B8.11/P

2.3.24 .U LOADING DATA; 8 to 53 characters

Cons truction Example Format

2.3.24.1 Element Identifier: full stop(.), 'U' .U .a
2.3.24.2 Separator: oblique (/) / /

2.3.24.3 Stowage Device ID AVE12345NW ammffff(f)mm(a)

.....

2.3.24.2 4 End of Element Delimiter < ≡ Examples:

.U/AVE1234 5 NW/11R/T/Y/NRT/Y/NW009/04MAR/SEL< ≡ .U//AFTRT/X/F/DEN< ≡ .U/T//MIA//AA614< ≡ .U/CAR1357KL//M< ≡B8.4/P

.....

4.6 MULTIPLE USE OF DATA ELEMENTS

Multiple use of elements may be accomplished by following the structure of the BSM and the sequencing of elements. The primary elements are the .F element (Outbound Flight Information) the .N element (Baggage Details), and the .I element (Inbound Flight Information) for a terminating or transfer BSM. The structure of the mandatory and conditional elements depends on whether the BSM is for an originating, transfer or terminating flight. Optional elements, which are related to mandatory elements are inserted in the order shown in 4.5. The .V element may occur once however elements .O, .N, .P, . G , .E and .R may be repeated multiple times, but only .O, .N, .E and .R may be used consecutively. The following schematic illustrates the multiple use of elements in a BSM.

Element Description

.F Outbound Flight (LAX

- NRT)

.I Inbound Flight (ORD

- LAX)

.O Onward Flight (NRT

- SIN)

.O Onward Flight (SIN

- SYD)

.N Baggage Tag Details

.S Reconciliation Data

.W Pieces and Weight Data

.P Passenger Name

.G Ground Transport; Delivery address

.G Remainder of delivery address

.Y Frequent Traveler Number

.C Corporate or Group Name

.L Automated PNR Address

.T Baggage Tag Printer ID

.K Default Message printer

.E Baggage Exception Data

.R Internal Airline Data

.R Internal Air line Data

.X Baggage Security Screening

.N Baggage Tag Details

.S Reconciliation Data

.W Pieces and Weight Data

.P Passenger Name

.G Ground Transport; Delivery address

.G Remainder of delivery address.Y Frequent Traveler Number

.C Corporate or Group Name

.L Automated PNR Address

.T Baggage Tag Printer ID

.K Default Message printer

.E Baggage Exception Data

.R Internal Airline Data

.R Internal Airline Data

.X Baggage Securit y Screening

B8.7/P

Section 7

- BAGGAGE NOT SEEN MESSAGE (BNS)

...

7.5 ELEMENT SEQUENCE SUMMARY

The following shows the sequence of elements in a BNS.

Element Requirement Definition

BNS Mandatory Standard Message Identifier

.V Mandatory Versio n and Supplementary Data

.F Mandatory Outbound Flight Information

.O Conditional Onward Flight Information

.N Mandatory Baggage Tag Details

.H Optional Handling Location

.P Conditional Passenger Name

.L Conditional Automated PNR Address

.W Optional Pieces Weight, Dimensions and Type

Data

.Y Conditional Frequent Traveler Number

.C Conditional Corporate or Group Name

.E Conditional Baggage Exception Data

.R Optional Internal Airline Data

ENDBNS Mandatory End of Message Iden tifier7.6 MULTIPLE USE OF DATA ELEMENTS

Multiple use of elements may be accomplished by following the structure of the BNS, the sequence of Its elements and the addressing for distributing the BNS. The prime elements are the .F (Outbound Flight Information),the .O (Onward Flight Information), and the following .N elements (Baggage Tag Details) which may be linked to the following .P element (Passenger Name). There may be only

one .F and one set of .O elements for each BNS. Each .F element will be followed by all .O elements. Each .N is the foundation for the other optional and conditional elements that follow. Optional and conditional elements which are

related to the .N are inserted in the order shown in 7.5.

**NOTE:** .N elements without related op tional elements (i.e., .P) must appear last.

The following schematic illustrates the multiple use of elements in the

BNS.

Elements Description

.F Outbound Flight Information (US783)

.O Onward Flight Information (BA223)

.O Onward Fl ight Information (BA351)

.N Baggage Tag Details #1 (for passenger #1 in .P element)

.P Passenger Name #1 (associated to .N element #1)

.L Automated PNR Address (for passenger #1)

.W Pieces and Weight Data (for bag(s) #1)

.Y Frequen t Traveler Number (for passenger #1)

.C Corporate or Group Name (for passenger #1)

.N Baggage Tag Details #2 (for passenger #2 in .P element)

.P Passenger Name #2 (associated to .N element #2)

.E Baggage Exception Data

.R Internal Airline Data (for passenger #2).R Internal Airline Data (for passenger #2)

.N Baggage Tag Details (for passenger #3 in .P element)

.P Passenger Name #3 (associated to .N element #3)

.E Baggage Exception Data

.N Baggage Tag Det ails #4 (for passenger #4 in .P element)

.P Passenger Name #4 (associated to .N element #4)

.N Baggage Tag Details #5 (no additional data supplied)

.N Baggage Tag Details #6 (no additional data supplied)

**Note:** See 7.9.2 for examples of mu ltiple usage in the BNS Message.

7.7 CONDITIONAL ELEMENTS AND DATA ITEMS

7.7.1 Version and Supplementary Data (.V element) The Message Reference Number is conditional upon the sender of the message requesting an acknowledgement, in which case a Messag e Reference Number is required. Additionally, a separator (oblique) is required in place of a Part Number, unless the message is partitioned, in which case the Part Number would follow the separator.

7.7.2 The Onward Flight Information element (.O) become s mandatory when data is

available.

7.7.3 Passenger Name element (.P) becomes mandatory when data is available.

7.7.4 Automated PNR Address element (.L) becomes mandatory when data is

available.

7.7.5 The Number of Checked Bags in the .W element (Piece s and Weight Data) is mandatory when using the Checked Weight data item.

7.7.6 Frequent Traveler Number element (.Y) becomes mandatory when data is

available.7.7. 6 4 Corporate or Group Name element (.C) becomes mandatory when data is

available.

7.7 .5 Baggage Exception Data (.E) The .E element becomes mandatory when the data is available.

7.8 CONSTRUCTION OF ELEMENTS AND DATA ITEMS IN THE BAGGAGE NOT

SEEN MESSAGE

Use Elements and Data Items Example (M) STANDARD MESSAGE IDENTIFIER BNS

(M) VERSI ON AND SUPPLEMENTARY DATA (M) Element Identifier .V (M) Data Dictionary Version Number /1

(M) Baggage Source Indicator T (M) Local Airport Code CDG (O) Part Number /PART1 (C) Message Reference Number /1234567890 (O) Acknowledgement Request /A (O) Encryption /123ABC456Z

(M) OUTBOUND FLIGHT INFORMATION (M) Element Identifier .F (M) Airline and Flight Number /AF912 (M) Date /30APR (M) Destination or Transfer Airport Code /AMS (M) Class of Travel of Baggage /C

(C) ONWARD FLIGHT INFORMATION (M) Element Identifier .O (M) Airline and Flight Number /KL601 (M) Date /3 0APR (M) Destination or Transfer Airport Code LAX (O) Class of Travel of Baggage /M

(M) BAGGAGE TAG DETAILS (M) Element Identifier .N (M) Baggage Tag Number /0037123456 (M) Number of Consecutive Tags 002(O) HANDLING LOCATION (M) Element Identifier .H (C) Handling Terminal /T4 (C) Handling Bay/Pier /GREEN (C) Handling Gate/Stand /D46

(C) PASSENGER NAME (M) Element Identifier .P (M) Separator (oblique) / ( O) Number Passengers With This Surname 2 (M) Passenger’s Surname TENHAVE (O) Given Name and/or Initials, and/or Title /AMS (O) Additional Given Name and/or Initials,

and/or Title /JMS

(C) AUTOMATED PNR ADDRESS

(M) Element Identifier .L (M) Automated PNR Address /U52I91

(O) PIECES WEIGHT, DIMENSIONS AND TYPE DATA (M) Element Identifier .W (M) Pieces/Weight Indicator /K (M) Number of Checked Bags /1 ( O) Checked Weight /10 (O) Unchecked Weight /3 (C) Unit /CM

(O) Length of the bag /68 (O) Width of the bag /54 (O) Height of the bag /24 (O) Baggage type code /02HWX

(C) FREQUENT TRAVELER NUMBER (M) Element Identifier .Y (M) Frequent Traveler ID Number /KL662503 (O) Tier Information /GOLD

(C) CORPORATE OR GROUP NAME (M) Element Identifier .C (M) Corporate or Group Name /AJAX TOUR(C) BAGGAGE EXCEPTION DATA (M) Ele ment Identifier .E (M) Exception Type /SPEQ

(O) INTERNAL AIRLINE DATA (M) Element Identifier .R (M) Free Text /FREE TEXT AREA

(M) END OF MESSAGE IDENTIFIER ENDBNS

7.9 EXAMPLE MESSAGES

7.9.1 Type

- B Baggage Not Seen Message, sent to the final destination, transfer point and tracing system.

AMSLLKL LAXLLKL AMSLLAF

ATLWMXS< ≡ Message sent to

.CDGBRAF 311840< ≡ Message sent by AF

BNS< ≡ Message type (BNS)

.V/1TCDG////123ABC4567Z< ≡ Transfer bags at CDG wi th Encryption

.F/AF912/30APR/AMS/C< ≡ Outbound flight info. (AF912 to AMS)

.O/KL601/30APR/LAX/M< ≡ Onward flight info. (KL601 to LAX)

. N/0037123456002< ≡ 2 missing bags, starting with tag number

0037123456

.H/T4/GREEN/D46 Handling location T 4/ Handling pier GREEN/Handling gate D46

.P/CLOVER/LMR< ≡ Passenger name

.L/U52I91< ≡ PNR Address

.W/K/3/38/11< ≡ Number of bags and weight

.Y/BSJ2238< ≡ Frequent Traveler Number

.C/AJAX TOUR< ≡ Tour Information

.R/LATE CHECKIN< ≡ Internal Airline Data

ENDBNS< ≡ End of Message IdentifierB8.9/P

7.9.2 Example of Multiple Use of Elements

AMSLLAF AMSLLKL LAXLLKL

LAXLLUA SMFLLLUA ATLWMXS Message sent to

.CDGBRAF 171250 Message sent by AF

BNS< ≡ Message Type (BNS)

.V/1TCDG////123ABC456Z< ≡ Transfer bags at CDG with Encryption

.F/AF912/30APR/AMS/C< ≡ Outbound to AMS on AF912 C

- Class

.O/KL601/30APR/LAX/M< ≡ Onward to LAX on KL601 M

- Class

.O/UA887/30APR/SMF/M< ≡ Onward to SMF on UA887 M

- Class

.N/0027123450002< ≡ 1 . 2 Bag Tags starting with

0027123450

.N/0027123453001< ≡ 2. 1 Bag Tag

- 0027123453

.P/TENHAVE/AMS< ≡ Passenger name

.Y/BSJ2238< ≡ Frequent Traveler Number

.E/AVIH Live Animal in Kennel

.R/PAX ENROUTE TO HER

.R/WEDDING

- URGENT< ≡ Internal Air line Data

.N/2001987654001< ≡ 3. 1 Bag Tag

- (no other information available for this bag)

ENDBNS< ≡ End of Message Identifier

B8.6/P

8.7.2 Flight Open Message

...

8.7.2.4 Partitioning of Messages A FOM may not be partitioned.

8.7.2.5 Element Sequence Summary The following shows the sequence of elements in the FOM.

Element Requirement Definition

BCM Mandatory Standard Message Identifier

FOM Mandatory Secondary Level Message Identifier

.V Mandatory Version and Supplementary Data

.F Mandatory Outbound Flight Information

.H Optional Handling Location

.R Optional Internal Airline Data

ENDBCM Mandatory End of Message Identifier

...8.7.2.8 Construction of Elements and Data Items In The Flight Open Messag e

Use Element and Data Item Example (M) STANDARD MESSAGE IDENTIFIER BCM

(M) SECONDARY LEVEL MESSAGE IDENTIFIER FOM

(M) VERSION AND SUPPLEMENTARY DATA (M) Element Identifier .V (M) Data Dictionary Version Number /1 (M) Baggage Source Indicator T (M) Local, Transfer or Terminating Airport Code FRA (N) Part Number

– show only oblique; no data / (C) Message Reference Number /1234567890 (O) Acknowledgement Request /A (O) Encryption /123ABC456Z

(M) OUTBOUND F LIGHT INFORMATION (M) Element Identifier .F (M) Airline and Flight Number /LH3348 (M) Date /20MAR (O) Destination or Transfer Airport Code /GVA

(O) HANDLING LOCATION (M) Element Identifier .H (C) Handling Terminal /T4 (C) Handling Bay/ Pier /GREEN (C) Handling Gate/Stand /D46

(O) INTERNAL AIRLINE DATA (M) Element Identifier .R (M) Free Text /DELAYED INBOUND

(M) END OF MESSAGE IDENTIFIER ENDBCMB8.5/P

Section 9

- BAGGAGE MANIFEST MESSAGE (BMM)

...

9.5 Element Seque nce Summary The following shows the sequence of elements in a BMM.

Element Requirement Definition

BMM Mandatory Standard Message Identifier

.V Mandatory Version and Supplementary Data

.K Optional Default Message Printer

.I Mandatory Inbound Flight Information

.U Conditional Loading Data

.F Conditional Outbound Flight Information

.H Optional Handling Location

.N Mandatory Baggage Tag Details

.S Optional Reconciliation Data

.

. W Optional Conditional Pieces Weight, Dimensions and Type Data

.Q Conditional Load Sequence Number

.O Conditional Onward Flight Information

.P Conditional Passenger Name

.Y Optional Frequent Traveler Number

.C Optional Corporate or Group Name

.L Conditional Automated PNR Addre ss
.E Optional Conditional Baggage Exception Data

.R Optional Internal Airline Data

.X Optional Conditional Baggage Security Screening

ENDBMM Mandatory End of Message Identifier

9.6 Multiple Use of Elements Multiple use of elements may be accomplished by following the structure of the BMM and the sequence of its elements. The prime element is the .I (Inbound Flight Information). This provides the foundation for the .U element (Loading Data) and the .N element (Baggage Details) that follow it, which in turn can be linked to the following .P element (Passenger Name). As the .U element is conditional, a .N element may follow the .I element directly. Optional elements, which are related to the mandatory elements,

are inserted in the order shown in Section 9.5. Except for the .V, .and the .K elements, all elements may occur multiple times, but only the .N,.O, .E and .R may be used consecutively.**Note:** Bags with passenger names must appear before bags without passenger names (see example in 9.9 .).

The following schematic illustrates the multiple use of elements in the BMM.

Element Description

.K Default Message Printer

.I Inbound Flight Information

.U Loading Data

.F Outbound Flight Information

.H Handling Location

.N Baggage Details

.S Reconciliation Data

.W Pieces and Weight Data

.Q Loading Sequence Number

.O Onward Flight Information

.O Onward Flight Information

.P Passenger Name

.Y Frequent Traveler Number

.C Corporate or Group Name

.L Automated PNR Address

.E Baggage Exception Data

.E Baggage Exception Data

.R Internal Airline Data

.R Internal Airline Data

.X Baggage Security Screening

.N Baggage De tails

.Q Loading Sequence Number

.P Passenger Name

.E Baggage Exception Data

.E Baggage Exception Data

.X Baggage Security Screening

.U Loading Data (new .U element)

.F Outbound Flight Information

.H Handling Location

.N Baggage Details

.Q Loading Sequence Number

.P Passenger Name

.R Internal Airline Data

.R Internal Airline Data

.X Baggage Security Screening

.F Outbound Flight Information

.N Baggage Details.Q Loading Sequence Number

.P Passenger Name

.R Internal Airline Data

.R Internal Airline Data

.X Baggage Security Screening

**Note:** See 9.9 for an example of multiple usage in a BMM

**.**

...

9.7.6 The Passenger Name element (.P) is used when the Passenger name is known.

9.7.7 Baggage Exception Data (.E) The .E element becomes mandatory when the data is available.

9.7.8 Pieces, Weight, Dimensions and Type Data (.W) The .W element becomes mandatory when the data is available.

9.7.9 Baggage Security Screening (.X) The .X element becomes mandatory when the data is available.

9.8 Construction of Elements and Data Items in the Baggage Manifest Message

Use Elements and Data Items Example (M) STANDARD MESSAGE IDENTIFIER BMM

(M) VERSION AND SUPPLEMENTARY DATA (M) Element Identifier .V (M) Data Dictionary Version Number /1 (M) Baggage Source Indicator T (M) Local or Transfer Airport Code LHR (O) Part Number /PART1 (C) Message Reference Num ber /1234567890 (O) Acknowledgement Request /A (O) Encryption /123ABC456Z

(O) DEFAULT MESSAGE PRINTER (M) Element Identifier .K (M) Baggage Message Default Printer ID /3D1C08(M) INBOUND FLIGHT INFORMATION (M) Element I dentifier .I (M) Airline and Flight Number /BA117 (M) Date /03OCT (M) Originating Airport Code /LHR

Use Elements and Data Items Example (C) LOADING DATA (M) Element Identifier .U (C) Stowage Device ID /AVE12345BA (C) A ircraft Compartment Or Loading Location /11R (O) Type Of Baggage In Container/Location /T (O) Classes of Travel of Baggage /F (O) Destination or Transfer Airport Code of the Container /SEL (O) Sealed Container Indicator /Y (O) C onnection Airline Code and Flight Number /NW009 (C) Connection Departure Date /04OCT (C) Destination or transfer Airport Code of the Container /NRT

(C) OUTBOUND FLIGHT INFORMATION (M) Element Identifier .F (M) Airline and Flight N umber /UA203 (M) Date /03OCT (M) Destination Or Transfer Airport Code /DEN (O) Class Of Travel Of Baggage /J

(O) HANDLING LOCATION (M) Element Identifier .H (C) Handling Terminal /T4 (C) Handling Bay/Pier /GREEN (C) Handling Gate/Stand /D46

(M) BAGGAGE TAG DETAILS (M) Element Identifier .N (M) Bag Tag Number /0085123456 (M) Number Of Consecutive Tags 002(O) RECONCILIATION DATA (M) Element Identifier .S (M) Aut hority To Load /Y (O) Seat Number /10A (O) Passenger Status /C (O) Sequence Number /098 (O) Security Number /888 (O) Passenger Profile Status /Y

( O C ) PIE CES WEIGHT, DIMENSIONS AND TYPE DATA (M) Element Identifier .W (M) Pieces/Weight Indicator /K (C) Number Of Checked Bags /1 (O) Checked Weight /38 (O) Unchecked Weight /5 (C) Unit /CM (O) Length of the bag /68 (O) Width of the bag /54 (O) Height of the bag /24 (O) Baggage type code /02HWX

(C) LOAD SEQUENCE NUMBER (M) Element Identifier .Q (M) Load Sequence Number /095

(C) ONWARD FLIGHT INFORMATION (M) Element Identifier .O (M) Airline and Flight Nu mber /UA999 (M) Date /03OCT (M) Destination Or Transfer Airport Code /SLC (O) Class Of Travel Of Baggage /J

(C) PASSENGER NAME (M) Element Identifier .P (M) Separator (oblique) / (O) Number Of Passengers With This Surname 2 (M) Passenger’s Surname GROBET (O) Given Name and/or Initials and/or Title /M (O) Additional Given Name and/or Initials and/or Title /J(O) FREQUENT TRAVELER NUMBER (M) Element Identifier .Y (M) Frequent Traveler ID Number /KL662503 (O) Tier Information /GOLD

(O) CORPORATE OR GROUP NAME (M) Element Identifier .C (M) Corporate or Group Name /IATA BALLET

(C) AUTOMATED PNR ADDRESS (M) Element Identifier ./L (M) Automated PNR Address /6Y21AS

(O) BAGGAGE EXCEPT ION DATA (M) Element Identifier .E (M) Exception Type /GRP

(O) INTERNAL AIRLINE DATA (M) Element Identifier .R (M) Free Text /FREE TEXT AREA

( O C ) BAGGAGE SECURITY SCREENING (M) Element Identifier .X (M) Baggage Status /CLR (O) Security Method /XRAY (O) Autograph /TRANSFER

(M) END OF PART or ENDPART1 or

END OF MESSAGE IDENTIFIER ENDBMM

9.9 Example Messages

9.9.1 Loaded Bags (Type

- B Message)

– Sent to BA’s handling Agent in SEL from BA Baggage Handling System in LHR (1 ba g in 1 container on flight)

Routing:

BA117/23JAN/LHR/SEL

JL955/24JAN/SEL/NRT

SELKMXH< ≡ To address

.LHRBRXH 231840< ≡ From address

BMM< ≡ BMM

– Standard Message

Identifier

.V/1TSEL/PART1/555333702//123ABC456Z< ≡ Transfer bag in SE L; Multi part with Encryption.K/3D2C08< ≡ Message Printer ID

.I/BA117/23JAN/LHR< ≡ Inbound flight BA117

.U/AVE1234JL/024L/T/Y/SEL/Y/JL955/2 3 4 JAN/NRT< ≡ Loading Information
.F/JL955/24JAN/NRT< ≡ Outbound Flight JL955

.H/T1< ≡ Handling Location

.N/01251234 56001< ≡ Bag tag number; Number of consecutive tags

.Q/001< ≡ Loading sequence

.P/1CHAN/T< ≡ Passenger’s name

.X/CLR< ≡ Screening description

ENDBMM< ≡ End of Message Identifier

9.9.2 Example of Multiple Usage of Elements

Routing:

BA111/23JAN/LH R/SIN

QF006/24JAN/SIN/SYD

BMM< ≡ BMM

– Secondary Message

Identifier

.V/1TSIN< ≡ Terminating and/or transfer bags

at SIN

.K/3D2C08< ≡ Message printer ID

.I/BA111/23JAN/LHR < ≡ Inbound flight BA111

.U/AVE1234BA//M/F/SIN/Y/QF6/24JAN/SYD< ≡ I. Loa ding

information

.F/QF006/24JAN/SYD/Y< ≡ A. Outbound Flight QF006

.N/0125064717001< ≡ 1. 1st tag number and number of tags

.Q/006< ≡ a. Loading sequence

.P/1NORMAN/G< ≡ b. Passenger’s Name

.Y/BA85521< ≡ c. Freq.Traveler Number.

.N/0125064912001< ≡ 2. 1s t tag number and number of tags

.Q/083< ≡ a. Loading sequence

.P/1ZELLER/F< ≡ b. Passenger’s name

.Y/US7444591< ≡ c. Freq. Traveler Number.

.X/CLR/XRAY< ≡ d. Baggage Security Screening

.N/0125064917001< ≡ 3. 1st tag number and number of tags

.Q/117< ≡ a . Loading sequence

.P/1SCHUT/KCWMRS< ≡ b. Passenger’s Name

.Y/US744591< ≡ c. Freq. Traveler Number.

.X/CLR/XRAY< ≡ d. Baggage Security Screening.N/0125067239001< ≡ 4. 1st tag number and number of tags

.Q/127< ≡ a. Loading sequence

.U//11R/M//SIN< ≡ B. Loading information

.N/0125065209001< ≡ 1. 1st tag number and number of tags

.Q/36< ≡ a. Loading sequence

.P/1JACKLIN/T< ≡ b. Passenger’s Name

.Y/QF003664< ≡ c. Freq. Traveler Number.

.X/CLR< ≡ d. Baggage Security Screening

ENDBMM< ≡ End of Message Identifie r

9.9.3 Example of BMM including information about unaccompanied baggage (UNAC)

BMM< ≡ BMM

– Standard Message

Identifier

.V/1TSEL/PART1/555333702//1234ABC456Z< ≡ Transfer bag in SEL; Multi part with encryption

.K/3D2C08< ≡ Message printer ID

.I/BA117/23JAN/LHR< ≡ Inbound flight BA117

.U/AVE1234JL/024L/T/Y/SEL/Y/JL955/24JAN/NRT< ≡ Loading

information

.F/JL955/24JAN/NRT< ≡ Outbound flight JL955

.H/T1< ≡ Handling location

.N/0125123456001< ≡ Bag tag number; Number of consecutive tags

.Q/001< ≡ Loading sequence

.P/1CHAN/T< ≡ Passenger’s Name

.E/UNAC< ≡ Unaccompanied baggage to be collected by the passenger or the airline/handling agent

.X/CLR< ≡ Screening description

ENDBMM< ≡ End of Message Identifier

...B8.10/P

Attachment ‘E’

BAGGAGE SOURCE MESSA GE (BSM) FOR SORTATI ON AND

RECONCILIATION AND B AGGAGE PROCESS MESSA GE (BPM) FOR

RECONCILIATION

• BSM data sent to sortation and reconciliation systems

• BTM BPM data sent from a reconcilia tion system to carrier host • Baggage Itinerary: LH430 FRA

- ORD

Filing Period: Effective Date:

1 March

- 1 June 2012 13 April 2012 LH

Host

FRA

Reconciliation System FRA

Sortation

System BSM BSM BPMRECOMMENDED PRACTICE 1790

ADDITIONAL SERVICES (amending)

PSC( 3 0 33 ) 1790 Expiry: Indefinite Type: B

T2.6/P

2. DEFINITIONS

...

Electronic Miscellaneous Document (EMD) means an electronic record issued by a Member or its authorized agent, in accordance with applicable tariffs, for residual value

or for the collect ion of miscellaneous charges. An EMD must be either an EMD

- A or an

EMD

- S.

Electronic Miscellaneous Document Associated

– EMD

- A means an EMD issued for

the collection of miscellaneous and excess baggage charges that are to be lifted with an ET flight coupon(s). The association between an EMD value coupon(s) and the corresponding ET flight coupon(s) requires that the coupon status of both remain synchronized.

The intent of the association between the ET flight coupon(s) and the EMD

- A value coupon(s ) is to ensure the usage of the coupon is synchronized.

T2.33/P

11. REVENUE ACCOUNTING

.....

For the purposes of revenue accounting and interline billing, APTCO optional Services issued on an EMD do not constitute ‘Sundry Charges’ as provided in

Resoluti on 727a.

Filing Period: Effective Date:

1 March

- 1 June 2012 13 April 2012RECOMMENDED PRACTICE 1797 COMMON USE PASSENGER PROCESSING SYSTEMS (CUPPS)

PSC( 29 33 )1797

P6.3.8

RECOMMENDED THAT:

Members use the procedures and specifications for Common Use Passenger Processing Systems (CUPPS) as set forth in Attachments ‘A’, ‘B’ and ‘C’.

(Attachments ‘A’, ‘B’ and ‘C’ are published separately

– contact Manager Airport and Inflight Services, email: milesC@iata.org ).

**Secretary note** : the following text is completely new.

When an organization plans to operate shared passenger processing systems in an airport or other common environment, for the purposes of supporting multiple airline processes, the specifications and standards as described in this Recommended Practice shall be applied.

Common Use Passenger Processing Systems (CUPPS) describes the range of services, specific a tions, and standards enacted t o enable multiple airlines, service providers, or other users to share physical check

- in or gate podium positions (whether simultaneously or consecutively). The CUPPS scenario assumes a circumstance whereby an airline or employee other service provider int eracts with a passenger for

check

- in and boarding processes. This Technical Specification d e scribes agent platforms that will accommodate, but not be limited to, check

- in and boarding a c tivities. Future developments may provide for other functions, both bu siness and technical.

Table 0

. 1 shows the CUPPS foundational principles.Table 0

. 1 : CUPPS Foundational Principles Principle Description

Platform Independence Diffe rences in legacy CUTE Platforms lead to additional application complexities and CUTE

vendor

- specific ve r sions that must be maintained

over time.

Business Process

Facilit a tion CUPPS provides a flexible Platform that facilitates Appl i cation functionality t hat may be used for a variety of bus i ness functions.
“Minimum, Defined” CUPPS Platforms must provide the functionality defined as required in the CUPPS Technical Specification. Affordability CUPPS provides the tools and technologies that may lead to ad ditional economies of scale and economies of scope. Predictability CUPPS provides enhanced predictability in terms

of d e ployment and overall platform and application maintenance (duration, cost, etc.) Serviceability CUPPS provides the tools and technol ogies to

increase eff i ciencies of application upgrades and

maintenance.

1. Overview

This section provides an overview of the benefits of CUPPS, its strategy as a product, the management oversight of the ongoing CUPPS activities, and migration strategies.

1.1 Benefits of CUPPS

A CUPPS implementation will enable airlines to provide passenger services in the

context of a shared check

- in, gate podium, or kiosk.

The major benefits of CUPPS are:

 Efficient use of expensive facilities on

- and off

- airport, there by reducing the need for facility expansion.

 Flexibility for accommodating flight segment additions or deletions by carriers in the use of space.

 The ability for an application provider to maintain a single CUPPS

- compliant application that will be seamless ly functional on any CUPPS platform, regardless of the particular platform provider.

 A platform that can easily accommodate various peripheral devices in support of business processes.

 An enabler for improved customer service.

 A flexible architecture to ea sily accommodate alterations in the passenger processing flow.

 An accommodation of the flow of data between emerging and evolving airport and airline systems, as mutually agreed upon between the platform provider and application provider. Improved flexib ility for system upgrades and new versions of software and

hardware.

 Enhanced ease of access to new markets, with overall predictability of cost magnitudes from a technology deployment standpoint.

1.2 CUPPS Product Strategy

The CUPPS product strategy is to deliver a common use platform to support individual and shared airline processes at a shared workstation at check

- in, gate, and other positions, while maintaining the ability for users to maintain their brand images. The key to the product strategy is a n open architecture system where it is possible to use virtually any hardware or software that complies with CUPPS standards included in the CUPPS Technical Specification (CUPPS

- TS).

The functionality described is not exclusive; any future products and/or applications, as appropriate, may be introduced as business needs change.

The initial CUPPS strategy is focused on implementation in both the agent

- assisted

check

- in and boarding environments on

- airport and potentially in kiosk environments.

CUPPS could also be carried forward to provide services at other venues such as rental car agencies, bus terminals, seaports, and railway stations.

The development of the CUPPS product will initially be done collaboratively with the cooperation of airlines and airpor ts, platform providers, and platform suppliers.

1.3 CUPPS vs. CUTE Summary

There are many differences between the legacy CUTE environment and the new

CUPPS forward

- looking environment.

Table 0

. 1 below provides a summary of the major differences.

Table 0

. 1 : CUTE vs. CUPPS Summary

CUTE CUPPS Proprietary peripheral interfaces per supplier. Unified peripheral interface across suppliers Varying support for various per ipherals and varying functionality provided. Unified support for each device category with defined basic functionality

Built

- in AEA support including ATB

- II with propriety supplier

- specific

extensions. Elimination of proprietary device

firmware in favor o f current formats supporting barcodes; no ATB

- II operations. Proprietary management interfaces with varying levels of functionality. Unified approach to system management, including remote administration capabilities. Legacy CUTE may utilize a mixture of workstation operating systems and All CUPPS workstations will use a defined operating system and networknetwork protocols. protocol (including network services). Legacy CUTE implementations provided a mixture of low

- and high

level peripheral interface technologies that were largely incompatible and supplier

- specific. CUPPS defines a standard high

- level

interface standard between applications and the platform.

1.4 CUPPS Platform Standards

The CUPPS platform comprises, at minimum, the hardware and soft ware components

defined in the CUPPS

- TS. The CUPPS platform is envisaged to support a comprehensive range of airline and airport passenger processes and services. Initial focus of the product will be on passenger check

- in (which could include baggage che ck

in) and boarding. Devices within a CUPPS platform shall only be used by applications initiated and operated within the platform or diagnostic software.

Application providers are responsible for the delivery of particular application functionality requi red to support the business processes of its users.

All physical components located at a particular airport shall be equally usable by all participating users.

1.5 CUPPS Management Oversight

The CUPPS Recommended Practice includes promotion of a framework to encourage competition, including among vendors, suppliers, carriers, and airports, and to encourage introduction of new technology and ideas. CUPPS is designed to increase efficiency though recommended practices published in a living document that

ack nowledges changes in technology and industry without compromising introduction of new technology or competition. The CUPPS RP is designed to foster competition and innovation through an open process that encourages all potential competitors to participate

.In order to facilitate the overall success of the initiative and to enhance the economic benefit to the industry, the three organizations with direct ownership interest in the recommended practice (IATA, A4A and ACI) have established the Passenger Expe rience Management Group (PEMG) to oversee the CUPPS group by setting its direction and priorities..

1.6 CUTE to CUPPS Migration

With any next

- generation standard or product, a mechanism must be provided to migrate from the previous standard or product to the next

- generation standard. This section provides the migration considerations for moving from CUTE to CUPPS.

Given the wide array of variations between CUTE implementations combined with the differences that exist due to the local business and operatio nal scenarios at each CUTE location, there is no one migration strategy that is applicable across suppliers. Therefore, each platform provider and/or platform supplier that proposes a CUPPS solution must provide a reasonable and realistic migration strate gy.

Note: CUTE suppliers are required to provide support for their existing CUTE platforms for a period of three years from the date of first publication of the CUPPS Technical Specification

Table 0

. 2 shows the g eneral considerations that each supplier’s migration strategy will likely address. Not every item will be applicable for a given situation nor will the list presented in

Table 0

. 2 constitute the entire list of co nsiderations that every site must contemplate. These reflect examples of major considerations.

Table 0

. 2 : CUTE to CUPPS Migration Considerations

Consideration Impact Potential operating system changes Fo r applications built on a non

- supported operating system, applications must be ported or rewritten for the CUPPS supported operating systems. Application changes Legacy CUTE applications must be adapted to work with the CUPPS platform.

Elimination of

pro prietary device

firmware Applications and business processes that rely on proprietary device firmware must be adapted to E

- Tickets and barcode technologies. Proprietary peripheral interfaces are eliminated in favor of a standard high

- level interface.

CU PPS suppliers are not required to provide solutions to any or all of the considerations given in

Table 0

. 2 nor are the suppliers prohibited from providing functionality that is outside of the CUPPS specification. It is understood that CUPPS suppliers will continue to offer solutions to customers based on mutually agreeable terms and conditions.2. CUPPS Technical Documentation Summary

Major deliverables of the CUPPS process will be the creation and adoption of the

CUPPS

- TR and CUPPS

- TS, which are overviewed below. The CUPPS

- TR provides a formal requirements document used to guide the CUPPS

- TS. CUPPS

- TS provides definitions for the functionality and performance of the CUPPS platform and defines the

functionali ty and performance of the interfaces between the application and platform.

The CUPPS

- TS will not, however, specify an implementation for that functionality or interface. CUPPS suppliers are free to implement their CUPPS products as the supplier deems app ropriate provided that they meet the functionality and interfaces defined in

CUPPS

- TS. The CUPPS

- TS also addresses the minimum operational characteristics for CUPPS applications.

2.1 General

The general considerations for CUPPS are provided below.

2.1.1 Access to the CUPPS

- TR and CUPPS

- TS

In accordance with the Governance terms of reference, ACI, A4A , and IATA shall produce, update, and make available the CUPPS

- TR and CUPPS

- TS in electronic format which shall set forth the standards and specifications for CUPPS. As a condition to certification, application providers and platform providers shall be required to maintain a current subscription to the CUPPS

- TR and CUPPS

- TS. To enable them to defray the costs incurred in developing and maintaining the CUPPS

- T R and CUPPS

- TS, ACI,

A4A , and IATA may establish an annual subscription fee for the documents. Access to these documents, and the fee to be charged, will be non

- discriminatory, i.e. all interested parties, whether or not members of ACI, A4A , or IATA, will be afforded access to the documents on the same terms, and will pay an equal fee for such access.

2.1.2 CUPPS Technical Documentation Ownership

The requirements, functional requirements, specifications, and interface descriptions as

described in CUPPS

- TR a nd CUPPS

- TS are owned by ACI, A4A , and IATA and are maintained by the CUPPS Management Group.

2.1.3 Data Privacy

The rules governing the safeguards placed on data acquisition, retention, and accessibility are defined below. Table 3.1 provides a summary com parison of Public Data, Personal Data, and Proprietary Data.

Additionally CUPPS recognizes and acknowledges that it should facilitate, and not prevent, the end customers' PCI Data Security Standard compliance. Examples of practices that can prevent complia nce include:

 Storage of magnetic stripe data and/or equivalent data on the chip in the

customer's network after authorization.

 Applications that require customers to disable other features required by the PCI Data Security Standard, such as anti

- virus soft ware or firewalls, in order to get the payment application to work properly.

 Vendors’ use of unsecured methods to connect to the application to provide support to the customer.Secure devices, when implemented in a PCI DSS

- compliant environment, will min imize the potential for security breaches leading to compromises of full magnetic stripe data, card verification codes and values (CAV2, CID, CVC2, CVV2), PINs and PIN blocks, and the damaging fraud resulting from these breaches.

The Application Supplier/P rovider shall ensure that when a Payment Card is read for any purpose other than payment, such as Form of Identification (FOID), the application shall include only the first 6 and the last 4 digits of the credit card number. All remaining digits shall be r eplaced with an X. E.g. 123456XXXXXX7890."

This behavior is in compliance with Card Scheme Operating Regulations and IATA

Resolutions 722

- f

- g

- h & 725

- f

- g

- h. For more information on PCI DSS and for the current version please visit: www.pcisecuritystandards.org

Table 0

. 3 : Comparison of Data Privacy Rules

Data Type Acquisition Retention Accessibility

Public Acquired as desired Period defined by

the PP Av ailable to all users or interfaced systems

Personal Only as allowed and appropriate Only as allowed and appropriate Only as allowed and appropriate Proprietary Only as allowed and appropriate Only as allowed and appropriate Only as allowed and appropriat e Usage and/or

Performance Automatically as

CUPPS is used Period defined by

the PP To using entity (PP, PS, AS, and User)

2.1.4 Public Data

Public Data have no access controls placed on them. Public Data may be requested by and revealed to any CUPPS use r or interfaced system. Public Data may be acquired and/or retained for a period to be defined by the PP.

2.1.5 Personal Data

Acquisition, retention, and accessibility of Personal Data must be provided in accordance with Recommended Practice 1774 (Protect ion of Privacy and Trans

- border Data Flows of Personal Data used in International Air Transport of Passengers and Cargo) and regulations defined by the applicable legal jurisdictions.

2.1.6 Proprietary Data

Acquisition of, retention of, and accessibility o f Proprietary Data is to be provided in accordance with the rules defined by the originator of the Proprietary Data. In the absence of superseding rules, the default rule implemented by CUPPS must be that Proprietary Data is acquired, retained, and accesse d only with the permission of the originator of the data.2.1.7 Usage and/or Performance Data

Acquisition, retention, and accessibility of Usage and/or Performance Data are to be provided in accordance with the CUPPS

- TS. In the absence of superseding r ules, the default rule implemented by CUPPS must be that Usage Data is:

 Acquired automatically by CUPPS.

 Retained for a period defined by, and at the discretion of, the platform provider.

 Accessed only by:

o The using entity, i.e. the entity using CUPPS whos e activity was recorded by the platform. A using entity must not be able to access another using entity’s data.

o The platform provider.

o The platform supplier.

2.12 CUPPS Logical System Architecture

Unlike CUTE, whose logical system architecture varied a cross suppliers, CUPPS provides a unified logical architecture. The logical system architecture is overviewed below. Further information regarding the logical architecture will be available in the

CUPPS

- TS.

Note that this section provides information onl y on the logical architecture of CUPPS. Since each CUPPS supplier is free to implement the CUPPS system as the supplier deems appropriate, it is not possible to define the physical architecture of a particular supplier’s implementation of CUPPS.

2.2.1 CUP PS Logical System Architecture Summary

Figure 0

. 1 shows a summary view of the logical architecture of a CUPPS implementation. Each block in the diagram is described below. Airline application server(s) or host sys tem(s) communicate to the airline CUPPS application using a mutually supported communications protocol. The architecture and functionality of the

airline back

- end systems or airline application are outside of the scope of CUPPS and

are therefore not discu ssed.

The CUPPS application communicates with the CUPPS platform utilizing the interface

defined in the CUPPS

- TS. Applications may only access CUPPS

- defined peripherals

via the interface defined in the CUPPS

- TS. Direct access to a CUPPS

- defined peripheral device is not allowed. Applications may access workstation components (see Table 0

. 5 ) via basic operating system services.

The airline system manager or the platform provider’s system manager components

may commu nicate with a CUPPS platform using the management interface defined in

CUPPS

- TS.Figure 0

. 1 : CUPPS Logical System Architecture Summary

Figure 0

. 2 shows a detai led view of the logical architecture.

Note: Figure 0

. 1 and

Figure 0

. 2 are presented here for illustrative purposes only. Refer to the CUPPS

- TS for

actual architectural de finitions.}Figure 0

. 2 : Logical System Architecture Detail

2.3 Network

The network infrastructure for a CUPPS implementation will provide functions described below. Technical specifications for the se functions are described more fully in CUPPS

TS. It is understood that the provider of the network infrastructure may not be the same entity as the provider of CUPPS. If a different entity provides the network, then Table 0.2 below represents examples of service requirements that CUPPS expects.Table 0

. 4 : Network Standards

Function Description

BC/DR The network underlying CUPPS should provide Business Continuity/Disaster Recovery functionality, ensurin g redundancy and resiliency.

DHCP Dynamic Host Configuration Protocol may be used to manage network address allocation.

DNS DNS provides name

- to

- IP and IP

- to

- name address lookup functionality for computer addresses and names. DNS used by CUPPS must supp ort multiple zone

- to

- zone transfers and multiple partial zone

- to

- zone transfers. Login/Logon A standardized login scheme will be used to gain access

to network resources.

MQoS Networks used for CUPPS must meet a MQoS standard.

NAPT NAPT hides the intern al structure of the network by mapping all addresses on the network to a single address using different network ports.

NAT NAT translates one range of network addresses onto another range.

SNMP SNMP provides a standard for remote management of

network de vices.

Standardized

Procedures CUPPS networks must be managed with a set of standardized procedures, e.g. ITIL, ISO, etc.

VPN A VPN provides for a secure tunnel between two points

on a network. VPNs are often used to tunnel from a

workstation on an exter nal network into a corporate private network.

Wireless Wireless infrastructure may be made available for use by the airlines, airports, and/or the general public. Appropriate security measures must be undertaken to

ensure access is controlled and data is kept secure for

CUPPS. NB: Reference to PCI

- DSS solutions within this

document do not refer to wireless infrastructure.

2.4 Hardware

The CUPPS hardware standards are overviewed below. The details of the hardware requirements for CUPPS are defined in th e CUPPS

- TS.

2.4.1 Workstations

The CUPPS Technical Specification shall provide the standard device abbreviations, descriptions, interface language(s) (e.g. AEA), function requirements (e.g. speed and resolution), and requirements levels (e.g. “defined, req uired”, “defined, not required”). Choices of specific hardware are left to the individual CUPPS supplier.2.4.2 Vendors

Workstation hardware may be provisioned from any vendor provided that the hardware meets the requirements for a given implementation. The vendors that are appropriate for a given implementation will vary depending upon the local implementation details and local preferences.

Table 0

. 5 shows the minimum components, e.g. the internal components tha t make up the workstation and its operating system, used by CUPPS workstations. A CUPPS interface will not be defined for these components. These components are directly accessed by either CUPPS or COTS applications.

Table 0

. 5 : Required Workstation Components

Function Description Computer The computer and its internal components. Keyboard A standard 101+

- key keyboard is required for each end

- user workstation per local configurations. Pointing Device A pointing device is required for each workstation.

Touch Screen A touch screen is required to support the check

- in and boarding functionality required by airlines and airports. Windows Operating System Services Windows provided print spooler, file access , memory management, etc.

Workstation Ergonomics

The workstations should be designed to maximize utilization of limited counter

- top surfaces (e.g. trackball versus mouse, etc.). The counter design should be configured in conjunction with ergonomically placed peripherals, to minimize time/motion activities in issuing/reading documents.

Consideration will be given to the occupational requirements related to accommodation for physical challenges and overall occupational health and safety.

A repository w ill be established for counter design documents related to common use installations. This repository will tentatively be held by Airports Council International

– World.

2.4.3 Servers

Server hardware may be provisioned from any vendor provided that the ha rdware meets the requirements for a given implementation. The vendors that are appropriate for a given implementation will vary depending upon the local implementation details and local preferences.2.5 Software

CUPPS software will be designed as descr ibed below.

2.5.1 Workstations

Table 0

. 6 shows the CUPPS software and design considerations for end

- user workstations. The CUPPS

- TS shall define the exact requirements for each of these

functions.

The “workstatio n” requirements given below do not imply or require any particular implementation by a CUPPS supplier other than these functions must be accessible via the defined interfaces from every CUPPS workstation in a given implementation. CUPPS suppliers are free to implement a software architecture that implements the standard CUPPS interfaces as they deem appropriate.

Table 0

. 6 : CUPPS Platform Workstation Software Components

Function Description

Alerts Platf orms must provide security alert distribution by authorized

administrators Application Management CUPPS platforms must implement application management functionality appropriate to support the CUPPS platforms. Application Requirements Applications m ust be well

- behaved, with no unreasonable performance impacts, security risks to the platform or local

network.

Authentication Platforms must provide authentication services for users onto

the workstation and local network resources.

COTS Software CO TS applications must be well

- behaved and must not pose any unreasonable performance or security impacts to the platform or local network.

Event Management Platform must implement an event management functions for application and platform events.

Hardw are Abstraction Layer (HAL) Platforms must provide a HAL that shields applications from the supplier, firmware, and connectivity of the peripheral.

IATA Message

Interface To facilitate integration with airport systems, platforms must provide the capa bility to send and receive IATA defined message formats. Logging Platforms must provide a logging interface appropriate for application support and debugging purposes.

Menus Platforms must provide a menu system with appropriate security. Operatin g System Workstations must use an operating system as defined in the

CUPPS

- TS.

Performance Platform performance must meet or exceed defined
parameters.

Permissions Platforms must manage and secure access to the platform,
network resources, and us er or airline data.Platform Management Platforms must provide management functionality to facilitate the administration, support, and usage.

Software

Distribution Platforms must provide a mechanism to distribute software

Storage Platforms must pr ovide an interface for secure storage of data in or persistent areas. Supplier CUPPS applications work across CUPPS implementations.

World

- Wide Naming Standards A world

- wide naming convention for the naming of CUPPS workstations and peripherals.

2. 5.2 Servers

Table 0

. 7 shows the CUPPS software and design considerations used on application or platform servers. The CUPPS

- TS shall define the exact requirements for each of these

functions.

The “server” requirem ents given below do not imply or require any particular implementation by a CUPPS supplier. CUPPS suppliers are free to implement a software architecture that implements the standard CUPPS interfaces as they deem appropriate.

Table 0

. 7 : CUPPS Platform Server Software Components

Function Description

CUPPS Platform Functionality CUPPS suppliers may implement software components on the CUPPS servers as they deem appropriate. Operating System(s) CUPPS supplie rs are free to implement any operating system on the server hardware that

satisfies CUPPS

- TS.

2.6 Logo Repository

IATA may maintain a repository of carrier

- approved logos, for use by approved IATA associates or ACI member airports to enable the associate s to find the latest approved version of carrier approved logos (or others, such as those used by ground handlers) for use on systems including CUPPS, AIDX, etc. It is recommended that the repository contain a variety of logos for each carrier, with descr iptions for proper use (for a light background, for a dark background, for small logos on individual lines of AIDX displays, etc.). Additionally, each logo should be made available in a format scalable to a variety of display sizes so that the logo can be viewed without distortion. Every effort should be made to provide enough information about each logo and its intended use, so as to reasonably ensure the logo will be correctly displayed.3. Roles and Responsibilities

This section addresses the roles and responsibilities of the various CUPPS parties, as they pertain to overall system provision and maintenance.

To ensure a consistent interpretation of the material below, please note these

definitions:

 Supplier A supplier is the entity that creates the system. Suppliers market their products and services to providers.

 Provider A provider is the entity that acquires the system from a supplier and provides it to the user community.

3.1 Platform Provider’s Responsibility

The platform provider will, as de fined in the SLA, ensure that:

 The CUPPS platform is operational and usable during the specified operational

hours.

 The CUPPS platform is functioning and certified according to CUPPS standards.

 Software levels and version control of the platform are mainta ined for the site.

 Statistical and management information is available.

 Notification is made to the application provider of faults that cannot be resolved.

 That the ability exists to disable an application if it is deemed to be causing other applications a nd/or the CUPPS platform to malfunction. If this is the case they will endeavor to inform the application provider in advance.

 CUPPS workstation locations are to be locally and mutually agreed upon.

3.2 Application Provider’s Responsibility

The applicatio n provider is responsible for the application code, which must follow and pass the Certification and Deployment process as defined in the CUPPS

- TS.

If the application provider decides to use a dedicated application Server, either at the

CUPPS site or a lo cation that is under the control of the application provider, then that application provider is responsible for the maintenance, administration, and support of

the Server.

The application provider is responsible for any communication lines to and from the application provider’s server(s).

The application provider must provide the correct protocol and interfaces to allow connection at the CUPPS site as mutually agreed between the platform provider and the application provider.

3.3 Establishment of Service Levels

Minimum Service Levels, in the form of a Service Level Agreement (SLA) will be locally and mutually agreed upon between the platform provider, the platform supplier, and the application supplier. As a guideline, a sample SLA template is included i n the CUPPS

TS.3.4 Management Information and Availability Figures

The platform provider should be able to supply all application providers the Availability figures and access to the management tool used for real time status of the CUPPS

installation.

3.5 Certification and Deployment

The platform and applications must be certified and deployed in accordance with the procedures in the Certification and Deployment section of the CUPPS

- TS.

4. Applicable Industry Standards

CUPPS adheres to, references, a nd acknowledges the standards shown below.

Table 0

. 1 : IATA Recommend Practices Reference

IATA A4A Title

1008 100.1

5 Glossary of Commonly Used Air Passenger Terms

1706 n/a Functional Specification for Standa rd Departure Control System

1706

e 30.10

2 Paper Specifications Documents to be Printed by a General Purpose Printer (GPP) In A Common Use Self

- Service (CUSS)

Kiosk

1720 n/a Seat Assignment Parameters

1724 20.03 General Conditions of Carriage (Passenger a nd Baggage)

1740

a 30.42 Form of Interline Baggage Tag

1796 30.76 Baggage System Interface

1774 n/a Protection of Privacy and Transborder Data Flows of Personal Data Used in International Air Transport of Passengers and Cargo

1778 n/a Corporate Client I dentification Service

1784 * Electronic Reservation Services Providers (ERSPs)

1797 n/a Common Use Terminal Equipment

* A4A Electronic Marketplace Committee RP

Table 0

. 2 : IATA/ARC Resolutions Reference

IAT

A A4A Title

740 30.4

2 Form of Interline Baggage Tag

800

z n/a Electronic Ticketing

898

a n/a Electronic Reservation Services

ProvidersTable 0

. 3 : IATA/ATA Resolutions Reference

IATA A4A Title

722e ATB Standard

722f 20.60 Electronic Ticket Airline 722g 20.61 Electronic Ticket Neutral

722h 20.62 Electronic Ticket Ground Handling

724 20.03 Passenger Ticket Notice and Conditions of Contract

728 110.1

6 Code Designators for Passenger Ticket and Bagg age Check

725f 20.63 Electronic Miscellaneous Documents Airline 725g 20.64 Electronic Miscellaneous Documents Neutral

740 30.35 Form of Interline Baggage Tag

791 20.20

4 Specifications for Airline Industry Integrated Circuit Card (ICC)

Table 0

. 4 : Other Document References

Reference Electronic Reservation Services Providers Implementation guide Electronic Ticketing Implementation Guide Integrated Circuit Card Implementation Guide Workstation Ergonomics ACI Logo Repository IATA Payment Card Industry Data Security Standards

5. Abbreviations and Glossary

ACI Airports Council International

AEA Association of European Airlines.

AIDX Aviation Information Data Exchange.

Application Provider An Applic ation Provider is an entity that provides and manages applications accessible from a CUPPS workstation. An Application Provider is often an airline, but may also be another organization that provides customer handling services, or any other entity

whose e nd

- users utilize software on a CUPPS workstation.Application Supplier An Application Supplier is an entity that creates application software. The Application Supplier writes the application software on behalf of, and provides related services to,

the A pplication Provider. An Application Supplier may be a technology firm contracted by an Application Provider, or an internal technology organization within an Application

Provider.

A 4 A Airlines for America (formerly the ATA

- Air Transport Association )

C OTS

Commercial Off

- The

- Shelf.

CUPPS Common Use Passenger Processing Systems.

CUPPS Application A CUPPS Application is a single business application that runs on a CUPPS Platform. A CUPPS Application conforms to the application standards defined in the CUPPS Technical Specification.

CUPPS Certified A CUPPS Certified Platform, Application or Device has successfully completed all three steps (Technical Compliance, Integration and Beta Testing) of the Certification process.

CUPPS Compliant A CUPPS Compli ant Platform, Application or Device has successfully completed the Technical Compliance Testing phase of the Certification process.

CUPPS Platform A CUPPS Platform is an IT environment that supports applications for one or more Application Providers (u sually airlines or other entities operating in an airport environment). A CUPPS Platform conforms to the platform standards defined in the CUPPS Technical Specification.

CUTE Common Use Terminal Equipment.

DHCP Dynamic Host Configuration Protocol.

DNS Domain Name System.

GUI Graphical User Interface.

HAL Hardware Abstraction Layer.IATA International Air Transport Association.

ICAO International Civil Aviation Organization.

IEEE Institute of Electrical and Electronics Engineers.

IETF Internet Eng ineering Task Force.

ITIL Information Technology Infrastructure Library.

JAR

Java Archive.

LAN

Local Area Network.

MQoS Minimum Quality of Service.

NAPT

Network Address Port Translation.

NAT

Network Address Translation.

OCR Optical Ch aracter Recognition or Optical Character Reader.

PAT

See NAPT.

Platform Provider A Platform Provider is an entity that acquires a CUPPS Platform from a Platform Supplier and offers it to the user community. A Platform Provider is responsible to

manage, m aintain and administer the implemented Platform in a production

environment.

Platform Supplier A Platform Supplier is an entity that creates the CUPPS Platform.

RFC Request For Comments; Request for Change.

SLA Service Level Agreement.SNMP Simple N etwork Management Protocol.

TCP/IP

Transmission Control Protocol over Internet Protocol.

VPN

Virtual Private Network.

6. References

AEA. AEA Technical Specifications 2007. AEA, 2007.

IATA. Common Use Self Service (CUSS).

IATA. Passenger Services Con ference Manual.

ICAO. Document 9303: Machine Readable Travel Documents. Tech. Rep.

Filing Period: Effective Date:

1 March

- 1 June 2012 13 April 2012