3.2

MIME Format Message

For MIME format message, there is EDIFACT message and Attachment file transmission message.
Each format and message structure are shown as follows.

3.2.1

EDIFACT message

3.2.1.1

Message format for EDIFACT messages

The following shows the message format for EDIFACT messages.

3.2.1.1.1

Messages used

NACCS uses the following messages. Note that PAXLST cannot be sent from lines other than those
provided by aeronautical communication contractors.
(1)UN/EDIFACTCUSRES (Customs response message)
CUSREP (Customs conveyance report message)
CUSCAR (Customs cargo report message)
PAXLST (Passenger list message)
CODECO (Container gate-in/gate-out report message)
IFTMIN (Instruction message)
IFTMBC (Booking confirmation message)
APERAK (Application error and acknowledgment message)
GENRAL (General purpose message)
CONTRL (Syntax and service report message)(2)US/EDIFACTPAXLST (Passenger list message)(3)PADIS EDIFACTPNRGOV (Passenger Name Record information to government)

3-2-1

3.2.1.1.2

Syntax rules

Syntax rules for EDIFACT messages used at NACCS should be ISO 9735 Third edition (version
3.0).
Note that for messages using PAXLST, syntax rules for UN/EDIFACT should be ISO 9735 Fourth
edition (version 4.0), and for syntax rules for US/EDIFACT, should be ISO 9735 First edition (version
1.0). However, when processing messages at NACCS mail server, process messages according tosyntax rules specified in ISO 9735 Third edition (version 3.0).
For messages using PNRGOV, syntax rules for PADIS EDIFACT should be ISO 9735 Fourth edition(version 4.0).

3.2.1.1.3

Message version

Message version for EDIFACT messages used at NACCS should be the following (1) and (2) which
are approved by D.98B and DMR (*). However, below message are not included.
For CONTRL messages, message version 2.0 should be used.
Message
ITFMBC

Version
D.99B

CUSCAR

D.17A

PAXLISTPNRGOV

D.02B
11.1

Remarks
Which is only used for “Advance Cargo
Information Registration (ADM01)” procedureand “Advance Cargo Information (House
Manifest) Registration (HDM01)” procedure*The following shows details where DMR was submitted from NACCS Center to United Nations andapproved.
(1) This was approved at Brussels JRT meeting held at October, 1998.
(These are incorporated in version D.99A.) CUSREP• Addition of segments to Segment Group 4
FII (conditional 1)
LOC (conditional 1)
RFF (conditional 1)
DTM (conditional 9)• Addition of segments to Segment Group 9
STS (conditional 9)(2) This was approved at Brussels JRT meeting held at October, 1998.
(These are incorporated in version D.99B.)
 CUSREP• Increase of the number of repeat of NAD segments in Segment Group 9.
9 times → 99 times

3-2-2

* DMR is abbreviation of "Data Maintenance Request". This refers to requesting of maintenanceof data directory of EDIFACT to United Nations.

3-2-3

3.2.1.1.4

Message structure

For structures of each EDIFACT message used at NACCS, refer to "Appendix 14.2.2 Message
Structure" in Appendix 14.2 EDIFACT Mapping Rules.
(Note 1) "++++" is attached before segments indicated in 3.2.1.1.3 (1) and (2).

3.2.1.1.5

Available character set

The character set which can be used in EDIFACT messages should be the Level A Character Set
plus the 2 characters "@" and "#".
However, the above rule does not apply for some of the procedures, and details are shown in
Mapping Table for Each Procedure as special notes.
Besides, note that the character set to be used in EDIFACT messages transmitted via lines which
are provided by aeronautical communication contractors should be Level A Character Set.
Table 3.2.1 and Table 3.2.2 show Level A Character Set.
Table 3.2.1
TypeCharacter (capitalletter)Numeric character
Space
PeriodComma
Hyphen/minus sign
Left parenthesis
Right parenthesis
Slash
Equal sign
Exclamation markQuotation mark
Percentage
AmpersandAsterisk
Semicolon
Inequality sign (lessthan)Inequality sign
(greater-than)Level A Character Set

Availablecharacter
A-Z

Remarks

0-9.

In NACCS, a period is uniformly used to indicate adecimal point.

,
(
)
/
=
!
"
%
&
*
;
<
>

3-2-4

Type

