Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 1415

FTP-FTAM Gateway Specification

Pages: 58
Historic
Part 1 of 3 – Pages 1 to 17
None   None   Next

Top   ToC   RFC1415 - Page 1
Network Working Group                                          J. Mindel
Request for Comments: 1415                                     R. Slaski
                                                     Open Networks, Inc.
                                                            January 1993


                     FTP-FTAM Gateway Specification

Status of the Memo

   This RFC specifies an IAB standards track protocol for the Internet
   community, and requests discussion and suggestions for improvements.
   Please refer to the current edition of the "IAB Official Protocol
   Standards" for the standardization state and status of this protocol.
   Distribution of this memo is unlimited.

Abstract

   This memo describes a dual protocol stack application layer gateway
   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 and
   hierarchical organization, rather than proprietary conventions are in
   use; and 2) X.500 Directory Services are available.

Acknowledgments

   The authors of this RFC would like to express their appreciation to
   the individuals and organizations that participated in the
   implementation of the FTP-FTAM Application Layer Gateway and its
   fielding on the MILNET.  Implementation credits go to Mr. John Scott,
   formerly of the MITRE Corporation, while fielding credits are
   extended to James Graham and R. Greg Lavender of Open Networks, Inc.
   (formerly NetWorks One) and Robert Cooney of the Naval Computer and
   Telecommunications Station (NCTS) Washington.  Dr. Marshall Rose is
   to be commended for recognizing the importance of the FTP-FTAM
   gateway and promulgating it as a part of the ISO Development
   Environment (ISODE).   The following individuals have provided
   valuable editorial comments:  Larry Friedman, Donna Vincent and
   Michael Resnick of Digital Equipment Corporation; Robert Cooney of
   NCTS; and S.E. Hardcastle-Kille of University College London. Funding
   of the FTP-FTAM Gateway Request for Comments effort was provided by
   Open Networks Inc. and the Defense Information Systems Agency (DISA),
   formerly the Defense Communications Agency.  DISA sponsors include
   Len Tabacchi, George Bradshaw, Tom Clarke, and Betsy Turner.
Top   ToC   RFC1415 - Page 2
Table of Contents

   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. Introduction

   The TCP/IP and OSI protocol suites will coexist in the Internet
   community for several years to come.  As more and more OSI hosts are
   fielded on the Internet, the requirement for gateways between the two
   protocol suites becomes more pressing.

   This specification describes an application layer gateway providing
   interoperability between the TCP/IP File Transfer Protocol (FTP) and
   the OSI File Transfer, Access, and Management (FTAM) protocol.  The
   proposed application layer gateway is based on a bi-directional set
   of mappings between the FTP and FTAM protocols.  Since the protocols
Top   ToC   RFC1415 - Page 3
   have quite different command structures, the mappings between them
   are not one-to-one.  This paper assumes knowledge of the File
   Transfer Protocol (FTP) [RFC959] and the File Transfer, Access, and
   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 an
      FTAM Responder as possible, and

      Provide FTAM users with as much emulated FTAM capability on an
      FTP Server as possible.

   Though it is anticipated that the application layer gateway will be
   implemented on full protocol suites of both TCP/IP and OSI, at least
   one implementation of such a gateway (included in the ISO Development
   Environment) can be configured to operate FTAM over either OSI or
   TCP/IP lower-layer services.

1.1. Relationship to Other Work

   Ideas presented in this specification are based on lessons learned in
   fielding the gateway on the MILNET, operational at NCTS Washington
   D.C. since 1989, and on the efforts of M. A. Wallace et al. of the
   National Institute of Standards and Technology (NIST) [NIST86].  In
   1986, NIST published a design document for an FTP-FTAM gateway.
   Since that time, at least one implementation (for a subset of the FTP
   and FTAM protocols) of the gateway has been developed [MITRE87] and
   is included with the ISODE.  This implementation is based on the NIST
   protocol translator gateway design [NIST86].

   This document's contribution to the advancement of the FTP-FTAM
   gateway concept is to:

      *  Enhance the user interaction capability provided by the ISODE
         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 layer
         gateway on the Internet so that it is useful as an Internet
         resource.

      *  Produce a formal specification for the FTP-FTAM gateway suitable
         for implementors to use in building additional FTP-FTAM
         gateways.
