ISO 28005-1:2024 船舶と海洋技術 — 電子ポートクリアランス (EPC) — Part 1:メッセージ構造とアプリケーション プログラミング インターフェイス | ページ 6

3.1.1

HTTP

hypertext transfer protocol

client/server communication protocol used to transfer information in the World Wide Web

Note 1 to entry: HTTP is defined in RFC 2068^[4] as a generic and stateless application-level protocol for distributed and collaborative, information systems.

Note 2 to entry: In this document, the term HTTP is used to mean HTTP implemented over transport layer security (3.1.2) , i.e. HTTPS (3.1.3) , unless otherwise specified.

3.1.2

TLS

transport layer security

protocol for secure communication over the internet

Note 1 to entry: TLS is defined in RFC 5246 (Version 1.2) and RFC 8446 (Version 1.3).

3.1.3

HTTPS

hypertext transfer protocol secure

HTTP (3.1.1) over transport layer security (TLS) (3.1.2)

Note 1 to entry: HTTPS is an extension of HTTP used for secure communication and is defined in RFC 2818.^[6] It uses TLS to encrypt the communication.

Note 2 to entry: In this document, the term HTTP is used to mean HTTP implemented over TLS, i.e. HTTPS, unless otherwise specified.

3.1.4

PKI

public key infrastructure

set of hardware, software, people, policies and procedures needed to create, manage, distribute, use, store and revoke digital certificates and manage public-key encryption

[SOURCE:ISO 20415:2019, 3.14]

3.1.5

digital signature

data appended to, or cryptographic transformation of, a data unit that allows a recipient of the data unit to prove the source and integrity of the unit and protect against forgery by, for example, the recipient

[SOURCE:ISO 20415:2019, 3.5]

3.1.6

API

application programming interface

collection of communication methods and associated parameters used by a client (3.1.11) to exchange information with a server (3.1.12)

Note 1 to entry: In this document, the term API is used in the meaning of one specific arrow in the sequence diagram (see Figure 2). Thus, a session will normally require the use of several APIs. This document describes one general API access point (3.1.17) that can be used by all APIs by changing the number of message components as well as the contents of one or more message parts.

3.1.7

API access point

application programming interface access point

collection of a specific communication method, one or more general message parts, and related semantics for formatting the message parts that can be used to realize application programming interfaces (APIs) (3.1.6)

3.1.8

authorization

granting a sender (3.1.9) the right to use one or more application programming interface access points (3.1.7)

3.1.9

sender

party that initiates a session (3.1.18) by sending a request (3.1.15) to a receiver

[SOURCE:IMO FAL.5/Circ.46:2022, modified — the definition has been shortened.]

3.1.10

receiver

party that receives a request (3.1.15) from a sender (3.1.9) , executes a service (3.1.14) , and returns a status message

[SOURCE:IMO FAL.5/Circ.46:2022, modified — the definition has been shortened.]

3.1.11

client

unit that sends a message to a server (3.1.12) and expects a response

Note 1 to entry: The sender and receiver can be both a server and a client.

3.1.12

server

unit that listens for incoming messages from one or more clients (3.1.11) and responds to them

Note 1 to entry: The sender and receiver can be both a server and a client.

3.1.13

message

information payload of an HTTP (3.1.1) request or response between the sender (3.1.9) and receiver (3.1.10)

Note 1 to entry: Examples of messages are request (3.1.15) , message status (3.1.16) and service request status (3.1.17) .

Note 2 to entry: When the full HTTP request or response itself is referred to, the term HTTP message will be used.

3.1.14

service

result of a process performed by a receiver (3.1.10) after a request (3.1.15) has been delivered by a sender (3.1.9)

Note 1 to entry: In this document, service is a general term and includes that the receiver unconditionally accepts an incoming report without doing any processing of the content of the report.

3.1.15

request

message sent by a sender (3.1.9) to request a service (3.1.14)

[SOURCE:IMO FAL.5/Circ.46:2022, modified — the definition has been shortened.]

3.1.16

message status

message (3.1.13) sent from a server (3.1.12) to a client (3.1.11) to inform about the status of a received message

Note 1 to entry: A message status can be combined with a service request status (3.1.17) in one message.

Note 2 to entry: A message status will normally only consist of a message header. If the message status is combined with a service request status, the message can also contain other message parts.

3.1.17

service request status

message (3.1.13) sent from a receiver (3.1.10) to a sender (3.1.9) to inform about the status of a service (3.1.14)

Note 1 to entry: A service request status can be combined with a message status (3.1.16) in one message.

3.1.18

session

sequence of messages (3.1.13) that is related to one and the same initial request (3.1.15)

[SOURCE:IMO FAL.5/Circ.46:2022]

3.1.19

session context

one or more sessions (3.1.18) related to the same overarching operation or event

Note 1 to entry: Session contexts can be nested. As an example, several berth calls can be individual session contexts nested inside a port call session context, which may also be nested inside an entry into national waters session context.

3.1.20

HTTP session

hypertext transfer protocol session

message (3.1.13) exchanges that take place between establishment of an HTTP (3.1.1) connection and its closing

Note 1 to entry: One HTTP session can include sending more than one request (3.1.15) .

3.1.21

MIG

message implementation guide

specific requirements to message (3.1.13) exchanges in conjunction with one or more concrete services (3.1.14)

3.1.22

EPC

electronic port clearance

services (3.1.14) a ship may request before, during, or after a port call

Note 1 to entry: EPC is used as a general term for all services a ship may request before, during, or after a port call. It is not limited to maritime single windows and other authority operated systems.

3.1.23

GLN

global location number

13-digit decimal number uniquely identifying a geographic position

Note 1 to entry: The list of registered numbers is maintained by GS1.^[17]

3.1.24

UN/LOCODE

United Nations code for trade and transport locations

two or three letter code identifying a country and a trade location within it

Note 1 to entry: The countries have a two-letter code as listed in ISO 3166-1. The locations in the respective countries have a three-letter code as maintained by UNECE.^[15]

3.1.25

MMSI

maritime mobile service identity

nine-digit decimal number uniquely identifying radiocommunication equipment

Note 1 to entry: MMSI is normally assigned by the national telecommunication authorities.

3.1.26

US-ASCII

7-bit character encoding defined in ISO/IEC 646

3.1.27

X.509

digital signature public certificate as defined in RFC 2459^[33]