Available
Remarks
character
The following character set is Level A Character Set. This is used for special purposes, sowhen using this in data elements, make sure to assign a release character (?) right before
this.
Apostrophe'
Segment ending sign
Plus sign+
Data element separator
Colon:
Component data element separator
Question mark?
Release character

Table 3.2.2

Range of Level A Character Set
0

0

0

0

1

1

1

1

0

0

1

1

0

0

1

1

0

1

0

1

0

1

0

1

0

1

2

3

4

5

6

7

Column

Bits

b7 b6

b5 b4 b3 b2 b1

row

0

0

0

0

0

SP

0

@

P

0

0

0

1

1

!

1

A

Q

0

0

1

0

2

"

2

B

R

0

0

1

1

3

#

3

C

S

0

1

0

0

4

4

D

T

0

1

0

1

5

%

5

E

U

0

1

1

0

6

&

6

F

V

0

1

1

1

7

'

7

G

W

1

0

0

0

8

(

8

H

X

1

0

0

1

9

)

9

I

Y

1

0

1

0

A

*

:

J

Z

1

0

1

1

B

+

;

K

1

1

0

0

C

,

<

L

1

1

0

1

D

-

=

M

1

1

1

0

E

.

>

N

1

1

1

1

F

/

?

O

(Note 1)

(Note 1) SP denotes a space.

3-2-5

3.2.1.2

EDIFACT message structure

When using EDIFACT messages, e-mail style processing mode (gateway computers) should be usedas the data transmission/receipt mode. In this case, a communications protocol header and a trailer
are added to an EDIFACT message.
Figure 3.2.1 shows message structure.

Communications protocol
Trailer

EDIFACT message(MIME)HeaderSent to NACCS
Center (processing
request message)

Communications protocol

Trailer

EDIFACT message(MIME)HeaderFigure 3.2.1 EDIFACT message

3-2-6

Received from
NACCS Center(processing result
message)3.2.1.2.1

Input (output) common fields

The following shows input (output) common fields of procedure messages for EDIFACT messages.
In addition, for the filing method for EDIFACT messages, details are shown in Mapping Table for
Each Procedure.

(1) Common field for input screen (processing request message)
Table 3.2.3 shows input common fields for EDIFACT.
Table 3.2.3
Item
Field nameNo.
1
Procedure Code2

User code

3

Identifying
Numbers
User Password

4
5

Message Tag(Note)

6

Input Message
ID(Note)

7

Index Tag
(Note)

Input Common Fields

LengthOutlineSample settings, etc.

Max
5
Fixed
5
Fixed
3
Max
8
Max
26

Set a procedure code for
identifying the procedure.
Set a user code, Identifying
Number and password for
identifying the user.

VBX (General Vessel Information
Registration)
1AABC
001
********

Set information for matching aprocessing request message
with a processing result
message.
(See 3.5.2)
Max This value will be output in a
10 processing result message.
(See 3.5.1)

Assign a unique value.

Max Used in the inquiry procedure,
64 etc. when inquiry results, etc.
do not fit in a single
processing result message, or
when inquiring consecutive
information (continued
processing), or when callingother specified information in
the cargo information inquiry
procedure (ICG).
(See 3.5.3)(When sequential processing is
implemented, set a value as
specified in Index Tag of theprocessing result message thathas arrived)

Assigns an arbitrary value.

(Note) See "3.5 Message control elements" for details on Message Tag, Input Message ID and
Index Tag.

3-2-7

(2) Output common fields (processing result messages)
Table 3.2.4 shows Output common fields for EDIFACT
Table 3.2.4
Item
Field nameNo.
1
Procedure Code

OutputInformation code

3

User code

4

Message Tag

5

Division
Sequence
Number6

7

Message Control Information

2

Termination

9

Message
Type(Reserved
area)
Input Message ID

10

Index Tag

8

Length

Output Common Fields
OutlineMax Indicates a procedure code
5 (Note 2)
Max The code of an output message.
7 Advisable to use this code for
sorting messages.
Fixed The code of the user who
5 received the relevant message
Max Used to identify a series of
26 processing result messages
responding to a processing
request message.
(See 3.5.2)
Fixed Used to identify a series of
3 processing result messages
responding to a processing
request message.
Fixed Used to identify a series of
1 processing result messages
responding to a processing
request message.
Fixed 1 To indicate a message class.
(See 3.4)
Max 3 (Note 1)

