ISO/PAS 28005-1:2012

PUBLICLY ISO/PAS
AVAILABLE 28005-1
SPECIFICATION
First edition
2012-09-01
Ships and marine technology —
Electronic port clearance (EPC) —
Part 1:
Message structures — Implementation of
a maritime single window system
Systèmes de management de la sûreté pour la chaîne
d'approvisionnement — Operations portuaires assistées par systèmes
électroniques —
Partie 1: Structure des messages — Mise en oeuvre d'un système
maritime à guichet unique
Reference number
©
ISO 2012
©  ISO 2012
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56  CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2012 – All rights reserved

Contents Page
Foreword . iv
Introduction . v
1  Scope . 1
2  Normative references . 1
3  Terms and definitions . 1
4  Conceptual system design . 3
4.1  General single window functionality . 3
4.2  Business to administration or business to business system . 3
4.3  Alternative message sequences . 4
4.4  Information sent by ship or agent . 4
4.5  Input data once . 4
5  General transaction requirements . 5
5.1  General transaction pattern . 5
5.1.1  Unique journal number . 5
5.1.2  Request . 5
5.1.3  Receipt . 6
5.1.4  Cancellation . 6
5.1.5  Acknowledgement . 6
5.2  Multiple copy-to parties . 7
5.3  Support for other reporting requirements . 7
5.4  Support for alternative data sources . 7
5.5  Support for alternative information transfer mechanisms . 7
5.6  Electronic communication interface requirements . 8
5.6.1  Ship interface . 8
5.6.2  SW interface . 8
5.7  Operational security . 8
6  Message requirements . 8
6.1  Example of message descriptions . 8
6.2  XML Schema to be used . 9
6.2.1  File header and end . 9
6.2.2  New data type definitions . 9
6.2.3  Data block definitions . 9
6.2.4  Message definitions . 10
6.3  Structure of the EPC message . 10
6.4  Structure of request data block . 11
6.5  Structure of cancel data block . 13
6.6  Structure of receiptdata block . 13
6.7  Structure of acknowledgement data block . 13
7  New data types . 14
7.1  epc:MessageTypeContentType — New code values . 14
7.2  RequestErrorCode — request error codes . 14
7.3  EPCClearanceStatusType — Data type for clearance status . 14
Annex A (informative) Implementation advice for single window . 16
Annex B (informative) Development of a single window . 22
Bibliography . 28

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for whom a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
In other circumstances, particularly when there is an urgent market requirement for such documents, a
technical committee may decide to publish other types of normative document:
 an ISO Publicly Available Specification (ISO/PAS) represents an agreement between technical experts in
an ISO working group and is accepted for publication if it is approved by more than 50 % of the members
of the parent committee casting a vote;
 an ISO Technical Specification (ISO/TS) represents an agreement between the members of a technical
committee and is accepted for publication if it is approved by 2/3 of the members of the committee casting
a vote.
An ISO/PAS or ISO/TS is reviewed after three years in order to decide whether it will be confirmed for a
further three years, revised to become an International Standard, or withdrawn. If the ISO/PAS or ISO/TS is
confirmed, it is reviewed again after a further three years, at which time it must either be transformed into an
International Standard or be withdrawn.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO/PAS 28005-1 was prepared by Technical Committee ISO/TC 8, Ships and marine technology.
ISO 28005 consists of the following parts, under the general title Ships and marine technology — Electronic
port clearance (EPC):
 Part 1: Message structures — Implementation of a maritime single window system [Publicly Available
Specification]
 Part 2: Core data elements
ISO 28005-2, Security management systems for the supply chain — Electronic port clearance (EPC) — Part 2: Core
data elements.
iv © ISO 2012 – All rights reserved