Top   ToC   RFC1415 - Page 4
      *  Provide a formal specification for organizations wishing to
         procure FTP-FTAM gateways.

1.2. Overview of Gateway Operation

   The gateway provides a virtual end-to-end application file transfer
   service.  As data is sent via FTP, the gateway immediately maps the
   requested function to FTAM and passes it to the FTAM host.  In a
   similar fashion, but using a different set of mappings, an FTAM
   request is sent to the gateway, immediately mapped to an FTP
   function, and passed along to the FTP host.

   In FTP, the two parties involved in a file transfer are the Client
   and Server.  The Client is responsible for initiating a connection to
   the Server.  Once the connection is established, all service requests
   originate from the Client.  The FTP-FTAM gateway does not support the
   FTP three node model.

   In FTAM, the two parties involved in a file transfer are the
   Initiator and Responder.  The Initiator is responsible for initiating
   a connection to the Responder.  Once the connection is established,
   either the Initiator or Responder may issue service requests to the
   other.

   The FTP-FTAM gateway provides two sets of services:

        1. FTP-Initiated Gateway Services

           Utilized when an FTP Client contacts the FTP-FTAM gateway to
           instigate a file transfer with an FTAM Responder.

        2. FTAM-Initiated Gateway Services

           Utilized when an FTAM Initiator contacts the FTP-FTAM
           gateway to instigate a file transfer with an FTP Server.

   The gateway services' names were selected to identify the roles that
   the FTP-FTAM gateway plays when performing file transfers.  For
   example, when a file transfer is instigated by an FTP Client, it
   contacts the FTP Server portion of the gateway, which maps protocol
   information to the FTAM Initiator portion of the gateway, which in
   turn contacts the remote FTAM Responder.  This example scenario uses
   the FTP-Initiated Gateway Services.

   Figure 1 illustrates the perspective of the application process in
   the FTP-Initiated service.  Figure 2 illustrates that of the FTAM-
   Initiated service.
Top   ToC   RFC1415 - Page 5
          TCP Host                                  OSI Host

      +--------------+                        +------------------+

      |  FTP Client  |                        |  FTAM Responder  |

      +--------------+                        +------------------+

             |                                          |

             |                                          |

             |                                          |

             |            FTP-FTAM Gateway              |

             |    +--------------------------------+    |

             +--  |  FTP Server    FTAM Initiator  |  --+

                  +--------------------------------+


             Figure 1  -  FTP-Initiated Gateway Service
Top   ToC   RFC1415 - Page 6
          TCP Host                                  OSI Host

      +--------------+                        +------------------+

      |  FTP Server  |                        |  FTAM Initiator  |

      +--------------+                        +------------------+

             |                                          |

             |                                          |

             |                                          |

             |                                          |

             |            FTP-FTAM Gateway              |

             |    +--------------------------------+    |

             +--  |  FTP Client    FTAM Responder  |  --+

                  +--------------------------------+

             Figure 2  -  FTAM-Initiated Gateway Service

2. Gateway Architecture

   The gateway architecture, termed a protocol translator [NIST86], is
   depicted in Figure 3.  It implements TCP/IP and OSI protocol stacks
   with an application level process providing the link between the two.
   The link between FTP and FTAM is defined by two sets of protocol
   mappings, one each for the FTP-Initiated and FTAM-Initiated service
   sets.
Top   ToC   RFC1415 - Page 7
      +------------+                               +-------------+

      |  FTP Host  |                               |  FTAM Host  |

      +------------+                               +-------------+

             |                                            |

             |                                            |

             |                                            |

             |                                            |

             |    +---------------------------------+     |

             |    |          FTP  -  FTAM           |     |

             |    |       Gateway Application       |     |

             |    |---------------------------------|     |

             |    |      FTP       |      FTAM      |     |

             |    |----------------+----------------|     |

             |    |    TCP/IP      |    TP4/et al   |     |

             |    +---------------------------------+     |

             |           /|\               /|\            |

             |            |                 |             |

             +------------+                 +-------------+



                  Figure 3  -  Gateway Protocol Stack

   A fundamental aspect of this gateway architecture is that data is
   mapped and transmitted immediately; i.e., no transferred file need
   ever reside on the gateway file system.  In the context of this
   document, the term "filesystem" refers to the file access and
   maintenance mechanisms provided by the operating system.  This lack
   of gateway filesystem interaction helps speed up the end-to-end data
   transfer.  Another speed-enhancing feature of this architecture is
   that both the FTP and FTAM network connections can operate