Sample settings, etc.
ACL01 (Application for
Checking of Loading (forcontainer vessel))
SAT1401

1AABC(Data set in the processing
request message sent by theuser is reflected as it is)

000 - 001

'E' is supplied at the end of themessage.
Otherwise, enter a space.
'R' is supplied for a processing
result message.

Max 10 Outputs all settings of the(Settings of a processing
processing request message.
request massage)
For EXC type messages, spaces
are filled (See 3.5.1)
Max 64 Set when inquiry results do not
fit in a single processing result
message (subsequent
processing to follow)(See 3.5.3)(Subsequent information)(Note 1) The reserved areas are used to control the system.
(Note 2) The Procedure Code set in the output common fields may not necessarily match that in
another input common fields. There are some occasions where a procedure code
different from that in the processing request message is specified in the output common
fields. Advisable to use output message codes for sorting messages.

3-2-8

3.2.1.2.2

Transmission unit for messages

3.2.1.2.2.1

Transmission unit for one exchange

In NACCS, UNA should not be used as a header for one exchange of EDIFACT messages. In
addition, one to multiple EDIFACT messages can be stored for one exchange (UNB - UNZ).
However, in "Passenger Manifest Report (PLR01)" procedure and "Surname/Given Name
Report (NLR01)" procedure, UNA can be used.

3.2.1.2.2.2

Transmission unit for single-message and multiple-message

Single-message refers to a message where 1 EDIFACT message (UNH - UNT) is stored in one
exchange (UNB - UNZ). Multiple-message refers to multiple EDIFACT messages are stored in
one exchange.
However, when using multiple messages, due to the limit in processing capacity of the
NACCS Center server, the maximum number of EDIFACT messages to be stored by one
exchange should be 99.
However, in "Passenger Manifest Report (PLR01)" procedure, "Surname/Given Name Report(NLRO1)" procedure, and "Passenger Reservation Record Report (PNR01)" procedure,“Advance Cargo Information Registration (ADM01)” procedure and “Advance Cargo
Information (House Manifest) Registration (HDM01)” procedure, only single-messages
should be used.

3.2.1.2.2.3

Transmission unit for single B/L message and multiple B/L message

A single B/L message refers to a message where 1 unit of B/L information and container
information relating to the B/L are stored in 1 CUSCAR message which is used in the"Manifest Information Registration (MFR)" procedure and "Manifest Information Correction(before submission of Cargo Manifest) (CMF01)" procedure. Multiple B/L message refers to amessage where multiple units of B/L information and container information are stored in asimilar CUSCAR message.
However, due to the limit in processing capacity of the NACCS Center server, only singlemessages should be used to send multiple B/L messages.

3-2-93.2.1.2.3

Message format

3.2.1.2.3.1

Processing request message(1) UN/US EDIFACT format
In the message structure of UN/US EDIFACT messages for processing request messages,
multiple function groups or multiple messages can be stored in 1 procedure message.
In addition, for multiple B/L messages, multiple B/Ls and containers can be stored.
However, the maximum length per procedure message is 10MB (10,000,000 bytes) for themultiple B/L message.
When multiple function groups or messages are included in 1 procedure message, and when
multiple B/Ls or containers are included in 1 multiple B/L message, those will be decomposed
into multiple NACCS EDI messages by the mail server.
For transmission/receipt of EDIFACT messages, e-mail style processing mode (gateway
computer) is used and a communications protocol header and a trailer are added.
Figure 3.2.2.1 shows the message structure of EDIFACT messages for processing request
messages.

UNB’

Communications
Protocol Header

1 Procedure
MessageCommunications
protocol trailer

Function Group(CUSCAR)

Function Group(PAXLST)

Function Group(CUSREP)

UNZ

UNG

’

Message(CUSCAR)

Message(CUSCAR)

Message(CUSCAR)

UNE

UNH

’

Segment
PCI*

Segment
NAD

Segment
LOC

UNT

TAG +

Single data element(4233)

Data value

24*PCI: Package Identification Segment+’

Complex data element(C210)

Component data
element(7102):

Component data
element(7102)

Data value

Data value

APPLE
USA
(Note) Function group header (UNG) and function group trailer (UNE) may not be used.
Figure 3.2.2.1

Message Structure of Processing Request Message* Message example: When multiple messages of CUSCAR, PAXLST, and CUSREP are stored in 1
message
CUSCAR
UNB