Introduction
This Publicly Available Specification contains technical specifications that facilitate an efficient exchange of
electronic information between ships and shore for coastal transit or port calls. This Publicly Available
Specification is intended to cover the exchange of safety and security information required under the IMO FAL
Convention and other international specification as defined in ISO 28005-2. This Publicly Available
Specification is based on XML and UN/CEFACT standards such as those specified in the FAL Compendium.
Implementors of this PAS should normally also provide electronic interfaces supporting the use of
UN/EDIFACT standards. Parties with economic interests related to the ship, cargo, passengers or crew, such
as land transporters, receiving parties, insurers, and financial entities, may also find value in configuring their
data reception capability to receive information formatted in accordance with this Publicly Available
Specification. However, this is not a requirement of this Publicly Available Specification.
It should be noted that there are a number of other data exchanges related to port calls taking place that are
outside the requirements of this Publicly Available Specification such as:
 Administrative and trade related data exchanges.
 Customs clearance for import and export of goods.
 Logistics arrangements for loading and discharge of cargo, including bay plans, mooring instructions, tug
orders and other needs.
 Commercial exchanges related to freight costs, ownership and insurance of cargo. Ship operational
exchanges related to the ordering of consumables, water, bunkers and spare parts, or the exchange of
crews.
 Commercial exchanges related to port logs/statements of fact, calculations of demurrage and port fees,
etc.
Other ISO Committees, e.g. ISO/TC154, provide message and data transmission standards for such data
exchanges.
This Publicly Available Specification, possibly together with other international standards, can be used to
implement a single window for port clearance. This single window can provide for: 1) the simplified electronic
means for clearance of ships in maritime transport, 2) standardization in logisitics activities, interface, and
information in overall maritime transport, 3) improved maritime logistics activities, interface, and information in
overall maritime transport, 4) improved maritime logistics efficiency and strengthened maritime logistics
competitiveness of IMO member states. The single window standard for maritime transport is built upon
general single window concepts and characteristics and has been expanded to integrate the requirements of
maritime transport.
ISO 28005 consists of two parts. Part 1 (PAS) specifies the overall configuration of electronic port clearance
(EPC) and defines the message structures for use in EPC. Part 2 contains detailed definitions of core data
elements used in the message structures.
PUBLICLY AVAILABLE SPECIFICATION ISO/PAS 28005-1:2012(E)

Ships and marine technology — Electronic port clearance
(EPC) —
Part 1:
Message structures — Implementation of a maritime single
window system
1 Scope
This Publicly Available Specification provides necessary guidance information related to electronic port
clearance (EPC), such as message transmission requirements, business scenarios, message structures and
software requirements. Within the context of this Publicly Available Specification, EPC includes the activities
that a user, such as a ship's master, a shipping agency or a ship owner undertakes to submit electronic data
to appropriate organisations to approve or reject the clearance for the ship to enter or leave a port.
This Publicly Available Specification defines XML message structures for transmission or information between
a ship or its representatives and certain organisations responsible for the processing of the ship's port
clearance request. The information to be transferred is that which is defined by the FAL Convention and other
related international instruments as defined by ISO 28005-2. These mesage structures are primarily intended
for machine to machine data transfers.
This Publicly Available Specification allows different configurations of the single window (SW), from a
minimum solution to support basic clearance requirements to a more complex system to facilitate more
extensive cooperation between ship and shore organisations.
Informative Annex A provides implementation advice for a SW. Informative Annex B suggests a methodology
for the development of a SW.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO 28005-2, Security management systems for the supply chain — Electronic port clearance (EPC) —
Part 2: Core data elements
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
acknowledgement
message sent from authorities giving the final acknowledgement of a request with the result of the request as
an approval or denial
3.2
authority
entity or entities acting on behalf of the port state under national legislation
3.3
cancellation
message sent from the ship to the single window to cancel a previous request
NOTE If the request is for port call clearance, the cancellation applies to all requests associated with that port call.
3.4
electronic port clearance
EPC
port clearance carried out by electronic messaging through a single window
3.5
empty tag
data elements that cannot be given a value by the sender and that are empty
NOTE See ISO 28005-2:2011.
3.6
journal number
reference code assigned by the single window to one specific call from one specific ship to the port
NOTE The journal number is normally assigned as a result of a first request message, but can also be assigned by
other methods. A scheduled service could get a pre-assigned series of journal numbers to cover a certain period. The
journal number is used in the exchanges between ship and single window to identify what port call a certain transaction
refers to.
3.7
port
location on a coast or shore containing one or more port facilities where ships can berth and transfer people or
cargo to and from land
NOTE Clearance to port will normally imply clearance for one specific port facility as defined in SOLAS Chapter XI-2
(International Ship and Port Facility Security Code - ISPS). Shifting the ship from one port facility to another will normally
require additional clearance, although not as extensive as for the general port clerance. For the purpose of this Publicly
Available Specification the term Port is used with the meaning of a port and an associated specific port facility in the port
3.8
port clearance
process undertaken by an entity or entities for the purpose of determining if a ship may enter the port, berth at
a facility, conduct certain operations, and/or depart the port
NOTE For cargo, additional clearance may be required to allow the unloading of the cargo or import of the cargo from
the tax free areas.
3.8
receipt
message sent from the single window as an inital response to a request
NOTE The receipt shows that the message was received and read and that necessary processing has been initiated.
In cases where all processing is done within the single window, the receipt may be the only response to the request.
3.9
request
message sent from the ship to the single window, containing a request for some form of clearance or other
service from one or more authorities connected to the single window
3.10
ship
ship itself, an agent in the port of call, the owner or management company, or any other entity that can legally
represent the ship in the transaction
NOTE When the term ship is used as one of the parties to a communication with a single window.
2 © ISO 2012 – All rights reserved

