rfc1415.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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

             |                                            |

             |                                            |

             |                                            |

             |                                            |

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

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



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



Mindel & Slaski                                                 [Page 8]

RFC 1415             FTP-FTAM Gateway Specification         January 1993


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



Mindel & Slaski                                                 [Page 9]

RFC 1415             FTP-FTAM Gateway Specification         January 1993


   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:




Mindel & Slaski                                                [Page 10]

RFC 1415             FTP-FTAM Gateway Specification         January 1993


           % 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:






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 Yard
                  @cn=wnyosi7
           ftam> user [e-mail]
           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.



Mindel & Slaski                                                [Page 12]

RFC 1415             FTP-FTAM Gateway Specification         January 1993


   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