UNG

UNH .. UNT× a times

PAXLST
UNE

UNG

UNH .. UNT× b times

Communications protocol header

CUSREP
UNE

UNG

UNH .. UNT

UNE

UNZ

× c times

Communications protocol trailer

3-2-10(2) PADIS EDIFACT format
In message structure of PADIS EDIFACT messages for processing request messages, single
function group can be stored in 1 procedure message.
In addition, PADIS EDIFACT messages can use only the single-message.
However, the maximum length per procedure message is 10MB (10,000,000 bytes).
For transmission/receipt of PADIS EDIFACT messages, e-mail style processing mode (gateway
computer) is used and a communications protocol header and a trailer are added.
Figure 3.2.2.2 shows the message structure of PADIS EDIFACT messages for processing
request messages.

UNB

UNH

TAG

’

+

Communications

Procedure

Communications

Protocol Header

message

protocol trailer

’

…

…

Function group (PNRGOV)

Segment

Segment

Segment

ORG*

ADD

TIF

+

Single data element+

Figure 3.2.2.2

Data

Component datavalue

element

element

A(3207)(6345)

Data

Data

value

value

JP

JPY

:

’

Component data

Message Structure of Processing Request Message

Message example: When 1 PNRGOV is stored in 1 message
PNRGOVUNZ

× 1 time

Communications protocol header

UNT(C354)* ORG:ORIGINATOR OF REQUEST DETAILS
segment…

Complex data element(9972)UNB UNH … UNT

UNZCommunications protocol trailer

3-2-11

3.2.1.2.3.2

Processing result message

Processing is carried out by each message, B/L, or container, and a processing result
notification massage and an output message are output by each message, B/L, or container.
In other words, in message structure for processing result messages, 1 message is stored in 1
procedure message.
For transmission/receipt of EDIFACT messages, e-mail style processing mode (gateway
computer) is used and a communications protocol header and a trailer are added to amessage.
Figure 3.2.3 shows the message structure of EDIFACT messages for processing result
messages.
Note that processing result messages are returned only to processing request messages with
UN/US EDIFACT format. Processing result messages are not returned to processing request
messages with PADIS EDIFACT format.
Communications
Protocol Header

UNB’

1 Procedure

Communications

Message

protocol trailer

1 message

UNZ(CUSRES)
UNH

TAG

’

Segment

Segment

Segment

NAD*

GIS

MEA

Single data

+

+

’

Complex data

element

element(3035)(C058)

Data

Component datavalue

element

element

CA(3124)(3124)

Data

Data

value

value

AAA

TOKYO

*NAD:Name And Address segment:

UNT

Component data

CORP.
Figure 3.2.3 Message Structure of Processing Result Message* Message example: When 1 CUSRES is stored in 1 message
CUSRESUNB UNH  UNT

UNZ

× 1 time

Communications protocol header

Communications protocol trailer

3-2-12

(Term description)
UNB: Exchange header. (mandatory)
A EDIFACT message must start with this segment.

UNG: Function group header. (can be omitted)
When storing multiple telegraphic segments within one message,group messagesby similar segments.

UNH: Message header. (mandatory)
1 message within a message must start with this segment.

UNT: Message trailer. (mandatory)
1 message must end with this segment.
UNE: Function group trailer. (can be omitted)
1 function must end with this segment.

UNZ: Exchange trailer. (mandatory)
A message must end with this segment.

3-2-133.2.1.2.4

Message processing mode

3.2.1.2.4.1

Processing mode for single-message

Figure 3.2.4 shows process image when one EDIFACT message is stored (single-massage) in
one EDIFACT message.

NACCS Center server
User system

User sends one EDIFACT message
by one transmission as one
EDIFACT message.

Mail server

Core processing system

In the EDIFACT conversion process,an EDIFACT message sent from user
is converted into a NACCS EDI
message and forwarded to the core
processing system.

In the core processing system, process
is carried out by each message
forwarded from the mail server.

UNB
UNH

1
EDIFACTmessage

SMTP(MIME)CUSREPAprocedure

NACCS EDI
Message

Conversion
process

Procedure data
Procedure A

UNT
UNZ

Transaction
UNH

UNB

1
EDIFACTmessage

CUSRES(processing
result)Procedure A

UNT

UNZ

POP3
(MIME)

