It is strongly recommended that airlines, coordinators or facilitators adhere to the rules for the construction of the standard messages as described in this Chapter. The common rules for the data elements as described in Chapter 2 of this Manual should also be followed.

* All dates, days and times are in UTC. However, while the standard is UTC, airlines and coordinators may, on a bilateral basis, exchange information in Local Time.

* The messages may contain data defined by either period/season (flights with regular frequency) or by single dates (individual flights). Both formats are described in this Chapter. They can be used jointly or separately.

* Period of operation may not be open-ended (use of “00XXX” as start or end dates is not permitted).

An SCR/SMA message must include data relevant to the Level 3 or Level 2 airport for flights that start or end outside the Period of Operation or Season. The Period of Operation will always reflect the date/time of operation at the airport where the SCR/SMA is made. → For further guidance, refer to Appendix H: SCR/SMA for Flights Partly out of Season.

* Coordinators and facilitators will respond to requests within 3 business days. Unless stated otherwise, offers from coordinators or facilitators to the airlines are valid for 3 business days only. If an airline has not accepted the offer within the 3-day time limit, the offer may be canceled.

* When an airport has no apron or terminal capacity constraints, the Aircraft Group Code for Aircraft Types (SSIM Appendix A) may be used.

* When submitting an SCR/SMA for ‘full season’ operations with less than daily frequency, airlines may use the start and end dates of the season even if these are not the actual dates of operation.

However, when the Frequency Rate is used to indicate that a flight operates at fortnightly intervals (every 2 weeks), the start date of the Period of Operation must be the first date of operation, and the end date must be the last date of operation.

* There can only be one arrival and one departure with a particular flight designator on a given date at an airport. If, for planning or ad hoc operational reasons, the same Flight Designator is used on the same UTC date, one flight should be filed using the Operational Suffix ‘Z’. Whenever a flight is filed with an Operational Suffix, this flight should retain the Operational Suffix in all future SCR/SMA messages. This should be provided even when changes mean that the Operational Suffix is no longer be required. If there is a significant risk that the need to use Operational Suffices will recur, or if an Operational Suffix is needed for an entire period, it is advisable to use different Flight Designators for these flights.

Airlines should ensure that once the Operational Suffix is used, it should be maintained in their system.

* When a coordinator or facilitator requires filings as turnarounds or when airlines elect to file flights as turnarounds (i.e. arrival and departure in a single data record), any modifications pertaining to either the arrival or departure require all unchanged elements to be repeated in order to maintain the turnaround link. Flights that are not turnaround flights (positioning to a hangar and then repositioning later to a gate) or flights for which no dedicated link can be given (e.g. flights of airlines at their home base) should be filed using separate arrival and departure formats. If flights are originally filed using an overmidnight indicator, any subsequent change should again be filed using the turnaround format. If existing clearances have been recorded as turnaround flights with historic rights, airlines may request the coordinator to provide individual records for the arrival and for the departure flight, i.e. unlink the (turnaround) flights. This procedure allows airlines to exchange parameters between flights and to maintain the historic rights to the flights. Requests to unlink historic flights are undertaken on a bilateral basis between airlines and coordinators and must be submitted to the coordinator before the deadline for the distribution of the Slot Historic List message (SHL) to the airline.

• An airline may decide that the response message from a coordinator or facilitator should be

sent to a message address that is different from where the (airline) request message was sent to the airport coordinator or facilitator. This may be undertaken on a bilateral basis and it is the responsibility of the airline to ensure that the coordinators are fully aware of the situation. Coordinators and facilitators will normally respond to all originating message addresses of the requesting airline.

• If an airline is unable to attend the SC, it should reply to the Slot Initial Allocation List message

(SAL) prior to the SC. If the coordinator or facilitator has responded with more than one offer for a specific request, the airline should indicate which offer is being accepted.

• Although the standards and formats used in this Chapter were initially designed for use with Type B messages, all the standards and formats are applicable to the use of emails, computer printouts, web data displays and any other media. Some additional standards apply when using email (see 6.2.1 below). Plain text files should be used and must not contain any special formatting information.

Each text file should contain information for only one airport, the standard message headings should appear before information lines, and supplementary information should continue to be indicated by using SI or GI lines as applicable. When using Type B messages, the maximum line lengths and maximum message lengths constraints must be followed. However, when using other media, there is no requirement to split data lines or messages into separate parts.