102 Communication Networks
Copyright © 2005 PragSoft
Figure 8.85 Envelope structure.
To: Cc:
From: Subject:
...
Heading
Body Contents
Envelope
Envelope addressing info...
As would be expected, the MHS service is defined by a set of service primitives. Figure 8.35 summarizes the primitives and their purpose.
Figure 8.86 MHS service primitives. Primitive
Issued By Types Purpose
LOGON UA
request response
To initiate a session. If successful, the UA is informed of any messages waiting.
MTA indicate
confirm LOGOFF
UA request
To terminate a session. MTA
confirm CHANGE
UA request
To change the UAs logon password. PASSWORD
MTA indicate
confirm REGISTER
UA request
To change the UAs profile maintained by the MTA
confirm MTA.
SUBMIT UA
request To submit a message an envelope to the MTA.
MTA confirm
DELIVER MTA
indicate To deliver a submitted message to the UA.
NOTIFY MTA
indicate To notify the UA of message delivery.
CANCEL UA
request To cancel a message delivery to a UA.
MTA confirm
PROBE UA
request To check if a SUBMIT would be successful.
MTA confirm
CONTROL UA
request response
To alter the ways in which message storage and delivery is controlled by the MTA.
MTA indicate
confirm
www.pragsoft.com Chapter 8: The Application Layer
103
MHS uses four protocols P1, P2, P3, and P7 to provides two types of service:
•
The Message Transfer MT service supports the handling of envelopes. This service operates between MTAs P1 protocol, between UAs and MTAMSs
P3 protocol, and between UAs and MSs P7 protocol.
•
The Inter-Personal Messaging IPM service supports the handling of the contents of envelopes. This service operates between UAs P2 protocol. IPM
depends on the MT service for its operation.
These services are organized as service groups, each of which contains related
service elements
. The service elements are supported by the service primitives depicted in Figure 8.35. Figure 8.87 summarizes sample MT and IPM service
elements. MHS protocols use the three common service elements described in Section 8.2
i.e., ACSE, RTSE, and ROSE. All envelopes are transferred as APDUs using the RTSE. All MHS protocols and messages are defined in ASN.1 and have BER
codings. This includes a set of application-wide tags defined for identifying the various data types defined for MHS.
Figure 8.87 Service groups and sample service elements. Group
Service Element Purpose
Basic Content Type Indication
Allows the originating UA to indicate the message content types e.g. text, binary to the recipient.
Message Identification Used by the MTS to uniquely identify each
message passing through it.
MT
Submission Delivery Notification Allows the originating UA to request notification of
receipt from the receiving UA. Delivery
Multidestination Delivery Allows the originating UA to specify multiple destination addresses.
Conversion Prohibit Conversion
Allows the originating UA to ask the MTS not to perform any conversion on the message.
Explicit Conversion Used by the UA to ask the MTS to perform code
conversion on the message. Basic
Same as MT Same as MT
Action Receipt Notification
Used by the originating UA to ask the receiving UA to notify the originator of the receipt.
IPM
Auto-forward Indication Used by the receiving UA to determine if the
message has been auto-forwarded. Information
Subject Indication Used by the originating UA to convey the message
subject to the receiving UA. Conveying
Expiry Indication Used by the originating UA to specify when the
message will become invalid.
The X.400 series of standards consist of a number of recommendations, of which the following were touched upon in this section:
104 Communication Networks
Copyright © 2005 PragSoft
CCITT X.400 ISO 10021.1 MHS Service Overview
CCITT X.402 ISO 10021.2 MHS Architecture
CCITT X.411 ISO 10021.4 MHS Message Transfer Service Definition
CCITT X.419 ISO 10021.6 MHS Protocol Specification
8.3.3. File Transfer, Access, and Management
Working with files in a distributed system consisting of a number of individual systems connected together by a network presents a challenge. Each system has its
own filestore which may be different from the filestores of other participating systems i.e., different filestore structure and different file formats. The ISO 8571 series of
standards for File Transfer, Access, and Management FTAM provide useful services for addressing this problem.
FTAM provides file service uniformity by having each real filestore represented by a virtual filestore . The latter serves as a generic model for the former. Although
the real file stores are system dependent and potentially different, the virtual file stores all adhere to the same format and protocol. FTAM furnishes the specification
for virtual filestores. The mapping between a virtual filestore and its corresponding real filestore is beyond the scope of FTAM; it is the responsibility of the system
which own the real filestore.
FTAM provides the necessary services for applications to establish associations with remote file system to: transfer files, access and manipulate file contents read
and write records, manage files create, delete, copy, move, etc., and manipulate file attributes name, access permissions, dates, etc..
Figure 8.89 illustrates FTAM’s role in a typical configuration, where a local application accesses the filestore of a remote system. FTAM provides an association
between an initiator and a responder which make the FTAM services accessible to the local and remote systems.
For its virtual filestores, FTAM uses a model which resembles the UNIX file system model. It views the whole file system as a tree-like hierarchical structure,
where the tree nodes represent directories and the leaves represent actual files or references similar to symbolic links in UNIX to other nodes. Each of these is
represented by an FTAM object i.e., file object, directory object, and reference object.
A file itself consists of attributes and contents. The file attributes denote its
various properties, such as name, creation date, and size. FTAM classifies attributes into four groups; these are summarized in Figure 8.89. The file contents is comprised
of a set of named Data Units DUs. DUs are combined in a hierarchical manner to build larger structures called File Access Data Units FADUs. Figure 8.Error
www.pragsoft.com Chapter 8: The Application Layer
105
Bookmark not defined.
illustrates this for a simple file structure consisting of four DUs organized as five FADUs.
Figure 8.88 FTAM structure.
Remote System Local Application
FTAM Initiator
Lower ISO Layers
Lower ISO Layers
FTAM Association
FTAM Responder
Virtual Filestore
Real Filestore
Figure 8.89 File attribute groups. Group
Attributes Description
Kernel File Name
File Structure File Mode
Basic properties required by all files. Storage
File Size Creator ID
User ID Read Date
Write Date Attribute Change Date
File Locks Properties pertaining to the physical file storage.
Security Access permission
Encryption Properties which regulate access to the file.
Private user-defined
Properties beyond the scope of FTAM.
Figure 8.90 Sample FTAM file structure.
FADU DU
DU DU
DU FADU
FADU FADU
FADU
106 Communication Networks
Copyright © 2005 PragSoft
FTAM services are defined using service primitives, which operate on FADUs, DUs, and file attributes, as well as managing the initiation and termination of FTAM
associations. FTAM defines many primitives, a sample of which is provided in Figure 8.11. FTAM uses ACSE for its operation.
Figure 8.11 Sample FTAM service primitives. Primitive
Types Purpose
F-INITIALIZE request, indicate
response, confirm Used by an initiator-responder pair to establish an
association. F-TERMINATE
request, indicate response, confirm
Used by the initiator-responder pair to terminate their association.
F-U-ABORT request, indicate
Used by an initiator-responder pair to report errors.
F-P-ABORT indicate
Used by the service provider to report errors. F-CREATE
request, indicate response, confirm
Used for creating a remote file. F-DELETE
request, indicate response, confirm
Used for deleting a remote file. F-SELECT
request, indicate response, confirm
Used for choosing a remote file to work with. F-DESELECT
request, indicate response, confirm
Used for releasing control over a selected remote file.
F-COPY request, indicate
response, confirm Used for making a copy of a remote file. The copy
will remain on the remote system. F-MOVE
request, indicate response, confirm
Used for moving a remote file within its filestore. F-OPEN
request, indicate response, confirm
Used for opening a remote file so that operations can be applied to its contents.
F-CLOSE request, indicate
response, confirm Used for closing an open remote file.
F-LOCATE request, indicate
response, confirm Used for locating an FADU of an open remote file.
F-ERASE request, indicate
response, confirm Used for erasing an FADU of an open remote file.
F-READ request, indicate
Commences the reading of an open remote file or part thereof.
F-WRITE request, indicate
Commences the writing of an open remote file or part thereof.
F-DATA request, indicate
Used for transferring an open remote file or part thereof.
F-DATA-END request, indicate
Finalizes one or more data transfer with F-DATA. F-TRANSFER-END request, indicate
response, confirm Finalizes an F-READ or F-WRITE operation in
progress. F-GROUP-primitive request, indicate
response, confirm A set of primitives used for collectively working on
groups of files e.g., F-GROUP-DELETE.
FTAM service primitives are organized into four regimes. The regimes denote
successive stages in an FTAM association which progressively narrow down the scope of the primitives. Figure 8.12. outlines the FTAM regimes and how they are