3.11
single window
SW
facility that allows parties involved in trade and transport to lodge standardized information and documents
with a single entry point to fulfil all import, export, and transit-related regulatory requirements
NOTE 1 If information is electronic, then individual data elements should only be submitted once.
NOTE 2 In this Publicly Available Specification, the term single window is restricted to a single window that is used for
clearance of ships according to requirements in the FAL Convention. This is sometimes called a maritime single window.
NOTE 3 Defined in UNR33.
3.12
Uniform Resource Identifier
URI
string of characters used to identify a name or a resource enabling interaction with representations of the
resource over a network (typically the World Wide Web) using specific protocols
NOTE 1 Schemes specifying a concrete syntax and associated protocols define each URI.
NOTE 2 A valid URI is specified according to ISOC RFC 3305. Schemes such as “mailto”, “http” and “https” are used in
this Publicly Available Specification.
4 Conceptual system design
4.1 General single window functionality
This Publicly Available Specification does not directly define the functionality of a single window (SW).
However, it is assumed that a SW exists and that it implements functionality to provide an electronic interface
between the ship or the ship representatives and authorities ashore.
Ship Authority 1
Agent Authority 2
SW
... ...
Party n Authority n
Figure 1 — General topology of SW system
The expected system configuration is shown in Figure 1. The SW acts as a single message centre for data
sent to or received from the ship or its representatives. The relevant authorities use the SW to perform their
clearance functions. The dashed line is the interface covered by this Publicly Available Specification.
4.2 Business to administration or business to business system
The definition of SW implies that the SW is uniquely a mechanism that implements a business to
administration (B2A) relationship. However, in the context of the interface between ship and port state
authorities, the port will in some cases operate as an authority and in other cases as a private entity. Thus,
this Publicly Available Specificiation will support both types of SW as illustrated below.
Public systems Private systems
Ship Authority 1
Port
SW
... ...
Authority n
Private systems Public systems
Ship
Authority 1
Port .
SW
...
Authority n
Figure 2 — Alternative SW solutions
Thus, a SW may in principle be implemented by private parties in the port and transfer data to public
authorities or vice versa. Also, data transfer could be between the ship and public authorities and the port
itself may not be part of the message exchange at all. This Publicly Available Specification does not mandate
any particular organisation of the SW.
4.3 Alternative message sequences
Port clearance can be a simple process where one clearance request is sent from a ship and one clearance
acknowledgement is returned from the SW when the ship has been cleared by the relevant authorities.
However, it may also be more complex, involving early bookings, updates, as well as cancellations of the
whole port call as illustrated below.
Activities before voyage Activities during voyage In port

Figure 3 — Example of a more complex ship voyage timeline
4.4 Information sent by ship or agent
Some ships may not have Internet access or may have delegated reporting responsibilities to an agent for
other reasons. This Publicly Available Specification will support information transmissions both from ship and
agent. Even if ships have access to the Internet, this may not be available at all times so the SW needs to
support some form of store and forward (e-mail) transmission mechanism in addition to direct web-based
access. This does not have any direct consequence for message formats.
4.5 Input data once
This Publicly Available Specification defines message structures that require information to be input only once.
This also includes provisions for the SW to accept certain data in other formats than what this Publicly
Available Specification defines.
4 © ISO 2012 – All rights reserved