Top   ToC   RFC1415 - Page 8
   simultaneously.  Additional advantages include:

        1. FTP and FTAM hosts require no modification to utilize gateway
           services.

        2. Users require no knowledge of the other protocol.

        3. Gateway access control is not impaired (since users cannot
           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 effort
   required to develop the gateway and the subsequent re-coding efforts
   required to keep it current.

3. Network Naming and Addressing

   The network naming and addressing schemes used by FTP (Domain Names
   (DN), IP Addresses) and FTAM (Distinguished Names, Presentation
   Addresses) are quite different.  This issue is quite apparent when a
   user of one protocol needs to identify a destination host of the
   other protocol.

   In the TCP/IP naming and addressing scheme, the identity of the FTP
   Server is its DN and its IP address [RFC1101].  To initiate a
   connection to an FTP Server, the FTP Client looks up a DN in either
   the Domain Name System (DNS) or static host table and obtains an IP
   address.

   In the OSI naming and addressing scheme, the identity of the FTAM
   Responder service is its Distinguished Name in the OSI Directory
   (X.500 or static table) and its Presentation address.  The
   Distinguished Name is an authoritative description of the service.  A
   Presentation address consists of a Presentation selector, a session
   selector, a transport selector, and a network address.  To initiate a
   connection to an FTAM Responder, the FTAM Initiator contacts the OSI
   Directory, presents the Distinguished Name of the desired FTAM
   Responder and asks for the Presentation address attribute associated
   with that name.

   An alternative to the direct use of Distinguished Names is to use
   "User Friendly Naming", as defined in [Kille92].  Gateway support for
   "User Friendly Naming" is recommended, but not required.
Top   ToC   RFC1415 - Page 9
4. Use of the Gateway Services

4.1. FTP-Initiated Gateway Service

   The FTP Client uses the FTP-Initiated gateway service to utilize the
   resources of an FTAM Responder.

   To initiate a file transfer from an FTP Client, the Client connects
   to the FTP-Initiated gateway service via TCP/IP.  The gateway then
   establishes a connection, via OSI, to the FTAM Responder.  At this
   point, the user can initiate file transfer operations.

   The FTP Client is responsible for providing the gateway with an
   authoritative Distinguished Name, or a User Friendly Name, of the
   desired OSI filestore.  It is the responsibility of the gateway to
   resolve this Distinguished Name, or User Friendly Name, to its
   corresponding Presentation address.

   The logon sequence taken by an FTP Client when initiating a file
   transfer with an FTAM Responder is given below:

             % ftp gateway
             ftp> site Distinguished-Name-of-FTAM Responder
             ftp> user username
             ftp> pass password

   The "ftp gateway" command initiates the connection between the FTP
   Client and the gateway.  Once connected to the gateway, the FTP
   Client should identify the desired FTAM Responder service via the
   Responder's Distinguished Name, or User Friendly Name, which is
   resolved by an algorithm running on the Directory Services provider.
   This information is sent via a "site Distinguished-Name-of-FTAM
   Responder" or "site UFN-of-FTAM Responder" command.

   Upon receipt of a Distinguished Name or a User Friendly Name, it is
   the gateway's responsibility to resolve it to the Presentation
   Address associated with that name.  This resolution is done by
   contacting the OSI Directory (X.500 or local static table) and
   presenting the Distinguished Name or User Friendly Name.  Once the
   Presentation address is obtained, the gateway can attempt a
   connection with the ultimate destination file transfer service
   represented by this Presentation address.

   The userid is passed via the "user username" command, and the
   password is passed via the "pass password".  If the FTAM Responder
   requires a password, a password prompt should appear after issuing
   the "user username" command.  It is anticipated that stronger
   authentication mechanisms will be required for DoD gateways in the
Top   ToC   RFC1415 - Page 10
   future.

   Using a specific example, suppose an FTAM Responder has the following
   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.mil
           ftp> site "c=US@o=Open Networks@ou=Network Services@cn=netwrx1
                @cn=FTAM service"
           ftp> user mindel
           ftp> pass ***********

   The "ftp washdc1-osigw.navy.mil" command initiates the connection
   between the FTP Client and the FTP-FTAM gateway at the Washington
   Navy Yard, Washington D.C.  Once connected, the OSI filestore at Open
   Networks is identified via its Distinguished Name, "@c=US@o=Open
   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.mil
           ftp> site "netwrx1, Open Networks, us"
           ftp> user mindel
           ftp> pass ***********

   As this example indicates, use of an intermediate gateway is not
   transparent.  To partially alleviate this awkwardness, the gateway
   can be made more transparent through the registration of the FTAM
   host in the DNS using the address of the gateway [RFC1279].

   An example will clarify this point.  Suppose that the "netwrx1, Open
   Networks, us" FTAM host is registered in the TCP/IP DNS with the DN
   of "ftam-service.netwrx1.com" and the IP address of the "washdc1-
   osigw.navy.mil" gateway.  In this example, the following set of user
   actions is required:
Top   ToC   RFC1415 - Page 11
           % ftp ftam-service.netwrx1.com
           ftp> user mindel
           ftp> pass ***********

   Since the "ftam-service.netwrx1.com" really points to the gateway
   address, the first command will connect the FTP Client to the
   gateway.  The gateway will then use the name (using [RFC1279]) to
   determine where the actual FTAM host is resident.  Gateway support
   for RFC1279 is recommended, but not required.

4.2. FTAM-Initiated Gateway Service

   The FTAM Initiator uses the FTAM-Initiated gateway service to utilize
   the resources of an FTP Server.

   To initiate a file transfer from an FTAM Initiator, the Initiator
   connects to the FTAM-Initiated gateway service via OSI.  The gateway
   then establishes a connection, via TCP/IP, to the FTP Server.  At
   this point, the user can initiate file transfer operations.

   The FTAM Initiator is responsible for providing the gateway with an
   authoritative DN of the desired TCP/IP filestore.  It is the
   responsibility of the gateway to resolve this DN to its corresponding
   IP address.

   The logon sequence taken by an FTAM Initiator when initiating a file
   transfer with an FTP Server is given below:

           % ftam gateway
           ftam> user username@DNS-string
           ftam> pass password

   The "ftam gateway" command initiates the connection between the FTAM
   Initiator and the gateway.  Once connected, userid and TCP/IP
   filestore are identified in the "username@DNS-string" argument to the
   user command.  If the FTP Server requires a password, a password
   prompt should appear after issuing the user command.

   The gateway should incorporate the BIND Resolver functionality so
   that upon receipt of a Domain Name, the Gateway FTP Client can
   resolve it via the distributed Domain Name System.

   Using a specific example, suppose that a FTP Server has the following
   Domain Name:  "ftp-service.netwrx1.com" and an FTP-FTAM gateway is
   available at:
Top   ToC   RFC1415 - Page 12
           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 Yard
                  @cn=wnyosi7
           ftam> user mindel@ftp-service.netwrx1.com
           ftam> pass ***********

   Alternatively, a User Friendly Name could be used rather than the
   Distinguished Name.

   As mentioned in the previous section, "Use of the FTP-Initiated
   Gateway Service", use of an intermediate gateway is not transparent.
   The gateway can be made more transparent through the registration of
   the FTP host in the X.500 OSI Directory.  By querying the X.500 OSI
   Directory, the gateway can identify where the actual host is
   resident.

   For example, suppose that the FTP Server in the previous example
   ("ftp-service.netwrx1.com") is registered in the X.500 Directory with
   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 Services
                  @cn=netwrx1@cn=FTP Service"
           ftam> user mindel
           ftam> pass ***********

4.3. Summary of Usage

   As shown in the discussions of the FTP-Initiated and FTAM-Initiated
   Gateway Services, the gateway user does not have access to the
   gateway filesystem; he merely makes use of the gateway logon
   procedure to specify the ultimate destination userid and password.
Top   ToC   RFC1415 - Page 13
   Two methods of interaction with the gateway were described.  In the
   former, the user must:

       1. Be aware that a gateway is required to reach the
          destination FTP or FTAM host.

       2. Determine which gateway is most appropriate for their
          respective source-destination pair.

       3. Explicitly connect to the gateway host prior to connecting
          to the destination host.

   Needless to say, the exchange of files between FTP and FTAM hosts
   requires more effort than that required for the exchange of files
   between a pair of hosts utilizing the same file transfer protocol.

   The latter, more transparent method does not necessarily require that
   the user determine which gateway is most appropriate for their
   respective source-destination pair.  In fact, filestore service
   providers are registered using the address of a predetermined
   gateway.  With this approach, the user:

       1. Must be aware that a gateway is required to reach the
          destination FTP or FTAM host.

       2. Need not determine which gateway is most appropriate to
          access their ultimate destination host.

       3. Need not explicitly connect to the gateway prior to
          connecting to the destination FTP or FTAM host.

5. Gateway State Variables and Transitions

   As described, the FTP-FTAM gateway provides two sets of services:
   FTP-Initiated and FTAM-Initiated.  Each service has its own mutually
   exclusive set of state variables and transitions that
   deterministically define the actions of the gateway.  Gateway support
   for these state variables and transitions is required.

   For conciseness in this discussion, FTP-Initiated will be abbreviated
   with "FTP-I", and FTAM-Initiated will be abbreviated with "FTAM-I".

   Concerning error conditions, if a connection is dropped when the
   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 to
   the host with the remaining connection, and then drop that
   connection.  If the remaining host is an FTP Client, then the gateway
   will send an ABOR, QUIT, and 426 reply code (Connection closed,
Top   ToC   RFC1415 - Page 14
   transfer aborted).  If it is an FTAM Initiator, then the gateway will
   send an F-P-ABORT with a <Diagnostic> value with identifier 1011
   (Lower layer failure), as well as any known <Further Details>.

   Other error conditions are not addressed in this discussion.

5.1. FTP-Initiated Gateway Service

   The set of state variables for the FTP-Initiated Gateway service
   follow:

  State Variable                State Definition
  ----------------------------------------------------------------

  FTP-I:Initial-State           Initial state of FTP-Initiated Gateway
                                service.

                                Gateway is waiting for an FTP Client to
                                issue a USER command in order to
                                proceed with connection establishment
                                with remote FTAM Responder.  If SITE or
                                ACCT commands are sent while waiting
                                for USER command, save arguments for
                                subsequent use.

  FTP-I:Wait-for-PASS           Gateway has already received USER
                                command from FTP Client, as well as
                                userid and destination host DN.
                                Gateway is waiting for the FTAM
                                Responder logon password.

  FTP-I:Wait-for-PAddress       Gateway has already received PASS
                                command from FTP Client.  Gateway is
                                resolving the provided FTAM Responder's
                                address to a Presentation Address.  The
                                provided address may be a Distinguished
                                Name, User Friendly Name, or Domain
                                Name.  Resolution will typically be
                                done using X.500 directory services.

  FTP-I:Wait-for-Connection     Gateway has initiated a connection to
                                the FTAM Responder and is waiting for
                                notification as to whether or not the
                                logon is successful.

  FTP-I:Wait-for-ClientCmd      Connection exists between FTP Client
                                and FTAM Responder.  Gateway is waiting
                                for next command or response from FTP
Top   ToC   RFC1415 - Page 15
                                Client.  Commands and responses are
                                mapped as they are received.

  FTP-I:Wait-for-RespondrCmd    Connection exists between FTP Client
                                and FTAM Responder.  Gateway is waiting
                                for next command or response from FTAM
                                Responder.  Commands and responses are
                                mapped as they are received.

   Each of the possible state transitions is provided in the remainder
   of Section 5.1.  For each state transition, the actions causing the
   transition are listed.

5.1.1. FTP-I:Initial-State   -->   FTP-I:Initial-State

        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-PASS

        1. Gateway receives USER command from FTP Client.  Arguments
           include Distinguished Name of FTAM Responder and userid on
           FTAM responder.

5.1.3. FTP-I:Wait-for-PASS   -->   FTP-I:Wait-for-PAddress

        1. Gateway receives PASS command from FTP Client.

5.1.4. FTP-I:Wait-for-PAddress   -->   FTP-I:Wait-for-Connection

        1. Gateway resolves received Distinguished Name, User Friendly
           Name, or Domain Name of FTAM Responder to OSI Presentation
           address.
        2. Gateway sends F-INITIALIZE to FTAM Responder with
           Presentation Address in <Called Presentation Address>,
           userid in <Initiator Identity>, and password in <Filestore
           Password>.

5.1.5. FTP-I:Wait-for-Connection   -->   FTP-I:Wait-for-NextMapping

        1. Gateway receives <State Result> of "Success" .
        2. Gateway sends 230 reply code (User Logged In) to FTP
           Client.

5.1.6. FTP-I:Wait-for-ClientCmd   -->   FTP-I:Wait-for-RespondrCmd

        1. Gateway receives command or response from FTP Client and
           maps it to FTAM protocol, as defined in section 8.1.
Top   ToC   RFC1415 - Page 16
5.1.7. FTP-I:Wait-for-RespondrCmd   -->   FTP-I:Wait-for-ClientCmd

        1. Gateway receives command or response from FTAM Responder
           and maps it to FTP protocol, as defined in section 8.1.

5.1.8. FTP-I:Wait-for-ClientCmd   -->   FTP-I:Wait-for-USER

        1. Gateway receives QUIT command from FTP Client; maps QUIT as
           per Section 8.1.

5.2. FTAM-Initiated Gateway Service

   The set of state variables for the FTAM-Initiated Gateway service
   follow:

  State Variable                State Definition
  ----------------------------------------------------------------

  FTAM-I:Initial-State          Initial state of FTAM-Initiated Gateway
                                Service.

                                Gateway is waiting for an FTAM
                                Initiator to issue an F-INITIALIZE
                                command in order to proceed with
                                connection establishment with remote
                                FTP Server.

  FTAM-I:Wait-for-IPAddress     Gateway has already received F-
                                INITIALIZE from FTAM Initiator.
                                Gateway is resolving the provided FTP
                                Server's address to an IP address.  The
                                provided address may be a Domain Name,
                                Distinguished Name, or User Friendly
                                Name.

  FTAM-I:Wait-for-Connection    Gateway has initiated a connection to
                                the FTP Server and is waiting for
                                notification as to whether or not the
                                logon is successful.

  FTAM-I:Wait-for-InitiatrCmd   Connection exists between FTAM
                                Initiator and FTP Server.  Gateway is
                                waiting for next command or response
                                from FTAM Initiator.  Commands and
                                responses are mapped as they are
                                received.
Top   ToC   RFC1415 - Page 17
  FTP-I:Wait-for-ServerCmd      Connection exists between FTAM
                                Initiator and FTP Server.  Gateway is
                                waiting for next command or response
                                from FTP Server.  Commands and
                                responses are mapped as they are
                                received.

   Each of the possible state transitions is provided in the remainder
   of Section 5.2.  For each state transition, the actions causing the
   transition are listed.

5.2.1. FTAM-I:Initial-State   -->   FTAM-I:Wait-for-IPAddress

        1. Gateway receives F-INITIALIZE from FTAM Initiator.  Domain
           Name of FTP Server is either in <Responding Presentation
           Address> or in the "@host" portion of the <Initiator
           Identity> parameter.  The userid is in <Initiator
           Identity>, and password is in <Filestore Password>
           parameter.

5.2.2. FTAM-I:Wait-for-IPAddress   -->   FTAM-I:Wait-for-Connection

        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-NextMapping

        1. Gateway receives 230 reply code (User Logged In) from FTP
           Server.
        2. Gateway sends <State Result> of "Success" to FTAM
           Initiator.

5.2.4  FTAM-I:Wait-for-InitiatrCmd   -->   FTAM-I:Wait-for-ServerCmd

        1. Gateway receives command or response from FTAM Initiator
           and maps it to FTP protocol, as defined in section 8.2.

5.2.5. FTAM-I:Wait-for-ServerCmd   -->   FTAM-I:Wait-for-InitiatrCmd

        1. Gateway receives command or response from FTP Server and
           maps it to FTAM protocol, as defined in section 8.2.

5.2.6. FTAM-I:Wait-for-InitiatrCmd  -->  FTAM-I:Wait-for-INITIALIZE

        1. Gateway receives F-CLOSE primitive from FTAM Initiator;
           maps F-CLOSE as per Section 8.2.


(next page on part 2)

Next Section