User receives a processing result
message for one EDIFACT message.

Conversion
process

In EDIFACT conversion process, a
NACCS EDI message forwarded
from the core processing system isconverted into a EDIFACT message(MIME format).

NACCS EDI
Message

The core processing system outputs a
processing result by each unit where
the procedure is carried out (by eachmessage).

Figure 3.2.4 Image of Single-Message Processing

3-2-14

Processing
resultProcedure A

3.2.1.2.4.2

Processing mode for multiple-message

Figure 3.2.5 shows outline of image of processing mode when multiple-message is used.

NACCS Center server
User system

User sends multiple EDIFACT
message by one transmission as one
EDIFACT message.
(Note) The maximum number ofmessages which can be sent in
one exchange is 99.

Mail server

Core processing system

In EDIFACT conversion process, a
EDIFACT message sent from user isconverted into a NACCS EDI
message and the message is divided
into processing unit of the core
processing system (by eachmessage).

In the core processing system, process
is carried out by each message divided
by the mail server.

UNB
CUSREP
Procedure A

UNH
1 EDIFACT
message

SMTP(MIME)CUSREP
Procedure B

UNT

Conversion
process

PAXLST
Procedure D

Procedure
data
Procedure A
Procedure
data
Procedure B

NACCS EDI
Message

Process todividemessage

Procedure
data
Procedure CProcedure

CUSCAR
Procedure D

data
Procedure D

UNZTransaction
UNH
1 EDIFACT
message

UNT

UNB
CUSRES(Processing
result)
UNB
Procedure A

メール
UNZ
CUSRES
Procedure B
UNB

Processing
resultProcedure A

POP3(MIME)UNZ
CUSRES
メール
Procedure C
UNB

NACCS EDI
Message

Processing
resultProcedure B
Processing
resultProcedure C

Conversion
process

Processing
resultProcedure D

UNZ

CUSRES
Procedure D

UNZ
User receives a processing result
message for each EDIFACT message.

In EDIFACT conversion process, a
NACCS EDI message forwarded
from the core processing system isconverted into a EDIFACT message(MIME format).

The core processing system outputs a
processing result by each unit where
the procedure is carried out (by eachmessage).

Figure 3.2.5 Image of Multiple-Message Processing

3-2-15

3.2.1.2.4.3

Processing Mode for Multiple B/L Message

Figure 3.2.6 shows image of processing mode when multiple B/L is used. The Number of B/L thatcan be registered in one message of multiple B/L Messages is up to max 2000 times. The error
occurs when the message is registered in the number of B/L more than 2000 times

NACCS Center server
User system
Mail server
User can stores (to total 2000 times)
multiple container information (Number
Unit) and B/L information(B/L Number
Unit) in one CUSCAR message and cansend that message to the NACCS Center
server.
(Note) Only single-messages should be
used to send multiple B/Lmessages.
UNH

UNB

Commoninformation

Max
2000
times

In EDIFACT conversion process,an EDIFACT message sent fromuser is converted into a NACCS
EDI message and the message isdivided into the processing unit of
the core processing system (byeach B/L and each container).

Conversion
process

CNT2

In the core processing system, theprocess is carried out by eachmessage divided by the mail server(by each B/L and each container).

NACCSEDI
message

SMTP(MIME)CUSCAR

CNT1

Core processing system

Process todividemessageCommo ninformation
Commo nCNT1 information
Commo nCNT2 informationCommon
CNT3 information

Commo nB/L1 information

UNZ

CNT3

B/L2

B/L1
B/L2

UNT

Transaction
UNB
UNH
1 EDIFACT
messag e

UNT