Early booking
Cancellation
Booking update
Pre-arrival notice
Cargo update
48 hour notice
24 hour notice
Departure notice
Update departure data
5 General transaction requirements
5.1 General transaction pattern
The general transaction pattern is shown in Figure 4. The shaded areas represent message exchanges that
are optional in this Publicly Available Specification.
SW Authorities
Ship
Clearance Request
Receipt
Auth. transfer request(s)
Update Request 1.n
Receipt 1.n
Cancellation
Receipt
Adm. Response 1.n
Acknowledgement 1.n
Auth. Response
Acknowledgement
Figure 4 — General transaction pattern
5.1.1 Unique journal number
With the following exception, all message exchanges between the ship (or agent) and the SW relating to one
specific port call shall be identified by a unique journal number for the port call. The journal number is a field in
the message header structure. The exception to this rule is that the first clearance request from the ship (or
agent) to the SW shall have an empty tag for the journal number if the journal number is unknown to the ship
or agent at the time of transmission. The receipt message from the SW, if the receipt accepts the request, will
contain the journal number to be used in all subsequent message exchanges. This will ensure that all
messages related to one particular port call can be easily and uniquely identified.
NOTE The SW needs to construct a unique journal number for each ship’s port call and embed it in a token string.
5.1.2 Request
A request message is sent to request clearance to enter or leave the port. The request message may also be
used for other purposes as described in 5.3 if the SW accepts such messages.
The SW may allow a request message to be updated for the puposes of changing or adding information
related to the port call.
The SW is, however, not required to accept updates of request messages. If updates are not allowed,
approval or denial of port clearance will be based on the initial request submission and further requests will
automatically receive a negative receipt message. In this case, if the orginal request message was; in error,
incomplete, or the information had subsequently changed, the original request should be cancelled and a new
request submitted.
When information contained in an accepted update is received, the authorities that require that information
shall be informed by the SW and previous approvals issued by that authority, which were based on the
original information, shall be automatically cancelled. The corresponding status of all required
acknowledgements will be transmitted to the ship in the receipt message.
The ship must keep track of the status of the required approvals.
The request message shall list the copy-to parties that should be copied on all responses to the request. The
SW may limit the number of recipients and this will be conveyed in the receipt message.
5.1.3 Receipt
All messages from the ship to the SW that can be processed by the SW will receive a receipt message from
the SW. The receipt message will signify one of two cases:
1. The information and syntax of the message sent from the ship is free of syntax errors and sufficiently
complete to be forwarded to some or all authorities involved. The receipt message will list those
authorities to which the request message had been forwarded. Upon receipt of the forwarded message,
the authorities will begin processing the information and for the purpose of issuing a request approval or
denial through an acknowledgement message. Port clearance approval or denial will be sent to the ship
when processing is complete. The receipt message will also specify which, if any, authorities do not have
enough information to process their approval or denial decision.

2. The message from the ship contained syntax errors, was incomplete, or contained information that cannot
be processed by the SW. The message will not be forwarded to the authorities and will not cause any
further processing. Incomplete request messages to a SW that do not allow for updates will be ignored.
The message needs to be corrected and resent. Examples of information that cannot be processed
include excessively long copy-to lists, illegal number of message bodies, illegal message codes or similar.
Messages that cannot be processed by the SW will be silently ignored and will not receive a receipt.
5.1.4 Cancellation
A cancellation message can be sent to the SW to cancel a previously submitted request. A cancellation
message that received a receipt will cease any further processing of the request and all previously received
acknowledgement messages, if any, will be voided.
NOTE A successful cancellation only applies to the SW process and there may still be consequences related to, e.g.
port fees.
5.1.5 Acknowledgement
An acknowledgement message is sent to the ship when one or more authorities have processed a request
and made a decision. An example transaction pattern is shown in Figure 5.
6 © ISO 2012 – All rights reserved

