As per Relevance of the word equivalent, we have this rfc below:
Network Working Group J.
Request for Comments: 1415 R.
Open Networks, Inc
January 1993
FTP-FTAM Gateway
Status of the
This RFC specifies an IAB standards track protocol for the
community, and requests discussion and suggestions for improvements
Please refer to the current edition of the "IAB Official
Standards" for the standardization state and status of this protocol
Distribution of this memo is unlimited
This memo describes a dual protocol stack application layer
that performs protocol translation, in an interactive environment
between the FTP and FTAM file transfer protocols
Two key assumptions are made: 1) POSIX file naming conventions
hierarchical organization, rather than proprietary conventions are
use; and 2) X.500 Directory Services are available
The authors of this RFC would like to express their appreciation
the individuals and organizations that participated in
implementation of the FTP-FTAM Application Layer Gateway and
fielding on the MILNET. Implementation credits go to Mr. John Scott
formerly of the MITRE Corporation, while fielding credits
extended to James Graham and R. Greg Lavender of Open Networks, Inc
(formerly NetWorks One) and Robert Cooney of the Naval Computer
Telecommunications Station (NCTS) Washington. Dr. Marshall Rose
to be commended for recognizing the importance of the FTP-
gateway and promulgating it as a part of the ISO
Environment (ISODE). The following individuals have
valuable editorial comments: Larry Friedman, Donna Vincent
Michael Resnick of Digital Equipment Corporation; Robert Cooney
NCTS; and S.E. Hardcastle-Kille of University College London.
of the FTP-FTAM Gateway Request for Comments effort was provided
Open Networks Inc. and the Defense Information Systems Agency (DISA),
formerly the Defense Communications Agency. DISA sponsors
Len Tabacchi, George Bradshaw, Tom Clarke, and Betsy Turner
Mindel & Slaski [Page 1]
RFC 1415 FTP-FTAM Gateway Specification January 1993
Table of
1. Introduction..................................................2
1.1. Relationship to Other Work ................................3
1.2. Overview of Gateway Operation .............................4
2. Gateway Architecture..........................................6
3. Network Naming and Addressing.................................8
4. Use of the Gateway Services...................................9
4.1. FTP-Initiated Gateway Service .............................9
4.2. FTAM-Initiated Gateway Service ...........................11
4.3. Summary of Usage .........................................12
5. Gateway State Variables and Transitions......................13
5.1. FTP-Initiated Gateway Service ............................14
5.2. FTAM-Initiated Gateway Service ...........................16
6. Document Type Support........................................18
6.1. Notes on NBS-9 ...........................................18
7. Functional Comparison of FTP and FTAM........................19
7.1. Loss of Functionality ....................................20
8. Mapping of Protocol Functions and Representations.............20
8.1. FTP-Initiated Gateway Service .............................22
8.2. FTAM-Initiated Gateway Service ............................38
9. Mapping between FTP Reply Codes and FTAM Parameters...........47
9.1. FTP Reply Codes to FTAM Parameters ........................48
9.2. FTAM Parameters to FTP Reply Codes ........................50
9.3. Future Mapping Problem ....................................54
9.4. Error Handling ............................................54
10. Implementation and Configuration Guidelines..................54
10.1. Robustness ...............................................54
10.2. Well-Known TCP/IP Port ...................................55
10.3. Gateway Listener Processes ...............................55
10.4. Implementation Testing ...................................55
10.5. POSIX File Naming and Organization .......................55
11. Security Considerations......................................55
12. References...................................................56
13. Authors' Addresses...........................................58
1.
The TCP/IP and OSI protocol suites will coexist in the
community for several years to come. As more and more OSI hosts
fielded on the Internet, the requirement for gateways between the
protocol suites becomes more pressing
This specification describes an application layer gateway
interoperability between the TCP/IP File Transfer Protocol (FTP)
the OSI File Transfer, Access, and Management (FTAM) protocol.
proposed application layer gateway is based on a bi-directional
of mappings between the FTP and FTAM protocols. Since the
Mindel & Slaski [Page 2]
RFC 1415 FTP-FTAM Gateway Specification January 1993
have quite different command structures, the mappings between
are not one-to-one. This paper assumes knowledge of the
Transfer Protocol (FTP) [RFC959] and the File Transfer, Access,
Management Protocol (FTAM) [ISO8571-1,2,3,4,5].
Two important goals of the mappings are to
Provide FTP users with as much emulated FTP capability on
FTAM Responder as possible,
Provide FTAM users with as much emulated FTAM capability on
FTP Server as possible
Though it is anticipated that the application layer gateway will
implemented on full protocol suites of both TCP/IP and OSI, at
one implementation of such a gateway (included in the ISO
Environment) can be configured to operate FTAM over either OSI
TCP/IP lower-layer services
1.1. Relationship to Other
Ideas presented in this specification are based on lessons learned
fielding the gateway on the MILNET, operational at NCTS
D.C. since 1989, and on the efforts of M. A. Wallace et al. of
National Institute of Standards and Technology (NIST) [NIST86].
1986, NIST published a design document for an FTP-FTAM gateway
Since that time, at least one implementation (for a subset of the
and FTAM protocols) of the gateway has been developed [MITRE87]
is included with the ISODE. This implementation is based on the
protocol translator gateway design [NIST86].
This document's contribution to the advancement of the FTP-
gateway concept is to
* Enhance the user interaction capability provided by the
implementation of the FTP-FTAM application layer gateway
* Clarify and enhance the mappings (FTP to FTAM, FTAM to FTP
documented by NIST
* Provide guidelines for fielding the FTP-FTAM application
gateway on the Internet so that it is useful as an
resource
* Produce a formal specification for the FTP-FTAM gateway
for implementors to use in building additional FTP-
gateways
Mindel & Slaski [Page 3]
RFC 1415 FTP-FTAM Gateway Specification January 1993
* Provide a formal specification for organizations wishing
procure FTP-FTAM gateways
1.2. Overview of Gateway
The gateway provides a virtual end-to-end application file
service. As data is sent via FTP, the gateway immediately maps
requested function to FTAM and passes it to the FTAM host. In
similar fashion, but using a different set of mappings, an
request is sent to the gateway, immediately mapped to an
function, and passed along to the FTP host
In FTP, the two parties involved in a file transfer are the
and Server. The Client is responsible for initiating a connection
the Server. Once the connection is established, all service
originate from the Client. The FTP-FTAM gateway does not support
FTP three node model
In FTAM, the two parties involved in a file transfer are
Initiator and Responder. The Initiator is responsible for
a connection to the Responder. Once the connection is established
either the Initiator or Responder may issue service requests to
other
The FTP-FTAM gateway provides two sets of services
1. FTP-Initiated Gateway
Utilized when an FTP Client contacts the FTP-FTAM gateway
instigate a file transfer with an FTAM Responder
2. FTAM-Initiated Gateway
Utilized when an FTAM Initiator contacts the FTP-
gateway to instigate a file transfer with an FTP Server
The gateway services' names were selected to identify the roles
the FTP-FTAM gateway plays when performing file transfers.
example, when a file transfer is instigated by an FTP Client,
contacts the FTP Server portion of the gateway, which maps
information to the FTAM Initiator portion of the gateway, which
turn contacts the remote FTAM Responder. This example scenario
the FTP-Initiated Gateway Services
Figure 1 illustrates the perspective of the application process
the FTP-Initiated service. Figure 2 illustrates that of the FTAM
Initiated service
Mindel & Slaski [Page 4]
RFC 1415 FTP-FTAM Gateway Specification January 1993
TCP Host OSI
+--------------+ +------------------+
| FTP Client | | FTAM Responder |
+--------------+ +------------------+
| |
| |
| |
| FTP-FTAM Gateway |
| +--------------------------------+ |
+-- | FTP Server FTAM Initiator | --+
+--------------------------------+
Figure 1 - FTP-Initiated Gateway
Mindel & Slaski [Page 5]
RFC 1415 FTP-FTAM Gateway Specification January 1993
TCP Host OSI
+--------------+ +------------------+
| FTP Server | | FTAM Initiator |
+--------------+ +------------------+
| |
| |
| |
| |
| FTP-FTAM Gateway |
| +--------------------------------+ |
+-- | FTP Client FTAM Responder | --+
+--------------------------------+
Figure 2 - FTAM-Initiated Gateway
2. Gateway
The gateway architecture, termed a protocol translator [NIST86],
depicted in Figure 3. It implements TCP/IP and OSI protocol
with an application level process providing the link between the two
The link between FTP and FTAM is defined by two sets of
mappings, one each for the FTP-Initiated and FTAM-Initiated
sets
Mindel & Slaski [Page 6]
RFC 1415 FTP-FTAM Gateway Specification January 1993
+------------+ +-------------+
| FTP Host | | FTAM Host |
+------------+ +-------------+
| |
| |
| |
| |
| +---------------------------------+ |
| | FTP - FTAM | |
| | Gateway Application | |
| |---------------------------------| |
| | FTP | FTAM | |
| |----------------+----------------| |
| | TCP/IP | TP4/et al | |
| +---------------------------------+ |
| /|\ /|\ |
| | | |
+------------+ +-------------+
Figure 3 - Gateway Protocol
A fundamental aspect of this gateway architecture is that data
mapped and transmitted immediately; i.e., no transferred file
ever reside on the gateway file system. In the context of
document, the term "filesystem" refers to the file access
maintenance mechanisms provided by the operating system. This
of gateway filesystem interaction helps speed up the end-to-end
transfer. Another speed-enhancing feature of this architecture
that both the FTP and FTAM network connections can
Mindel & Slaski [Page 7]
RFC 1415 FTP-FTAM Gateway Specification January 1993
simultaneously. Additional advantages include
1. FTP and FTAM hosts require no modification to utilize
services
2. Users require no knowledge of the other protocol
3. Gateway access control is not impaired (since users
directly access the gateway filesystem).
4. No additional filesystem space is required on the gateway
5. Interactive nature of protocols is preserved
6. Users become aware of fatal errors immediately
Disadvantages of this design include the initial coding
required to develop the gateway and the subsequent re-coding
required to keep it current
3. Network Naming and
The network naming and addressing schemes used by FTP (Domain
(DN), IP Addresses) and FTAM (Distinguished Names,
Addresses) are quite different. This issue is quite apparent when
user of one protocol needs to identify a destination host of
other protocol
In the TCP/IP naming and addressing scheme, the identity of the
Server is its DN and its IP address [RFC1101]. To initiate
connection to an FTP Server, the FTP Client looks up a DN in
the Domain Name System (DNS) or static host table and obtains an
address
In the OSI naming and addressing scheme, the identity of the
Responder service is its Distinguished Name in the OSI
(X.500 or static table) and its Presentation address.
Distinguished Name is an authoritative description of the service.
Presentation address consists of a Presentation selector, a
selector, a transport selector, and a network address. To initiate
connection to an FTAM Responder, the FTAM Initiator contacts the
Directory, presents the Distinguished Name of the desired
Responder and asks for the Presentation address attribute
with that name
An alternative to the direct use of Distinguished Names is to
"User Friendly Naming", as defined in [Kille92]. Gateway support
"User Friendly Naming" is recommended, but not required
Mindel & Slaski [Page 8]
RFC 1415 FTP-FTAM Gateway Specification January 1993
4. Use of the Gateway
4.1. FTP-Initiated Gateway
The FTP Client uses the FTP-Initiated gateway service to utilize
resources of an FTAM Responder
To initiate a file transfer from an FTP Client, the Client
to the FTP-Initiated gateway service via TCP/IP. The gateway
establishes a connection, via OSI, to the FTAM Responder. At
point, the user can initiate file transfer operations
The FTP Client is responsible for providing the gateway with
authoritative Distinguished Name, or a User Friendly Name, of
desired OSI filestore. It is the responsibility of the gateway
resolve this Distinguished Name, or User Friendly Name, to
corresponding Presentation address
The logon sequence taken by an FTP Client when initiating a
transfer with an FTAM Responder is given below
% ftp
ftp> site Distinguished-Name-of-FTAM
ftp> user
ftp> pass
The "ftp gateway" command initiates the connection between the
Client and the gateway. Once connected to the gateway, the
Client should identify the desired FTAM Responder service via
Responder's Distinguished Name, or User Friendly Name, which
resolved by an algorithm running on the Directory Services provider
This information is sent via a "site Distinguished-Name-of-
Responder" or "site UFN-of-FTAM Responder" command
Upon receipt of a Distinguished Name or a User Friendly Name, it
the gateway's responsibility to resolve it to the
Address associated with that name. This resolution is done
contacting the OSI Directory (X.500 or local static table)
presenting the Distinguished Name or User Friendly Name. Once
Presentation address is obtained, the gateway can attempt
connection with the ultimate destination file transfer
represented by this Presentation address
The userid is passed via the "user username" command, and
password is passed via the "pass password". If the FTAM
requires a password, a password prompt should appear after
the "user username" command. It is anticipated that
authentication mechanisms will be required for DoD gateways in
Mindel & Slaski [Page 9]
RFC 1415 FTP-FTAM Gateway Specification January 1993
future
Using a specific example, suppose an FTAM Responder has the
Distinguished Name
CountryName = "US
Organization = "Open Networks
OrganizationalUnit = "Network Services
CommonName = "netwrx1"
CommonName = "FTAM service
and the FTP-FTAM gateway is available at "washdc1-osigw.navy.mil".
The FTP user action will appear as
% ftp washdc1-osigw.navy.
ftp> site "c=US@o=Open Networks@ou=Network Services@cn=netwrx
@cn=FTAM service
ftp> user
ftp> pass ***********
The "ftp washdc1-osigw.navy.mil" command initiates the
between the FTP Client and the FTP-FTAM gateway at the
Navy Yard, Washington D.C. Once connected, the OSI filestore at
Networks is identified via its Distinguished Name, "@c=US@o=
Networks@ou=Network Services@cn=netwrx1@cn=FTAM service".
Alternatively, a User Friendly Name, such as
"netwrx1, Open Networks, us
can be specified, enabling the following FTP user action
% ftp washdc1-osigw.navy.
ftp> site "netwrx1, Open Networks, us
ftp> user
ftp> pass ***********
As this example indicates, use of an intermediate gateway is
transparent. To partially alleviate this awkwardness, the
can be made more transparent through the registration of the
host in the DNS using the address of the gateway [RFC1279].
An example will clarify this point. Suppose that the "netwrx1,
Networks, us" FTAM host is registered in the TCP/IP DNS with the
of "ftam-service.netwrx1.com" and the IP address of the "washdc1-
osigw.navy.mil" gateway. In this example, the following set of
actions is required
Mindel & Slaski [Page 10]
RFC 1415 FTP-FTAM Gateway Specification January 1993
% ftp ftam-service.netwrx1.
ftp> user
ftp> pass ***********
Since the "ftam-service.netwrx1.com" really points to the
address, the first command will connect the FTP Client to
gateway. The gateway will then use the name (using [RFC1279])
determine where the actual FTAM host is resident. Gateway
for RFC1279 is recommended, but not required
4.2. FTAM-Initiated Gateway
The FTAM Initiator uses the FTAM-Initiated gateway service to
the resources of an FTP Server
To initiate a file transfer from an FTAM Initiator, the
connects to the FTAM-Initiated gateway service via OSI. The
then establishes a connection, via TCP/IP, to the FTP Server.
this point, the user can initiate file transfer operations
The FTAM Initiator is responsible for providing the gateway with
authoritative DN of the desired TCP/IP filestore. It is
responsibility of the gateway to resolve this DN to its
IP address
The logon sequence taken by an FTAM Initiator when initiating a
transfer with an FTP Server is given below
% ftam
ftam> user username@DNS-
ftam> pass
The "ftam gateway" command initiates the connection between the
Initiator and the gateway. Once connected, userid and TCP/
filestore are identified in the "username@DNS-string" argument to
user command. If the FTP Server requires a password, a
prompt should appear after issuing the user command
The gateway should incorporate the BIND Resolver functionality
that upon receipt of a Domain Name, the Gateway FTP Client
resolve it via the distributed Domain Name System
Using a specific example, suppose that a FTP Server has the
Domain Name: "ftp-service.netwrx1.com" and an FTP-FTAM gateway
available at
Mindel & Slaski [Page 11]
RFC 1415 FTP-FTAM Gateway Specification January 1993
CountryName = "US
Organization = "GOV
OrganizationalUnit = "DOD
OrganizationalUnit = "DISA
Locality = "Washington Navy Yard
CommonName = "wnyosi7"
The FTAM user action will appear as
% ftam @c=US@o=GOV@ou=DOD@ou=DISA@l=Washington Navy
@cn=wnyosi
ftam> user mindel@ftp-service.netwrx1.
ftam> pass ***********
Alternatively, a User Friendly Name could be used rather than
Distinguished Name
As mentioned in the previous section, "Use of the FTP-
Gateway Service", use of an intermediate gateway is not transparent
The gateway can be made more transparent through the registration
the FTP host in the X.500 OSI Directory. By querying the X.500
Directory, the gateway can identify where the actual host
resident
For example, suppose that the FTP Server in the previous
("ftp-service.netwrx1.com") is registered in the X.500 Directory
the following Distinguished Name
CountryName = "US
Organization = "Open Networks
OrganizationalUnit = "Network Services
CommonName = "netwrx1"
CommonName = "FTP service
and the Presentation Address of the FTP-FTAM gateway. This approach
described in [RFC1279], would permit the following user interactions
% ftam @c=US@o=Open Networks@ou=Network
@cn=netwrx1@cn=FTP Service
ftam> user
ftam> pass ***********
4.3. Summary of
As shown in the discussions of the FTP-Initiated and FTAM-
Gateway Services, the gateway user does not have access to
gateway filesystem; he merely makes use of the gateway
procedure to specify the ultimate destination userid and password
Mindel & Slaski [Page 12]
RFC 1415 FTP-FTAM Gateway Specification January 1993
Two methods of interaction with the gateway were described. In
former, the user must
1. Be aware that a gateway is required to reach
destination FTP or FTAM host
2. Determine which gateway is most appropriate for
respective source-destination pair
3. Explicitly connect to the gateway host prior to
to the destination host
Needless to say, the exchange of files between FTP and FTAM
requires more effort than that required for the exchange of
between a pair of hosts utilizing the same file transfer protocol
The latter, more transparent method does not necessarily require
the user determine which gateway is most appropriate for
respective source-destination pair. In fact, filestore
providers are registered using the address of a
gateway. With this approach, the user
1. Must be aware that a gateway is required to reach
destination FTP or FTAM host
2. Need not determine which gateway is most appropriate
access their ultimate destination host
3. Need not explicitly connect to the gateway prior
connecting to the destination FTP or FTAM host
5. Gateway State Variables and
As described, the FTP-FTAM gateway provides two sets of services
FTP-Initiated and FTAM-Initiated. Each service has its own
exclusive set of state variables and transitions
deterministically define the actions of the gateway. Gateway
for these state variables and transitions is required
For conciseness in this discussion, FTP-Initiated will be
with "FTP-I", and FTAM-Initiated will be abbreviated with "FTAM-I".
Concerning error conditions, if a connection is dropped when
gateway is in any state other than FTP-I:Initial-State or FTAM
I:Initial-State, then the gateway will issue a fatal error message
the host with the remaining connection, and then drop
connection. If the remaining host is an FTP Client, then the
will send an ABOR, QUIT, and 426 reply code (Connection closed
Mindel & Slaski [Page 13]
RFC 1415 FTP-FTAM Gateway Specification January 1993
transfer aborted). If it is an FTAM Initiator, then the gateway
send an F-P-ABORT with a <Diagnostic> value with identifier 1011
(Lower layer failure), as well as any known .
Other error conditions are not addressed in this discussion
5.1. FTP-Initiated Gateway
The set of state variables for the FTP-Initiated Gateway
follow
State Variable State
----------------------------------------------------------------
FTP-I:Initial-State Initial state of FTP-Initiated
service
Gateway is waiting for an FTP Client
issue a USER command in order
proceed with connection
with remote FTAM Responder. If SITE
ACCT commands are sent while
for USER command, save arguments
subsequent use
FTP-I:Wait-for-PASS Gateway has already received
command from FTP Client, as well
userid and destination host DN
Gateway is waiting for the
Responder logon password
FTP-I:Wait-for-PAddress Gateway has already received
command from FTP Client. Gateway
resolving the provided FTAM Responder'
address to a Presentation Address.
provided address may be a
Name, User Friendly Name, or
Name. Resolution will typically
done using X.500 directory services
FTP-I:Wait-for-Connection Gateway has initiated a connection
the FTAM Responder and is waiting
notification as to whether or not
logon is successful
FTP-I:Wait-for-ClientCmd Connection exists between FTP
and FTAM Responder. Gateway is
for next command or response from
Mindel & Slaski [Page 14]
RFC 1415 FTP-FTAM Gateway Specification January 1993
Client. Commands and responses
mapped as they are received
FTP-I:Wait-for-RespondrCmd Connection exists between FTP
and FTAM Responder. Gateway is
for next command or response from
Responder. Commands and responses
mapped as they are received
Each of the possible state transitions is provided in the
of Section 5.1. For each state transition, the actions causing
transition are listed
5.1.1. FTP-I:Initial-State --> FTP-I:Initial-
1. Gateway receives SITE or ACCT command from FTP Client
SITE argument includes Distinguish Name of FTAM Responder
5.1.2. FTP-I:Initial-State --> FTP-I:Wait-for-
1. Gateway receives USER command from FTP Client.
include Distinguished Name of FTAM Responder and userid
FTAM responder
5.1.3. FTP-I:Wait-for-PASS --> FTP-I:Wait-for-
1. Gateway receives PASS command from FTP Client
5.1.4. FTP-I:Wait-for-PAddress --> FTP-I:Wait-for-
1. Gateway resolves received Distinguished Name, User
Name, or Domain Name of FTAM Responder to OSI
address
2. Gateway sends F-INITIALIZE to FTAM Responder
Presentation Address in Presentation Address>,
userid in <Initiator Identity>, and password in <
Password>.
5.1.5. FTP-I:Wait-for-Connection --> FTP-I:Wait-for-
1. Gateway receives of "Success" .
2. Gateway sends 230 reply code (User Logged In) to
Client
5.1.6. FTP-I:Wait-for-ClientCmd --> FTP-I:Wait-for-
1. Gateway receives command or response from FTP Client
maps it to FTAM protocol, as defined in section 8.1.
Mindel & Slaski [Page 15]
RFC 1415 FTP-FTAM Gateway Specification January 1993
5.1.7. FTP-I:Wait-for-RespondrCmd --> FTP-I:Wait-for-
1. Gateway receives command or response from FTAM
and maps it to FTP protocol, as defined in section 8.1.
5.1.8. FTP-I:Wait-for-ClientCmd --> FTP-I:Wait-for-
1. Gateway receives QUIT command from FTP Client; maps QUIT
per Section 8.1.
5.2. FTAM-Initiated Gateway
The set of state variables for the FTAM-Initiated Gateway
follow
State Variable State
----------------------------------------------------------------
FTAM-I:Initial-State Initial state of FTAM-Initiated
Service
Gateway is waiting for an
Initiator to issue an F-
command in order to proceed
connection establishment with
FTP Server
FTAM-I:Wait-for-IPAddress Gateway has already received F
INITIALIZE from FTAM Initiator
Gateway is resolving the provided
Server's address to an IP address.
provided address may be a Domain Name
Distinguished Name, or User
Name
FTAM-I:Wait-for-Connection Gateway has initiated a connection
the FTP Server and is waiting
notification as to whether or not
logon is successful
FTAM-I:Wait-for-InitiatrCmd Connection exists between
Initiator and FTP Server. Gateway
waiting for next command or
from FTAM Initiator. Commands
responses are mapped as they
received
Mindel & Slaski [Page 16]
RFC 1415 FTP-FTAM Gateway Specification January 1993
FTP-I:Wait-for-ServerCmd Connection exists between
Initiator and FTP Server. Gateway
waiting for next command or
from FTP Server. Commands
responses are mapped as they
received
Each of the possible state transitions is provided in the
of Section 5.2. For each state transition, the actions causing
transition are listed
5.2.1. FTAM-I:Initial-State --> FTAM-I:Wait-for-
1. Gateway receives F-INITIALIZE from FTAM Initiator.
Name of FTP Server is either in
Address> or in the "@host" portion of the <
Identity> parameter. The userid is in <
Identity>, and password is in Password
parameter
5.2.2. FTAM-I:Wait-for-IPAddress --> FTAM-I:Wait-for-
1. Gateway resolves received Domain Name, Distinguished Name
or User Friendly Name of FTP Server to IP address
2. Gateway sends USER to FTP Server
3. Gateway sends PASS to FTP Server
5.2.3. FTAM-I:Wait-for-Connection --> FTAM-I:Wait-for-
1. Gateway receives 230 reply code (User Logged In) from
Server
2. Gateway sends of "Success" to
Initiator
5.2.4 FTAM-I:Wait-for-InitiatrCmd --> FTAM-I:Wait-for-
1. Gateway receives command or response from FTAM
and maps it to FTP protocol, as defined in section 8.2.
5.2.5. FTAM-I:Wait-for-ServerCmd --> FTAM-I:Wait-for-
1. Gateway receives command or response from FTP Server
maps it to FTAM protocol, as defined in section 8.2.
5.2.6. FTAM-I:Wait-for-InitiatrCmd --> FTAM-I:Wait-for-
1. Gateway receives F-CLOSE primitive from FTAM Initiator
maps F-CLOSE as per Section 8.2.
Mindel & Slaski [Page 17]
RFC 1415 FTP-FTAM Gateway Specification January 1993
6. Document Type
The set of FTAM document types supported by the FTP-FTAM gateway is
subset of the document types identified in the Stable
Agreements for Open Systems Interconnection Protocols: Part 9 -
Phase 2, produced by the March 1992 Open Systems
Implementors' Workshop [NIST92]. This subset was chosen for
equivalence to those document types supported by FTP. The
includes
FTAM-1 "ISO FTAM Unstructured text
FTAM-3 "ISO FTAM Unstructured binary
NBS-9 "NBS-9 FTAM File directory file
FTAM document types map to FTP document types as follows
FTAM <->
----------------------------------
FTAM-1 <->
FTAM-3 <-> 8 bit
NBS-9 <->
Gateway support for FTAM-1 and FTAM-2 is required, whereas
for NBS-9 is recommended
6.1. Notes on NBS-9
NBS-9 is optional in GOSIP versions 1 and 2 [NIST91]. NBS-9 will
superseded by its replacement when ISO/IEC ISP 10607-2 and ISO/
ISP 10607-2/Amendment 1 are published [NIST92].
For conformance to NBS-9, an FTAM Responder is only required
return the <Filename> file attribute, subject to local security
access control. All other requested attributes need not be returned
Systems supporting the NBS-9 document type shall make available
NBS-9 document called 'DIRLIS'. This document can be used to
a listing of files and their associated attributes from a
Filestore
Mindel & Slaski [Page 18]
RFC 1415 FTP-FTAM Gateway Specification January 1993
7. Functional Comparison of FTP and
A comprehensive comparison of the services offered by FTP and FTAM
beyond the scope of this specification. What follows is an
of several key points. Refer to [NIST 86a] and [ROSE90] for a
complete discourse on this topic
FTAM is not a superset of FTP; each protocol has functions that
it performs. The set of FTAM functions is, however, larger than
set of FTP functions
FTP combines file management and file transfer into one
engine, whereas FTAM separates management and transfer as they
to files
The file transfer services of both FTP and FTAM expect a
underlying end-to-end service. At a minimum, this service
the capability to transfer entire files between remote hosts and
display remote filenames
In addition to this basic file transfer service, FTAM supports
capability to: access a few records from a file server, create
network file system (similar to Sun's Network File System),
printing and spooling, and access remote database records. FTP
not support these additional capabilities
FTP uses TELNET services to set up a connection between the
Client and FTP Server. A three-digit reply code followed
explanatory text indicates the status of the preceding request
provides diagnostic information explaining each transaction
FTAM relies on the Association Control Service Element (ACSE)
start and stop the network for network file interaction. Generally
the ASCE establishes the application association and
application context needed to support the FTAM protocol
The FTAM protocol is modularized so as to keep the allowable
of actions in any particular state relatively small. There are
more possible sequences of FTP operations than possible sequences
FTAM operations [NIST86].
Because FTAM is more robust than FTP, FTAM allows greater
for conveying information about files. FTAM deals only with
of application processes, and leaves data representation and
management facilities to other OSI service elements
In contrast to the Client/Server model present in the FTP scheme
FTAM is based on the Initiator/Responder model. The key
Mindel & Slaski [Page 19]
RFC 1415 FTP-FTAM Gateway Specification January 1993
is that once the FTAM Initiator has established a connection with
remote host, either the Initiator or Responder can request
of the other. In the FTP realm, the Client both initiates
connection and requests all services
The FTP Client knows the real properties of the remote
filesystem. FTAM, in contrast, embraces a conceptual model of
filesystem, labeled a virtual filestore model. The virtual
is a collection of files, each of which has a name that
identifies it. Each file has a set of attributes, such as
information and contents, which is the data associated with the file
One file attribute is the <Contents Type> of the file, typically
value "FTAM-1", "FTAM-3", or "NBS-9". The FTAM Initiator only
the properties of the corresponding Responder and virtual filestore
not the real properties of the filesystem on the remote host
7.1. Loss of
As happens whenever two dissimilar protocols, or languages for
matter, are translated, some loss of functionality is inevitable
With reference to the FTP-FTAM gateway, several of the most
losses of functionality are
1. Diagnostics passed between protocols may not be
translated
2. The FTAM partial file (record) transfer may not
supported
3. Some FTAM attributes are not supported by FTP
The primary goal of the gateway protocol mappings are to
this loss of functionality. As this gateway specification
subsequent implementations evolve, means to partially overcome
of functionality may become more obvious. For example, the
may be able to emulate file record transfers between FTAM
and FTP Servers
8. Mapping of Protocol Functions and
The mappings presented are based upon the FTAM
implementation as defined in Stable Implementation Agreements
Open Systems Interconnection Protocols: Part 9 - FTAM Phase 2,
produced by the March 1992 Open Systems Environment Implementors
Workshop [NIST92], and in [ISO8571-1], [ISO8571-2],[ISO8571-
3],[ISO8571-4], and [ISO8571-5]. The FTP protocol as defined
Request for Comments [RFC959]. The mappings are strongly
by the work of M. A. Wallace et. al. at NIST [NIST86] and John
Mindel & Slaski [Page 20]
RFC 1415 FTP-FTAM Gateway Specification January 1993
at MITRE [MITRE87].
A key goal of the mappings presented in this document is to
the loss of functionality between the two protocols. The
approach taken to implement the mappings is left to the discretion
the gateway implementor. The focus of the protocol function
representation mappings is on non-error encumbered processing.
mapping of diagnostic and error messages is treated separately
section 9.
At a minimum, the FTAM implementation in the FTP-FTAM gateway
for Implementation Profiles T1 (Simple File Transfer) and M
(Management), as defined in [NIST92], is required.
Implementation Profiles correspond to the A/111 and A/13 Profiles
Standards Promotion and Application Group in Europe,
[NIST92].
At a minimum, the gateway support for the following is required
ASCII and 8 bit binary file types. It should also support
File Stream Mode
The following FTAM document types: FTAM-1 (unstructured
file), FTAM-3 (unstructured binary file), and NBS-9 (set
directory entries).
POSIX file naming and organization conventions are assumed in
mappings; i.e., files in the systems are assumed to be organized in
hierarchical structure in which all of the non-terminal nodes
directories and all of the terminal nodes are any other type of file
The following terminology is used in the mapping specifications
argument .......FTP Service Command argument, as used in [RFC959].
parameter ......FTAM Service Primitive parameters and attributes
as enumerated in Tables 6, 50, and 51 of [ISO8571-
3].
The following notation is used in the mapping specifications
Arguments and parameters are enclosed in angle brackets; e.g.,
Values of arguments and parameters are enclosed in
marks; e.g., "Success
Mindel & Slaski [Page 21]
RFC 1415 FTP-FTAM Gateway Specification January 1993
FTP Service Commands and FTAM Primitives are in uppercase; e.g., F
8.1. FTP-Initiated Gateway
The protocol mapping between FTP and FTAM may be one-to-zero (i.e.,
not mappable), one-to-one, or one-to-many
The general steps taken by the FTP-FTAM gateway to provide the FTP
Initiated service are
1. Accept an FTP Client request at the FTP Server side of
gateway service
2. Map the request to the (set of) corresponding
Initiator function(s).
3. Acting as an FTAM Initiator, send the FTAM
function(s) to the FTAM Responder
4. Accept information returned to the FTAM Initiator side
the gateway. This information originated at the
Responder
5. Map this returned information to the protocol
understood by the FTP Server side of the gateway
6. Send this returned information from the FTP Server side
the gateway to the FTP Client
For each FTP protocol function, the FTAM protocol functions
to map it are identified
FTP
------------------------------------------------------------------
ABOR F-BEGIN-GROUP, F-CANCEL, F-CLOSE, F-DESELECT, F-END-
ACCT F-INITIALIZE
ALLO
APPE F-BEGIN-GROUP, F-CLOSE, F-CREATE, F-DATA, F-DATA-END, F
DESELECT, F-END-GROUP, F-OPEN, F-READ-ATTRIBUTES, F-SELECT
F-TRANSFER-END, F-
CDUP F-BEGIN-GROUP, F-DESELECT, F-END-GROUP, F-
Mindel & Slaski [Page 22]
RFC 1415 FTP-FTAM Gateway Specification January 1993
CWD F-BEGIN-GROUP, F-END-GROUP, F-DESELECT, F-
DELE F-BEGIN-GROUP, F-DELETE, F-END-GROUP, F-
HELP
LIST F-BEGIN-GROUP, F-CLOSE, F-DATA, F-DATA-END, F-DESELECT, F
END-GROUP, F-OPEN, F-READ, F-READ-ATTRIBUTES, F-SELECT, F
TRANSFER-
MKD
MODE
NLST F-BEGIN-GROUP, F-CLOSE, F-DATA, F-DATA-END, F-DESELECT, F
END-GROUP, F-OPEN, F-READ, F-SELECT, F-TRANSFER-
NOOP
PASS F-
PASV
PORT
PWD F-BEGIN-GROUP, F-DESELECT, F-END-GROUP, F-READ-ATTRIBUTES
F-
QUIT F-P-ABORT or F-U-ABORT, F-
REIN F-BEGIN-GROUP, F-CANCEL, F-CLOSE, F-DESELECT, F-END-
REST F-CHECK, F-
RETR F-BEGIN-GROUP, F-CLOSE, F-DATA, F-DATA-END, F-DESELECT, F
END-GROUP, F-OPEN, F-READ, F-SELECT, F-TRANSFER-
RMD
RNFR F-BEGIN-GROUP, F-DESELECT, F-END-GROUP, F-
RNTO F-BEGIN-GROUP, F-CHANGE-ATTRIBUTES, F-DESELECT, F-END
GROUP, F-
SITE F-
SMNT
Mindel & Slaski [Page 23]
RFC 1415 FTP-FTAM Gateway Specification January 1993
STAT
STOR F-BEGIN-GROUP,F-CLOSE, F-CREATE, F-DATA, F-DATA-END, F
DESELECT, F-END-GROUP, F-OPEN, F-READ-ATTRIBUTES, F-SELECT
F-TRANSFER-END, F-
STOU F-BEGIN-GROUP, F-CLOSE, F-CREATE, F-DATA, F-DATA-END, F
DESELECT, F-END-GROUP, F-OPEN, F-READ-ATTRIBUTES, F-SELECT
F-TRANSFER-END, F-
STRU
TYPE
USER F-
The remainder of this section presents detailed mapping
for each of the FTP protocol functions. Gateway support for
mappings is required
8.1.1.
1. Send F-CANCEL to FTAM Responder
2. Send the following grouped request to the FTAM Responder
F-BEGIN-
F-
F-
F-END-
3. Translate FTAM Responder and <Diagnostic
parameters to equivalent FTP reply code(s) and send
codes to FTP Client
4. Translate FTP Client reply codes to equivalent FTAM <
Result> and <Diagnostic> parameters and send parameters
FTAM Responder
8.1.2.
1. Set parameter value for issuing F-INITIALIZE
FTAM Responder
2. If Presentation Address>, <Initiator Identity>,
Password> parameters are available,
connection with FTAM Responder
Otherwise wait for additional ACCT commands
3. Translate FTAM Responder and <Diagnostic
parameters to equivalent FTP reply code(s) and send
codes to FTP Client
4. Translate FTP Client reply codes to equivalent FTAM <
Result> and <Diagnostic> parameters and send parameters
Mindel & Slaski [Page 24]
RFC 1415 FTP-FTAM Gateway Specification January 1993
FTAM Responder
Note
a. The ACCT command will be effective with the next
command
8.1.3.
1. Return a 200 reply code to FTP Client
8.1.4.
1. Save current pathname by appending saved CWD string
<pathname> argument. If no saved CWD string, proceed
step 12.
2. Send the following grouped request to FTAM Responder
F-BEGIN-
F-
F-READ-
Save <Contents Type> parameter
F-
F-END-
3. If the <Contents Type> parameter value returned with
F-READ-ATTRIBUTES has a value of "NBS-9", proceed to
12.
4. Send the following grouped request to the FTAM responder
F-BEGIN-
F-
Set the parameter in the F-CREATE
"Select Old File".
F-
F-END-
5. If the file existed, set the <Contents Type> parameter
the F-CREATE to match that returned by
F-READ-ATTRIBUTES
6. If the file did not exist and no previous FTP TYPE "Image
command was issued, then set the <Contents Type>
to "FTAM-1";
Otherwise, set the <Contents Type> parameter to "FTAM-3".
7. Send F-WRITE, with Transfer Specification,
Operation> parameter set to "File Extend", to
Responder
8. Loop reading data from FTP data connection, sending
data in F-DATA PDUs until end-of-file on the
connection
9. Send F-DATA-END to FTAM Responder
10. Send F-TRANSFER-END to FTAM Responder
11. Send the following grouped request to the FTAM Responder
Mindel & Slaski [Page 25]
RFC 1415 FTP-FTAM Gateway Specification January 1993
F-BEGIN-
F-
F-
F-END-
12. Translate FTAM Responder and <Diagnostic
parameters to equivalent FTP reply code(s) and send
code(s) to FTP Client
13. Translate FTP Client reply codes to equivalent
and <Diagnostic> parameters and
parameters to FTAM Responder
Note
a. <pathname> argument is assumed to be a filename,
to the currently saved CWD
b. CWD of the FTAM system must be defined prior to issuance
APPE
8.1.5.
1. Determine parent directory from saved CWD string. If
saved CWD string, proceed to step 4.
2. Set <Contents Type> parameter to "NBS-9".
3. Send the following grouped request to FTAM Responder
F-BEGIN-
F-
F-
F-END-
4. Translate FTAM Responder and <Diagnostic
parameters to equivalent FTP reply code(s) and send
code(s) to FTP Client
5. Translate FTP Client reply codes to equivalent FTAM <
Result> and <Diagnostic> parameters and send parameters
FTAM Responder
Note
a. A POSIX file organization is assumed; i.e., files in
systems are organized in a hierarchical structure in
all of the non-terminal nodes are directories and all
the terminal nodes are any other type of file
b. If the parent directory does not exist, the current
directory remains unchanged
c. CWD of the FTAM system must be defined prior to issuance
CDUP
8.1.6.
1. Save <pathname> argument as CWD string
2. Set <Contents Type> parameter to "NBS-9".
Mindel & Slaski [Page 26]
RFC 1415 FTP-FTAM Gateway Specification January 1993
3. Send the following grouped request to FTAM Responder
F-BEGIN-
F-
F-
F-END-
4. Translate FTAM Responder and <Diagnostic
parameters to equivalent FTP reply code(s) and send
code(s) to FTP Client
5. Translate FTP Client reply codes to equivalent FTAM <
Result> and <Diagnostic> parameters and send parameters
FTAM Responder
Note
a. The <pathname> argument is assumed to be an
directory specification
b. If the specified directory does not exist, the
working directory remains unchanged
c. Saved CWD string is used in other FTP-to-FTAM mappings
such as APPE
8.1.7.
1. Save current pathname by appending saved CWD string
<pathname> argument. If no saved CWD string, proceed
step 3.
2. Send the following grouped request to FTAM Responder
F-BEGIN-
F-
F-
F-END-
3. Translate FTAM Responder and <Diagnostic
parameters to equivalent FTP reply code(s) and send
code(s) to FTP Client
4. Translate FTP Client reply codes to equivalent
parameters and send parameters to FTAM Responder
Note
a. <pathname> argument is assumed to be a filename,
to the currently saved CWD
b. CWD of the FTAM system must be defined prior to issuance
DELE
8.1.8.
1. If no argument is provided, send
information about the implementation of the gateway to
FTP Client. If an argument is provided, send more
information
Mindel & Slaski [Page 27]
RFC 1415 FTP-FTAM Gateway Specification January 1993
2. Return the FTP reply code 214 to the FTP Client
8.1.9.
1. If <pathname> argument is provided, proceed to step 3.
2. Save current pathname by appending saved CWD string
<pathname> argument; If no saved CWD string, proceed
step 11.
3. Send the following grouped request to the FTAM Responder
F-BEGIN-
F-
F-READ-
Save <Filename>, <Contents Type>,
Modification>, and
F-
F-END-
4. If the <Contents Type> parameter of the F-READ-
is not "NBS-9", then return the <Filename>, <
Type>, Modification>, and
parameter values, obtained with the
F-READ-ATTRIBUTES, to the FTP data connection
and proceed to step 8.
5. Send the following grouped request to the FTAM Responder
F-BEGIN-
F-
F-
F-END-
6. Send F-READ to FTAM Responder
7. Loop reading F-DATA until F-DATA-END. As data is received
write the <Filename>, , <Contents Type>,
and Modification> parameter values
the PDU to the FTP data connection
8. Send F-TRANSFER-END to FTAM Responder
9. Send the following grouped request to the FTAM responder
F-BEGIN-
F-
F-
F-END-
10. Translate FTAM Responder and <Diagnostic
parameters to equivalent FTP reply code(s) and send
code(s) to FTP Client
11. Translate FTP Client reply codes to equivalent FTAM <
Result> and <Diagnostic> parameters and send parameters
FTAM Responder
Note
a. Assume the <pathname> argument is relative to the
CWD, whether filename or directory specification
Mindel & Slaski [Page 28]
RFC 1415 FTP-FTAM Gateway Specification January 1993
b. CWD of the FTAM system must be defined prior to issuance
LIST
c. Transfers over data connection should be in ASCII
e. If list of files with full directory/file specification
received from FTAM Responder, then gateway should
list to strip off directory portion
8.1.10.
1. Return a 502 reply code (Command not implemented) to
FTP Client
Note
a. As indicated in the NIST Stable Implementation
for FTAM [NIST92], creation or deletion of NBS-9 files
outside the scope of the agreements
8.1.11.
1. If <argument> is "Stream", return 200 reply code to
Client; Otherwise return a 504 reply code (Command
implemented for that parameter).
8.1.12.
1. If <pathname> argument is provided, use <pathname>
as <Filename> parameter value in F-SELECT issued in step 3.
2. If no argument is provided, use saved CWD value
<Filename> parameter value in F-SELECT issued in step 3;
no CWD string is saved and no argument is provided,
to step 9.
3. Set <Contents Type> parameter to "NBS-9".
4. Send the following grouped request to the FTAM Responder
F-BEGIN-
F-
F-
F-END-
5. Send F-READ to FTAM Responder
6. Loop reading F-DATA until F-DATA-END. As data is received
write the filenames and other useful information from
PDU to the FTP data connection
7. Send F-TRANSFER-END to FTAM Responder
8. Send the following grouped request to the FTAM responder
F-BEGIN-
F-
F-
F-END-
9. Translate FTAM Responder and <Diagnostic
Mindel & Slaski [Page 29]
RFC 1415 FTP-FTAM Gateway Specification January 1993
parameters to equivalent FTP reply code(s) and send
code(s) to FTP Client
10. Translate FTP Client reply codes to equivalent FTAM <
Result> and <Diagnostic> parameters and send parameters
FTAM Responder
Note
a. As per RFC 959 (FTP), the NLST <pathname> argument is
directory
b. Assume the argument is relative to the saved CWD,
filename or directory specification
c. CWD of the FTAM system must be defined prior to issuance
NLST
d. Transfers over data connection should be in ASCII
e. Gateway should parse full directory/file
received from FTAM Responder to strip off
portion. This is required to support the "FTP
get" function that pipes NLST output to the STOR command
8.1.13.
1. Return a 200 reply code to FTP Client
8.1.14.
1. Set Password> parameter for F-INITIALIZE
2. If Presentation Address>, Identity>,
Password> are available, issue F- INITIALIZE
FTAM Responder
3. Translate FTAM Responder and <Diagnostic
parameters to equivalent FTP reply code(s) and send
code(s) to FTP Client
4. Translate FTP Client reply codes to equivalent FTAM <
Result> and <Diagnostic> parameters and send parameters
FTAM Responder
8.1.15.
1. Wait for data transfer on default data port or data
specified by PORT command
2. Return a 200 reply code to FTP Client
8.1.16.
1. Return a 200 reply code to FTP Client
Mindel & Slaski [Page 30]
RFC 1415 FTP-FTAM Gateway Specification January 1993
8.1.17.
1. If there is a saved CWD string, return it to the FTP
and proceed to step 4.
2. Set <Contents Type> attribute to "NBS-9".
3. Send the following grouped request to FTAM Responder
F-BEGIN-
F-
F-READ-
F-
F-END-
4. Return the current directory name to the FTP client
5. Translate FTAM Responder and <Diagnostic
parameters to equivalent FTP reply code(s) and send
code(s) to FTP Client
6. Translate FTP Client reply codes to equivalent FTAM <
Result> and <Diagnostic> parameters and send parameters
FTAM Responder
8.1.18.
1. If user is not logged in, proceed to step 5.
2. If file transfer is in progress, send F-P-ABORT
F-U-ABORT to FTAM Responder
3. If file transfer is not in progress, send and F-
to FTAM Responder
4. Return charge information to FTP Client
5. Translate FTAM Responder and <Diagnostic
parameters to equivalent FTP reply code(s) and send
code(s) to FTP Client
6. Translate FTP Client reply codes to equivalent FTAM <
Result> and <Diagnostic> parameters and send parameters
FTAM Responder
8.1.19.
1. Flush all I/O and account information
2. Allow all transfers in progress to be completed
3. Set all parameters 