CUSRES
メールresult)(processing
CNT1
UNB(1 container unit)

POP3(MIME)CUSRES
UNZ
メール(processing result)
UNB
CNT2(1 container unit)

NACCSEDI
message

Conversion
processCUS RE S
メール
UNZ(processing
result)UNB
CNT3(1 container unit)

Processing
result
CNT1 Processing
resultCNT2
Processing
result
CNT3
Processing
result
B/L1
Processing
result
B/L2

CUS RE S

メール
UNZ（処理 結果）UNB
B/L1(1 B/L unit)

CUS
RE S
メール
UNZ
(processing result)
B/L2(1 B/L unit)
UNZ

User receives one B/L unit and one
container unit of EDIFACT message as
the processing result message.

In EDIFACT conversion process, a
NACCS EDI message forwarded
from the core processing system isconverted into an EDIFACT
message (MIME format).

The core processing system outputs
a process result message by each B/
L and container.

Figure 3.2.6 Image of Multiple B/L Processing

3-2-16

3.2.1.3

Receipt confirmation for EDIFACT message

3.2.1.3.1

Timing of receipt confirmation

The following 3 measures can be considered as measures to confirm that an EDIFACT sent by user
is received by the NACCS Center server.
(1) Send a receipt confirmation at the time when the mail server on the Center side receives themessage.
(2) Send a receipt confirmation to the user at the time when conversion from an EDIFACT
message to a NACCS EDI message is completed in the mail server on the Center side.
(3) Send a receipt confirmation to the user at the time when the core processing system of the
NACCS Center server completes the procedure.
In (1), the fact where the EDIFACT message is recorded at the mail server will be demonstrated.
However, when an error occurs in subsequent message exchanges, a receipt error message will besent to the user during the (2) time.
In (3), "processing result notification" will be sent to the user as a result of the procedure process, so
it is pointless to send a receipt confirmation to the user at this time.
Therefore, the time to send a receipt confirmation for the EDIFACT message (Note) should be whenconversion to a NACCS EDI message described in (2) is completed.
(Note) In this case, the time to send a receipt confirmation does not have a meaning used for laws
and regulations.

3.2.1.3.2

Measure for receipt confirmation

CONTRL message is used as a measure to confirm receipt of a EDIFACT message sent from user.
User chooses whether receipt confirmation function is used. A CONTRL message will be returned asreceipt confirmation when user specifies "1" in the "receipt confirmation request classification"column of UNB segment of the EDIFACT message (processing request message).
In addition, a CONTRL message is used not only for receipt confirmation but also for notification
when syntax errors occur in an EDIFACT message (processing request message) sent by user
(CONTRL message used for error notification is output to user even when "1" is note specified in the"receipt confirmation request classification" column).
However, in "Passenger Manifest Report (PLR01)" procedure, "Surname/Given Name Report(NLR01)" procedure, and "Passenger Reservation Record Report (PNR01)" procedure, “Advance
Cargo Information Registration (ADM01)” procedure and “Advance Cargo Information (House
Manifest) Registration (HDM01)” procedure, reply sent from NACCS using response message(CONTRL, etc.) is not performed.
(Refer to "Appendix 14.2.4 Error Handling for EDIFACT messages")

3.2.1.3.3

Notification of receipt confirmation

CONTRL messages are stored in the user's mailbox for incoming messages within the mail server.
Therefore, receipt confirmation is carried out by retrieving messages from the user's mailbox forincoming messages within the mail server.

3-2-17

3.2.2

Attachment file message

3.2.2.1

Message format for attachment file message

Message format for attachment files used in NACCS is MIME format message. Encode format is
Base64.

3.2.2.2

Message structure of attachment fileFigure 3.2.7 and Figure 3.2.8 show message structures for attachment files procedure.

Communications protocol
Trailer

Attachment file transmission
message (MIME)HeaderSent to NACCS
Center (processing
request message)

Communications protocol

Header

Attachment file transmission
message (MIME)

Trailer

Received from
NACCS Center(processing result
message)

Figure 3.2.7 Attachment File Transmission Message

Protocol header/trailer
System header /procedure data
MIME
Headercontent
Fieldboundary content
field

NACCS
boundary content
messagefield

Attachment
file
Data 1boundary…

content
field

Figure 3.2.8 Attachment File Transmission Message (MIME format)

3-2-18

Attachment boundary
file
Data n3.2.2.3

Implemented mode

Data transmission processing mode for transmission of attachment files are all processing mode
(interactive processing mode (interactive), interactive processing mode (netNACCS), interactive
processing mode (SMTP two-way), interactive processing mode (ebMS), WebNACCS processing
mode (Web browser), and e-mail style processing mode (gateway computer)).
When sending attachment files, multiple attachment files can be sent at once as long as those do not
exceed the maximum message length for attachment file (10,000,000 bytes). Transmission of a fileshould not be carried out when the file exceeds the maximum message length by one file. User
should transmit a message after dividing the message into multiple procedures so that it does notexceed the maximum message length.
The maximum message length which can be transmitted varies depending on procedures, so refer tothe "Procedure Specifications".

Figure 3.2.9 shows illustrated image of divided transmission of attachment files.

(When this is transmitted in one message, the maximum message length will be exceeded)
MIME
NACCS
Header, etc. message

Attachment
file
Data 1

Attachment Attachment Attachment Attachment
file
file
file
file
Data 2
Data 3
Data 4
Data 5→ When 5 files are attached, the maximum message length will be exceeded.
Divide the attachment files so that one message does not exceed the
maximum message length, and transmit it in multiple messages. (In theexample, 5 files are divided into 3 files and 2 files)(Message 1  3 files are attached, which enables it to be kept within the maximum
message length.
MIME
Header, etc.

NACCS
message

Attachment
file
Data 1

Attachment
file
Data 2

Attachment
file
Data 3(Message 2  2 files are attached, which enables it to remain within the maximum
message length.
MIME
Header, etc.

NACCS
message

Attachment
file
Data 1

Attachment
file
Data 2

Figure 3.2.9 Illustrated Image of Divided Transmission of Attachment File

3-2-193.2.2.4 Processing sequence
3.2.2.4.1 Interactive processing mode
Figure 3.2.10 shows processing sequence for attachment files in interactive processing mode
(software package), and Figure 3.2.11 shows the processing sequence for interactive processing
mode (SMTP two-way).

(1) Processing request message(attachment file procedure)(1) Attachment files are stored.
Staff terminal at relevant ministries(2) Processing result message(3) Attachment files are
obtained.

Software package

Customs system

User system

Customs terminal

Customs system
Staff terminal at relevant ministries

NACCS Center server

Figure 3.2.10 Attachment File Processing sequence in Interactive Processing Mode (Software
Package)(1) SMTP(attachment file procedure)(1) Attachment files are stored.
Staff terminal at relevant
ministries(3) Attachment files
are obtained.

(2) SMTP
SMTP user server

Customs system

User system

NACCS Center server

Customs terminal

Customs system
Staff terminal at relevant ministries

Figure 3.2.11 Attachment File Processing Sequence in Interactive Processing Mode (SMTP Two-Way)(1) User sends a procedure message with attachment files to the NACCS Center server throughthe procedure dedicated to attachment files.
The NACCS Center server issues an acquisition key for attachment files and stores transaction
output messages with attachment files and the acquisition key for attachment files.
(2) User receives a processing result message from the NACCS Center server.
(3) Staff terminal at other relevant ministers or customs system retrieves stored messages.

3-2-203.2.2.4.2 WebNACCS processing mode
Figure 3.2.12 shows processing sequence for attachment files in WebNACCS processing mode
(web browser).

(1) HTTPS(attachment file procedure)(1) Attachment files are stored.

(3) Attachment files are
obtained(2) HTTPS

Web browser

Staff terminal at relevant
ministries

User system

NACCS Center server

Staff terminal at relevant ministries

Fig. 3.2.12 Attachment File Processing Sequence in the WebNACCS Processing Mode (Web
Browser)(1) User sends business messages with attachment files to the NACCS Center server over
HTTPS through the service dedicated to attachment files.
The NACCS Center server issues an acquisition key for attachment files and storestransaction output messages with attachment files and the acquisition key for attachment
files.
(2) User retrieves a processing result message from the NACCS Center server over HTTPS.
(3) Staff terminal at relevant ministers retrieves stored attachment files.

3-2-21

3.2.2.4.3

E-mail style processing mode

Figure 3.2.13 shows processing sequence in e-mail style processing mode (gateway computer):(1) SMTP(attachment fileprocedure)(1) Attachment files are stored.

Staff terminal at relevant
ministries(3) Attachment files
are obtained.

(2) POP3

Gateway computer

Customs system

User system

Figure 3.2.13

(1)

(2)
(3)

NACCS Center server

Customs terminal

Customs system
Staff terminal at relevant ministries

Attachment File Processing Sequence in E-Mail Style Processing Mode (Gateway
Computer)User sends a procedure message with attachment files to the NACCS Center server (mailserver) over SMTP through the procedure dedicated to attachment files.
The NACCS Center server issues an acquisition key for attachment files and storestransaction output messages with attachment files and the acquisition key for attachment
files.
User retrieves a processing result message from the NACCS Center server (mailbox) over
POP3.
Staff terminal at other relevant ministers or customs system retrieves stored messages.

3-2-22