SW Auth. 1 Auth. 2
Ship
Clearance Request 0
Receipt
Acknowledgement 0
Acknowledgement 0
Figure 5 — Normal approval/denial sequence
If the SW allows multiple updates to a request and these updates result in retransmission of certain
approval/denial (acknowledgement) messages, the ship must keep track of acknowledgement messages so
that an accurate at-the-moment status can be maintained. The SW is not required to forward
acknowledgement messages for requests that have already been updated or cancelled.
This Publicly Available Specification allows for the SW to buffer and merge acknowledgements from two or
more authorities and send only one acknowledgement message to the ship. In this case, the initial receipt
shall specifiy one authority (the SW itself) as place holder for merged acknowledgements.
5.2 Multiple copy-to parties
This Publicly Available Specification allows for the SW to send copies of receipts and acknowledgements to
multiple parties. If multiple copy-to parties are allowed and used they must be listed in the initial request
message. However, this Publicly Available Specification does not require the SW to permit multi copy-to
parties nor does it prohibit the SW from restricting the number of copy-to parties to a certain limit.
5.3 Support for other reporting requirements
This Publicly Available Specification allows the SW to accept messages for other purposes, such as advance
notice of arrival, passing national baseline, entering VTS or ship reporting areas etc. The request message
format has provisions to allow such reporting and can be used for this purpose. However, the SW is not
required to implement this functionality.
5.4 Support for alternative data sources
This Publicly Available Specification allows the SW to use previous requests, other databases and sources to
populate request applications. This could be done to save ship and agent resources to submit full requests,
e.g. for a scheduled shipping operation.
5.5 Support for alternative information transfer mechanisms
This Publicly Available Specification does not prohibit a SW from using other message formats or information
transfer mechanisms than those specified in this Publicly Available Specification. This may be to support local
regulations or to make use of other international standards, e.g. trade related.
If possible, the SW implementation should attempt to integrate such messages into the clearance process by
making use of the information contained in these messages where appropriate.The procedure for integrating
such messages is not specified in this Publicly Available Specification.
NOTE This clause allows, e.g. a mix of UN/EDIFACT or other ISO messages and messages from this Publicly
Available Specification to be used by one and the same SW.
5.6 Electronic communication interface requirements
5.6.1 Ship interface
The ship interface shall, at a minimum, support the “mailto” URI scheme for incoming messages.
5.6.2 SW interface
The SW interface shall, at a minimum, support a synchronous (“mailto”) and synchronous (“http”) URI
schemes for incoming messages.
The SW shall, as a minimum, support “mailto” and “http” URI schemes for outgoing messages to ship.
5.7 Operational security
As the single window will be used for transactions that can have commercial as well legal importance, it needs
to address the issue of information security. Security normally involves some or all of the following concepts
[SWG]:
 Confidentiality: Assurance that information is not disclosed to unauthorized individuals or systems.
 Integrity: Assurance that the received (or sent) information is correct and logically consistent.
 Authentication: Assurance that the identity of the sender (or receiver) is the one specified.
 Authorization: Assurance that the sender or receiver has the authority to provide or receive the
information.
 Availability: Assurance that the system is available when needed.
 Non-repudiation: Assurance that the sender or receiver of information cannot deny that the information
was sent or received.
 Message Transmission: Assurance that messages through the single window are traceable and that
some concept of guaranteed delivery is applied.
Necessary emphasis needs to be put on implementing technical features that address the relevant security
issues.
6 Message requirements
6.1 Example of message descriptions
Messages and associated data types are described in a table as exemplified below.
Table 1 — Message: ExempleMessage
Tag Type Card. Description
EPCMessageHeaderType epc:EPCMessageHeaderType1.1 Message header
ExampleBody ExampleBodyType 1.1 Body of message

Table 2 — Data Type: ExampleBodyType
Tag Type Card. Description
PassengerList epc:PassengerListType 0.1 Passenger list, if needed
CrewList epc:CrewListType 0.1 Crew list
8 © ISO 2012 – All rights reserved

Messages and data types are descibed in the same table type. Messages consisting of nested data types will
require the definition of each of the data types as well as the message itself in separate tables.
In this example, a new message “ExampleMessage” is defined that consists of two mandatory data types: The
header and the body of the message. Cardinality (Card.) shows how many times the element can be
repreated where 0.1 means optional, up to one time; 1.1 mean exactly once; and 1.n means any number
from at least one time to infinite. The Type column defines the data type. The type codes prefixed by “epc:”
are defined in ISO 28005-2. Those without the prefix are defined in this Publicly Available Specification, either
in the same clause or in 6.3 for data types used in more than one message.
Most elements in the body of a message are optional and have cardinality from zero and up. This allows
different sub-types of messages to be assembled from one and the same schema.
The description column gives a brief description of the element. If necessary, a more extensive description is
given in the text of the clause.
6.2 XML Schema to be used
To ensure ships can interact with all SW systems that have adopted this Publicly Available Specification, the
following XML Schema shall be used.
6.2.1 File header and end
The file needs a header with the following structure:

xmlns:epc="http://www.iso.org/28005-2"
targetNamespace="http://www.iso.org/28005-2">



This defines name space and includes definitions from ISO 28005-2.
After the content described below, the file is terminated by a single end of schema statement:

6.2.2 New data type definitions
This Publicly Available Specification defines some new data types in addiiton to those defined in ISO 28005-2.
These need to be included in the schema file. The data type in question is EPCClearanceStatusType
which is defined in 7.3.
6.2.3 Data block definitions
The data blocks EPCRequestBody, EPCCancelBody, EPCReceiptBody and EPCAcknowledgeBody must
be defined. Each table line entry will be mapped to an XSD element definition as shown below.


minOccurs="0" maxOccurs="unbounded"/>
...
minOccurs="0"/>

...


The structure is given directly from the information in the table where minOccur and maxOccur is used to
define cardinality where this is not exactly one.
6.2.4 Message definitions
The actual definition of the message format will be done by the XSD statements shown below. Note the use of
the choice structure to specify that exactly one of the message bodyies shall be included.





minOccurs="0"/>
minOccurs="0"/>
minOccurs="0"/>
minOccurs="0"/>





6.3 Structure of the EPC message
All EPC messages use the same XML Schema and can be parsed by the same general parser software.
However, the four basic types of messages: request, cancel, receipt and acknowledge, need to be processed
differently and these differences are described in the following subclauses. This subclause will define the
general structure of the EPC message as well as of the header.
Table 3 — Message: EPCMessage
Tag Type Card. Description
EPCMessageHeader epc:EPCMessageHeaderType 1.1 Uniform message header
EPCRequestBody EPCRequestBodyType 0.1 Request message body
EPCCancelBody EPCCancelBodyType 0.1 Cancel message body
EPCReceiptBody EPCReceiptBodyType 0.1 Receipt message body
EPCAcknowledgeBody EPCAcknowledgeBodyType 0.1 Acknowledgement message body
EPCComment epc:string 0.1 General comment to ship, port or
authority to be read by human
operator.
The message consists of two parts: the header and the body. The message body can be one of the four
optional types. The message shall contain exactly one message body. The header structure is defined in
ISO 28005-2, but with the following additional requirements:
1. JournalNumber: This is mandatory in this Publicly Available Specification. If the journal number is not
known, e.g. as in a first request, the data portion of the tag shall be empty (no data) or an empty string.

2. MessageType: For a port clearance request message, the message type shall be “FAL”. For other
service requests, various codes may be used, dependent on data content. The code “Receipt” is used
for an acknowledgement message and the code “ACK” is used for an acknowledgement message.
The new code “CANCEL” shall be used for a cancellation message (see 7.1).
10 © ISO 2012 – All rights reserved

3. ReportingSystem: Not used for the type of messages that are described in this Publicly Available
Specification and shall be ignored by ship and SW in this context. The code may be used for other
services, such as entering or leaving named ship reporting area or for advanced notifications.

4. Version: For this version of this Publicly Available Specification, the first code (M) shall be “1”. The
SW and the ship is required to accept all messages with this version code. Higher version code
messages may be rejected through a negative receipt. Other codes (N, P) may be used by ship or
SW to signal versions in internal software or for other purposes.

5. ReplyURI: This is the copy-to list of parties that shall get receipt or acknowledgement messages.
Minimum one party needs to be specified and a SW limited number of parties may be specified.
6.4 Structure of request data block
The request data block is descibed in Table 4. This is a general compilation of the information elements
defined in ISO 28005-2 and presented in the same order, except the first element which is the general service
request that can be used for non-clearance related requests, when the SW supports such. All elements are
optional, but with different cardinality. The ship is repsonsible for including those information elements that are
required for clearance.
Table 4 — Data type: EPCRequestBody
Tag Type Card. Description
OtherServiceRequest epc:OtherServiceRequestType 0.n Additional service request
Agent epc:Agent Type 0.1 The ship's agent
Company epc:CompanyType 0.1 The ship's operating company
InmarsatCallNumber epc:InmarsatCallNumberType 0.1 Inmarsat call number to ship
NameofMaster epc:NameType 0.1 Name of Master
RegistrationPort epc:RegistrationPortType 0.1 Port of Registration
ShipID epc:ShipIDType 0.1 Ship identity
CargoData epc:CargoDataType 0.1 Detailed description of cargo
CargoOverview epc:CargoOverviewType 0.1 Brief description of onboard cargo
CargoType epc:CargoTypeContentType 0.1 Type of cargo
DGSafetyDataSheet epc:DGSafetyDataSheetType 0.n Safety data related to dangerous goods
DutiableCrewEffect epc:DutiableCrewEffectType 0.1 List of crew effects that may be dutiable
GeneralDescriptionOfDG epc:GeneralDescriptionOfDGTyp 0.1 General description of dangerous cargo
e
ShipStore epc:ShipStoreType 0.1 Description of ship's dutiable stores
CrewList epc:CrewListType 0.1 Information about all crew on board
PassengerList epc:PassengerListType 0.1 Information about passengers
PersonsOnboard epc:PersonsOnboardType 0.1 Number of persons onboard
Certificate epc:CertificateType 0.n Certificate description
ShipClass epc:ShipClassType 0.1 Class Notation for Ship
INFClassContent epc:INFClassContentType 0.1 Irradiated Nuclear Fuel class
CurrentShipSecurityLevel epc:CurrentShipSecurityLevelTyp 0.1 Current security level in port
e
PortCalls epc:PortCallsType 0.1 Last ten port calls
Tag Type Card. Description
ShipToShipActivityList epc:ShipToShipActivityListType 0.1 Ship-to-ship activities
HasSecurityPlan epc:HasSecurityPlanType 0.1 Approved security plan
Beam epc:BeamType 0.1 Beam of vessel
DeadWeight epc:DeadWeightType 0.1 Dead weight
DoubleBottomContent epc:DoubleBottomContentType 0.1 Double bottom or sides indicator
GrossTonnage epc:GrossTonnageType 0.1 Gross tonnage
IceClass epc:IceClassType 0.1 Ship ice class
LengthOverall epc:LengthOverallType 0.1 Length overall
NetTonnage epc:NetTonnageType 0.1 Net tonnage
SummerDraught epc:SummerDraughtType 0.1 Summer draught
ShipTypeContent epc:ShipTypeContentType 0.1 Ship type code
AirDraught epc:AirDraughtType 0.1 Air draught
ArrivalDraught epc:ArrivalDraughtType 0.1 Arrival draught
ATA epc:ATAType 0.1 Actual time of arrival
ATD epc:ATDType 0.1 Actual time of departure
ATP epc:ATPType 0.1 Actual time of passage
BulkLoadUnloadData epc:BulkLoadUnloadDataType 0.1 Data required for safe loading and
unloading
CallPurpose epc:CallPurposeType 0.1 Purpose of call
DepartureDraught epc:DepartureDraughtType 0.1 Departure draught
EntryPosition epc:EntryPositionType 0.1 Time and position for entry to ship
reporting
ETA epc:ETAType 0.1 Estimated time of arrival
ETD epc:ETDType 0.1 Estimated time of departure
ETP epc:ETPType 0.1 Estimated time of passage
ExitPosition epc:ExitPositionType 0.1 Time and position for exit from ship
reporting
LastPortOfCall epc:LastPortOfCallType 0.1 Last port of call
Location epc:LocationType 0.1 Identification of a location
NavigationalStatusContent epc:NavigationalStatusContentsT 0.1 Navigational status
s ype
NextPortOfCall epc:NextPortOfCallType 0.1 Next port of call
NextReportTime epc:NextReportTimeType 0.1 Time of next report
OBOLoadUnloadData epc:OBOLoadUnloadDataType 0.1 Data required for safe loading and
unloadin
...