# data[].attributes.attachment_caption
Apuntes Servicios en red de otros profes

# data[].attributes.attachment_link.description
Made with Softr, the easiest way to turn your data into portals and internal tools.

# data[].attributes.attachment_link.readable_text
VirtualBox is a powerful x86 and AMD64/Intel64 virtualization product for enterprise as well as home use. Not only is VirtualBox an extremely feature rich, high performance product for enterprise customers, it is also the only professional solution that is freely available as Open Source Software under the terms of the GNU General Public License (GPL) version 3. See " About VirtualBox" for an introduction.

Presently, VirtualBox runs on Windows, Linux, macOS, and Solaris hosts and supports a large number of guest operating systems including but not limited to Windows (NT 4.0, 2000, XP, Server 2003, Vista, 7, 8, Windows 10 and Windows 11), DOS/Windows 3.x, Linux (2.4, 2.6, 3.x, 4.x, 5.x and 6.x), Solaris and OpenSolaris, OS/2, OpenBSD, NetBSD and FreeBSD.

VirtualBox is being actively developed with frequent releases and has an ever growing list of features, supported guest operating systems and platforms it runs on. VirtualBox is a community effort backed by a dedicated company: everyone is encouraged to contribute while Oracle ensures the product always meets professional quality criteria.

Hot picks:

# data[].attributes.attachment_link.description
VirtualBox is a powerful x86 and AMD64/Intel64 virtualization product for enterprise as well as home use. Not only is VirtualBox an extremely feature rich, high performance product for enterprise customers, it is also the only professional solution that is freely available as Open Source Software under the terms of the GNU General Public License (GPL) version 3.

# data[].attributes.attachment_link.readable_text
OpenSSH 9.6 released December 18, 2023

OpenSSH is the premier connectivity tool for remote login with the SSH protocol. It encrypts all traffic to eliminate eavesdropping, connection hijacking, and other attacks. In addition, OpenSSH provides a large suite of secure tunneling capabilities, several authentication methods, and sophisticated configuration options.

The OpenSSH suite consists of the following tools:

OpenSSH is developed by a few developers of the OpenBSD Project and made available under a BSD-style license.

OpenSSH is incorporated into many commercial products, but very few of those companies assist OpenSSH with funding.

Contributions towards OpenSSH can be sent to the OpenBSD Foundation.

# data[].attributes.attachment_link.readable_text
Secure Shell Working Group                                  J. Galbraith
Internet-Draft                                          VanDyke Software
Expires: January 11, 2007                                   O. Saarenmaa
                                                                F-Secure
                                                           July 10, 2006


                       SSH File Transfer Protocol
                    draft-ietf-secsh-filexfer-13.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance withSection 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed athttp://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed athttp://www.ietf.org/shadow.html. This Internet-Draft will expire on January 11, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The SSH File Transfer Protocol provides secure file transfer functionality over any reliable, bidirectional octect stream. It is the standard file transfer protocol for use with the SSH2 protocol. This document describes the file transfer protocol and its interface to the SSH2 protocol suite. Galbraith & Saarenmaa Expires January 11, 2007 [Page 1]

Internet-Draft         SSH File Transfer Protocol              July 2006


Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 42. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43. Use with the SSH Connection Protocol . . . . . . . . . . . . . 43.1. The Use of 'stderr' in the server . . . . . . . . . . . . 54. General Packet Format . . . . . . . . . . . . . . . . . . . . 54.1. Request Synchronization and Reordering . . . . . . . . . . 64.2. New data types defined by this document . . . . . . . . . 74.3. Packet Types . . . . . . . . . . . . . . . . . . . . . . . 75. Protocol Initialization . . . . . . . . . . . . . . . . . . . 95.1. Client Initialization . . . . . . . . . . . . . . . . . . 95.2. Server Initialization . . . . . . . . . . . . . . . . . . 95.3. Determining Server Newline Convention . . . . . . . . . . 105.4. Supported Features . . . . . . . . . . . . . . . . . . . . 105.5. Version re-negotiation . . . . . . . . . . . . . . . . . . 146. File Names . . . . . . . . . . . . . . . . . . . . . . . . . . 157. File Attributes . . . . . . . . . . . . . . . . . . . . . . . 167.1. valid-attribute-flags . . . . . . . . . . . . . . . . . . 177.2. Type . . . . . . . . . . . . . . . . . . . . . . . . . . . 187.3. Size . . . . . . . . . . . . . . . . . . . . . . . . . . . 187.4. allocation-size . . . . . . . . . . . . . . . . . . . . . 197.5. Owner and Group . . . . . . . . . . . . . . . . . . . . . 197.6. Permissions . . . . . . . . . . . . . . . . . . . . . . . 207.7. Times . . . . . . . . . . . . . . . . . . . . . . . . . . 217.8. ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . 217.9. attrib-bits and attrib-bits-valid . . . . . . . . . . . . 247.10. text-hint . . . . . . . . . . . . . . . . . . . . . . . . 277.11. mime-type . . . . . . . . . . . . . . . . . . . . . . . . 277.12. link-count . . . . . . . . . . . . . . . . . . . . . . . . 277.13. untranslated-name . . . . . . . . . . . . . . . . . . . . 287.14. Extended Attributes . . . . . . . . . . . . . . . . . . . 288. Requests From the Client to the Server . . . . . . . . . . . . 288.1. Opening and Closing Files and Directories . . . . . . . . 288.1.1. Opening a File . . . . . . . . . . . . . . . . . . . . 298.1.2. Opening a Directory . . . . . . . . . . . . . . . . . 358.1.3. Closing Handles . . . . . . . . . . . . . . . . . . . 358.2. Reading and Writing . . . . . . . . . . . . . . . . . . . 368.2.1. Reading Files . . . . . . . . . . . . . . . . . . . . 368.2.2. Reading Directories . . . . . . . . . . . . . . . . . 378.2.3. Writing Files . . . . . . . . . . . . . . . . . . . . 378.3. Removing and Renaming Files . . . . . . . . . . . . . . . 388.4. Creating and Deleting Directories . . . . . . . . . . . . 398.5. Retrieving File Attributes . . . . . . . . . . . . . . . . 408.6. Setting File Attributes . . . . . . . . . . . . . . . . . 418.7. Dealing with Links . . . . . . . . . . . . . . . . . . . . 428.8. Byte-range locks . . . . . . . . . . . . . . . . . . . . . 438.8.1. Obtaining a byte range lock . . . . . . . . . . . . . 43 Galbraith & Saarenmaa Expires January 11, 2007 [Page 2]

Internet-Draft         SSH File Transfer Protocol              July 2006


8.8.2. Releasing a byte range lock . . . . . . . . . . . . . 448.9. Canonicalizing the Server-Side Path Name . . . . . . . . . 458.9.1. Best Practice for Dealing with Paths . . . . . . . . . 469. Responses from the Server to the Client . . . . . . . . . . . 479.1. Status Response . . . . . . . . . . . . . . . . . . . . . 489.2. Handle Response . . . . . . . . . . . . . . . . . . . . . 529.3. Data Response . . . . . . . . . . . . . . . . . . . . . . 529.4. Name Response . . . . . . . . . . . . . . . . . . . . . . 539.5. Attrs Response . . . . . . . . . . . . . . . . . . . . . . 5310. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 5411. Implementation Considerations . . . . . . . . . . . . . . . . 5512. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5513. Security Considerations . . . . . . . . . . . . . . . . . . . 5514. Changes from Previous Protocol Versions . . . . . . . . . . . 5715. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5715.1. Normative References . . . . . . . . . . . . . . . . . . . 5715.2. Informative References . . . . . . . . . . . . . . . . . . 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .59 Intellectual Property and Copyright Statements . . . . . . . . . .60 Galbraith & Saarenmaa Expires January 11, 2007 [Page 3]

Internet-Draft         SSH File Transfer Protocol              July 2006


1. Introduction This protocol provides secure file transfer (and more generally file system access). It is designed so that it could be used to implement a secure remote file system service as well as a secure file transfer service. This protocol assumes that it runs over a secure channel, such as a channel in [RFC4251], that the server has already authenticated the client, and that the identity of the client user is available to the protocol. In general, this protocol follows a simple request-response model. Each request and response contains a sequence number and multiple requests may be pending simultaneously. There are a relatively large number of different request messages, but a small number of possible response messages. Each request has one or more response messages that may be returned in result (e.g., a read either returns data or reports error status). The packet format descriptions in this specification follow the notation presented in [RFC4251]. Even though this protocol is described in the context of the SSH2 protocol, this protocol is general and independent of the rest of the SSH2 protocol suite. It could be used in a number of different applications, such as secure file transfer over TLS [RFC2246] and transfer of management information in VPN applications.2. Acknowledgements This document owes its initial creation and protocol design to Tatu Ylonen and Sami Lehtinen of SSH Communications Security Corp. We express our gratitude to them for their initial work on this protocol.3. Use with the SSH Connection Protocol When used with the SSH2 Protocol suite, this protocol is intended to be used as a subsystem as described in [RFC4254] in the section "Starting a Shell or a Command". The subsystem name used with this protocol is "sftp". Galbraith & Saarenmaa Expires January 11, 2007 [Page 4]

Internet-Draft         SSH File Transfer Protocol              July 2006


3.1. The Use of 'stderr' in the server This protocol uses stdout and stdin to transmit binary protocol data. The "session" channel ([RFC4254]), which is used by the subsystem, also supports the use of stderr. Data sent on stderr by the server SHOULD be considered free format debug or supplemental error information, and MAY be displayed to the user. For example, during initialization, there is no client request active, so errors or warning information cannot be sent to the client as part of the SFTP protocol at this early stage. However, the errors or warnings MAY be sent as stderr text.4. General Packet Format All packets transmitted over the secure connection are of the following format: uint32 length byte type uint32 request-id ... type specific fields ... 'length' The length of the entire packet, excluding the length field itself, such that, for example, for a packet type containing no type specific fields, the length field would be 5, and 9 bytes of data would be sent on the wire. (This is the packet format used in [RFC4253].) All packet descriptions in this document omit the length field for brevity; the length field MUST be included in any case. The maximum size of a packet is in practice determined by the client (the maximum size of read or write requests that it sends, plus a few bytes of packet overhead). All servers SHOULD support packets of at least 34000 bytes (where the packet size refers to the full length, including the header above). This should allow for reads and writes of at most 32768 bytes. 'type' The type code for the packet. Galbraith & Saarenmaa Expires January 11, 2007 [Page 5]

Internet-Draft         SSH File Transfer Protocol              July 2006


   There are no restrictions on the order in which responses to
   outstanding requests are delivered to the client, except that the
   server must ensure fairness in the sense that processing of no
   request will be indefinitely delayed even if the client is sending
   other requests so that there are multiple outstanding requests all
   the time.

   A client MUST be prepared to receive responses to multiple overlapped
   requests out of order.

4.2. New data types defined by this document This document defines these data types in addition to those defined in [RFC4251]. uint16 Represents a 16-bit unsigned integer. Stored as 2 bytes in the order of decreasing significance (network byte order). int64 Represents a 64-bit signed integer. Stored using two's complement, as eight bytes in the order of decreasing significance (network byte order). extension-pair string extension-name string extension-data 'extension-name' is the name of a protocol extension. Extensions not defined by IETF CONSENSUS MUST follow the the DNS extensibility naming convention outlined in [RFC4251]. 'extension-data' is any data specific to the extension, and MAY be zero length if the extension has no data.4.3. Packet Types The following values are defined for packet types. Galbraith & Saarenmaa Expires January 11, 2007 [Page 7]

Internet-Draft         SSH File Transfer Protocol              July 2006


   protocol version (Section 5). Because the client has no way to respond to unrecognized packet types, new packet types to be sent from the server to the client the client MUST not used unless the protocol version is changed or the client has negotiated to received them. This negotiation MAY be explicit, through the use of extensions, or MAY be implicit, by the client itself using a packet type not defined above.5. Protocol Initialization When the file transfer protocol starts, the client first sends a SSH_FXP_INIT (including its version number) packet to the server. The server responds with a SSH_FXP_VERSION packet, supplying the lowest of its own and the client's version number. Both parties should from then on adhere to that particular version of the protocol. The version number of the protocol specified in this document is 6. The version number should be incremented for each incompatible revision of this protocol. Note that these two packets DO NOT contain a request id. These are the only such packets in the protocol.5.1. Client Initialization The SSH_FXP_INIT packet (from client to server) has the following data: uint32 version 'version' is the version number of the client. If the client wishes to interoperate with servers that support noncontiguous version numbers it SHOULD send '3', and then use the 'version-select' extension (see below.) Otherwise, this value is '6' for this version of the protocol.5.2. Server Initialization The SSH_FXP_VERSION packet (from server to client) has the following data: uint32 version extension-pair extensions[0..n] 'version' is the lower of the protocol version supported by the server and the version number received from the client. Galbraith & Saarenmaa Expires January 11, 2007 [Page 9]

Internet-Draft         SSH File Transfer Protocol              July 2006


   'extensions' is 0 or more extension-pairs (Section 4.2). Implementations MUST silently ignore any extensions whose names they do not recognize.5.3. Determining Server Newline Convention In order to correctly process text files in a cross platform compatible way, newline sequences must be converted between client and server conventions. The SSH_FXF_TEXT_MODE file open flag (Section 8.1.1) makes it possible to request that the server translate a file to a 'canonical' wire format. This format uses CRLF as the line separator. Servers for systems using other conventions MUST translate to and from the canonical form. However, to ease the burden of implementation on servers that use a single, simple, separator sequence the following extension allows the canonical format to be changed. string "newline" string new-canonical-separator (usually CR or LF or CRLF) All clients MUST support this extension. When processing text files, clients SHOULD NOT translate any character or sequence that is not an exact match of the server's newline separator. In particular, if the newline sequence being used is the canonical CRLF sequence, a lone CR or a lone LF SHOULD be written through without change.5.4. Supported Features The sftp protocol has grown to be very rich, and now supports a number of features that may not be available on all servers. When a server receives a request for a feature it cannot support, it MUST return a SSH_FX_OP_UNSUPPORTED status code, unless otherwise specified. The following extension facilitates clients being able to use the maximum available feature set, and yet not be overly burdened by dealing with SSH_FX_OP_UNSUPPORTED status codes. All servers MUST include it as part of their version packet. Galbraith & Saarenmaa Expires January 11, 2007 [Page 10]

Internet-Draft         SSH File Transfer Protocol              July 2006


       string "supported2"
       string supported-structure
           uint32 supported-attribute-mask
           uint32 supported-attribute-bits
           uint32 supported-open-flags
           uint32 supported-access-mask
           uint32 max-read-size
           uint16 supported-open-block-vector
           uint16 supported-block-vector
           uint32 attrib-extension-count
           string attrib-extension-names[attrib_extension-count]
           uint32 extension-count
           string extension-names[extension-count]

   Note that the name "supported2" is used here to avoid conflict with
   the slightly different "supported" extension that was previously
   used.
   supported-attribute-mask
      This mask MAY be applied by the client to the 'File Attributes'
      valid-attribute-flags field (Section 7.1) in order to ensure that no unsupported attributes are present during a operation which writes attributes. supported-attribute-bits This mask MAY be applied by the client to the 'File Attributes' attrib-bits field (Section 7.9) in order to ensure that no unsupported attrib-bits are present during a operation which writes attribute bits. supported-open-flags The supported-open-flags mask MAY be applied by the client to the SSH_FXP_OPEN (Section 8.1.1) flags field. supported-access-mask This mask may be applied by the client to the ace-mask field of an ACL during a operation that writes the ACL. This mask SHOULD NOT be applied to the desired-access field of the SSH_FXP_OPEN (Section 8.1.1) request. Doing so will simply result in not requesting the access required by the client. In the case of open operations, the server is responsible for translating the client's requested access to a mode it supports that is sufficient to grant all access requested by the client. Galbraith & Saarenmaa Expires January 11, 2007 [Page 11]

Internet-Draft         SSH File Transfer Protocol              July 2006


   max-read-size
      This is the maximum read size that the server guarantees to
      complete.  For example, certain embedded server implementations
      complete only the first 4K of a read, even if there is additional
      data to be read from the file.

      If the server specifies a non-zero value for max-read-size, it
      MUST return the requested number of bytes for reads that are less
      than or equal to the value, unless it encounters EOF or an ERROR.

      The server MAY use this value to express that it is willing to
      handle very large read requests, in excess of the standard 34000
      bytes specified inSection 4. supported-open-block-vector supported-block-vector 16-bit masks specifying which combinations of blocking flags are supported. Each bit corresponds to one combination of the SSH_FXF_BLOCK_READ, SSH_FXF_BLOCK_WRITE, SSH_FXF_BLOCK_DELETE, and SSH_FXF_BLOCK_ADVISORY bits fromSection 8.1.1.3, with a set bit corresponding to a supported combination and a clear bit an unsupported combination. The index of a bit, bit zero being the least significant bit, viewed as a four-bit number, corresponds to a combination of flag bits, shifted right so that BLOCK_READ is the least significant bit. The combination `no blocking flags' MUST be supported, so the low bit will always be set. For example, a server supporting only the classic advisory read (shared) and write (exclusive) locks would set the bits corresponding to READ+WRITE+ADVISORY, 0b1011, and WRITE+ADVISORY, 0b1010, plus the always-set bit 0b0000, giving a mask value of 0b0000110000000001, or 0x0c01; a server supporting no locking at all would set only bit zero, giving 0x0001. 'supported-open-block-masks' applies to the SSH_FXP_OPEN (Section 8.1.1) flags field. 'supported-block-masks' applies to the SSH_FXF_BLOCK request. attrib-extension-count Count of extension names in the attrib-extension-names array. attrib-extension-names Names of extensions that can be used in an ATTRS (Section 7.14) structure. Galbraith & Saarenmaa Expires January 11, 2007 [Page 12]

Internet-Draft         SSH File Transfer Protocol              July 2006


   extension-count
      Count of extension names in the extension-names array.

   extension-names
      Names of extensions that can be used with the SSH_FXP_EXTEND
      (Section 10) packet. Naturally, if a given attribute field, attribute mask bit, open flag, or extension is required for correct operation, the client MUST either not mask the bit off, or MUST fail the operation gracefully without sending the request to the server. The client MAY send requests that are not supported by the server; however, it is not normally expected to be productive to do so. The client SHOULD apply the mask even to attrib structures received from the server. The server MAY include attributes or attrib-bits that are not included in the mask. Such attributes or attrib-bits are effectively read-only. The supported capabilities of the acl attribute are sent using the following extension. string "acl-supported" string supported-structure uint32 capabilities 'capabilities' is a combination of the following bits: SSH_ACL_CAP_ALLOW 0x00000001 SSH_ACL_CAP_DENY 0x00000002 SSH_ACL_CAP_AUDIT 0x00000004 SSH_ACL_CAP_ALARM 0x00000008 SSH_ACL_CAP_INHERIT_ACCESS 0x00000010 SSH_ACL_CAP_INHERIT_AUDIT_ALARM 0x00000020 SSH_ACL_CAP_ALLOW SSH_ACL_CAP_DENY SSH_ACL_CAP_AUDIT SSH_ACL_CAP_ALARM The server supports the associated ACL ACE type. SSH_ACL_CAP_INHERIT_ACCESS The server can control whether a ACL will inherit DENY and ALLOW ACEs that are marked inheritable from it's parent object. Galbraith & Saarenmaa Expires January 11, 2007 [Page 13]

Internet-Draft         SSH File Transfer Protocol              July 2006


   SSH_ACL_CAP_INHERIT_AUDIT_ALARM
      The server can control whether a ACL will inherit AUDIT or ALARM
      ACEs that are marked inheritable from it's parent object.


5.5. Version re-negotiation If the server supports other versions than what was negotiated, it may wish to send the 'versions' extension to inform the client of this fact. The client may then optionally choose to use one of the other versions supported. string "versions" string comma-separated-versions 'comma-separated-versions' is a string of comma separated version numbers. Defined versions are: "2", "3", "4", "5", "6". Any other version advertised by the server must follow the DNS extensibility naming convention outlined in [RFC4251]. For example: "2,3,6,private@example.com". If the client and server have negotiated a a version greater than or equal to version '3' (the version at which SSH_FXP_EXTENDED was introduced) in the initial VERSION/INIT exchange, the client may select a new version to use from the list the server provided using the following SSH_FXP_EXTENDED request. string "version-select" string version-from-list If the 'version-from-list' is one of the versions on the servers list, the server MUST respond with SSH_FX_OK. If the server did not send the "versions" extension, or the version-from-list was not included, the server MAY send a status response describing the failure, but MUST then close the channel without processing any further requests. The 'version-select' MUST be the first request from the client to the server; if it is not, the server MUST fail the request and close the channel. Although this request does take a full round trip, no client need wait for the response before continuing, because any valid request MUST succeed, and any invalid request results in a channel close. Since the request is the first request, it is not possible for the server to have already sent responses conforming to the old version. Galbraith & Saarenmaa Expires January 11, 2007 [Page 14]

Internet-Draft         SSH File Transfer Protocol              July 2006


   Typically, the client SHOULD NOT down-grade the protocol version
   using this extension; however, it is not forbidden to do so.  One
   reason a client might do so is to work around a buggy implementation.


6. File Names This protocol represents file names as strings. File names are assumed to use the slash ('/') character as a directory separator. File names starting with a slash are "absolute", and are relative to the root of the file system. Names starting with any other character are relative to the user's default directory (home directory). Note that identifying the user is assumed to take place outside of this protocol. Servers SHOULD interpret a path name component ".." (Section 13) as referring to the parent directory, and "." as referring to the current directory. An empty path name is valid, and it refers to the user's default directory (usually the user's home directory). Otherwise, no syntax is defined for file names by this specification. Clients should not make any other assumptions; however, they can splice path name components returned by SSH_FXP_READDIR together using a slash ('/') as the separator, and that will work as expected. It is understood that the lack of well-defined semantics for file names may cause interoperability problems between clients and servers using radically different operating systems. However, this approach is known to work acceptably with most systems, and alternative approaches that e.g. treat file names as sequences of structured components are quite complicated. The preferred encoding for filenames is UTF-8. This is consistent with IETF Policy on Character Sets and Languages [RFC2277] and it is further supposed that the server is more likely to support any local character set and be able to convert it to UTF-8. However, because the server does not always know the encoding of filenames, it is not always possible for the server to preform a valid translation to UTF-8. When an invalid translation to UTF-8 is preformed, it becomes impossible to manipulate the file, because the translation is not reversible. Therefore, the following extensions are provided in order to make it possible for the server to communicate it's abilities to the client, and to allow the client to control whether the server attempts the conversion. Galbraith & Saarenmaa Expires January 11, 2007 [Page 15]

Internet-Draft         SSH File Transfer Protocol              July 2006


   are 'as encoded on the wire.'  The server can use this information to
   determine if the client sent all the intended data and the file was
   transfered in its entirity.

   If this field is present during a setstat operation, the file MUST be
   extended or truncated to the specified size.  If the file is
   extended, the semantics are to write the byte value 0x00 from the
   previous end of file to the new offset.

   Files opened with the SSH_FXF_TEXT flag may have a size that is
   greater or less than the value of the size field.  The server MAY
   fail setstat operations specifying size for files opened with the
   SSH_FXF_TEXT flag.

7.4. allocation-size The 'allocation-size' field specifies the number of bytes that the file consumes on disk. This field MAY be less than the 'size' field if the file is 'sparse' (Section 7.9). It will usually be larger than the 'size' field, however, as most file-systems allocate space to files in units that are larger than a single byte. When present during file creation, the file SHOULD be created and the specified number of bytes preallocated. If the preallocation fails, the file should be removed (if it was created) and an error returned. If this field is present during a setstat operation, the file allocation SHOULD be changed to the specified size. If the allocation size is increased, additional space is allocated to the file, but the 'size' is not changed (the end-of-file marker is not move.) If the new allocation size is smaller, than the operation is effectively a truncation. Querying the 'allocation-size' after setting it MUST return a value that is greater-than or equal to the value set, but it MAY not return the precise value set. If both 'size' and 'allocation-size' are set during a setstat operation, and 'allocation-size' is less than 'size', the server MUST return SSH_FX_INVALID_PARAMETER.7.5. Owner and Group The 'owner' and 'group' fields are represented as UTF-8 strings; this is the form used by NFS v4. See NFS version 4 Protocol [RFC3010]. The following text is selected quotations fromsection 5.6. To avoid a representation that is tied to a particular underlying Galbraith & Saarenmaa Expires January 11, 2007 [Page 19]

Internet-Draft         SSH File Transfer Protocol              July 2006


   implementation at the client or server, the use of UTF-8 strings has
   been chosen.  The string should be of the form "user@dns_domain".
   This will allow for a client and server that do not use the same
   local representation the ability to translate to a common syntax that
   can be interpreted by both.  In the case where there is no
   translation available to the client or server, the attribute value
   must be constructed without the "@".  Therefore, the absence of the @
   from the owner or owner_group attribute signifies that no translation
   was available and the receiver of the attribute should not place any
   special meaning on the attribute value.  Even though the attribute
   value cannot be translated, it may still be useful.  In the case of a
   client, the attribute string may be used for local display of
   ownership.

   user@localhost represents a user in the context of the server.

   If either the owner or group field is zero length, the field should
   be considered absent, and no change should be made to that specific
   field during a modification operation.

7.6. Permissions The 'permissions' field contains a bit mask specifying file permissions. These permissions correspond to the st_mode field of the stat structure defined by POSIX [IEEE.1003-1.1996]. This protocol uses the following values for the symbols declared in the POSIX standard. S_IRUSR 0000400 (octal) S_IWUSR 0000200 S_IXUSR 0000100 S_IRGRP 0000040 S_IWGRP 0000020 S_IXGRP 0000010 S_IROTH 0000004 S_IWOTH 0000002 S_IXOTH 0000001 S_ISUID 0004000 S_ISGID 0002000 S_ISVTX 0001000 Implementations MUST NOT send bits that are not defined. The server SHOULD NOT apply a 'umask' to the mode bits; but should set the mode bits as specified by the client. The client MUST apply an appropriate 'umask' to the mode bits before sending them. Galbraith & Saarenmaa Expires January 11, 2007 [Page 20]

Internet-Draft         SSH File Transfer Protocol              July 2006




   The 'atime' field contains the last access time of the file.  Many
   operating systems either don't have this field, only optionally
   maintain it, or maintain it with less resolution than other fields.

   The 'mtime' contains the last time the file was written.

   'createtime' contains the creation time of the file.

   'ctime' contains the last time the file attributes were changed.  The
   exact meaning of this field depends on the server.

   All times are represented as seconds from Jan 1, 1970 in UTC.  A
   negative value indicates number of seconds before Jan 1, 1970.  In
   both cases, if the SSH_FILEXFER_ATTR_SUBSECOND_TIMES flag is set, the
   nseconds field is to be added to the seconds field for the final time
   representation.  For example, if the time to be represented is one-
   half second before 0 hour January 1, 1970, the seconds field would
   have a value of negative one (-1) and the nseconds fields would have
   a value of one-half second (500000000).  Values greater than
   999,999,999 for nseconds are considered invalid.



   The 'ACL' field contains an ACL similar to that defined insection5.9 of NFS version 4 Protocol [RFC3010]. The structure of the ACL is: uint32 acl-flags uint32 ace-count ACE ace[ace-count] The ACE data structure is composes as follows: uint32 ace-type uint32 ace-flag uint32 ace-mask string who [UTF-8] acl-flags SFX_ACL_CONTROL_INCLUDED 0x00000001 SFX_ACL_CONTROL_PRESENT 0x00000002 SFX_ACL_CONTROL_INHERITED 0x00000004 SFX_ACL_AUDIT_ALARM_INCLUDED 0x00000010 Galbraith & Saarenmaa Expires January 11, 2007 [Page 21]

Internet-Draft         SSH File Transfer Protocol              July 2006


      open request and must set the SFX_ACL_AUDIT_ALARM_INCLUDED during
      the setstat operation.

      Clients that do not intend specifically to modify the AUDIT or
      ALARM entries SHOULD NOT set SSH_FXF_ACCESS_AUDIT_ALARM_INFO in
      the open-flags and SHOULD NOT set the SFX_ACL_AUDIT_ALARM_INCLUDED
      bit because these operations are often privileged and will fail.

      If the SFX_ACL_AUDIT_ALARM_INCLUDED is set, and the requested
      change can not be made, the server MUST fail the request.

      Servers that do not seperate control and audit/alarm information
      may have to read the existing ACL and merge in enteries not
      included by the client.  The server must take this into account
      when opening files with the ACE4_WRITE_ACL permission requested.

   ace-type
      one of the following four values (taken from NFS Version 4
      Protocol [RFC3010]: ACE4_ACCESS_ALLOWED_ACE_TYPE 0x00000000 ACE4_ACCESS_DENIED_ACE_TYPE 0x00000001 ACE4_SYSTEM_AUDIT_ACE_TYPE 0x00000002 ACE4_SYSTEM_ALARM_ACE_TYPE 0x00000003 ace-flag A combination of the following flag values. See NFS Version 4 Protocol[RFC3010] section 5.9.2: ACE4_FILE_INHERIT_ACE 0x00000001 ACE4_DIRECTORY_INHERIT_ACE 0x00000002 ACE4_NO_PROPAGATE_INHERIT_ACE 0x00000004 ACE4_INHERIT_ONLY_ACE 0x00000008 ACE4_SUCCESSFUL_ACCESS_ACE_FLAG 0x00000010 ACE4_FAILED_ACCESS_ACE_FLAG 0x00000020 ACE4_IDENTIFIER_GROUP 0x00000040 ace-mask Combination of the following flags (taken from [RFC3010], section5.9.3. The semantic meaning of these flags is also given in [RFC3010]. Galbraith & Saarenmaa Expires January 11, 2007 [Page 23]

Internet-Draft         SSH File Transfer Protocol              July 2006




       ACE4_READ_DATA         0x00000001
       ACE4_LIST_DIRECTORY    0x00000001
       ACE4_WRITE_DATA        0x00000002
       ACE4_ADD_FILE          0x00000002
       ACE4_APPEND_DATA       0x00000004
       ACE4_ADD_SUBDIRECTORY  0x00000004
       ACE4_READ_NAMED_ATTRS  0x00000008
       ACE4_WRITE_NAMED_ATTRS 0x00000010
       ACE4_EXECUTE           0x00000020
       ACE4_DELETE_CHILD      0x00000040
       ACE4_READ_ATTRIBUTES   0x00000080
       ACE4_WRITE_ATTRIBUTES  0x00000100
       ACE4_DELETE            0x00010000
       ACE4_READ_ACL          0x00020000
       ACE4_WRITE_ACL         0x00040000
       ACE4_WRITE_OWNER       0x00080000
       ACE4_SYNCHRONIZE       0x00100000

   who
      UTF-8 string of the form described in 'Owner and Group'
      (Section 7.5) Also, as per '5.9.4 ACE who' [RFC3010] there are several identifiers that need to be understood universally. Some of these identifiers cannot be understood when an client access the server, but have meaning when a local process accesses the file. The ability to display and modify these permissions is permitted over SFTP. OWNER The owner of the file. GROUP The group associated with the file. EVERYONE The world. INTERACTIVE Accessed from an interactive terminal. NETWORK Accessed via the network. DIALUP Accessed as a dialup user to the server. BATCH Accessed from a batch job. ANONYMOUS Accessed without any authentication. AUTHENTICATED Any authenticated user (opposite of ANONYMOUS). SERVICE Access from a system service. To avoid conflict, these special identifiers are distinguish by an appended "@". For example: ANONYMOUS@.7.9. attrib-bits and attrib-bits-valid These fields, taken together, reflect various attributes of the file or directory, on the server. Galbraith & Saarenmaa Expires January 11, 2007 [Page 24]

Internet-Draft         SSH File Transfer Protocol              July 2006


   Bits not set in 'attrib-bits-valid' MUST be ignored in the 'attrib-
   bits' field.  This allows both the server and the client to
   communicate only the bits they knows about without inadvertently
   twiddling bits they don't understand.

   The following attrib-bits are defined:

       SSH_FILEXFER_ATTR_FLAGS_READONLY         0x00000001
       SSH_FILEXFER_ATTR_FLAGS_SYSTEM           0x00000002
       SSH_FILEXFER_ATTR_FLAGS_HIDDEN           0x00000004
       SSH_FILEXFER_ATTR_FLAGS_CASE_INSENSITIVE 0x00000008
       SSH_FILEXFER_ATTR_FLAGS_ARCHIVE          0x00000010
       SSH_FILEXFER_ATTR_FLAGS_ENCRYPTED        0x00000020
       SSH_FILEXFER_ATTR_FLAGS_COMPRESSED       0x00000040
       SSH_FILEXFER_ATTR_FLAGS_SPARSE           0x00000080
       SSH_FILEXFER_ATTR_FLAGS_APPEND_ONLY      0x00000100
       SSH_FILEXFER_ATTR_FLAGS_IMMUTABLE        0x00000200
       SSH_FILEXFER_ATTR_FLAGS_SYNC             0x00000400
       SSH_FILEXFER_ATTR_FLAGS_TRANSLATION_ERR  0x00000800

   SSH_FILEXFER_ATTR_FLAGS_READONLY
      Advisory, read-only bit.  This bit is not part of the access
      control information on the file, but is rather an advisory field
      indicating that the file should not be written.

   SSH_FILEXFER_ATTR_FLAGS_SYSTEM
      The file is part of the operating system.

   SSH_FILEXFER_ATTR_FLAGS_HIDDEN
      File SHOULD NOT be shown to user unless specifically requested.
      For example, most UNIX systems SHOULD set this bit if the filename
      begins with a 'period'.  This bit may be read-only (Section 5.4). Most UNIX systems will not allow this to be changed. SSH_FILEXFER_ATTR_FLAGS_CASE_INSENSITIVE This attribute applies only to directories. This attribute is always read-only, and cannot be modified. This attribute means that files and directory names in this directory should be compared without regard to case. It is recommended that where possible, the server's filesystem be allowed to do comparisons. For example, if a client wished to prompt a user before overwriting a file, it should not compare the new name with the previously retrieved list of names in the directory. Rather, it should first try to create the new file by specifying SSH_FXF_CREATE_NEW flag. Then, if this fails and returns SSH_FX_FILE_ALREADY_EXISTS, it should prompt the user and then retry the create specifying SSH_FXF_CREATE_TRUNCATE. Galbraith & Saarenmaa Expires January 11, 2007 [Page 25]

Internet-Draft         SSH File Transfer Protocol              July 2006


      Unless otherwise specified, filenames are assumed to be case
      sensitive.

   SSH_FILEXFER_ATTR_FLAGS_ARCHIVE
      The file should be included in backup / archive operations.

   SSH_FILEXFER_ATTR_FLAGS_ENCRYPTED
      The file is stored on disk using file-system level transparent
      encryption.  This flag does not affect the file data on the wire
      (for either READ or WRITE requests.)

   SSH_FILEXFER_ATTR_FLAGS_COMPRESSED
      The file is stored on disk using file-system level transparent
      compression.  This flag does not affect the file data on the wire.

   SSH_FILEXFER_ATTR_FLAGS_SPARSE
      The file is a sparse file; this means that file blocks that have
      not been explicitly written are not stored on disk.  For example,
      if a client writes a buffer at 10 M from the beginning of the
      file, the blocks between the previous EOF marker and the 10 M
      offset would not consume physical disk space.

      Some servers may store all files as sparse files, in which case
      this bit will be unconditionally set.  Other servers may not have
      a mechanism for determining if the file is sparse, and so the file
      MAY be stored sparse even if this flag is not set.

   SSH_FILEXFER_ATTR_FLAGS_APPEND_ONLY
      Opening the file without either the SSH_FXF_APPEND_DATA or the
      SSH_FXF_APPEND_DATA_ATOMIC flag (Section 8.1.1.3) MUST result in an SSH_FX_INVALID_PARAMETER error. SSH_FILEXFER_ATTR_FLAGS_IMMUTABLE The file cannot be deleted or renamed, no hard link can be created to this file, and no data can be written to the file. This bit implies a stronger level of protection than SSH_FILEXFER_ATTR_FLAGS_READONLY, the file permission mask or ACLs. Typically even the superuser cannot write to immutable files, and only the superuser can set or remove the bit. SSH_FILEXFER_ATTR_FLAGS_SYNC When the file is modified, the changes are written synchronously to the disk. Galbraith & Saarenmaa Expires January 11, 2007 [Page 26]

Internet-Draft         SSH File Transfer Protocol              July 2006


   SSH_FILEXFER_ATTR_FLAGS_TRANSLATION_ERR
      The server MAY include this bit in a directory listing or realpath
      response.  It indicates there was a failure in the translation to
      UTF-8.  If this flag is included, the server SHOULD also include
      the UNTRANSLATED_NAME attribute.


7.10. text-hint The value is one of the following enumerations, and indicates what the server knows about the content of the file. SSH_FILEXFER_ATTR_KNOWN_TEXT 0x00 SSH_FILEXFER_ATTR_GUESSED_TEXT 0x01 SSH_FILEXFER_ATTR_KNOWN_BINARY 0x02 SSH_FILEXFER_ATTR_GUESSED_BINARY 0x03 SSH_FILEXFER_ATTR_KNOWN_TEXT The server knows the file is a text file, and should be opened using the SSH_FXF_TEXT_MODE flag. SSH_FILEXFER_ATTR_GUESSED_TEXT The server has applied a heuristic or other mechanism and believes that the file should be opened with the SSH_FXF_TEXT_MODE flag. SSH_FILEXFER_ATTR_KNOWN_BINARY The server knows the file has binary content. SSH_FILEXFER_ATTR_GUESSED_BINARY The server has applied a heuristic or other mechanism and believes has binary content, and should not be opened with the SSH_FXF_TEXT_MODE flag. This flag MUST NOT be present during either a setstat or a fsetstat operation.7.11. mime-type The 'mime-type' field contains the mime-type [RFC1521] string. Most servers will not know this information and should not set the bit in their supported-attribute-mask.7.12. link-count This field contains the hard link count of the file. This attribute MUST NOT be present during a setstat operation. Galbraith & Saarenmaa Expires January 11, 2007 [Page 27]

Internet-Draft         SSH File Transfer Protocol              July 2006


7.13. untranslated-name This field contains the name before filename translation was attempt. It MUST NOT be included unless the server also set the SSH_FILEXFER_ATTR_FLAGS_TRANSLATION_ERR (Section 7.9) bit in the attrib-bits field.7.14. Extended Attributes The SSH_FILEXFER_ATTR_EXTENDED flag provides a general extension mechanism for the attrib structure. If the flag is specified, then the 'extended_count' field is present. It specifies the number of 'extension-pair' items that follow. Each of these items specifies an extended attribute. Implementations MUST return SSH_FX_UNSUPPORTED if there are any unrecognized extensions. Clients can avoid sending unsupported extensions by examining the attrib-extension-names of the "supported2" extension attrib-extension-names (Section 5.4). Additional fields can be added to the attributes by either defining additional bits to the flags field to indicate their presence, or by defining extended attributes for them. The extended attributes mechanism is recommended for most purposes; additional flags bits should be defined only by an IETF standards action that also increments the protocol version number. The use of such new fields MUST be negotiated by the version number in the protocol exchange. It is a protocol error if a packet with unsupported protocol bits is received.8. Requests From the Client to the Server Requests from the client to the server represent the various file system operations.8.1. Opening and Closing Files and Directories Many operations in the protocol operate on open files. The SSH_FXP_OPEN and SSH_FXP_OPENDIR requests return a handle (which is an opaque variable-length string) which may be used to access the file or directory later. The client MUST NOT send requests to the server with bogus or closed handles. However, the server MUST perform adequate checks on the handle in order to avoid security risks due to fabricated handles. This design allows either stateful and stateless server implementation, as well as an implementation which caches state between requests but may also flush it. The contents of the file handle string are entirely up to the server and its design. The Galbraith & Saarenmaa Expires January 11, 2007 [Page 28]

Internet-Draft         SSH File Transfer Protocol              July 2006


   client should not modify or attempt to interpret the file handle
   strings.

   The file handle strings MUST NOT be longer than 256 bytes.

8.1.1. Opening a File Files are opened and created using the SSH_FXP_OPEN message. byte SSH_FXP_OPEN uint32 request-id string filename [UTF-8] uint32 desired-access uint32 flags ATTRS attrs The response to this message will be either SSH_FXP_HANDLE (if the operation is successful) or SSH_FXP_STATUS (if the operation fails.)8.1.1.1. filename The 'filename' field specifies the file name. See Section ''File Names'' for more information. If 'filename' is a directory file, the server MUST return an SSH_FX_FILE_IS_A_DIRECTORY error.8.1.1.2. desired-access The 'desired-access' field is a bitmask containing a combination of values from the ace-mask flags (Section 7.8). Note that again, the meaning of these flags is given in [RFC3010]. The server MUST be prepared to translate the SFTP access flags into its local equivalents. If the server cannot grant the access desired, it MUST return SSH_FX_PERMISSION_DENIED. The server MAY open the file with greater access than requested if the user has such access and the server implementation requires it. For example, a server that does not distinguish between READ_ATTRIBUTE and READ_DATA will have to request full 'read' access to the file when the client only requested READ_ATTRIBUTE, resulting in greater access than the client originally requested. In such cases, it is possible, and permissible in the protocol, that the client could open a file requesting some limited access, and then access the file in a way not permitted by that limited access and the server would permit such action. However, the server MUST NOT ever grant access to the file that the client does not actually have the rights to. Galbraith & Saarenmaa Expires January 11, 2007 [Page 29]

Internet-Draft         SSH File Transfer Protocol              July 2006


      SSH_FXF_OPEN_OR_CREATE
         If the file exists, it is opened.  If the file does not exist,
         it is created.

      SSH_FXF_TRUNCATE_EXISTING
         An existing file is opened and truncated.  If the file does not
         exist, the server MUST return the same error codes as defined
         for SSH_FXF_OPEN_EXISTING.

   SSH_FXF_APPEND_DATA
      Data is always written at the end of the file.  The offset field
      of SSH_FXP_WRITE requests is ignored.

      Data is not required to be appended atomically.  This means that
      if multiple writers attempt to append data simultaneously, data
      from the first may be lost.  However, data MAY be appended
      atomically.

   SSH_FXF_APPEND_DATA_ATOMIC
      Data is always written at the end of the file.  The offset field
      of the SSH_FXP_WRITE requests are ignored.

      Data MUST be written atomically so that there is no chance that
      multiple appenders can collide and result in data being lost.

      If both append flags are specified, the server SHOULD use atomic
      append if it is available, but SHOULD use non-atomic appends
      otherwise.  The server SHOULD NOT fail the request in this case.

   SSH_FXF_TEXT_MODE
      Indicates that the server should treat the file as text and
      convert it to the canonical newline convention in use.  (See
      Determining Server Newline Convention.  (Section 5.3) When a file is opened with this flag, the offset field in the read and write functions is ignored. Servers MUST process multiple, parallel reads and writes correctly in this mode. Naturally, it is permissible for them to do this by serializing the requests. Clients SHOULD use the SSH_FXF_APPEND_DATA flag to append data to a text file rather then using write with a calculated offset. Galbraith & Saarenmaa Expires January 11, 2007 [Page 31]

Internet-Draft         SSH File Transfer Protocol              July 2006


   The response to this request will be a SSH_FXP_STATUS message.  Note
   that on some server platforms even a close can fail.  For example, if
   the server operating system caches writes, and an error occurs while
   flushing cached writes, the close operation may fail.

   Note that the handle is invalid regardless of the SSH_FXP_STATUS
   result.  There is no way for the client to recover a handle that
   fails to close.  The client MUST release all resources associated
   with the handle regardless of the status.  The server SHOULD take
   whatever steps it can to recover from a close failure and to ensure
   that all resources associated with the handle on the server are
   correctly released.

8.2. Reading and Writing8.2.1. Reading Files The following request can be used to read file data: byte SSH_FXP_READ uint32 request-id string handle uint64 offset uint32 length handle 'handle' is an open file handle returned by SSH_FXP_OPEN. If 'handle' is not a handle returned by SSH_FXP_OPEN, the server MUST return SSH_FX_INVALID_HANDLE. offset The offset (in bytes) relative to the beginning of the file that the read MUST start at. This field is ignored if SSH_FXF_TEXT_MODE was specified during the open. length 'length' is the maximum number of bytes to read. The server MUST not respond with more data than is specified by the 'length' parameter. However, the server MAY respond with less data if EOF is reached, an error is encountered, or the servers internal buffers can not handle such a large request. If the server specified a non-zero 'max-read-size' in its 'supported2' (Section 5.4) extension and 'length' is <= 'max-read- size', then failure to return 'length' bytes indicates that EOF or an error occurred. Galbraith & Saarenmaa Expires January 11, 2007 [Page 36]

Internet-Draft         SSH File Transfer Protocol              July 2006


   handle
      'handle' is a handle returned by SSH_FXP_OPEN or SSH_FXP_OPENDIR.
      Note that some servers MAY return SSH_FX_OP_UNSUPPORTED if the
      handle is a directory handle.

   offset
      Beginning of the byte-range to lock.

   length
      Number of bytes in the range to lock.  The special value 0 means
      lock from 'offset' to the current end-of-file.  (This operation is
      equivalent to doing a SSH_FXP_STAT to retrive the 'size' and then
      using that to calculate the length.)

   uLockMask
      A bit mask of SSH_FXF_BLOCK_* values; the meanings are described
      inSection 8.1.1.3. The result is a SSH_FXP_STATUS packet. If the requested range overlaps in any fashion with an already granted SSH_FXP_BLOCK request (even if the request is from the same client in the same connection), the result is SSH_FX_BYTE_RANGE_LOCK_REFUSED. It is permissible for 'offset' to be >= 'size', or for 'length' to extend past 'size'. However, in no case does this operation effect 'size'. Naturally, all of the same restrictions regarding conflicting locks / access apply to such a lock. Take together the 'offset' and the 'length' can be considered to form a unique key, which is then used to release the lock using the SSH_FXP_UNBLOCK (below) request.8.8.2. Releasing a byte range lock SSH_FXP_UNBLOCK removes a previously acquired byte-range lock on the specified handle. The 'offset' and 'length' MUST match exactly the offset and length specified to the SSH_FXP_LOCK request. byte SSH_FXP_UNBLOCK uint32 request-id string handle uint64 offset uint64 length Galbraith & Saarenmaa Expires January 11, 2007 [Page 44]

Internet-Draft         SSH File Transfer Protocol              July 2006


   execution, however, is guaranteed to be as if they had been processed
   one at a time in the order in which the requests were sent).

   Response packets are of the same general format as request packets.
   Each response packet begins with the request identifier.

9.1. Status Response The format of the data portion of the SSH_FXP_STATUS response is as follows: byte SSH_FXP_STATUS uint32 request-id uint32 error/status code string error message (ISO-10646 UTF-8 [RFC-2279]) string language tag (as defined in [RFC-1766]) error-specific data request-id The 'request-id' specified by the client in the request the server is responding to. error/status code Machine readable status code indicating the result of the request. Error code values are defined below. The value SSH_FX_OK indicates success, and all other values indicate failure. Implementations MUST be prepared to receive unexpected error codes and handle them sensibly (such as by treating them as equivalent to SSH_FX_FAILURE). Future protocol revisions may add additional error codes without changing the version number. error message Human readable description of the error. language tag 'language tag' specifies the language the error is in. error-specific data The error-specific data may be empty, or may contain additional information about the error. For error codes that send error- specific data, the format of the data is defined below. Error codes: Galbraith & Saarenmaa Expires January 11, 2007 [Page 48]

Internet-Draft         SSH File Transfer Protocol              July 2006


   data
      'data' is an arbitrary byte string containing the requested data.
      The data string may be at most the number of bytes requested in a
      SSH_FXP_READ request, but may also be shorter.  (See
Section 8.2.1.) end-of-file This field is optional, and if present and true it indicates that EOF was reached during this read. This can help the client avoid a round trip to determine whether a short read was normal (due to EOF) or some other problem (limited server buffer for example.)9.4. Name Response The SSH_FXP_NAME response has the following format: byte SSH_FXP_NAME uint32 request-id uint32 count repeats count times: string filename [UTF-8] ATTRS attrs bool end-of-list [optional] count The number of names returned in this response, and the 'filename' and 'attrs' field repeat 'count' times. filename A file name being returned (for SSH_FXP_READDIR, it will be a relative name within the directory, without any path components; for SSH_FXP_REALPATH it will be an absolute path name.) attrs The attributes of the file as described in Section ''File Attributes''. end-of-list If this field is present and true, there are no more entries to be read. This field should either be omitted or be true unless the request is SSH_FXP_READDIR.9.5. Attrs Response The SSH_FXP_ATTRS response has the following format: Galbraith & Saarenmaa Expires January 11, 2007 [Page 53]

Internet-Draft         SSH File Transfer Protocol              July 2006


       byte   SSH_FXP_ATTRS
       uint32 request-id
       ATTRS  attrs

   attrs
      The returned file attributes as described in Section ''File
      Attributes''.



10. Extensions The SSH_FXP_EXTENDED request provides a generic extension mechanism for adding additional commands. byte SSH_FXP_EXTENDED uint32 request-id string extended-request ... any request-specific data ... request-id Identifier to be returned from the server with the response. extended-request A string naming the extension, following the the DNS extensibility naming convention outlined in [RFC4251], or defined by IETF consensus. request-specific data The rest of the request is defined by the extension; servers SHOULD NOT attempt to interpret it if they do not recognize the 'extended-request' name. The server may respond to such requests using any of the response packets defined in Section ''Responses from the Server to the Client''. Additionally, the server may also respond with a SSH_FXP_EXTENDED_REPLY packet, as defined below. If the server does not recognize the 'extended-request' name, then the server MUST respond with SSH_FXP_STATUS with error/status set to SSH_FX_OP_UNSUPPORTED. The SSH_FXP_EXTENDED_REPLY packet can be used to carry arbitrary extension-specific data from the server to the client. It is of the following format: byte SSH_FXP_EXTENDED_REPLY uint32 request-id ... any request-specific data ... Galbraith & Saarenmaa Expires January 11, 2007 [Page 54]

Internet-Draft         SSH File Transfer Protocol              July 2006


   There is a range of packet types reserved for use by extensions.  In
   order to avoid collision, extensions that that use additional packet
   types should determine those numbers dynamically.

   The suggested way of doing this is have an extension request from the
   client to the server that enables the extension; the extension
   response from the server to the client would specify the actual type
   values to use, in addition to any other data.

   Extension authors should be mindful of the limited range of packet
   types available (there are only 45 values available) and avoid
   requiring a new packet type where possible.


11. Implementation Considerations In order for this protocol to perform well, especially over high latency networks, multiple read and write requests should be queued to the server. The data size of requests should match the maximum packet size for the next layer up in the protocol chain. When implemented over ssh, the best performance should be achieved when the data size matches the channel's max packet, and the channel window is a multiple of the channel packet size. Implementations MUST be aware that requests do not have to be satisfied in the order issued. (See Request Synchronization and Reordering (Section 4.1).) Implementations MUST also be aware that read requests may not return all the requested data, even if the data is available.12. IANA Considerations IANA registrie needs to be created for each of the following: o The packet types define defined inSection 4.3 o The extension specified in this draft, which are: 'text-seek', 'supported2', 'acl-supported', 'newline', 'versions', 'version- select', 'filename-charset', 'filename-translation-control'13. Security Considerations It is assumed that both ends of the connection have been authenticated and that the connection has privacy and integrity Galbraith & Saarenmaa Expires January 11, 2007 [Page 55]

Internet-Draft         SSH File Transfer Protocol              July 2006


   features.  Such security issues are left to the underlying transport
   protocol, except to note that if this is not the case, an attacker
   may be able to manipulate files on the server and thus wholly
   compromise the server.

   This protocol provides file system access to arbitrary files on the
   server (constrained only by the server implementation).  It is the
   responsibility of the server implementation to enforce any access
   controls that may be required to limit the access allowed for any
   particular user (the user being authenticated externally to this
   protocol, typically using [RFC4252]). Extreme care must be used when interpreting file handle strings. In particular, care must be taken that a file handle string is valid in the context of a given 'file-share' session. For example, the 'file- share' server daemon may have files which it has opened for its own purposes, and the client must not be able to access these files by specifying an arbitrary file handle string. The permission field of the attrib structure (Section 7.6) may include the SUID, SGID, and SVTX (sticky) bits. Clients should use extreme caution when setting these bits on either remote or local files. (I.e., just because a file was SUID on the remote system does not necessarily imply that it should be SUID on the local system.) Filesystems often contain entries for objects that are not files at all, but are rather devices. For example, it may be possible to access serial ports, tape devices, or named pipes using this protocol. Servers should exercise caution when granting access to such resources. In addition to the dangers inherent in allowing access to such a device, some devices may be 'slow', and could cause denial of service by causing the server to block for a long period of time while I/O is performed to such a device. Servers should take care that file-system quotas are respected for users. In addition, implementations should be aware that attacks may be possible, or facilitated, by filling a filesystem. For example, filling the filesystem where event logging and auditing occurs may, at best, cause the system to crash, or at worst, allow the attacker to take untraceable actions in the future. Servers should take care that filenames are in their appropriate canonical form, and to ensure that filenames not in canonical form cannot be used to bypass access checks or controls. If the server implementation limits access to certain parts of the file system, extra care must be taken in parsing file names which contain the '..' path element, and when following symbolic links, Galbraith & Saarenmaa Expires January 11, 2007 [Page 56]

Internet-Draft         SSH File Transfer Protocol              July 2006


   shortcuts, or other filesystem objects which might transpose the path
   to refer to an object outside of the restricted area.  There have
   been numerous reported security bugs where a ".." in a path name has
   allowed access outside the intended area.


14. Changes from Previous Protocol Versions RFC EDITOR: PLEASE REMOVE ENTIRE SECTION BEFORE PUBLISHING Please refer to the following web page for pervious versions of the protocol:http://tools.ietf.org/wg/secsh/draft-ietf-secsh-filexfer/ RFC EDITOR: END PLEASE REMOVE ENTIRE SECTION BEFORE PUBLISHING15. References15.1. Normative References [RFC3010] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, "NFS version 4 Protocol",RFC 3010, December 2000. [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture",RFC 4251, January 2006. [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol",RFC 4253, January 2006. [RFC4254] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Connection Protocol",RFC 4254, January 2006. [IEEE.1003-1.1996] Institute of Electrical and Electronics Engineers, "Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) [C Language]", IEEE Standard 1003.2, 1996.15.2. Informative References [RFC1521] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies",RFC 1521, September 1993. Galbraith & Saarenmaa Expires January 11, 2007 [Page 57]

Internet-Draft         SSH File Transfer Protocol              July 2006


   [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",RFC 2246, January 1999. [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages",BCP 18, RFC 2277, January 1998. [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Authentication Protocol",RFC 4252, January 2006. Trademark notice "ssh" is a registered trademark in the United States and/or other countries. Galbraith & Saarenmaa Expires January 11, 2007 [Page 58]

Internet-Draft         SSH File Transfer Protocol              July 2006


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found inBCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository athttp://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained inBCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Galbraith & Saarenmaa Expires January 11, 2007 [Page 60]

# data[].attributes.attachment_link.description
The SSH File Transfer Protocol provides secure file transfer functionality over any reliable, bidirectional octect stream. It is the standard file transfer protocol for use with the SSH2 protocol. This document describes the file transfer protocol and its interface to the SSH2 protocol suite.

# data[].attributes.attachment_link.readable_text
File formats:

Status:

PROPOSED STANDARD

Updated by:

RFC 8996

Author:

P. Ford-Hutchinson

Stream:

IETF

Source:

NON WORKING GROUP

DOI: 10.17487/RFC4217

Discuss this RFC: Send questions or comments to the mailing list iesg@ietf.org

Other actions: View Errata | Submit Errata | Find IPR Disclosures from the IETF | View History of RFC 4217

Abstract

This document describes a mechanism that can be used by FTP clients and servers to implement security and authentication using the TLS protocol defined by RFC 2246, "The TLS Protocol Version 1.0.", and the extensions to the FTP protocol defined by RFC 2228, "FTP Security Extensions". It describes the subset of the extensions that are required and the parameters to be used, discusses some of the policy issues that clients and servers will need to take, considers some of the implications of those policies, and discusses some expected behaviours of implementations to allow interoperation. This document is intended to provide TLS support for FTP in a similar way to that provided for SMTP in RFC 2487, "SMTP Service Extension for Secure SMTP over Transport Layer Security", and HTTP in RFC 2817, "Upgrading to TLS Within HTTP/1.1.".

This specification is in accordance with RFC 959, "File Transfer Protocol". It relies on RFC 2246, "The TLS Protocol Version 1.0.", and RFC 2228, "FTP Security Extensions". [STANDARDS-TRACK]

For the definition of Status, see RFC 2026.

For the definition of Stream, see RFC 8729.

# data[].attributes.attachment_link.description
File formats: Status: PROPOSED STANDARD Updated by: RFC 8996 Author: P.

# data[].attributes.attachment_link.readable_text
Network Working Group                                          J. Postel
Request for Comments: 959                                    J. Reynolds
                                                                     ISI
Obsoletes RFC: 765 (IEN 149)                                Octubre 1985
Traducción al castellano:                                   Febrero 2000
Gonzalo Paniagua Javier                           <gpanjav@jazzfree.com>

              PROTOCOLO DE TRANSFERENCIA DE FICHEROS (FTP)

Estado de este Documento

   Este documento es la especificación oficial del Protocolo de
   Transferencia de Ficheros (File Transfer Protocol, FTP). Se permite
   la distribucion ilimitada de este documento.

   Las siguientes nuevas órdenes opcionales se incluyen en esta edición
   de la especificación:

      CDUP (cambiar al directorio padre), SMNT (montar estructura), STOU
      (guardar con nombre único), RMD (Borrar directorio), MKD (Make
      Directory), PWD (mostrar directorio actual), y SYST (sistema).

   Esta especificación es compatible con ediciones anteriores.

1.  INTRODUCCION

   Los objetivos del FTP son 1) promocionar el uso compartido de
   ficheros (programas y/o datos), 2) animar al uso indirecto o
   implícito (a través de programas) de servidores remotos, 3) hacer
   transparente al usuario las variaciones entre la forma de almacenar
   ficheros en diferentes ordenadores, y 4) transferir datos fiable y
   eficientemente. El FTP, aunque puede ser utilizado directamente por
   un usuario en un terminal, está diseñado principalmete para ser usado
   por programas.

   Con esta especificación se intentan satisfacer las diversas
   necesidades de los usuarios de maxi-hosts, mini-hosts, estaciones de
   trabajo personales y TAC's con un diseño de protocolo simple y fácil
   de programar.

   En este documento se asumen conocimientos del Protocolo de Contol de
   Transmisión (TCP, Transmision Control Protocol) [2] y del Protocolo
   Telnet [3]. Estos documentos se encuentras en el manual de protocolos
   de ARPA-Internet.

2.  HISTORIA, TERMINOLOGIA Y MODELO FTP

   En esta sección se tratan la historia, la terminología y el modelo



Postel & Reynolds               Estándar                        [Pág. 1]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


   FTP.  Los términos que se definen en esta sección son sólo aquellos
   que tienen un significado especial en el FTP. Parte de la
   terminología es muy específica al modelo FTP; algunos lectores pueden
   encontrar conveniente consultar la sección sobre el modelo FTP
   mientras revisan la terminología.

   2.1.  HISTORIA

      El FTP ha pasado por un larga evolución a través de los años.  El
      apéndice III es una recopilación cronológica de los RFC que tratan
      el FTP. Estos incluyen la primera propuesta de mecanismos para
      transferencia de ficheros de 1971, que se desarrolló para su uso
      en servidores del M.I.T. (RFC 114), más los comentarios y
      discusiones del RFC 141.

      El RFC 172 proporcionó un protocolo orientado al nivel de usuario
      para transferir ficheros entre ordenadores (incluyendo IMP's
      terminales). Una revisión de este plasmada en el RFC 265, inició
      una revisión adicional, mientras que el RFC 281 sugirió más
      cambios.  El uso de una transacción para elegir el tipo de datos
      se propuso en el RFC 294 en enero de 1982.

      El RFC 354 dejó obsoletos los RFCs 264 y 265. El Protocolo de
      Transferencia de Ficheros se definió en este momento como un
      protocolo para transferencia de ficheros entre ordenadores
      conectados a la red ARPANET, señalando como función principal del
      FTP la transferencia de ficheros fiable y eficiente entre
      ordenadores y permitiendo el uso adecuado de las características
      de almacenamiento remotas. El RFC 385 siguió comentando errores,
      enfatizó algunos puntos y añadió características al protocolo,
      mientras que el RFC 414 fue un informe sobre los servidores FTP
      que estaban funcionando. El RFC 430, que salió a la luz en 1973,
      (entre otros muchos RFCs) presentó más comentarios sobre el FTP.
      Finalmente, se publicó un documento "oficial" sobre el FTP como
      RFC 454.

      Hacia julio de 1973, se hicieron considerables cambios a las
      últimas versiones del FTP, pero la estructura general permaneció
      igual.  El RFC 542 se publicó como una nueva espcificación
      "oficial" para reflejar esos cambios. Sin embargo, muchas
      implementaciones basadas en anterios especificaciones no se
      actualizaron.

      En 1974, los RFCs 607 y 614 continuaron los comentarios sobre el
      FTP.  El RFC 624 propuso más cambios en el diseño y pequeñas
      modificaciones.  En 1975, el RFC 686, titulado "Leaving Well
      Enough Alone", trató las diferencias entre todas las primeras y
      las últimas versiones del FTP. El RFC 691 presentó una pequeña



Postel & Reynolds               Estándar                        [Pág. 2]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


      revisión del RFC 686, referente al tema de ficheros para imprimir.

      Motivado por la transición del NCP al TCP como protocolo
      subyacente, nació un fénix de todos los anteriores esfuerzos en el
      RFC 765 como la especificación de FTP para uso sobre TCP.

      Esta edición de la especificación FTP está dirigida a la
      corrección de pequeños errores en la documentación, a mejorar la
      explicación de algunas características del protocolo, y a añadir
      algunas nuevas órdenes opcionales.

      En particular, se incluyen las siguientes nuevas órdenes
      opcionales en esta edición de la especificación:

         CDUP - Cambiar al directorio padre (Change to Parent Directory)

         SMNT - Montar estructura (Structure Mount)

         STOU - Guardar con nombre único (Store Unique)

         RMD - Borrar directorio (Remove Directory)

         MKD - Crear directorio (Make Directory)

         PWD - Mostrar directorio actual (Print Working Directory)

         SYST - Sistema (System)

      Esta especificación es compatible con la anterior edición. Un
      programa implementado conforme a la especificación anterior
      debería estar automáticamente en conformidad con esta
      especificación.

   2.2.  TERMINOLOGIA

      ASCII

         El conjunto de caracteres ASCII se considera tal y como está
         definido en el manual de protocolos de ARPA-Internet. En el FTP
         los caracteres ASCII se definen como la mitad inferior de un
         código de 8 bits (i.e., el bit más significativo es cero).

      controles de acceso

         Los controles de acceso definen los privilegios de acceso del
         usuario para el uso de un sistema y de los ficheros que hay en
         él. Son necesarios para evitar el uso no autorizado o
         accidental de ficheros. Es una prerrogativa para un proceso



Postel & Reynolds               Estándar                        [Pág. 3]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


         servidor FTP utilizar los controles de acceso.

      tamaño de byte

         Hay dos tamaños de byte interesantes en el FTP: el tamaño
         lógico de byte del fichero y el tamaño de byte usado para la
         transmisión de los datos. El tamaño de byte utilizado para la
         transmisión es siempre de 8 bits. Este tamaño no es
         necesariamente el tamaño de byte con el que se guardan los
         datos en un sistema ni el tamaño lógico de byte para la
         interpretación de la estructura de los datos.

      conexión de control

         La ruta de comunicación entre el USER-PI y el SERVER-PI para el
         intercambio de órdenes y respuestas. Esta conexión sigue el
         Protocolo Telnet.

      conexión de datos

         Una conexión bidireccional sobre la que se transfieren los
         datos en un modo y tipo especificados. Los datos transferidos
         pueden ser una parte de un fichero, un fichero entero o un
         cierto numero de ficheros. La conexión se puede establecer
         entre un server-DTP y un user-DTP o entre dos server-DTP's.

      puerto de datos

         El proceso de transferencia pasiva de datos "escucha" en el
         puerto de datos hasta que recibe una conexión del proceso de
         transferencia activa para abrir la conexión de datos.

      DTP

         El proceso de transferencia de datos (DTP, Data Transfer
         Process) establece y maneja la conexión de datos. Puede ser
         activo o pasivo.

      Fin-de-linea (EOL, end-of-line)

         La secuencia fin-de-linea define la separación entre líneas. La
         secuencia consiste en un retorno de carro seguido de un
         carácter de nueva línea.

      EOF (fin-de-fichero, end-of-file)

         La condición fin-de-fichero que define el final de un fichero
         en proceso de transmisión.



Postel & Reynolds               Estándar                        [Pág. 4]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


      EOR (end-of-record, fin-de-registro)

         La condición fin-de-registro que define el final de un registro
         en proceso de transferencia.

      recuperación de errores

         Un procedimiento que permite al usuario recuperar el control a
         partir de ciertas condiciones de error, como un fallo en el
         servidor o en el proceso de transferencia. En el FTP, la
         recuperación de errores puede implicar el reinicio de la
         transferencia de un fichero a partir de un cierto punto.

      órdenes FTP

         Un conjunto de órdenes que abarcan la información de control
         que va desde el proceso user-FTP al proceso server-FTP.

      fichero

         Un conjunto ordenado de datos del ordenador (incluyendo
         programas), de longitud arbitraria, definido de forma única por
         una ruta.

      modo

         El modo en que se tranfieren datos por la conexión de datos.
         El modo define el formato de los datos durante la
         transferencia, incluyendo EOR y EOF. Los modos de transferencia
         definidos para FTP se describen en la sección Modos de
         Transmisión.

      NVT

         El terminal virtual de red (Network Virtual Terminal) tal y
         como se define en el Protocolo Telnet.

      NVFS

         El sistema de ficheros virtual de red (Network Virtual File
         System). Un concepto que define un sistema de ficheros de red
         estándar con órdenes estándar y convenciones sobre los nombres
         de ruta [pathname].

      página

         Un fichero se puede estructurar como un conjunto de partes
         independientes llamadas páginas. El FTP soporta la transmisión



Postel & Reynolds               Estándar                        [Pág. 5]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


         de ficheros discontinuos como páginas indizadas independientes.

      nombre de ruta [pathname]

         El nombre de ruta se define como una cadena de caracteres que
         el usuario pasa al sistema de ficheros para identificar un
         fichero. La ruta normalmente contiene nombres de dispositivos
         y/o directorios y un nombre de fichero. El FTP no especifica
         aún un estándar para indicar una ruta. Cada usuario debe seguir
         las normas que dictan los sistemas de ficheros implicados en la
         transferencia para nombrar los ficheros.

      PI

         El Intérprete del Protocolo (Protocol Interpreter). La parte
         del usuario y del servidor del protocolo tienen distintos
         papeles que se implementan como un user-PI y un server-PI.

      registro

         Un fichero secuencial se puede estructurar en un número de
         partes contiguas llamadas registros. El FTP soporta las
         estructuras de registro, pero un fichero no tiene por qué tener
         una estructura de registro.

      respuesta

         Una respuesta es un asentimiento (positivo o negativo) enviada
         por el servidor al usuario a través de la conexión de control
         en respuesta a una orden FTP. La forma general de una respuesta
         es un código de terminación seguido de una cadena de texto. Los
         códigos son usados por los programas y el texto por las
         personas.

      server-DTP (server Data Transfer Process)

         El proceso de transferencia de datos (Data Transfer Process),
         en su estado normal de "activo", establece una conexión de
         datos con el puerto de datos que está a la espera. Prepara los
         parámetros para transferir y almacenar y transfiere los datos
         cuando así se requiere a través de su PI. El DTP se puede poner
         en estado "pasivo" para esperar una conexión, en lugar de
         iniciarla.

      proceso server-FTP

         Un proceso o un conjunto de ellos que realizan la función de
         transferencia de ficheros en conjunción con el proceso user-FTP



Postel & Reynolds               Estándar                        [Pág. 6]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


         y, posiblemente, otro servidor. Las funciones consisten en un
         intérprete de protocolo (PI) y un proceso de transferencia de
         datos (DTP).

      server-PI (server Protocol Interpreter)

         El intérprete de protocolo del servidor "escucha" en el puerto
         L hasta que recibe una conexión de un user-PI y establece una
         conexión de comunicaciones para control. Recibe órdenes FTP
         estándar desde el user-PI, envía respuestas y controla el
         server-DTP.

      tipo

         El tipo de representación de datos usado para transferir y
         almacenar los datos. El tipo implica ciertas transformaciones a
         la hora de almacenar y enviar los datos. Los tipos de
         representación definidos en el FTP se describen en la sección
         titulada "Estableciendo conexiones de datos".

      usuario

         Una persona o un proceso en su lugar que desea utilizar el
         servicio de transferencia de ficheros. La persona puede
         interactuar directamente con el proceso server-FTP, pero se
         prefiere el uso de un proceso user-FTP ya que el diseño del
         protocolo está orientado a su utilización por autómatas.

      user-DTP (user Data Transfer Process)

         El Proceso de Transferencia de Datos espera a recibir una
         conexión en el puerto de datos desde el proceso server-FTP.  Si
         dos servidores están transfiriendo datos entre ellos, el user-
         DTP permanece inactivo.

      proceso user-FTP

         Un conjunto de funciones incluyendo un intérprete de protocolo,
         un proceso de transferencia de datos y una interfaz de usuario
         que juntos realizan la función de transferir ficheros en en
         cooperación con un proceso server-FTP. La interfaz de usuario
         permite usar un lenguaje local en el diálogo orden-respuesta
         con el usuario.

      user-PI (user Protocol Interpreter)

         El intérprete de protocolo de usuario inicia la conexión de
         control desde su puerto U hasta el proceso server-FTP, envía



Postel & Reynolds               Estándar                        [Pág. 7]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


         órdenes FTP y controla el user-DTP si es necesario para la
         transferencia de ficheros.

      2.3.  EL MODELO FTP

         Teniendo en cuenta las definiciones anteriores, el siguiente
         modelo (mostrado en la Figura 1) representa un diagrama de un
         servicio FTP.

                                        ------------
                                        |/--------\|
                                        ||        ||   ---------
                                        ||Interfaz|<-->|Usuario|
                                        |\----^---/|   ---------
              ----------                |     |    |
              |/------\|  Ordenes FTP   |/----V---\|
              ||Server|<---------------->|   User ||
              ||  PI  || Respuestas FTP ||    PI  ||
              |\--^---/|                |\----^---/|
              |   |    |                |     |    |
 ----------   |/--V---\|   Conexión     |/----V---\|  ----------
 |Sistema |<-->|Server|<---------------->|  User  |<-->|Sistema|
 |  de    |   ||      ||   de datos     ||        ||  |   de   |
 |ficheros|   || DTP  ||                ||   DTP  ||  |ficheros|
 ----------   |\------/|                |\--------/|  ----------
              ----------                -------------
                Server-FTP                   User-FTP

          Figura 1: Modelo para el uso del FTP.

   NOTAS: 1. La conexión de datos es bidireccional.
         2. La conexión de datos no tiene por qué existir todo el
         tiempo.

         En el modelo descrito en la Figura 1, el intérprete de
         protocolo de usuario (user-PI), inicia la conexión de control.
         La conexión de control sigue el Protocolo Telnet. Las órdenes
         FTP estándar las genera el user-PI y se transmiten al proceso
         servidor a través de la conexión de control. (El usuario puede
         establecer una conexión de control directa con el server-FTP,
         desde un terminal TAC por ejemplo, y enviar órdenes FTP
         estándar, obviando así el proceso user-FTP.)  Las respuestas
         estándar se envían desde el server-PI al user-PI por la
         conexión de control como contestación a las órdenes.

         Las órdenes FTP especifican parámetros para la conexión de
         datos (puerto de datos, modo de transferencia, tipo de
         representación y estructura) y la naturaleza de la operación



Postel & Reynolds               Estándar                        [Pág. 8]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


         sobre el sistema de ficheros (almacenar, recuperar, añadir,
         borrar, etc.). El user-DTP u otro proceso en su lugar, debe
         esperar a que el servidor inicie la conexión al puerto de datos
         especificado y transferir los datos en función de los
         parámetros que se hayan especificado. Se debe reseñar que el
         puerto de datos no tiene por qué estar en el mismo ordenador
         que envía las órdenes FTP a través de la conexión de control,
         pero el usuario o el proceso user-FTP debe asegurarse de que se
         espera la conexión en el puerto de datos indicado. También hay
         que destacar que la conexión de datos se puede usar
         simultáneamente para enviar y para recibir.

         En otra situación, un usuario puede querer transferir ficheros
         entre dos ordenadores que no son locales. El usuario prepara
         las conexiones de control con los dos servidores y da las
         órdenes necesarias para crear una conexión de datos entre
         ellos. De esta forma, la información de control se envía al
         user-PI pero los datos se transfieren entre los procesos de
         transferencia de datos de los servidores. A continuación se
         muestra un modelo de esta interacción servidor-servidor.

               Control     ------------   Control
                ---------->| User-FTP |<-----------
                |          | User-PI  |           |
                |          |   "C"    |           |
                V          ------------           V
         --------------                        --------------
         | Server-FTP |   Data Connection      | Server-FTP |
         |    "A"     |<---------------------->|    "B"     |
         -------------- Port (A)      Port (B) --------------


                              Figura 2

      El protocolo requiere que las conexiones de control permanezcan
      abiertas mientras se transfieren datos. Es responsabilidad del
      usuario solicitar el cierre de las conexiones de control una vez
      termine de usar el servicio, mientras que el servidor es el
      encargado de cerrarlas. El servidor puede interrumpit la
      transferencia de datos si las conexiones de control se cierran sin
      previa solicitud.

      La relación entre FTP y Telnet:

         El FTP usa el protocolo Telnet en la conexión de control. Esto
         se puede conseguir de dos formas: primera, el user-PI o el
         server-PI pueden implementar las reglas del Protocolo Telnet
         directamente; o, segunda, el user-PI o el server-PI pueden usar



Postel & Reynolds               Estándar                        [Pág. 9]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


         el módulo Telnet que exista en el sistema.

         La facilidad de implementación, compartir código y la
         programación modular, están a favor de la segunda aproximación.
         La eficiencia y la independencia abogan por la primera
         aproximación. En la práctica, el FTP no depende mucho del
         protocolo Telnet, por ello la primera aproximación no
         necesariamente implica gran cantidad de código.

3.  FUNCIONES DE TRANSFERENCIA DE DATOS

   Los ficheros sólo se transmiten por la conexión de datos. La conexión
   de control se usa para enviar órdenes, que describen la función a
   realizar, y las repuestas a estas órdenes (ver la sección "Respuestas
   FTP"). Varias órdenes se refieren a la transferencia de datos entre
   ordenadores. Estas órdenes incluyen MODE (modo) que especifica cómo
   se transmiten los bits de datos y las órdenes STRU (STRUcture,
   estructura) y TYPE, que se usan para definir la forma de
   representación de los datos. La transmisión y la representación son
   básicamente independientes, pero el modo de transmisión flujo depende
   de la estructura del fichero y si se especifica el modo de
   transmisión "comprimido", la naturaleza del byte de relleno depende
   del tipo de representación.

   3.1.  REPRESENTACION DE DATOS Y ALMACENAMIENTO

      Los datos se tranfieren desde un dispositivo de almacenamiento en
      el ordenador que envía los datos a otro en el ordenador que los
      recibe. A menudo es necesario realizar ciertas transformaciones en
      los datos porque la representación de los datos almacenados varía
      de un ordenador a otro. Por ejemplo NVT-ASCII tiene diferentes
      representaciones de los datos almacenados en diferenctes sistemas.

      Los TOPS-20 de DEC generalmente almacenana NVT-ASCII como cinco
      caracteres ASCII de 7 bits, justificados a la izquierda en una
      palabra de 36 bits. Es conveniente convertir caracteres a la
      representación estándar NVT-ASCII cuando se transmite texto entre
      sistemas diferentes. Los ordenadores que intervienen en la
      transferencia deberían realizar las transformaciones necesarias
      entre la representación estándar y su representación interna.

      Nos encontramos con un problema diferente cuando se transmiten
      datos en forma binaria (no caracteres) entre ordenadores con
      distinto tamaño de palabra. No siempre está claro cómo se deben
      enviar los datos y como se deben almacenar al recibirlos. Por
      ejemplo, cuando se transmiten bytes de 32 bits desde un sistema
      con tamaño de palabra de 32 bits a un sistema con tamaño de
      palabra de 36 bits, sería conveniente (por razones de eficiencia y



Postel & Reynolds               Estándar                       [Pág. 10]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


      utilidad) almacenar los bytes de 32 bits justificados a la derecha
      en una palabra de 36 bits en el sistema receptor. En cualquier
      caso, el usuario debería tener la opción de especificar la
      representación de los datos y las transformaciones realizadas en
      ellos. Hay que señalar que el FTP proporciona muy limitados tipos
      de representación. Las transformaciones necesarias más allá de
      esta limitada capacidad las deberá realizar el usuario
      directamente.

      3.1.1.  TIPOS DE DATOS

         El usuario especifica las representaciones de datos que se
         manejarán en el FTP. Este tipo puede definir implícita (como es
         el caso de ASCII y EBCDIC) o explícitamente (como en un tamaño
         de byte local) un tamaño de byte para la interpretación
         denominado "tamaño de byte lógico". Hay que tener en cuenta que
         esto no tiene nada que ver con el tamaño de byte usado para la
         transmisión a través de la conexión de datos, llamado "tamaño
         de byte de transferencia", y no debería haber confusión entre
         ambos. Por ejemplo, NVT-ASCII tiene un tamaño de byte lógico de
         8 bits. Si el tipo es tamaño de byte local entonces la orden
         TYPE tiene un segundo parámetro obligatorio especificando el
         tamaño de byte lógico. El tamaño del byte de transferencia es
         siempre de 8 bits.

         3.1.1.1.  TIPO ASCII

            Este es el tipo por defecto y debe ser admitido por todas
            las implementaciones del FTP. Su principal propósito es
            transferir ficheros de texto, excepto cuando ambos
            ordenadores encuentran el tipo EBCDIC más conveniente.

            El ordenador que envía los datos, los convierte de una
            representación de caracteres interna a la representación
            estándar NVT-ASCII de 8 bits (ver la especificación de
            Telnet).  El receptor convertirá los datos del tipo estándar
            a su propia forma interna.

            De acuerdo con el estándar NVT, la secuencia <CRLF> se debe
            usar donde sea necesario para indicar el final de una línea
            de texto.  (Ver el tratamiento de la estructura del fichero
            al final de la sección sobre Almacenamiento y Representación
            de los Datos.)

            Usar la representación estándar NVT-ASCII implica que los
            datos se deben interpretar como bytes de 8 bits.

            El parámetro de formato para los tipos ASCII y EBCDIC se



Postel & Reynolds               Estándar                       [Pág. 11]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


            expone más adelante.

         3.1.1.2.  TIPO EBCDIC

            El propósito de este tipo es la transferencia eficaz entre
            ordenadores que usan EBCDIC como su representación de
            carácter interna.

            Para la transmisión, los datos están en forma de caracteres
            EBCDIC de 8 bits. El código de carácter es la única
            diferencia entre la especificación funcional de los tipos
            EBCDIC y ASCII.

            Fin-de-linea (en contraposición a fin-de-registro - ver el
            tratamiento de la estructura) probablemente apenas se usará
            con el tipo EBCDIC para denotar la estructura, pero donde
            sea necesario se usará el carácter <NL>.

         3.1.1.3.  TIPO IMAGEN

            Los datos se envían como bits contiguos que, para la
            transferencia, están empaquetados en bytes de transferencia
            de 8 bits. El receptor debe almacenar los datos como bits
            contiguos.  La estructura del sistema de almacenamiento
            puede necesitar el rellenado del fichero (o de cada
            registro, para un fichero estructurado en registros) hasta
            el límite pertinente (byte, palabra o bloque). Este
            rellenado, que debe ser todo ceros, sólo puede tener lugar
            al final del fichero (o de cada registro) y debe haber una
            forma de identificar los bits de relleno para poder
            eliminarlos si se obtiene el fichero. La transformación de
            relleno debe ser conocida por el usuario para procesar el
            fichero en el lugar de recepción.

            El tipo imagen está indicado para el almacenamiento y
            obtención de ficheros y la transferencia de datos binarios.
            Se recomienda que todas las implementaciones del FTP acepten
            este tipo.

         3.1.1.4.  TIPO LOCAL

            Los datos se transfieren en bytes lógicos del tamaño
            especificado por el segundo parámetro obligatorio, tamaño de
            byte. El valor del tamaño de byte debe ser un entero
            decimal; no hay valor por defecto. El tamaño de byte lógico
            no es necesariamente el mismo que el tamaño de byte de
            transferencia.  Si hay diferencia entre los tamaños de byte,
            entonces los bytes lógicos se deben empaquetar



Postel & Reynolds               Estándar                       [Pág. 12]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


            contiguamente, a pesar de los límites del byte de
            transferencia y con el relleno necesario al final.

            Cuando los datos llegan al receptor, se transformarán de una
            manera independiente del tamaño de byte lógico y del
            ordenador en cuestión. Esta transformación debe ser
            inversible (i.e., se obtendrá el mismo fichero si se usan
            los mismos parámetros) y los desarrolladores de la
            implementación deben hacerla pública.

            Por ejemplo, un usuario enviando números en coma flotante de
            36 bits a un ordenador con tamaño de palabra de 32 bits
            puede enviar esos datos como byte local con un tamaño lógico
            de 36.  El receptor debería almacenar los bytes lógicos de
            forma que sea fácil su manipulación; en este ejemplo, poner
            los bytes lógicos de 36 bits en palabras dobles de 64 bits
            sería suficiente.

            En otro ejemplo, un par de ordenadores con tamaño de palabra
            de 36 bits, pueden enviarse datos en palabras usando "TYPE L
            36".  Los datos se enviarían en los bytes de transmisión de
            8 bits y empaquetados para que 9 bytes de transmisión lleven
            dos palabras de 36 bits.

         3.1.1.5.  CONTROL DE FORMATO

            Los tipos ASCII y EBCDIC llevan un segundo parámetro
            (opcional); este es para indicar qué tipo de control de
            formato vertical, si es que lo hay, se asocia con el
            fichero. Los siguientes tipos de representación de datos se
            definen en el FTP:

            Un fichero de texto se envía a un ordenador por uno de estos
            tres propósitos: para su impresión, para almacenarlo y
            posteriormente recuperarlo, o para procesarlo. Si se envía
            un fichero para imprimirlo, el receptor debe saber cómo está
            representado el control de formato vertical. En el segundo
            caso, debe ser posible almacenar el fichero y después
            recuperarlo exactamente igual. Por último, debería ser
            posible enviar un fichero de un ordenador a otro y
            procesarlo en el receptor sin problemas indebidos. Un
            formato ASCII o EBCDIC por sí solo no satisface estas tres
            condiciones. Por lo tanto, estos tipos tiene un segundo
            parámetro especificando uno de los siguientes tres formatos:

            3.1.1.5.1.  NO PARA IMPRIMIR [NON PRINT]

               Este es el formato por defecto si se omite el segundo



Postel & Reynolds               Estándar                       [Pág. 13]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


               parámetro (formato). Se debe admitir en todas las
               implementaciones del FTP.

               El fichero no necesita ninguna información de formato
               vertical. Si se pasa a un proceso para imprimir, este
               proceso puede asumir valores estándar para espaciado y
               márgenes.

               Normalmente, este formato se usará con ficheros que van a
               ser procesados o simplemente almacenados.

             3.1.1.5.2.  CONTROLES DE FORMATO TELNET

               El fichero contiene controles de formato vertical
               ASCII/EBCDIC (i.e., <CR>, <LF>, <NL>, <VT>, <FF>) que el
               proceso para imprimir interpretará apropiadamente.
               <CRLF>, siguiendo exactamente este orden, también indica
               fin-de-línea.

            3.1.1.5.3.  CONTROL DE CARRO (ASA)

               El fichero contiene caracteres de control de formato
               vertical ASA (FORTRAN). (Vea el apéndice C RFC 740; y
               Comunicaciones de la ACM, Vol. 7, No. 10, p. 606, octubre
               1964). En una línea o registro formateado de acuerdo con
               en estándar ASA, el primer carácter no se imprime. En su
               lugar, se usa para determinar el movimiento vertical del
               papel que debería tener lugar antes de que se imprima el
               resto del registro.

               El estándar ASA especifica los siguientes caracteres de
               control:

               Carácter      Espaciado vertical

               espacio       Mueve el papel una línea arriba

               0             Mueve el papel dos líneas arriba

               1             Mueve hasta el comienzo de la sig. página

               +             No se mueve, i.e., sobreescribe

               Claramente, debe haber alguna manera para el proceso que
               imprime de distinguir el final de la entidad estructural.
               Si un fichero tiene estructura de registro (ver más
               abajo) no hay problema; los registros se marcan
               explícitamente durante la transferencia y el



Postel & Reynolds               Estándar                       [Pág. 14]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


               almacenamiento. Si el fichero no tiene estructura de
               registro, la secuencia fin-de-linea <CRLF> se usa para
               separar líneas al imprimir, pero los controles ASA tienen
               prioridad sobre estos especificadores de formato.

      3.1.2.  ESTRUCTURAS DE DATOS

         Además de los diferentes tipos de representación, el FTP
         permite especificar la estructura de un fichero. Se definen
         tres estructuras de fichero en el FTP:

         estructura de fichero, donde no hay una estructura interna y el
         fichero se considera como una secuencia continua de bytes de
         datos,

         estructura de registro, donde el fichero está compuesto de
         registros secuenciales,

         y estructura de página, donde el fichero está compuesto de
         páginas indizadas independientes.

         Si no se usa la orden STRU (estructura), se asume por defecto
         estructura de fichero, pero todas las implementaciones del FTP
         deben aceptar para ficheros de "texto"  las estructuras de
         fichero y de registro (i.e., para los TYPE ASCII y TYPE
         EBCDIC). La estructura de un fichero afectará al modo de
         transferencia y a la interpretación y almacenamiento del
         fichero (vea la sección Modos de Transmisión).

         La estructura "natural" de un fichero depende del ordenador que
         almacena el fichero. Un fichero con código fuente se guardará
         en un Mainframe de IBM, normalmente, en registros de tamaño
         fijo pero en un TOPS-20 de DEC se guardará como un flujo de
         caracteres particionados en líneas, separados, por ejemplo, por
         <CRLF>. Si se quiere realizar una transferencia entre
         odenadores tan dispares que sea útil, debe haber una forma para
         que uno reconozca lo que el otro asume por defecto.

         Con unos ordenadores orientados por naturaleza a ficheros y
         otros orientados a registros, puede haber problemas si se envía
         un fichero con una estructura a un ordenador orientado a la
         otra. Si un fichero de texto se envía con estructura de
         registros a un ordenador que está orientado a ficheros,
         entonces éste último debería aplicar internamente una
         transformación basada en la estructura de registros.
         Obviamente, esta transformación debería ser adecuada, pero,
         además, debe ser inversible para que se pueda obtener un
         fichero identico usando estructura de registro.



Postel & Reynolds               Estándar                       [Pág. 15]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


         En el caso de enviar un fichero con estructura de fichero a un
         ordenador orientado a registro, surge la cuestión de qué
         criterio debe usar el ordenador para dividir el fichero en
         registros que se puedan procesar localmente. Si es necesaria
         esta división, la implementación del FTP debería usar la
         secuencia <CRLF> para ficheros de texto ASCII o <NL> para
         ficheros de texto EBCDIC como separador de registro. Si una
         implementación del FTP adopta esta técnica, debe estar
         preparada para hacer la transformación inversa si se recupera
         el fichero con estructura de fichero.

         3.1.2.1.  ESTRUCTURA DE FICHERO

            La estructura de fichero se asume por defecto si no se
            utiliza la orden STRU (eSTRUctura).

            Si el fichero tiene esta estructura, se considera como una
            secuencia continua de bytes de datos, sin ninguna estructura
            interna.

         3.1.2.2.  ESTRUCTURA DE REGISTRO

            Todas las implementaciones del FTP deben aceptar la
            estructura de registro para ficheros de texto (i.e., con
            tipos ASCII o EBCDIC).

            El fichero está formado por registros dispuestos
            secuencialmente.

         3.1.2.3.  ESTRUCTURA DE PAGINA

            Para transmitir ficheros discontínuos, el FTP define una
            estructura de página. Los fichero de este tipo también se
            conocen como ficheros de acceso aleatorio o como ficheros
            con huecos.  En estos ficheros hay a veces otra información
            asociada con el fichero como un todo (por ejemplo, un
            descriptor de fichero), o con una sección del fichero (por
            ejemplo, controles de acceso a página) o ambos. En el FTP
            las secciones del fichero se llaman páginas.

            Para tratar con varios tamaños de página y con la
            información asociada, cada página se envía con una cabecera
            de página. Esta cabecera tiene definidos los siguientes
            campos:

               Longitud de la cabecera

                  El número de bytes lógicos en la cabecera incluyendo



Postel & Reynolds               Estándar                       [Pág. 16]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


                  este.  El tamaño mínimo de la cabecera es de 4.

               Indice de página

                  El número lógico de página de esta sección del
                  fichero.  Esto no es el número de secuencia de
                  transmisión de esta página, sino el índice usado para
                  identifiar esta página del fichero.

               Tamaño de datos

                  El número de bytes lógicos que hay en los datos de la
                  página. El mínimo es 0.

               Tipo de página

                  Existen los siguientes tipos de página:

                     0 = Ultima página

                        Se usa para indicar el final de una transmisión
                        con estructura de página. El tamaño de cabecera
                        debe ser 4 y el tamaño de datos debe ser 0.

                     1 = Página normal

                        Este es el tipo usado para ficheros paginados
                        simples sin información de control de acceso
                        asociada a nivel de página. El tamaño de la
                        cabecera debe ser 4.

                     2 = Página de descriptor

                        Este tipo se utiliza para transmitir la
                        información descriptiva del fichero considerado
                        como un todo.

                     3 = Página con control de acceso

                        Este tipo incluye un campo adicional en la
                        cabecera para ficheros paginados con información
                        de control de acceso a nivel de página. El
                        tamaño de la cabecera debe ser 5.

               Campos opcionales

                  Se pueden usar más campos en la cabecera para
                  proporcionar, por ejemplo, información de control por



Postel & Reynolds               Estándar                       [Pág. 17]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


                  página.

                  Todos los campos miden un byte lógico. El tamaño de
                  byte lógico se especifica por la orden TYPE. Vea el
                  apéndice I para más detalles y un caso específico de
                  estructura de página.

      Una nota de atención sobre los parámetros: un fichero debe ser
      almacenado y recuperado con los mismos parámetros si la versión
      recuperada debe ser idéntica a la versión originalmente
      transmitida. Por tanto, las implementaciones del FTP deben
      devolver un fichero idéntico al original si los parámetros usados
      para almacenar y recuperar el fichero son los mismos.

   3.2.  ESTABLECIENDO CONEXIONES DE DATOS

      La mecánica de transferir datos consiste en preparar la conexión
      de datos en los puertos apropiados y elegir los parámetros para la
      transferencia. El usuario y los server-DTPs tienen ambos un puerto
      por defecto. El puerto por defecto del proceso de usuario es el
      mismo que el puerto de la conexión de control (i.e., U). El puerto
      por defecto del proceso servidor es el puerto adyacente al puerto
      de la conexión de control (i.e., L-1).

      El tamaño de byte para la transferencia es de 8 bits. Este tamaño
      sólo es relevante para la transferencia de datos; no tiene nada
      que ver con la representación de los datos dentro del sistema de
      ficheros de un ordenador.

      El proceso de transferencia de datos pasivo (que puede ser un
      user-DTP o un segundo server-DTP) deberá "escuchar" en el puerto
      de datos antes de enviar una orden de petición de transferencia.
      Esta orden determina el sentido de la transferencia de los datos.
      El servidor, una vez recibida la petición de transferencia,
      iniciará la conexión de datos al puerto indicado. Una vez
      establecida la conexión, la transferencia de datos comienza entre
      los DTPs y el server-PI envía una respuesta de confirmación al
      user-PI.

      Todas las implementaciones del FTP deben soportar el uso de los
      puertos de datos por defecto y sólo el user-PI puede solicitar un
      cambio a un puerto diferente.

      Usando la orden PORT, el usuario puede especificar un puerto
      alternativo. Puede que el usuario quiera volcar un fichero en una
      impresora de líneas TAC o que se obtenga el fichero de un tercer
      ordenador. En este último caso, el user-PI establece las
      conexiones de control con ambos ordenadores. Luego dice a un



Postel & Reynolds               Estándar                       [Pág. 18]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


      servidor (mediante una orden FTP) que "escuche" hasta recibir una
      conexión que el otro iniciará. El user-PI envía aun server-PI una
      orden PORT indicando el puerto de datos del otro.  Finalmente, se
      envían a ambos las órdenes apropiadas de transferencia. La
      secuencia exacta de órdenes y respuestas entre el usuario y los
      servidores está en la sección sobre Respuestas FTP.

      En genera, es responsabilidad del servidor mantener la conexión de
      datos (abrirla y cerrarla). La excepción a esto se produce cuando
      el user-DTP envía los datos en un modo de transferencia que
      requiere cerrar la conexión para indicar EOF. El servidor DEBE
      cerrar la conexión de datos bajo las siguientes circunstancias:

         1. El servidor ha terminado de enviar datos en un modo de
         transferencia que requiere un cierre para indicar EOF.

         2. El servidor recibe una orden ABORT del usuario.

         3. Una orden del usuario especifica un nuevo puerto.

         4. La conexión de control se cierra correctamente o de
         cualquier otro modo.

         5. Se produce una condición de error irrecuperable.

      En cualquier caso, el cierre es una opción del servidor que se
      debe indicar al proceso de usuario sólo mediante una respuesta 250
      ó 226.

   3.3.  MANEJO DE LA CONEXION DE DATOS

      Puertos de la conexión de datos por defecto: Todas las
      implementaciones del FTP deben soportar el uso de los puertos de
      datos por defecto y sólo el user-PI puede iniciar el uso de otros
      puertos.

      Negociando puertos de datos distintos a los que hay por defecto:
      el user-PI puede especificar un puerto de datos diferente por su
      parte con la orden PORT. El user-PI puede solicitar al servidor la
      localización de un puerto en el propio servidor con la orden PASV.
      Como una conexión está definida por el par de direcciones,
      cualquiera de estas acciones es suficiente para tener una conexión
      de datos diferente, pero se permite usar ambas órdenes para
      utilizar nuevos puertos en los dos lados de la conexión.

      Reutilización de la conexión de datos: Cuando se usa el modo flujo
      para transferencia de datos el final de fichero se indica cerrando
      la conexión. Esta causa un problema si se van a transferir varios



Postel & Reynolds               Estándar                       [Pág. 19]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


      ficheros en la sesión, debido a la necesidad que tiene el TCP de
      mantener el registro de la conexión por un tiempo de espera para
      garantizar una comunicación fiable.  Por eso la conexión no puede
      reabrirse inmediatamente.

         Hay dos soluciones a este problema. La primera es negociar un
         puerto diferente al que hay por defecto. La segunda es usar
         otro modo de transmisión.

         Un comentario sobre los modos de transmisión. El modo flujo de
         transferencia es implícitamente poco fiable porque no se puede
         determinar si la conexión se ha cerrado prematuramente o no.
         Los otros modos de transferencia (de bloque, comprimido) no
         cierran la conexión para indicar el final de fichero. Los datos
         que envía el FTP a través de ellos hacen que se pueda
         determinar el final de fichero. Por eso, usando estos modos, se
         puede dejar la conexión de datos abierta para transferir más de
         un fichero.

   3.4.  MODOS DE TRANSMISION

      Otro aspecto a considerar en la transferencia de datos es la
      elección apropiada del modo de transmisión. Hay tres modos: uno
      que formatea los datos y permite reiniciar la transmisión; otro
      que además comprime los datos para una transferencia eficaz; y
      otro que pasa los datos sin apenas procesarlos. En este último
      caso, el modo interactúa con el atributo de estructura para
      determinar el tipo de proceso. En el modo comprimido, el tipo de
      representación determina el byte de relleno.

      Todas las transferencia de datos se deben complementar con un fin-
      de-fichero (EOF, end-of-file) que se puede indicar explícita o
      implícitamente cerrando la conexión de datos. Para ficheros con
      estructura de registro, todos los indicadores de fin-de-registro
      (EOR) son explícitos, incluyendo el último. Para ficheros
      transmitidos con estructura de página, se usa una página con el
      indicador de última página activado.

      NOTA: en el resto de esta sección, byte significa "byte de
      transferencia" excepto donde se indique explícitamente.

      Para estandarizar la transferencia, el ordenador que envía los
      datos trasladará sus caracteres de fin de línea o de fin de
      registro a la representación indicada por el modo de transferencia
      y la estructura del fichero y el receptor realizará la traducción
      inversa a su representación interna. Un campo de contador de
      registro de un Mainframe de IBM puede no ser reconocido por otro
      ordenador, por eso, la información de fin-de-registro se puede



Postel & Reynolds               Estándar                       [Pág. 20]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


      transferir como un código de control de dos bytes en modo flujo o
      como un bit activado en un descriptor de modo bloque o comprimido.
      El fin-de-línea en un fichero ASCII o EBCDIC no estructurado en
      registros se debería indicar con <CRLF> o <NL> respectivamente.
      Debido a que estas transformaciones implican un trabajo extra para
      algunos sistemas, sistemas idénticos que transfieren entre ellos
      un fichero de texto no estructurado en registros pueden preferir
      usar una representación binaria y modo flujo para la
      transferencia.

      Se definen los siguientes modos de transmisión en el FTP:

      3.4.1.  MODO FLUJO

         Los datos se transmiten como un flujo de bytes. No hay ninguna
         restricción en el tipo de representación usado; se permiten
         estructuras de registro.

         En un fichero estructurado en registros, EOR y EOF se indicarán
         por un código de control de dos bytes. El primer byte del
         código de control consistirá en todo unos, el carácter de
         escape. El segundo tendrá el bit de orden más bajo activado y
         ceros en el resto para EOR y el segundo bit de orden más bajo
         activado para EOF; esto es, el byte valdrá 1 para EOR y 2 para
         EOF. EOF y EOR se pueden indicar conjuntamente en el último
         byte transmitido activando los dos bits más bajos (i.e., el
         valor 3). Si se pretende transmitir un byte con todo unos como
         dato, se debería repetir em el segundo byte del código de
         control.

         Si la estructura es de fichero, se indica el EOF cuando el
         ordenador que envía los datos cierra la conexión de datos y
         todos los bytes son bytes de datos.

      3.4.2.  MODO BLOQUE

         El fichero se transmite como una serie de bloques de datos
         precedidos por uno o más bytes cabecera. Los bytes de la
         cabecera contienen un campo contador y un código descriptor. El
         campo contador indica la longitud total del bloque de datos en
         bytes, indicando así el inicio del siguiente bloque de datos
         (no hay bits de relleno). El código descriptor define: último
         bloque del fichero (EOF), último bloque del registro (EOR),
         indicador de reinicio (vea la sección sobre Recuperación de
         Errores y Reinicio) o datos sospechosos (i.e., los datos
         tranferidos pueden contener errores y no son fiables). Este
         último código NO es para controlar errores desde el propio FTP.
         Su uso está motivado por el deseo de ciertos sitios que



Postel & Reynolds               Estándar                       [Pág. 21]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


         intercambian cierto tipo de información (por ejemplo, datos
         sísmicos o meteorológicos) enviando y recibiendo todos los
         datos a pesar de que pueda haber errores locales (como errores
         leyendo una cinta magnética). Se permiten estructuras de
         registro y se puede usar cualquier tipo de representación.

         La cabecera consiste en tres bytes. De los 24 bits de
         información, los 16 más bajos representan un contador de bytes
         y los 8 más altos representan códigos de descripción como se
         muestra a continuación.

         Cabecera de Bloque

            +----------------+----------------+----------------+
            | Descriptor     |    Contador de Bytes            |
            |         8 bits |                      16 bits    |
            +----------------+----------------+----------------+

         Los códigos de descripción se indican mediante bits en el byte
         de descripción. Hay asignados 4 códigos, donde cada número de
         código es el valor decimal del correspondiente bit en el byte.

         Código     Significado

            128     El final del bloque de datos es EOR
             64     El final del bloque de datos es EOF
             32     Puede haber errores en el bloque
             16     El bloque de datos es un marcador de reinicio

         Con esta codificación, más de una condición codificada puede
         ocurrir para un bloque en particular. Se pueden activar tantos
         bits como sea necesario.

         El indicador de reinicio está incluído en el flujo de datos
         como un número de 8 bits representando caracteres imprimibles
         en el lenguaje usado en la conexión de control (por ejemplo,
         NVT-ASCII). <SP> (espacio en el lenguaje apropiado) no se debe
         usar DENTRO de un indicador de reinicio.

         Por ejemplo, para transmitir un indicardor de seis caracteres,
         se debería enviar lo siguiente:










Postel & Reynolds               Estándar                       [Pág. 22]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


            +----------+--------+--------+
            |Descriptor|  Byte count     |
            |code= 16  |             = 6 |
            +----------+--------+--------+

            +-------+-------+-------+
            | Marca | Marca | Marca |
            | 8 bits| 8 bits| 8 bits|
            +-------+-------+-------+

            +-------+-------+-------+
            | Marca | Marca | Marca |
            | 8 bits| 8 bits| 8 bits|
            +-------+-------+-------+

      3.4.3.  MODO COMPRIMIDO

         Hay tres clases de información a enviar: datos normales,
         enviados en una cadena de bytes; datos comprimidos, formados
         por repeticiones o relleno; e información de control, enviada
         en una secuencia de escape de dos bytes. Si se envía n>0 bytes
         (hasta 127) de datos normales, estos n bytes van precedidos de
         un byte con el bit más a la izquierda a cero y los 7 bits más a
         la derecha contienen el número n.

                  Cadena de bytes:

             1       7                8                     8
            +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+
            |0|       n     | |    d(1)       | ... |      d(n)     |
            +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+
                                          ^             ^
                                          |---n bytes---|
                                              de datos

            Cadena de n bytes de datos d(1),..., d(n)
            El contador n debe ser positivo.

         Para comprimir una cadena de n repeticiones del byte de datos
         d, se envían los 2 siguientes bytes:

         Byte Repetido:

              2       6               8
            +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
            |1 0|     n     | |       d       |
            +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+




Postel & Reynolds               Estándar                       [Pág. 23]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


         Una cadena de n bytes de relleno se puede comprimir en un sólo
         byte, donde el byte de relleno varía según el tipo de
         representación.  Si el tipo es ASCII o EBCDIC, el byte de
         relleno es <SP> (espacio, código ASCII 32, código EBCDIC 64).
         Si el tipo es imagen o byte local, el relleno es un byte cero.

         Cadena de Relleno:


              2       6
            +-+-+-+-+-+-+-+-+
            |1 1|     n     |
            +-+-+-+-+-+-+-+-+

         La secuencia de escape está formada por dos bytes, el primero
         de los cuales es el byte de escape (todo ceros) y el segundo
         contiene códigos de descripción según lo definido para el modo
         bloque. Los códigos tienen el mismo significado que
         anteriormente y se aplican a la cadenas de bytes transmitidas
         con éxito.

         EL modo comprimido es útil para obtener un ancho de banda
         adicicional en transmisiones muy largas con un coste extra de
         CPU muy pequeño. Se puede usar de forma muy efectiva para
         reducir el tamaño de ficheros para imprimir como los generados
         por ordenadores RJE.

   3.5.  RECUPERACION DE ERRORES Y REINICIO

      No hay nada que detecte bits perdidos o alterados en las
      transmisiones de datos; este nivel de control de errores lo maneja
      el TCP. Sin embargo, se proporciona un medio para recomenzar
      transferencia para proteger a los usuarios de fallos graves en el
      sistema (incluyendo fallos de un ordenador, un proceso FTP o de la
      red usada).

      Sólo está definido el procedimiento de reinicio para los modos de
      transferencia de bloque y comprimido. Requiere que el que envía
      datos inserte un código marcador especial en el flujo de datos con
      información que indique por dónde vamos. Esta información sólo
      tiene significado para el ordenador que envía los datos, pero debe
      consistir en caracteres imprimibles en el lenguaje negociado o por
      defecto de la conexión de control (ASCII o EBCDIC). El indicador
      puede representar una cuenta de los bits, los registros o
      cualquier otra información por la que un sistema pueda identificar
      un punto de control. El receptor de los datos, si implementa el
      procedimiento de reinicio, debería guardar la correspondiente
      posición de este marcador en el sistema receptor y devolver esta



Postel & Reynolds               Estándar                       [Pág. 24]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


      información al usuario.

      En el caso de un fallo del sistema, el usuario puede reiniciar la
      transferencia de datos identificando el último marcador recibido
      con el procedimiento de recomenzar del FTP. El siguiente ejemplo
      ilustra el uso de este procedimiento:

      El que envía datos inserta un bloque marcador apropiado en el
      flujo de datos en un punto conveniente. El que recibe marca el
      correspondiente punto en sus sistema de ficheros y proporciona al
      usuario información del último marcador recibido, ya sea
      directamente o por la conexión de control en una respuesta 110
      (dependiendo de quién envíe el fichero). Si ocurre un error del
      sistema, el usuario o proceso reinicia el servidor en el último
      punto que este indicó enviando la orden recomenzar con el marcador
      del servidor como argumento. La orden se transmite por la conexión
      de control y es seguida inmediatamente por la orden (ya sea RETR,
      STOR o LIST) que se estaba ejecuntado cuando ocurrió el error.

4.  FUNCIONES DE TRANSFERENCIA DE FICHEROS

   El canal de comunicación entre el user-PI y el server-PI se establece
   como una conexión TCP desde el usuario al puerto estándar. El
   intérprete de protocolo de usuario es responsable de enviar órdenes
   FTP e interpretar las respuestas recibidas; el server-PI interpreta
   las órdenes, envía respuestas y controla su DTP para establecer la
   conexión de datos y transferirlos. Si el proceso de transferencia
   pasiva es el user-DTP, entonces está controlado a través del
   protocolo interno del ordenador donde se ejecuta el user-DTP; si es
   otro server-DTP, está controlado a través de órdenes recibidas en su
   PI desde el user-PI. Las respuestas FTP se tratan en la siguiente
   sección.

   Al describir algunas de las órdenes en esta sección, viene bien ser
   explícito con las posibles respuestas.

   4.1.  ORDENES FTP

      4.1.1.  ORDENES DE CONTROL DE ACCESO

         Las siguientes órdenes especifican identificadores de control
         de acceso (los códigos de las órdenes están entre paréntesis).

         NOMBRE DE USUARIO (USER)
            El argumento es una cadena Telnet que identifica al usuario.
            Esta identificación es la que requiere el servidor para
            acceder a su sistema de ficheros. Normalmente esta será la
            primera orden a transmitir una vez establecida la conexión



Postel & Reynolds               Estándar                       [Pág. 25]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


            de control (algunos ordenadores lo pueden requerir). El
            servidor puede requerir información adicional como una
            contraseña y/o cuenta. Los servidores pueden permitir una
            nueva orden USER en cualquier momento para cambiar el
            control de acceso y/o la información de la cuenta. Esto
            tiene el efecto de descartar cualquier información anterior
            sobre usuario, contraseña y cuenta y comienza la secuencia
            de acceso otra vez. Todos lo parámetros de la transferencia
            permanecen sin cambios y cualquier transferencia de fichero
            en curso se completa bajo los anteriores parámetros de
            control de acceso.

         CONTRASEÑA (PASS)
            El argumento es una cadena Telnet especificando la
            contraseña del usuario. Esta orden debe ir inmediatamente
            precedida por la orden USER y, para algunos ordenadores,
            completa la identificación del usuario para el control de
            acceso. Como la información de la contraseña es un dato
            confidencial, es preferible, en general, "enmascararla" o
            evitar mostrarla en pantalla. Parece que el servidor no
            tiene un medio a prueba de tontos para conseguir esto. Por
            tanto es responsabiliad del proceso user-FTP el ocultar la
            información sobre la contraseña.

         CUENTA (ACCT)
            El argumento es una cadena Telnet identificando la cuenta
            del usuario. Esta orden no está necesariamente relacionada
            con la orden USER, ya que algunos ordenadores pueden
            requerir una cuenta para acceder y otros sólo para cierto
            tipo de acceso, como almacenar ficheros. En este último
            caso, la orden se puede enviar en cualquier momento.

            Hay códigos de respuesta para diferenciar automáticamente
            estos casos: cuando se requiere información de la cuenta, la
            respuesta a una orden PASS correcta es el código 332. Por
            otra parte, si NO se requiere esta información, la respuesta
            a una orden PASS correcta es 230; y si la cuenta se requiere
            para una orden enviada más tarde, el servidor debería
            devolver una respuesta 332 o una 532 dependiendo de que
            almacene (esté pendiente de recibir el comando ACCT) o
            descarte la orden, respectivamente.

         CAMBIO DE DIRECTORIO DE TRABAJO (CWD)
            Esta orden permite al usuario trabajar en un directorio o
            conjunto de datos [data set] diferente para almacenar o
            recuperar información sin alterar su información de entrada
            o de cuenta. Los parámetros de transferencia permanecen sin
            cambios. El argumento es un nombre de ruta especificando el



Postel & Reynolds               Estándar                       [Pág. 26]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


            directorio o alguna otra agrupación de ficheros dependiente
            del sistema.

         CAMBIAR AL DIRECTORIO PADRE (CDUP)
            Esta orden es un caso especial de CWD y se incluye para
            simplificar la implementación de programas para transferir
            árboles de directorios entre sistemas operativos que tienen
            diferentes formas de nombrar al directorio padre. Los
            códigos de respuestas deberán ser idénticos a los de CWD.
            Vea el Apéndice II para más detalles.

         MONTAR ESTRUCTURA (SMNT)
            Esta orden permite al usuario montar un sistema de ficheros
            diferente sin alterar su información de entrada o de cuenta.
            Los parámetros de transferencia permanecen sin cambios. El
            argumento es un nombre de ruta especificando un directorio o
            alguna otra agrupación de ficheros dependiente del sistema.

         REINICIALIZAR (REIN)
            Esta orden termina una orden USER, descargando todos los
            datos del entrada/salida y la información de cuenta, excepto
            que si hay alguna transferencia en proceso permite que
            termine. Todos los parámetros se inician con sus valores por
            defecto y la conexión de control se deja abierta. El estado
            alcanzado es idéntico al que se tiene inmediatamente después
            de abrir la conexión de control. Posiblemente se espere una
            orden USER a continuación de esta.

         DESCONECTAR (QUIT)
            Esta orden termina una orden USER y si no hay en proceso
            ninguna transferencia, cierra la conexión de control. Si hay
            una transferencia de fichero en proceso, la conexión
            permanecerá abierta hasta que el servidor envíe una
            respuesta con el resultado de la transferencia y luego se
            cierra. Si el proceso de usuario está transfiriendo ficheros
            para varios usuarios (USERs) pero no quiere cerrar la
            conexión y reabrirla para cada usuario, se debería usar el
            comndo REIN en lugar de QUIT. Un cierre inesperado de la
            conexión de control provoca que el servidor actúe como si
            hubiera recibido las órdenes interrumpir (ABOR) y
            desconectar (QUIT).

      4.1.2.  ORDENES DE PARAMETROS DE TRANSFERENCIA

         Todos los parámetros de transferencia de datos tienen valores
         por defecto y las órdenes que especifican valores para ellos
         sólo se deben utilizar si se van a cambiar los parámetros por
         defecto. El valor por defecto es el último valor especificado



Postel & Reynolds               Estándar                       [Pág. 27]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


         o, si no se ha especificado ninguno, el valor por defecto
         estándar es el que se indica aquí. Esto implica que el servidor
         debe "recordar" los valores por defecto aplicables. Las órdenes
         pueden ir en cualquier orden, pero deben preceder a la
         transferencia. Las siguientes órdenes especifican parámetros de
         transferencia de datos:

         PUERTO DE DATOS (PORT)
            El argumento es una especificación ordenador-puerto para el
            puerto que será usado en la conexión de datos. Hay valores
            por defecto tanto para el puerto de usuario como para el del
            servidor y, bajo circunstancias normales, esta orden y su
            respuesta no son necesarias. Si se usa esta orden, el
            argumento es la concatenación de una dirección IP (32 bits)
            y un puerto TCP (16 bits). Esta información está repartida
            en campos de 8 bits y el valor de cada campo se transmite
            como un número decimal (representado como una cadena de
            caracteres). Los campos están separados por comas. Una orden
            PORT podría ser algo así:

                  PORT h1,h2,h3,h4,p1,p2

            donde h1 es el número decimal correspondiente a los 8 bits
            más altos de la dirección IP del ordenador.

         PASIVO (PASV)
            Esta orden solicita al server-DTP que "escuche" en un puerto
            de datos (que no es el puerto por defecto) y espere a
            recibir una conexión en lugar de iniciar una al recibir una
            orden de transferencia. La respuesta a este comando incluye
            la dirección IP y el puerto donde este servidor está
            esperando a recibir la conexión.

         TIPO DE REPRESENTACION (TYPE)
            El argumento especifica un tipo de representación tal y como
            se describió en la sección Representación de Datos y
            Almacenamiento. Algunos tipos requieren un segundo
            parámetro. El primer parámetro es un único carácter Telnet y
            el segundo, para ASCII y EBCDIC, también; el segundo
            parámetro para tamaño de byte local es un entero decimal.
            Los parámetros están separados por un <SP> (espacio, código
            ASCII 32).

            Se asignan los siguientes códigos para tipos:







Postel & Reynolds               Estándar                       [Pág. 28]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


                    \    /
          A - ASCII |    | N - No para imprimir
                    |-><-| T - Formateo con caracteres Telnet
          E - EBCDIC|    | C - Control de carro (ASA)
                    /    \
          I - Imagen

          L <tamaño de byte> - Tamaño de byte local

            La representación por defecto es ASCII no para imprimir. Si
            se cambia el parámetro de formato y más tarde sólo el primer
            argumento, el formato vuelve a ser el inicial por defecto
            (no para imprimir).

         ESTRUCTURA DEL FICHERO (STRU)
            El argumento es un único carácter Telnet especificando una
            estructura de fichero de las descritas en la sección
            Representación de Datos y Almacenamiento.

            Existen los siguientes códigos para la estructura:

               F - Fichero (sin estructurar en registros) R -
               Estructurado en registros P - Estruturado en páginas

            La estructura por defecto es Fichero.

         MODO DE TRANSFERENCIA (MODE)
            El argumento es un único carácter Telnet especificando un
            modo de transferencia de los descritos en la sección Modos
            de Transmisión.

            Los posibles códigos son los siguientes:

               S - Flujo

               B - Bloque

               C - Comprimido

            El modo por defecto es Flujo.

      4.1.3.  ORDENES DE SERVICIO FTP

         Las órdenes de servicio FTP definen la transferencia del
         fichero o la función del sistema de ficheros que requiere el
         usuario. El argumento normalmente será un nombre de ruta. La
         sintaxis del nombre de ruta debe seguir las convenciones del
         servidor (con valores estándar por defecto aplicables) y las



Postel & Reynolds               Estándar                       [Pág. 29]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


         convenciones del lenguaje usado en la conexión de control.  Se
         sugiere que por defecto se utilice el último dispositivo,
         directorio o nombre de fichero o el valor por defecto para los
         usuarios locales. Las órdenes pueden enviarse en cualquier
         secuencia, excepto que la orden "renombrar" debe ir seguida por
         una "renombrar a" y la orden "recomenzar" debe ir seguida por
         la orden de servicio interrumpida (por ejemplo, STOR o RETR).
         Cuando se transfieren datos se debe hacer siempre a través de
         la conexión de datos, excepto para algunas respuestas
         informativas. Las siguientes órdenes especifican peticiones de
         servicio FTP:

         RECUPERAR (RETR)
            Esta orden hace que el server-DTP transfiera una copia del
            fichero especificado en el nombre de ruta al proceso que
            está al otro lado de la conexión de datos. El estado y el
            contenido del fichero en el servidor debe permanecer tal y
            como estaba.

         ALMACENAR (STOR)
            Esta orden hace que el server-DTP lea los datos transferidos
            por la conexión de datos y los guarde en un fichero en el
            servidor. Si el fichero especificado en el nombre de ruta
            existe en el servidor, su contenido se debe reemplazar con
            los datos recibidos. Se crea un fichero nuevo en el servidor
            si el indicado no existía ya.

         ALMACENAR UNICO (STOU)
            Esta orden se comporta igual que STOR sólo que el fichero
            resultante se crea en el directorio actual con un nombre
            único para ese directorio. La respuesta 250 Transferencia
            iniciada debe incluir el nombre generado.

         AÑADIR (con creación) (APPE)
            Esta orden hace que el server-DTP reciba datos a través de
            la conexión de control y los guarde en un fichero en el
            servidor. Si el fichero especificado en el nombre de ruta
            existe, los datos se añaden a ese fichero; si no, se crea un
            fichero nuevo en el servidor.

         SOLICITAR ESPACIO (ALLO)
            Esta orden puede ser necesaria para que algunos servidores
            reserven suficiente espacio de almacenamiento para recibir
            el nuevo fichero.  El argumento debe ser un entero decimal
            indicando el número de bytes (usando el tamaño de byte
            lógico) de almacenamiento que se deben reservar. Para
            ficheros enviados con estructura en registros o páginas,
            puede ser necesario enviar el tamaño máximo de registro o



Postel & Reynolds               Estándar                       [Pág. 30]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


            página; esto se indica con un entero decimal como segundo
            argumento de la orden. Este segundo argumento es opcional,
            pero cuando se utilice, debe estar separado del primero por
            los caracteres Telnet <SP> R <SP>. A continueción de esta
            orden se deberá indicar una orden STOR o APPE. La orden ALLO
            debería tratarse como la orden NOOP (no operación) por los
            servidores que no necesitan conocer de antemano el tamaño
            del fichero y aquellos servidores que sólo interpreten el
            tamaño máximo de registro o página deberían admitir un valor
            inutil como primer argumento e ignorarlo.

         RECOMENZAR (REST)
            El argumento representa un marcador del servidor a partir
            del cual debe recomenzar la transferencia. La orden no
            realiza la transferencia del fichero, pero hace que el
            puntero de lectura o escritura del fichero se sitúe a
            continuación del punto indicado. A continuación de esta
            orden se debe enviar la orden de servicio FTP apropiada que
            hará que continúe la transferencia del fichero.

         RENOMBRAR DE (RNFR)
            Esta orden indica el fichero que queremos cambiar de nombre
            en el servidor. Debe ir inmediatamente seguida de la orden
            "renombrar a" con el nuevo nombre para el fichero.

         RENOMBRAR A (RNTO)
            Esta orden especifica el nuevo nombre para el fichero
            indicado mediante el comando RNFR. Las dos órdenes seguidas
            hacen que el fichero cambie de nombre.

         INTERRUMPIR (ABOR)
            Este comando pide al servidor que interrumpa la orden de
            servicio FTP previa y cualquier transferencia de datos
            asociada. La orden de interrupción puede requerir alguna
            "acción especial", tratada más adelante, para forzar el
            reconocimiento de la orden por el servidor. No se hará nada
            si la orden anterior ha finalizado (incluyendo la
            transferencia de datos). El servidor no cierra la conexión
            de control, pero puede que sí cierre la conexión de datos.
            Hay dos posibles casos para el servidor al recibir esta
            orden: (1) la orden de servicio FTP está ya terminada, o (2)
            aún está en ejecución.

            En el primer caso, el servidor cierra la conexión de datos
            (si está abierta) y devuelve una respuesta 226 indicando que
            la orden de interrumpir se ha procesado correctamente. En el
            segundo caso, el servidor interrumpe el servicio FTP en
            proceso y cierra la conexión de datos, devolviendo una



Postel & Reynolds               Estándar                       [Pág. 31]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


            respuesta 426 para indicar que la solicitud de servicio
            terminó anormalmente. Luego, el servidor envía una respuesta
            226 para indicar que la orden de interrumpir se ha procesado
            correctamente.

         BORRAR (DELE)
            Esta orden borra en el servidor el fichero indicado en el
            nombre de ruta. Si se quiere tener un nivel extra de
            protección (del tipo "¿Seguro qu quiere borrar el
            fichero?"), la debería proporcionar el proceso user-FTP.

         BORRAR DIRECTORIO (RMD)
            Esta orden borra en el servidor el directorio indicado. Vea
            el Apéndice II.

         CREAR DIRECTORIO (MKD)
            Esta orden crea el directorio indicado en el servidor. Vea
            el Apéndice II.

         MOSTRAR EL DIRECTORIO DE TRABAJO (PWD)
            Esta orden hace que el servidor nos devuelva en la respuesta
            el nombre del directorio actual. Vea Apéndice II.

         LISTAR (LIST)
            Esta orden hace que el servidor envíe una listado de los
            ficheros a través del proceso de transferencia de datos
            pasivo. Si el nombre de ruta u otra agrupación de ficheros,
            el servidor debe transferir una lista de los ficheros en el
            directorio indicado. Si el nombre de ruta especifica un
            fichero, el servidor debería enviar información sobre el
            fichero. Si no se indica argumento alguno, implica que se
            quiere listar el directorio de trabajo actual o directorio
            por defecto. Los datos se envían a traves de la conexión de
            datos con tipo ASCII o EBCDIC. (El usuario se debe asegurar
            del tipo con TYPE).  Como la información sobre un fichero
            puede variar mucho de un sistema a otro, es muy difícil que
            ésta pueda ser procesada automáticamente, pero puede ser
            útil para una persona.

         LISTAR NOMBRES (NLST)
            Esta orden hace que se envíe un listado de directorio desde
            el servidor. El nombre de ruta indica un directorio u otra
            agrupación de ficheros específica del sistema; si no hay
            argumento, se asume el directorio actual. Los datos se
            transfieren en formato ASCII o EBCDIC a través de la
            conexión de datos separados unos de otros por <CRLF> o <NL>.
            (Una vez más el usuario se debe asegurar con TYPE). La
            función de esta orden es devolver información que pueda ser



Postel & Reynolds               Estándar                       [Pág. 32]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


            usada por un programa para procesar posteriormente los
            ficheros automáticamente. Por ejemplo, implementando una
            función que recupere varios ficheros.

         PARAMETROS DEL SISTEMA (SITE)
            Esta orden la usa el servidor para proporcionar servicios
            específicos propios de su sistema que son fundamentales para
            transferir ficheros pero no lo suficientemente universales
            como para ser incluídos como órdenes en el protocolo. La
            naturaleza de este servicio y la especificación de su
            sintaxis se puede obtener como respuesta a una orden HELP
            SITE.

         SISTEMA (SYST)
            Esta orden devuelve el tipo de sistema operativo del
            servidor.  La respuesta debe tener como primera palabra uno
            de los nombres de sistema listados en la versión actual del
            documento Números Asignados [4].

         ESTADO (STAT)
            Esta orden hace que el servidor nos envía una respuesta con
            su estado a través de la conexión de control. La orden se
            puede enviar durante la transferencia de un fichero (junto
            con las señales Telnet IP y Synch--vea la sección Ordenes
            FTP) en cuyo caso el servidor responderá con el estado de la
            operación en progreso, o se puede enviar entre
            transferencias de ficheros. En este último caso, la orden
            puede llevar un argumento. Si el argumento es un nombre de
            ruta, la orden es similar a LIST, excepto que los datos se
            devolverán por la conexión de control. Si no hay ningún
            argumento, el servidor devolverá información general del
            estado del proceso servidor FTP. Esto debería incluir los
            valores actuales de los parámetros de transferencia y el
            estado de las conexiones.

         AYUDA (HELP)
            Esta orden hace que el servidor envíe información sobre la
            implementación del FTP a través de la conexión de control.
            La orden puede tener un argumento que debe ser un nombre de
            orden y así devuelve información más específica como
            respuesta. La respuesta es de tipo 211 ó 214. Se sugiere que
            se permita el uso de HELP antes de el comando USER. El
            servidor puede usar esta respuesta para especificar
            parámetros dependientes del sistema, por ejemplo, en
            respuesta a HELP SITE.

         NO OPERACION (NOOP)
            Esta orden no afecta a ningún parámetro ni orden introducida



Postel & Reynolds               Estándar                       [Pág. 33]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


            previamente. No hace nada más que provocar que el servidor
            envíe una respuesta OK.

      El Protocolo de Transferencia de Ficheros sigue la especificación
      del Protocolo Telnet en todas las comunicaciones a través de la
      conexión de control. Como el lenguaje usado para comunicación
      Telnet puede ser una opción negociada, todas las referencias en
      las siguientes dos secciones se referirán al "lenguaje Telnet" y
      el correspondiente "código Telnet de fin-de-línea". De momento,
      podemos entender que esto significa NVT-ASCII y <CRLF>. No se hará
      mención a ninguna otra especificación del Protocolo Telnet.

      Las órdenes FTP son "cadenas Telnet" terminadas con el "código
      Telnet de fin de línea". Los códigos de orden son caracteres
      alfabéticos terminados con el carácter <SP> (espacio) si tienen
      parámetros o el carácter Telnet EOL (fin de línea) si no los
      tienen. En esta seción se han descrito los códigos de orden y su
      significado; la sintaxis detallada se encuentra en la sección
      sobre Ordenes, las secuencias de respuesta se explican en la
      sección Secuencia de Ordenes y Respuestas, y se muestran ejemplos
      del uso de estos comandos en la sección Escenario Típico del FTP.

      Las órdenes FTP se pueden dividir en aquellas que indican
      identificadores de control de acceso, parámetros de transferencia
      de datos y peticiones de servicio FTP. Algunas órdenes (como ABOR,
      STAT y QUIT) se pueden enviar por la conexión de control cuando
      hay una transferencia en proceso. Puede que algunos servidores no
      sean capaces de gestionar las conexiones de control y de datos
      simultáneamente, en cuyo caso puede ser necesaria alguna acción
      especial para captar la atención del servidor. Se recomienda
      insistentemente esta forma:

         1. Se inserta la señal Telnet "Interrumpir Proceso" (IP) en la
         conexión de control.

         2. Se envía la señal Telnet "Synch".

         3. Se envía el comando (p.e., ABOR) por la conexión de control.

         4. El intérprete de protocolo del servidor, después de recibir
         la señal "IP", lee de la conexión de control UNICAMENTE UN
         COMANDO.  (Para otros servidores, puede que esto no sea
         necesario, pero el hacerlo no tendrá ninguna repercusión.)

   4.2.  RESPUESTAS FTP

      Las respuestas a órdenes del FTP están pensadas para asegurar la
      sincronización entre peticiones y acciones en el proceso de



Postel & Reynolds               Estándar                       [Pág. 34]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


      transferencia de ficheros y para garantizar que el proceso de
      usuario siempre conoce el estado del servidor. Cada orden debe
      generar por lo menos una respuesta, aunque puede haber más de una;
      en este último caso, las diferentes respuestas se deben distinguir
      fácilmente. Además, algunos comandos deben ocurrir en secuencia,
      como USER, PASS y ACCT o RNFR y RNTO. Las respuestas muestran la
      existencia de un estado intermedio si todos los comandos
      anteriores han ido correctamente. Un error en cualquier punto de
      la seuencia implica que se debe iniciar de nuevo desde el
      principio.

      Los detalles de la secuencia orden-respuesta se muestran en un
      conjunto de diagramas de estado más abajo.

      Una respuesta FTP consiste en un número de tres cifras
      (transmitido como tres caracteres alfanuméricos) seguidos de
      texto. El número se proporciona para su uso por autómatas que
      deben determinar el próximo estado; el texto va dirigido a las
      personas. Se pretende que el número contenga suficiente
      información codificada como para que el intérprete de protocolo de
      usuario no necesite examinar el texto y pueda o bien descartarlo o
      bien mostrarlo al usuario. En particular, el texto puede depender
      del servidor y, por tanto, puede variar en cada código de
      respuesta.

      Una respuesta debe contener el código de 3 dígitos, seguidos de
      espacio <SP>, seguido de una línea de texto (en la que hay
      definido una longitud máxima), y termina con el código Telnet de
      fin de línea. Habrá casos en los que el texto es mayor que una
      línea. En estos casos el texto debe ir marcado para que el proceso
      de usuario sepa cuando ha terminado la respuesta (i.e., deje de
      leer de la conexión de control) y haga otras cosas.  Esto requiere
      de un formato especial en la primera línea para indicar que hay
      más y otro en la última línea para indicar lo propio. Al menos una
      de estas debe contener el código de respuesta apropiado para
      indicar el estado de la transacción. Para satisfacer a todos, se
      ha decidido que ambas, la primera y la última línea, deben
      contener el mismo código.

      Por tanto, el formato para respuestas multi-línea consiste en que
      la primera línea empieza con el código de respuesta requerido
      seguido inmediatamente de un guión, "-" (también es el signo
      menos), seguido de el texto. La última línea empezará con el mismo
      código, seguido inmediatamente por un espacio <SP>, opcionalmente
      texto, y el código Telnet de fin de línea.

      Por ejemplo:




Postel & Reynolds               Estándar                       [Pág. 35]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


                 123-Primera linea
                     Segunda linea
                 234 Una linea que comienza con numeros
                 123 La ultima linea

      El proceso de usuario sólo necesita buscar la segunda ocurrencia
      del mismo código de respuesta, seguido de <SP> (espacio), al
      principio de una línea. Si una línea intermedia comienza con un
      número de tres dígitos, el servidor debe desplazar ese número para
      evitar confusiones.

      Este esquema permite permite que se usen los procedimientos
      estándar del sistema para la información de respuesta (como, por
      ejemplo, para STAT), con las líneas primera y última añadidas
      "artificialmente". En casos raros en los que estos procedimientos
      generen tres dígitos y un espacio al principio de cualquier línea,
      el principio de cada línea de texto se debería desplazar con algún
      texto neutral, como espacios.

      Este esquema asume que las respuestas multilínea no pueden estar
      anidadas.

      Cada tres dígitos de la respuesta tienen un significado especial.
      Se pretende permitir un rango de respuestas desde muy simple a muy
      sofisticado para el proceso de usuario. El primer dígito denota si
      la respuesta es buena, mala o incompleta. (Refiriendonos al
      diagrama de estado), un proceso de usuario poco sofisticado podrá
      determinar su próxima acción simplemente examinando el primer
      dígito. Un proceso de usuario que quiera conocer aproximadamente
      el tipo de error ocurrido (por ejemplo, error del sistema de
      ficheros o error de sintaxis) puede examinar el segundo dígito,
      reservando el tercero para una mayor precisión en la información
      (por ejemplo, orden RNTO sin ser precedida por una RNFR).

      Hay cinco valores para el primer dígito del código de respuesta:

         1yz Respuesta preliminar positiva
            Se ha iniciado la acción requerida; se espera otra respuesta
            antes de seguir con una nueva orden. (El proceso de usuario
            que envía otra orden antes de que la respuesta de
            finalización llegue, estará violando el protocolo, pero el
            proceso servidor debería encolar cualquier orden que reciba
            mientras está ejecutando una orden anterior.) Este tipo de
            respuesta se puede usar para indicar que se ha aceptado la
            orden y que el proceso de usuario debería ocuparse ahora de
            la conexión de datos, en implementaciones donde controlar
            ambas conexiones a la vez es difícil. El proceso servidor
            puede enviar, a lo sumo, una respuesta 1yz por orden



Postel & Reynolds               Estándar                       [Pág. 36]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


            recibida.

         2yz Respuesta de finalización positiva
            La acción requerida se ha completado satisfactoriamente. Se
            puede iniciar una nueva orden.

         3yz Respuesta intermedia positiva
            La orden se ha aceptado, pero se está pendiente de recibir
            más información para completarla. El usuario debería enviar
            otra orden indicando esta información. Esta respuesta se
            utiliza en órdenes que deben ir en secuencia.

         4yz Repuesta de finalización negativa transitoria
            La orden no se ha aceptado y la acción requerida no se ha
            llevado a cabo, pero la condición de error es temporal y se
            puede solicitar la acción de nuevo. El usuario debería
            volver al principio de la secuencia de comandos, si es que
            la hay. Es difícil dar un significado a "transitoria",
            particularmente cuando dos sistemas diferentes (el servidor
            y el usuario) deben estar de acuerdo en la interpretación.
            Cada respuesta la categoría 4yz puede tener un valor
            diferente, pero se pretende con ella que el proceso de
            usuario reintente la operación. Una regla para determinar si
            una respuesta pertenece a la categoría 4yz o a la 5yz
            (permanente negativa) es que las respuestas son 4yz si la
            orden se puede repetir sin cambios en la forma o en las
            propiedades del usuario o del servidor (por ejemplo, la
            orden y sus argumentos son los mismos; el usuario no cambia
            su cuenta ni su nombre; el servidor no lo interpreta de
            diferente forma.

         5yz Respuesta de finalización negativa permanente
            La orden no se ha aceptado y la acción requerida no ha
            tenido lugar. El proceso de usuario no debería repetir la
            misma petición (en la misma secuencia). Incluso algunas
            condiciones de error "permanente" se pueden corregir, por
            eso el usuario (la persona) puede hacer posteriormente que
            su proceso de usuario repita posteriormente la orden (por
            ejemplo, se corrige el argumento, o el usuario cambia el
            estado de su directorio.)

      Las siguientes agrupaciones de funciones se codifican en el
      segundo dígito:

         x0z Sintaxis
            Estas respuestas se refieren a errores de sintaxis, órdenes
            correctas sintácticamente pero que no encajan en ninguna
            otra categoría, órdenes no implementadas o superfluas.



Postel & Reynolds               Estándar                       [Pág. 37]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


         x1z Información
            Estas son respuestas a solicitudes de información como
            STATUS o HELP.

         x2z Conexiones
            Respuestas referidas a las conexiones de control y de datos.

         x3z Autenticación y cuenta
            Respuestas para el proceso de entrada al sistema y
            procedimientos de cuenta.

         x4z Sin especificar aún.

         x5z Sistema de ficheros
            Estas respuestas indican el estado del sistema de ficheros
            en el servidor según se realizan transferencias u otras
            acciones sobre el sistema de ficheros.

      El tercer dígito afina más en el significado de cada una de las
      categorías indicadas por el segundo. La lista de respuestas de la
      siguiente sección mostrará esto. El texto asociado con cada
      respuesta es sólo una recomendación, no una obligación, y puede
      incluso cambiar según la orden asociada. Los códigos de respuesta,
      por otra parte, deben seguir estrictamente las especificaciones;
      es decir, las implementaciones de servidores no deben inventarse
      nuevos códigos para situaciones que son ligeramente diferentes a
      las descritas aquí, sino que deberían adaptarse a los códigos ya
      definidos.

      Una orden como TYPE o ALLO cuya correcta ejecución no proporciona
      al usuario ninguna nueva información debería devolver un código
      200. Si la orden no se ha implementado porque no tiene sentido
      para un determinado sistema, por ejemplo ALLO en un TOPS-20, una
      respuesta de finalización positiva es conveniente para no
      confundir al proceso de usuario. En este caso se usa una respuesta
      202 con, por ejemplo, el siguiente texto: "No es necesario
      solicitar espacio para el fichero." Si, por otra parte, la orden
      no es específica a ningún sistema y no está implementada, la
      respuesta debe ser 502. Un caso particular de esto es la respuesta
      504 para una orden que está implementada pero que se solicita con
      un argumento no implementado.

      4.2.1  Códigos de respuesta por grupos funcionales

         200 Orden correcta.

         500 Error de sintaxis, comando no reconocido.
            Esto puede incluir errores como línea de orden demasiado



Postel & Reynolds               Estándar                       [Pág. 38]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


            larga.

         501 Error de sintaxis en parámetros o argumentos.

         202 Orden no implementada, no necesaria en este sistema.

         502 Orden no implementada.

         503 Secuencia de órdenes incorrecta.

         504 Orden no implementada para ese parámetro.


         110 Respuesta de marcador de reinicio.
            En este caso, el texto debe ser:
               MARK yyyy = mmmm
            Donde yyyy es el marcador del flujo de datos en el proceso
            de usuario y mmmm es el equivalente en el servidor (atención
            a los espacios entre los marcadores y el "=").

         211 Estado del sistema o respuesta de ayuda del sistema.

         212 Estado del directorio.

         213 Estado del fichero.

         214 Mensaje de ayuda.
            Sobre como usar el servidor o el significado de una orden
            particular no estándar. Esta respuesta sólo es útil para una
            persona.

         215 NOMBRE system type.
            Donde NOMBRE es un nombre de sistema oficial de la lista que
            hay en el documento Números Asignados.

         120 El servicio estará en funcionamiento en nnn minutos.

         220 Servicio preparado para nuevo usuario.

         221 Cerrando la conexión de control.
            Desconectado si procede.

         421 Servicio no disponible, cerrando la conexión de control.
            Esta puede ser la respuesta a cualquier comando si el
            servidor sabe que debe finalizar.

         125 La conexión de datos ya está abierta; comenzando
         transferencia.



Postel & Reynolds               Estándar                       [Pág. 39]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


         225 Conexión de datos abierta; no hay transferencia en proceso.

         425 No se puede abrir la conexión de datos.

         226 Cerrando la conexión de datos.
            La acción sobre fichero requerida ha sido correcta (por
            ejemplo, una transferencia o interrupción).

         426 Conexión cerrada; transferencia interrumpida.

         227 Iniciando modo pasivo (h1,h2,h3,h4,p1,p2).


         230 Usuario conectado, continúe.

         530 No está conectado.

         331 Usuario OK, necesita contraseña.

         332 Necesita una cuenta para entrar en el sistema.

         532 Necesita una cuenta para almacenar ficheros.


         150 Estado del fichero correcto; va a abrirse la conexión de
         datos.

         250 La acción sobre fichero solicitado finalizó correctamente.

         257 "NOMBRERUTA" creada.

         350 La acción requiere más información

         450 Acción no realizada.
            Fichero no disponible (por ejemplo, fichero bloqueado).

         550 Acción no realizada,
            Fichero no disponible (por ejemplo, fichero no existe, no se
            tiene acceso al mismo).

         451 Acción interrumpida. Error local.

         551 Acción interrumpida. Tipo de página desconocido.

         452 Acción no realizada.
            Falta de espacio en el sistema de ficheros.

         552 Acción interrumpida.



Postel & Reynolds               Estándar                       [Pág. 40]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


            Se ha sobrepasado el espacio disponible de almacenamiento
            (para el directorio actual).

         553 Acción no realizada.
            Nombre de fichero no permitido.

      4.2.2 Códigos de respuesta por número.

         110 Respuesta de marcador de reinicio.
            En este caso, el texto debe ser:
               MARK yyyy = mmmm
            Donde yyyy es el marcador del flujo de datos en el proceso
            de usuario y mmmm es el equivalente en el servidor (atención
            a los espacios entre los marcadores y el "=").

         120 El servicio estará en funcionamiento en nnn minutos.

         125 La conexión de datos ya está abierta; comenzando
         transferencia.

         150 Estado del fichero correcto; va a abrirse la conexión de
         datos.

         200 Orden correcta.

         211 Estado del sistema o respuesta de ayuda del sistema.

         212 Estado del directorio.

         213 Estado del fichero.

         214 Mensaje de ayuda.
            Sobre como usar el servidor o el significado de una orden
            particular no estándar. Esta respuesta sólo es útil para una
            persona.

         215 NOMBRE system type.
            Donde NOMBRE es un nombre de sistema oficial de la lista que
            hay en el documento Números Asignados.

         220 Servicio preparado para nuevo usuario.

         221 Cerrando la conexión de control.
            Desconectado si procede.

         225 Conexión de datos abierta; no hay transferencia en proceso.

         226 Cerrando la conexión de datos.



Postel & Reynolds               Estándar                       [Pág. 41]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


            La acción sobre fichero requerida ha sido correcta (por
            ejemplo, una transferencia o interrupción).

         227 Iniciando modo pasivo (h1,h2,h3,h4,p1,p2).

         230 Usuario conectado, continúe.

         250 La acción sobre fichero solicitado finalizó correctamente.

         257 "NOMBRERUTA" creada.

         331 Usuario OK, necesita contraseña.

         332 Necesita una cuenta para entrar en el sistema.

         532 Necesita una cuenta para almacenar ficheros.

         350 La acción requiere más información.

         421 Servicio no disponible, cerrando la conexión de control.
            Esta puede ser la respuesta a cualquier comando si el
            servidor sabe que debe finalizar.

         425 No se puede abrir la conexión de datos.

         426 Conexión cerrada; transferencia interrumpida.

         450 Acción no realizada.
            Fichero no disponible (por ejemplo, fichero bloqueado).

         451 Acción interrumpida. Error local.

         452 Acción no realizada.
            Falta de espacio en el sistema de ficheros.

         500 Error de sintaxis, comando no reconocido.
            Esto puede incluir errores como línea de orden demasiado
            larga.

         501 Error de sintaxis en parámetros o argumentos.

         202 Orden no implementada, no necesaria en este sistema.

         502 Orden no implementada.

         503 Secuencia de órdenes incorrecta.

         504 Orden no implementada para ese parámetro.



Postel & Reynolds               Estándar                       [Pág. 42]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


         530 No está conectado.

         550 Acción no realizada,
            Fichero no disponible (por ejemplo, fichero no existe, no se
            tiene acceso al mismo).

         551 Acción interrumpida. Tipo de página desconocido.

         552 Acción interrumpida.
            Se ha sobrepasado el espacio disponible de almacenamiento
            (para el directorio actual).

         553 Acción no realizada.
            Nombre de fichero no permitido.

5.  ESPECIFICACIONES

   5.1.  IMPLEMENTACION MINIMA

      Para hacer un FTP funcional sin mensajes de error innecesarios, se
      requiere que todos los servidores implementen como mínimo las
      siguientes funciones:

         TIPO - ASCII No para imprimir

         MODO - Flujo

         ESTRUCTURA - Fichero, registros

         ORDENES - USER, QUIT, PORT,

                  TYPE, MODE, STRU,

                  para los valores por defecto

                  RETR, STOR,

                  NOOP.

      Los valores por defecto de los parámetros de transferencia:

         TYPE - ASCII No para imprimir MODE - Flujo STRU - Fichero

      Todos los servidores deben aceptar los valores indicados como
      estándar por defecto.

   5.2.  CONEXIONES




Postel & Reynolds               Estándar                       [Pág. 43]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


      El intérprete de protocolo del servidor debe "escuchar" en el
      puerto L. El usuario o el intérprete de protocolo de usuario
      iniciará la conexión de control full-duplex (bidireccional). Los
      procesos de servidor y de usuario deberían seguir las convenciones
      del Protocolo Telnet tal y como se especifican en el Manual de
      Protocolos de ARPA-Internet [1]. Los servidores no tienen ninguna
      obligación de proporcionar facilidades para la edición de la línea
      de comandos y pueden requerir que esto se haga en el ordenador del
      usuario. El servidor deberá cerrar la conexión a petición del
      usuario después de que todas las transferencias y respuestas se
      han enviado.

      El user-DTP debe "escuchar" en el puerto de datos especificado;
      este puede ser el puerto por defecto (U) u otro especificado por
      la orden PORT.  El servidor, por defecto, iniciará las conexiones
      de datos desde su propio puerto de datos por defecto (L-1) usando
      el puerto de datos indicado por el usuario. El sentido de la
      transferencia y el puerto se determinarán por la orden de servicio
      FTP.

      Todas las implementaciones del FTP deben poder transferir datos
      usando el puerto por defecto y sólo el user-PI puede solicitar el
      uso de puertos diferentes.

      Cuando se van a transferir datos entre dos servidores, A y B (ver
      Figura 2), el user-PI, C, establece la conexión de control entre
      ambos server-PIs. A uno de los servidores, por ejemplo, A, se le
      envía un comando PASV indicandole que "escuche" en su puerto de
      datos en lugar de iniciar la conexión cuando reciba la petición de
      transferencia. Cuando el user-PI recibe la respuesta a la orden
      PASV, que incluye la dirección del ordenador y el puerto donde
      está escuchando, el user-PI envía el puerto de A a B mediante un
      comando PORT; se devuelve una respuesta. Luego el user-PI puede
      enviar las correspondientes órdenes a A y B. El servidor B inicia
      la conexión y comienza la transferencia de datos. La secuencia
      orden-respuesta se muestra aquí. Los mensajes se muestran en orden
      verticalmente, pero no horizontalmente:














Postel & Reynolds               Estándar                       [Pág. 44]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


         User-PI - Servidor A              User-PI - Servidor B
         --------------------              --------------------

         C->A : Conexión                   C->B : Conexión
         C->A : PASV
         A->C : 227 Iniciando modo pasivo. A1,A2,A3,A4,a1,a2
                                           C->B : PORT A1,A2,A3,A4,a1,a2
                                           B->C : 200 Orden correcta.
         C->A : STOR                       C->B : RETR
                    B->A : Conexión a HOST-A, PORT-a
                                Figura 3

      El servidor cerrará la conexión de datos en las condiciones
      descritas en la sección Estableciendo Conexiones de Datos. Si se
      va a cerrar la conexión de datos y no se necesita esto para
      indicar el final de fichero, el servidor lo debe hacer
      inmediatamente. No se permite que espere hasta recibir una nueva
      orden de transferencia porque el proceso de usuario ya habrá
      comprobado la conexión de datos para ver si necesita "escuchar"
      (recuerde que el usuario debe "escuchar" en un puerto cerrado
      ANTES de enviar la petición de transferencia. Para evitar fallos
      de sincronización, el servidor envía una respuesta (226) después
      de cerrar la conexión de datos (o, si la conexión se deja abierta,
      una respuesta "Transferencia completada." (250) y el user-PI
      debería esperar una de estas respuestas antes de enviar una nueva
      orden de transferencia) .

      En cualquier momento en que el servidor o el usuario vean que el
      otro va a cerrar la conexión, debería leer inmediatamente
      cualquier dato que permanezca encolado en la conexión y proceder
      al cierre de la misma.

   5.3.  ORDENES

      Las órdenes son cadenas de caracteres Telnet transmitidas por la
      conexión de control tal y como se describe en la sección Ordenes
      FTP.

      Las funciones y la semántica de las órdenes se describe en las
      secciones Ordenes de Control de Acceso, Ordenes de Parámetros de
      Transferencia, Ordenes de Sevicio FTP y Ordenes Varias. La
      sintaxis de los comandos se detalla aquí.

      Las órdenes comienzan con un código de orden seguido de unos
      argumentos. Los códigos de orden tienen cuatro o menos carcteres
      alfabéticos. Las letras mayúsculas y las minúsculas se tratan de
      la misma manera. Por tanto, cualquiera de las siguientes puede
      representar a la orden "recuperar":



Postel & Reynolds               Estándar                       [Pág. 45]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


               RETR    Retr    retr    ReTr    rETr

      También se aplica esto a cualquier símbolo que represente valores
      de los parámetros como la 'A' para el tipo ASCII. Los códigos de
      comando y el campo de argumentos están separados por uno o más
      espacios.

      El campo de argumentos consiste en una cadena de caracteres de
      longitud variable terminada con la secuencia de caracteres <CRLF>
      (Retorno de carro, avance de línea) para la representación NVT-
      ASCII; para otros lenguajes negociados puede que se use otro
      representación para el fin de línea. El servidor no realizará
      ninguna acción hasta recibir el código de fin de línea.

      La sintaxis se especifica más abajo en NVT-ASCII. Todos los
      caracteres del campo de argumentos son caracteres ASCII,
      incluyendo los enteros decimales representados en ASCII. Los
      paréntesis cuadrados indican que un argumento es opcional. Si no
      se proporciona el argumento implica que se toma un valor por
      defecto apropiado.

      5.3.1.  ORDENES FTP
         Las órdenes FTP son las siguientes:

            USER <SP> <nombre-usuario> <CRLF>

            PASS <SP> <contraseña> <CRLF>

            ACCT <SP> <información-cuenta> <CRLF>

            CWD  <SP> <nombre-ruta> <CRLF>

            CDUP <CRLF>

            SMNT <SP> <nombre-ruta> <CRLF>

            QUIT <CRLF>

            REIN <CRLF>

            PORT <SP> <dirIP-puerto> <CRLF>

            PASV <CRLF>

            TYPE <SP> <código-tipo> <CRLF>

            STRU <SP> <código-estructura> <CRLF>




Postel & Reynolds               Estándar                       [Pág. 46]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


            MODE <SP> <código-modo> <CRLF>

            RETR <SP> <nombre-ruta> <CRLF>

            STOR <SP> <nombre-ruta> <CRLF>

            STOU <CRLF>

            APPE <SP> <nombre-ruta> <CRLF>

            ALLO <SP> <entero-decimal>

                [<SP> R <SP> <entero-decimal>] <CRLF>

            REST <SP> <marcador> <CRLF>

            RNFR <SP> <nombre-ruta> <CRLF>

            RNTO <SP> <nombre-ruta> <CRLF>

            ABOR <CRLF>

            DELE <SP> <nombre-ruta> <CRLF>

            RMD  <SP> <nombre-ruta> <CRLF>

            MKD  <SP> <nombre-ruta> <CRLF>

            PWD  <CRLF>

            LIST [<SP> <nombre-ruta>] <CRLF>

            NLST [<SP> <nombre-ruta>] <CRLF>

            SITE <SP> <cadena> <CRLF>

            SYST <CRLF>

            STAT [<SP> <nombre-ruta>] <CRLF>

            HELP [<SP> <cadena>] <CRLF>

            NOOP <CRLF>


      5.3.2.  ARGUMENTOS DE LAS ORDENES FTP

         La sintaxis de los argumentos (usando la notación BNF) es:



Postel & Reynolds               Estándar                       [Pág. 47]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


            <nombre-usuario> ::= <cadena>

            <contraseña> ::= <cadena>

            <información-cuenta> ::= <cadena>

            <cadena> ::= <carácter> | <carácter><cadena>

            <carácter> ::= cualquier carácter ASCII excepto <CR> y <LF>

            <marcador> ::= <pr-cadena>

            <pr-cadena> ::= <pr-carácter> | <pr-carácter><pr-cadena>

            <pr-carácter> ::= caracteres imprimibles, cualquier código
                              ASCII desde 33 a 126.

            <tamaño-byte> ::= <número>

            <dirIP-puerto> ::= <host-número>,<port-número>

            <host-número> ::= <número>,<número>,<número>,<número>

            <port-número> ::= <número>,<número>

            <número> ::= cualquier entero decimal desde 1 a 255

            <código-formateo> ::= N | T | C

            <código-tipo> ::= A [<sp> <código-formateo>]
                          | E [<sp> <código-formateo>]
                          | I
                          | L <sp> <tamaño-byte>

            <código-estructura> ::= F | R | P

            <código-modo> ::= S | B | C

            <nombre-ruta> ::= <cadena>

            <entero-decimal> ::= cualquier entero decimal

   5.4.  SECUENCIA DE ORDENES Y RESPUESTAS

      La comunicación entre el usuario y el servidor se lleva a cabo
      mediante un diálogo. Como tal, el usuario envía una orden y el
      servidor devuelve una respuesta. El usuario debería esperar a
      recibir la respuesta antes de enviar más ordenes.



Postel & Reynolds               Estándar                       [Pág. 48]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


      Algunas órdenes requieren una segunda respuesta a la que el
      usuario debería también esperar. Estas respuestas informan, por
      ejemplo, del estado o la finalización de una transferencia o del
      cierre de la conexión de datos.  Son respuestas secundarias a
      órdenes de transferencia de ficheros. Un grupo importante de
      respuestas informativas son los mensajes al iniciar la conexión.
      En circunstancias normales, un servidor enviará una respuesta 220,
      "Esperando órdenes", cuando se completa la conexión. El usuario
      debería esperar esta respuesta antes de enviar cualquier orden. Si
      el servidor no puede aceptar órdenes en ese momento, se debería
      enviar una respuesta 120 indicando el tiempo previsto de retraso y
      una respuesta 220 cuando esté disponible. El usuario sabrá así que
      no debe desconectar.

      Respuestas espontáneas

         A veces "el sistema" tiene que enviar un mensaje al usuario
         espontáneamente (normalmente a todos los usuarios). Por
         ejemplo, "El sistema se apagará en 15 minutos". El FTP no
         proporciona los medios para enviar este mensaje inmediatamente
         al usuario. Se recomienda que esa información se encole en el
         server-PI y se envíe en la siguiente respuesta (posiblemente en
         una respuesta multilínea).

         La tabla siguiente lista las respuestas indicando la
         finalización de cada orden correcta o incorrectamente. Se deben
         usar estas respuestas estrictamente; el servidor puede cambiar
         el texto en las respuestas, pero el significado y la acción que
         implica el número de código y la secuencia de comandos no debe
         alterarse.

      Secuencias orden-respuesta

         En esta sección se presenta la secuencia orden-respuesta. Cada
         orden se muestra con sus posibles respuestas; los grupos de
         órdenes se muestran juntos. En primer lugar aparecen las
         respuestas preliminares (con las respuestas de ejecución
         correcta indentadas a continuación), luego las respuestas de
         finalización positiva y negativa y , por último, las respuestas
         intermedias con el resto de las órdenes de la secuencia. Este
         listado es la base de los diagramas, que se verán más tarde.

            Establecimiento de conexión
               120
                  220
               220
                421




Postel & Reynolds               Estándar                       [Pág. 49]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


            Login
               USER
                  230
                  530
                  500, 501, 421
                  331, 332
               PASS
                  230
                  202
                  530
                  500, 501, 503, 421
                  332
               ACCT
                  230
                  202
                  530
                  500, 501, 503, 421
               CWD
                  250
                  500, 501, 502, 421, 530, 550
               CDUP
                  200
                  500, 501, 502, 421, 530, 550
               SMNT
                  202, 250
                  500, 501, 502, 421, 530, 550
            Logout
               REIN
                  120
                  220
                  421
                  500, 502
               QUIT
                  221
                  500

            Parámetros de transferencia
               PORT
                  200
                  500, 501, 421, 530
               PASV
                  227
                  500, 501, 502, 421, 530
               MODE
                  200
                  500, 501, 504, 421, 530
               TYPE
                  200



Postel & Reynolds               Estándar                       [Pág. 50]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


                  500, 501, 504, 421, 530
               STRU
                  200
                  500, 501, 504, 421, 530

            Acciones sobre ficheros
                ALLO
                  200
                  202
                  500, 501, 504, 421, 530
               REST
                  500, 501, 502, 421, 530
                  350
               STOR
                  125, 150
                     (110)
                     226, 250
                     425, 426, 451, 551, 552
                  532, 450, 452, 553
                  500, 501, 421, 530
               STOU
                  125, 150
                     (110)
                     226, 250
                     425, 426, 451, 551, 552
                  532, 450, 452, 553
                  500, 501, 421, 530
               RETR
                  125, 150
                     (110)
                     226, 250
                     425, 426, 451
                  450, 550
                  500, 501, 421, 530
               LIST
                  125, 150
                     226, 250
                     425, 426, 451
                  450
                  500, 501, 502, 421, 530
               NLST
                  125, 150
                     226, 250
                     425, 426, 451
                  450
                  500, 501, 502, 421, 530
               APPE
                  125, 150



Postel & Reynolds               Estándar                       [Pág. 51]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


                     (110)
                     226, 250
                     425, 426, 451, 551, 552
                  532, 450, 550, 452, 553
                  500, 501, 502, 421, 530
               RNFR
                  450, 550
                  500, 501, 502, 421, 530
                  350
               RNTO
                  250
                  532, 553
                  500, 501, 502, 503, 421, 530
               DELE
                  250
                  450, 550
                  500, 501, 502, 421, 530
               RMD
                  250
                  500, 501, 502, 421, 530, 550
               MKD
                  257
                  500, 501, 502, 421, 530, 550
               PWD
                  257
                  500, 501, 502, 421, 550
               ABOR
                  225, 226
                  500, 501, 502, 421

            Ordenes informativas
               SYST
                  215
                  500, 501, 502, 421
               STAT
                  211, 212, 213
                  450
                  500, 501, 502, 421, 530
               HELP
                  211, 214
                  500, 501, 502, 421

            Otras órdenes
               SITE
                  200
                  202
                  500, 501, 530
               NOOP



Postel & Reynolds               Estándar                       [Pág. 52]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


                  200
                  500 421

6.  DIAGRAMAS DE ESTADO

   Aquí presentamos los diagramas de estado para una implementación FTP
   muy simple. Sólo se tiene en cuenta el primer dígito de la respuesta.
   Hay un diagrama de estado por cada grupo de órdenes FTP o secuencia
   de las mismas.

   La agrupación de las órdenes se ha hecho construyendo un modelo para
   cada una de ellas y juntando las que tienen modelos idénticos
   estructuralmente.

   Para cada órden o secuencia hay tres posibles resultados: sin
   problemas (S), fallo (F) y error (E). En los diagramas se ha usado el
   símbolo B para "inicio" y el símbolo W para indicar "espera una
   respuesta".

   En primer lugar tenemos el diagrama que representa el grupo más
   grande de órdenes FTP:

                               1,3    +---+
                          ----------->| E |
                         |            +---+
                         |
      +---+    ord    +---+    2      +---+
      | B |---------->| W |---------->| S |
      +---+           +---+           +---+
                         |
                         |     4,5    +---+
                          ----------->| F |
                                      +---+
      Este diagrama modela las órdenes:
         ABOR, ALLO, DELE, CWD, CDUP, SMNT, HELP, MODE, NOOP, PASV,
         QUIT, SITE, PORT, SYST, STAT, RMD, MKD, PWD, STRU y TYPE.

   El otro grupo grande de órdenes se representa con un diagrama muy
   parecido:












Postel & Reynolds               Estándar                       [Pág. 53]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


                               3      +---+
                          ----------->| E |
                         |            +---+
                         |
      +---+    ord    +---+    2      +---+
      | B |---------->| W |---------->| S |
      +---+       --->+---+           +---+
                 |     | |
                 |     | |     4,5    +---+
                 |  1  |  ----------->| F |
                  -----               +---+

      Este diagrama es para las órdenes:
         APPE, LIST, NLST, REIN, RETR, STOR y STOU.

   Como se puede ver, este segundo modelo puede usarse para representar
   el primer grupo de órdenes; la única diferencia es que en el primer
   grupo las respuestas que empiezan por 1 no se esperan y, por tanto,
   se tratan como un error, mientras que el segundo grupo espera (a
   veces necesita) las respuestas que empiezan por 1.

   Recuerde que, como mucho, se permite una respuesta que empiece por 1
   por cada orden.

   El resto de los diagramas modela secuencias de órdenes; quizá el más
   simple de ellos es la secuencia de renombrar un archivo:

      +---+   RNFR    +---+    1,2    +---+
      | B |---------->| W |---------->| E |
      +---+           +---+        -->+---+
                       | |        |
                3      | | 4,5    |
         --------------  ------   |
        |                      |  |   +---+
        |               ------------->| S |
        |              |   1,3 |  |   +---+
        |             2|  --------
        |              | |     |
        V              | |     |
      +---+   RNTO    +---+ 4,5 ----->+---+
      |   |---------->| W |---------->| F |
      +---+           +---+           +---+

   El siguiente diagrama es un modelo simple de la orden recomenzar:







Postel & Reynolds               Estándar                       [Pág. 54]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


      +---+   REST    +---+    1,2    +---+
      | B |---------->| W |---------->| E |
      +---+           +---+        -->+---+
                       | |        |
                3      | | 4,5    |
         --------------  ------   |
        |                      |  |   +---+
        |               ------------->| S |
        |              |   3   |  |   +---+
        |             2|  --------
        |              | |     |
        V              | |     |
      +---+   ord     +---+ 4,5 ----->+---+
      |   |---------->| W |---------->| F |
      +---+        -->+---+           +---+
                  |      |
                  |  1   |
                   ------

         Donde "ord" es APPE, STOR o RETR.

   Podemos ver que los tres modelos anteriores son similares. Recomenzar
   difiere de renombrar sólo en el tratamiento de las respuestas tipo
   100 en la segunda parte, mientras que el segundo grupo espera (a
   veces necesita) respuestas tipo 100. Sólo se permite una respuesta
   tipo 100 por cada orden.

























Postel & Reynolds               Estándar                       [Pág. 55]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


                            1
      +---+   USER    +---+------------->+---+
      | B |---------->| W | 2       ---->| E |
      +---+           +---+------  |  -->+---+
                       | |       | | |
                     3 | | 4,5   | | |
         --------------   -----  | | |
        |                      | | | |
        |                      | | | |
        |                 ---------  |
        |               1|     | |   |
        V                |     | |   |
      +---+   PASS    +---+ 2  |  ------>+---+
      |   |---------->| W |------------->| S |
      +---+           +---+   ---------->+---+
                       | |   | |     |
                     3 | |4,5| |     |
         --------------   --------   |
        |                    | |  |  |
        |                    | |  |  |
        |                 -----------
        |             1,3|   | |  |
        V                |  2| |  |
      +---+   ACCT    +---+--  |   ----->+---+
      |   |---------->| W | 4,5 -------->| F |
      +---+           +---+------------->+---+

   Por último, mostramos un diagrama generalizado que se puede usar para
   modelar el intercambio orden y respuesta.






















Postel & Reynolds               Estándar                       [Pág. 56]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


               ------------------------------------
              |                                    |
     Inicio   |                                    |
        |     V                                    |
        |   +---+  ord   +---+ 2         +---+     |
         -->|   |------->|   |---------->|   |     |
            |   |        | W |           | S |-----|
         -->|   |     -->|   |-----      |   |     |
        |   +---+    |   +---+ 4,5 |     +---+     |
        |     |      |    | |      |               |
        |     |      |   1| |3     |     +---+     |
        |     |      |    | |      |     |   |     |
        |     |       ----  |       ---->| F |-----
        |     |             |            |   |
        |     |             |            +---+
         -------------------
              |
              |
              V
             Fin

7.  ESCENARIO TIPICO DEL FTP

   El usuario del ordenador U quiere transferir ficheros a/desde el
   ordenador S:

   Generalmente, el usuario se comunicará con el servidor a través del
   proceso user-FTP. El siguiente puede ser un escenario típico. Lo que
   muestra el user-FTP está entre paréntesis, '---->' representa órdenes
   de U a S y
    '<----' representa respuestas de S a U.




















Postel & Reynolds               Estándar                       [Pág. 57]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


   ORDENES DEL USUARIO              ACCIONES QUE IMPLICAN
   ftp (host) multics<CR>         Conectarse a S en el puerto L
                                  estableciendo conexiones de control.
                                  <---- 220 Servicio preparado <CRLF>.
   username Doe <CR>              USER Doe<CRLF>---->
                                  <---- 331 Nombre de usuario OK,
                                            necesita contraseña<CRLF>.
   password mumble <CR>           PASS mumble<CRLF>---->
                                  <---- 230 Usuario aceptado<CRLF>.
   retrieve (local type) ASCII<CR>
   (local pathname) test 1 <CR>   El user-FTP abre el fichero local en
                                  modo ASCII.
   (for. pathname) test.pl1<CR>   RETR test.pl1<CRLF> ---->
                                  <---- 150 Fichero correcto;
                                        se va a abrir la conexión
                                        de datos<CRLF>.
                                  El servidor crea la conexión de datos
                                  al puerto U.
                                  <---- 226 Cerrando conexión de datos,
                                      transferencia completada<CRLF>.
   type Image<CR>                 TYPE I<CRLF> ---->
                                  <---- 200 Orden OK<CRLF>
   store (local type) image<CR>
   (local pathname) file dump<CR> El user-FTP abre el fichero local en
                                  modo binario.
   (for.pathname) >udd>cn>fd<CR>  STOR >udd>cn>fd<CRLF> ---->
                                  <---- 550 Acceso denegado<CRLF>
   terminate                      QUIT <CRLF> ---->
                                  El servidor cierra todas las
                                  conexiones.

8.  ESTABLECIMIENTO DE LA CONEXION

   La conexión de control del FTP se establece mediante FTP entre el
   puerto del proceso de usuario U y el puerto del proceso servidor L. A
   este protocolo se le ha asignado el puerto 21 (25 en octal), por
   tanto L=21.

APENDICE I -  ESTRUCTURA PAGINADA

   La necesidad del FTP para admitir estructura paginada deriva
   principalmente de la necesidad de admitir la transmisión eficiente de
   ficheros entre sistemas TOPS-20, particularmente los fichero usados
   por el NLS.

   El sistema de ficheros del TOPS-20 está basado en el concepto de
   páginas.  El sistema operativo es más eficiente manipulando páginas
   que ficheros. El sistema operativo proporciona una interfaz con el



Postel & Reynolds               Estándar                       [Pág. 58]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


   sistema de ficheros de tal forma que muchas aplicaciones ven los
   ficheros como un flujo de caracteres secuencial. Sin embargo, algunas
   aplicaciones usan las estructuras paginadas directamente y algunas de
   ellas crean ficheros con huecos.

   Un fichero del TOPS-20 consiste en 4 cosas: un nombre de ruta, una
   tabla de páginas, un conjunto de páginas (posiblemente vacío) y un
   conjunto de atributos. El nombre de ruta se especifica con la orden
   RETR o STOR. Incluye el nombre de directorio, el nombre del fichero,
   la extensión y el número de generación.

   La tabla de páginas contiene hasta 2**18 entradas. Cada una de ellas
   puede estar vacía o apuntar a una página. Si no está vacía, hay unos
   bits de acceso a la página; no todas las páginas de un fichero tienen
   por qué tener los mismos permisos de acceso.

   Una página es un conjunto contiguo de 512 palabras de 36 bits cada
   una. Los atributos del fichero, que está en el Bloque de Descripción
   del Fichero (FDB), contienen datos como la hora de creación, de
   escritura, de lectura,...

   Las entradas de la tabla de páginas NO tienen por qué ser contiguas.
   Puede haber páginas vacías entre otras ocupadas. Además, el puntero
   de fin de fichero es simplemente un número. No hace falta que apunte
   al "último" dato del fichero.

   Las llamadas al sistema de entrada/salida del TOPS-20 hacen que el
   puntero de fin de fichero quede después del último dato escrito, pero
   otras operaciones pueden hacer que esto no sea así si un programa lo
   requiere.

   De hecho, en estos dos casos, ficheros con huecos y punteros de fin
   de fichero que NO están al final del fichero, ocurren con los
   ficheros de datos NLS.

   Los ficheros paginados del TOPS-20 se pueden enviar con los
   siguientes parámetros FTP:

   TYPE L 36, STRU P y MODE S (de hecho, se puede usar cualquier modo).

   Cada página de información tiene una cabecera. Cada campo de la
   cabecera, que es una byte lógico, es una palabra del TOPS-20, por
   ello el tipo es L 36.

   Los campos de la cabecera son:
      Palabra 0: Longitud de la cabecera.
         La longitud de la cabecera es 5.




Postel & Reynolds               Estándar                       [Pág. 59]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


      Palabra 1: Indice de página.
         Si los datos son de la página de un fichero, este es el número
         de ellas que hay en el mapa de páginas del fichero. Las páginas
         vacías (huecos) del fichero no se envían. Tener en cuenta que
         un hueco NO es lo mismo que una página de ceros.

      Palabra 2: Longitud de datos.
         El número de palabras de datos de esta página que van a
         continuación de la cabecera. El número total de palabras
         transmitidas es la longitud de la cabecera más la longitud de
         datos.

      Palabra 3: Tipo de página.
         Un código para indicar el tipo de página. Un 3 indica una
         página de datos; un 2 indica que es un FDB.

      Palabra 4: Control de acceso a la página.
         Los bits de control asociados a la página en el mapa de páginas
         del fichero.

   A continuación de la cabecera van los datos. La longitud de los datos
   es o 512 para una página de datos o 31 para un FDB. Los ceros finales
   se pueden descartar, haciendo que la longitud de datos sea inferior a
   512.

APPENDIX II -  ORDENES DE DIRECTORIO

   Como UNIX tiene una estructura de directorio en forma de árbol en el
   que los directorios se pueden manipular fácilemente como ficheros
   normales, es conveniente ampliar los servidores FTP de estos sistemas
   para tratar con la creación de directorios. Como hay más tipos de
   servidores con un sistema similar, estas órdenes son tan generales
   como es posible.

      Se han añadido 4 órdenes de directorio al FTP:
         MKD nombreruta
            Crea un directorio con el nombre "nombreruta".

         RMD nombreruta
            Borra el directorio llamado "nombreruta".

         PWD
            Muestra el nombre del directorio de trabajo actual.

         CDUP
            Cambia el directorio actual a directorio padre.

   El nombre de ruta indicado se crea (borra) como un subdirectorio del



Postel & Reynolds               Estándar                       [Pág. 60]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


   directorio de trabajo actual a menos que "nombreruta" contenga
   suficiente información que indique al servidor que es un nombre de
   ruta absoluto.

   CODIGOS DE RESPUESTA

      La orden CDUP es un caso especial de CWD y se incluye para
      simplificar la implementación de programas para transferir árboles
      de directorios completos entre sistemas que llaman de forma
      diferente al directorio padre.  Lo códigos de respuesta a CDUP son
      los mismos que para CWD.

      Los códigos de respuesta para RMD son los mismos que para su
      análogo con ficheros, DELE.

      Los códigos de respuesta para MKD, sin embargo, son un poco más
      complicados. Un directorio creado recientemente será, lo más
      seguro, el objeto de una próxima orden CWD. Desafortunadamente, el
      argumento de MKD no siempre es apropiado para CWD. Este es el
      caso, por ejemplo, de crear un directorio en un TOPS-20 dando sólo
      el nombre de subdirectorio. Esto es, en un servidor FTP de un
      TOPS-20, la secuencia

         MKD DIRECTORIO
         CWD DIRECTORIO

      fallará. Sólo podemos referirnos al nuevo directorio por su nombre
      absoluto; por ejemplo, si se realiza el comando MKD cuando estamos
      conectados al directorio <DFRANKLIN>, sólo podemos referirnos al
      nuevo subdirectorio como <DFRANKLIN.DIRECTORIO>.

      Incluso en UNIX y Multics puede ocurrir algo similar. Si se trata
      de un nombre de ruta relativo (al directorio actual), el usuario
      necesita estar en el mismo directorio actual para alcanzar el
      subdirectorio. Según qué aplicación, esto puede ser un
      inconveniente. No es muy robusto en ningún caso.

      Para solucionar estos problemas, una vez que finalice
      correctamente una orden MKD, el servidor debería devolver una
      respuesta de la forma:
         257<espacio>"<nombre-directorio>"<espacio><comentario>

      Así el servidor comunica al usuario la cadena que debe usar para
      referirse al nuevo directorio. El nombre de directorio puede
      contener cualquier carácter; si en el nombre hay comillas dobles,
      se debería indicar usando dos veces ls comillas dobles.

      Por ejemplo, un usuario se conecta al directorio /usr/dm y crea un



Postel & Reynolds               Estándar                       [Pág. 61]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


      subdirectorio llamado nombreruta:

         CWD /usr/dm
         200 directorio cambiado a /usr/dm
         MKD nombreruta
         257 "/usr/dm/nombreruta" directorio creado.

      Un ejemplo que contiene comillas dobles:

         MKD foo"bar 257 "/usr/dm/foo""bar" directorio creado.  CWD
         /usr/dm/foo"bar 200 directorio cambiado a /usr/dm/foo"bar

      Si existe un subdirectorio con el mismo nombre, se produce un
      error y el servidor debe enviar una respuesta de error "acceso
      denegado":

         CWD /usr/dm 200 directorio cambioado a /usr/dm MKD nombreruta
         521-"/usr/dm/nombreruta" ya existe el directorio; 521 no se
         realizó ninguna acción.

      Las respuestas indicando error para MKD son análogas a las de su
      primo para crear ficheros, STOR. También se da una respuesta
      "acceso denegado" si el nombre de un fichero coincide con el del
      nuevo directorio (esto es un problema en UNIX, pero no debería
      serlo en un TOPS-20).

      Como el comando PWD devuelve el mismo tipo de información que un
      MKD correcto, la respuesta a un comando PWD correcto usa también
      el código 257.

   SUTILEZAS

      Como estos comandos serán más útiles a la hora de transferir
      subárboles de un ordenador a otro, observe con cuidado que el
      argumento de MKD se interpreta como un subdirectorio del
      directorio actual a menos que contenga información suficiente que
      indique lo contrario. Un ejemplo hipotético de su uso en un
      TOPS-20:

         CWD <algun.lugar>
         200 Directorio de trabajo cambiado
         MKD sobreelarcoiris
         257 "<algun.lugar.sobreelarcoiris>" directorio creado
         CWD sobreelarcoiris
         431 No existe el directorio
         CWD <algun.lugar.sobreelarcoiris>
         200 Directorio de trabajo cambiado
         CWD <algun.lugar>



Postel & Reynolds               Estándar                       [Pág. 62]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


         200 Directorio de trabajo cambiado a <algun.lugar>
         MKD <absoluto>
         257 "<absoluto>" directorio creado
         CWD <absoluto>

      El primer ejemplo da como resultado un subdirectorio del
      directorio actual. En cambio, el segundo ejemplo le indica al
      TOPS-20 que el directorio <absoluto> es un directorio de primer
      nivel. Vea también que en el primer ejemplo el usuario "viola" el
      protocolo intentando acceder al nuevo directorio con un nombre
      diferente al devuelto por el TOPS-20. Podía haber habido problemas
      de ambigüedad si existiera un directorio llamado
      <sobreelarcoiris>, pero esto es una ambigüedad inherente al
      sistema TOPS-20.  Estas consideraciones se aplican también a la
      orden RMD. Lo que hay que tener en cuenta es: excepto cuando
      hacerlo así viole las convenciones de un sistema para diferenciar
      nombres de ruta absolutos y relativos, el sistema debería tratar
      los operandos de MKD y RMD como subdirectorios. La respuesta 257
      del MKD siempre debe contener el nombre de ruta absoluto del
      directorio creado.

APENDICE III - RFCs sobre FTP

   Bhushan, Abhay, "Un protocolo de transferencia de ficheros", RFC 114
   (NIC 5823), MIT-Project MAC, 16 de abril de 1971.

   Harslem, Eric, y John Heafner, "Comentarios sobre el RFC 114 (Un
   protocolo de transferencia de ficheros)", RFC 141 (NIC 6726), RAND,
   29 de abril de 1971.

   Bhushan, Abhay, et al, "El Protocolo de Transferencia de Ficheros",
   RFC 172 (NIC 6794), MIT-Project MAC, 23 de junio de 1971.

   Braden, Bob, "Comentarios sobre las propuestas DTP y FTP", RFC 238
   (NIC 7663), UCLA/CCN, 29 de septiembre de 1971.

   Bhushan, Abhay, et al, "El Protocolo de Transferencia de Ficheros",
   RFC 265 (NIC 7813), MIT-Project MAC, 17 de noviembre de 1971.

   McKenzie, Alex, "Una sugerencia para añadir al protocolo FTP", RFC
   281 (NIC 8163), BBN, 8 de diciembre de 1971.

   Bhushan, Abhay, "El uso de la transacción "Tipo de datos" en FTP",
   RFC 294 (NIC 8304), MIT-Project MAC, 25 de enero de 1972.

   Bhushan, Abhay, "El Protocolo de Transferencia de Ficheros", RFC 354
   (NIC 10596), MIT-Project MAC, 8 de julio de 1972.




Postel & Reynolds               Estándar                       [Pág. 63]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


   Bhushan, Abhay, "Comentarios sobre el protocolo de transferencia de
   ficheros (RFC 354)", RFC 385 (NIC 11357), MIT-Project MAC, 18 de
   agosto de 1972.

   Hicks, Greg, "Documentación para el usuario del FTP", RFC 412 (NIC
   12404), Utah, 27 de noviembre de 1972.

   Bhushan, Abhay, "Estado del FTP y comentarios adicionales", RFC 414
   (NIC 12406), MIT-Project MAC, 20 de noviembre de 1972.

   Braden, Bob, "Comentarios sobre el FTP", RFC 430 (NIC 13299),
   UCLA/CCN, 7 de febrero de 1973.

   Thomas, Bob, and Bob Clements, "Interacción servidor-servidor en el
   FTP", RFC 438 (NIC 13770), BBN, 15 sw enero de 1973.

   Braden, Bob, "Ficheros para imprimir y FTP", RFC 448 (NIC 13299),
   UCLA/CCN, 27 de febrero de 1973.

   McKenzie, Alex, "Protocolo de Transferencia de Ficheros", RFC 454
   (NIC 14333), BBN, 16 de febrero de 1973.

   Bressler, Bob, and Bob Thomas, "Recogido de correo mediante FTP", RFC
   458 (NIC 14378), BBN-NET and BBN-TENEX, 20 de febrero de 1973.

   Neigus, Nancy, "Protocolo de Transferencia de Ficheros", RFC 542 (NIC
   17759), BBN, 12 de julio de 1973.

   Krilanovich, Mark, and George Gregg, "Comentarios sobre el FTP", RFC
   607 (NIC 21255), UCSB, 7 de enero de 1974.

   Pogran, Ken, and Nancy Neigus, "Respuesta al RFC 607 - Comentarios
   sobre el FTP", RFC 614 (NIC 21530), BBN, 28 de enero de 1974.

   Krilanovich, Mark, George Gregg, Wayne Hathaway, and Jim White,
   "Comentarios sobre el FTP", RFC 624 (NIC 22054), UCSB, Ames Research
   Center, SRI-ARC, 28 de febrero de 1974.

   Bhushan, Abhay, "Comentarios sobre el FTP y respuesta al RFC 430",
   RFC 463 (NIC 14573), MIT-DMCG, 21 de febrero de 1973.

   Braden, Bob, "Compresión de datos en FTP", RFC 468 (NIC 14742),
   UCLA/CCN, 8 de marzo de 1973.

   Bhushan, Abhay, "FTP y el sistema de correo de red", RFC 475 (NIC
   14919), MIT-DMCG, 6 de marzo de 1973.

   Bressler, Bob, and Bob Thomas "Interacción servidor-servidor en FTP -



Postel & Reynolds               Estándar                       [Pág. 64]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


   II", RFC 478 (NIC 14947), BBN-NET and BBN-TENEX, 26 de marzo de 1973.

   White, Jim, "Use of FTP by the NIC Journal", RFC 479 (NIC 14948),
   SRI-ARC, 8 marzo de 1973.

   White, Jim, "Host-Dependent FTP Parameters", RFC 480 (NIC 14949),
   SRI-ARC, 8 de marzo de 1973.

   Padlipsky, Mike, "An FTP Command-Naming Problem", RFC 506 (NIC
   16157), MIT-Multics, 26 de junio de 1973.

   Day, John, "Memo to FTP Group (Proposal for File Access Protocol)",
   RFC 520 (NIC 16819), Illinois, 25 de junio de 1973.

   Merryman, Robert, "The UCSD-CC Server-FTP Facility", RFC 532 (NIC
   17451), UCSD-CC, 22 de junio de 1973.

   Braden, Bob, "TENEX FTP Problem", RFC 571 (NIC 18974), UCLA/CCN, 15
   de noviembre de 1973.

   McKenzie, Alex, and Jon Postel, "Telnet and FTP Implementation -
   Schedule Change", RFC 593 (NIC 20615), BBN and MITRE, 29 de noviembre
   de 1973.

   Sussman, Julie, "FTP Error Code Usage for More Reliable Mail
   Service", RFC 630 (NIC 30237), BBN, 10 de abril de 1974.

   Postel, Jon, "Códigos de respuesta FTP revisados", RFC 640 (NIC
   30843), UCLA/NMC, 5 junio de 1974.

   Harvey, Brian, "Leaving Well Enough Alone", RFC 686 (NIC 32481), SU-
   AI, 10 mayo de 1975.

   Harvey, Brian, "Un intento más con el FTP", RFC 691 (NIC 32700), SU-
   AI, 28 de mayo 1975.

   Lieb, J., "La orden CWD en el FTP", RFC 697 (NIC 32963), 14 de julio
   de 1975.

   Harrenstien, Ken, "FTP Extension: XSEN", RFC 737 (NIC 42217), SRI-KL,
   31 de octubre de 1977.

   Harrenstien, Ken, "FTP Extension: XRSQ/XRCP", RFC 743 (NIC 42758),
   SRI-KL, 30 de diciembre de 1977.

   Lebling, P. David, "Survey of FTP Mail and MLFL", RFC 751, MIT, 10 de
   diciembre de 1978.




Postel & Reynolds               Estándar                       [Pág. 65]

RFC 959          Protocolo de transferencia de ficheros     Octubre 1985


   Postel, Jon, "Especificación del protocolo de transferencia de
   ficheros", RFC 765, ISI, junio de 1980.

   Mankins, David, Dan Franklin, and Buzz Owen, "Ordenes FTP orientadas
   a directorio", RFC 776, BBN, diciembre de 1980.

   Padlipsky, Michael, "Orden de guardar con nombre único en FTP", RFC
   949, MITRE, julio de 1985.


REFERENCIAS

   [1]  Feinler, Elizabeth, "Libro de trabajo sobre la transición de
   protocolo en Internet",Network Information Center, SRI International,
   marzo de 1982.

   [2]  Postel, Jon, "Protocolo de control de la transmisión -
   Especificación del protocolo del programa DARPA Internet", RFC 793,
   DARPA, septiembre de 1981.

   [3]  Postel, Jon, and Joyce Reynolds, "Especificación del Protocolo
   Telnet", RFC 854, ISI, mayo de 1983.

   [4]  Reynolds, Joyce, and Jon Postel, "Números asignados", RFC 943,
   ISI, abril de 1985.


























Postel & Reynolds               Estándar                       [Pág. 66]


# data[].attributes.attachment_link.readable_text
The SSH File Transfer Protocol (SFTP) is used to transfer files over a cryptographically protected Secure Shell (SSH) connection.

RFC 4250 The Secure Shell (SSH) Protocol Assigned Numbers

RFC 4251 The Secure Shell (SSH) Protocol Architecture

RFC 4252 The Secure Shell (SSH) Authentication Protocol

RFC 4253 The Secure Shell (SSH) Transport Layer Protocol

RFC 4254 The Secure Shell (SSH) Connection Protocol

RFC 4255 Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints

RFC 4256 Generic Message Exchange Authentication for the Secure Shell Protocol (SSH)

RFC 4335 The Secure Shell (SSH) Session Channel Break Extension

RFC 4344 The Secure Shell (SSH) Transport Layer Encryption Modes

RFC 4419 Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol

RFC 4462 Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol

RFC 4716 The Secure Shell (SSH) Public Key File Format

RFC 4819 Secure Shell Public Key Subsystem

RFC 5647 AES Galois Counter Mode for the Secure Shell Transport Layer Protocol

RFC 8709 Ed25519 and Ed448 Public Key Algorithms for the Secure Shell (SSH) Protocol

RFC 8731 Secure Shell (SSH) Key Exchange Method Using Curve25519 and Curve448

# data[].attributes.attachment_link.description
The SSH File Transfer Protocol (SFTP) is used to transfer files over a cryptographically protected Secure Shell (SSH) connection.

# data[].attributes.attachment_link.readable_text
Network Working Group                                          T. Ylonen
Internet-Draft                                               S. Lehtinen
Expires: April 1, 2002                  SSH Communications Security Corp
                                                            October 2001


                       SSH File Transfer Protocol
                    draft-ietf-secsh-filexfer-02.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions ofSection 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed athttp://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed athttp://www.ietf.org/shadow.html. This Internet-Draft will expire on April 1, 2002. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract The SSH File Transfer Protocol provides secure file transfer functionality over any reliable data stream. It is the standard file transfer protocol for use with the SSH2 protocol. This document describes the file transfer protocol and its interface to the SSH2 protocol suite. Ylonen & Lehtinen Expires April 1, 2002 [Page 1]

Internet-Draft         SSH File Transfer Protocol           October 2001


Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 32. Use with the SSH Connection Protocol . . . . . . . . . . . . 43. General Packet Format . . . . . . . . . . . . . . . . . . . 54. Protocol Initialization . . . . . . . . . . . . . . . . . . 75. File Attributes . . . . . . . . . . . . . . . . . . . . . . 86. Requests From the Client to the Server . . . . . . . . . . . 106.1 Request Synchronization and Reordering . . . . . . . . . . . 106.2 File Names . . . . . . . . . . . . . . . . . . . . . . . . . 116.3 Opening, Creating, and Closing Files . . . . . . . . . . . . 116.4 Reading and Writing . . . . . . . . . . . . . . . . . . . . 136.5 Removing and Renaming Files . . . . . . . . . . . . . . . . 146.6 Creating and Deleting Directories . . . . . . . . . . . . . 156.7 Scanning Directories . . . . . . . . . . . . . . . . . . . . 156.8 Retrieving File Attributes . . . . . . . . . . . . . . . . . 166.9 Setting File Attributes . . . . . . . . . . . . . . . . . . 176.10 Dealing with Symbolic links . . . . . . . . . . . . . . . . 186.11 Canonicalizing the Server-Side Path Name . . . . . . . . . . 187. Responses from the Server to the Client . . . . . . . . . . 208. Vendor-Specific Extensions . . . . . . . . . . . . . . . . . 249. Security Considerations . . . . . . . . . . . . . . . . . . 2510. Changes from previous protocol versions . . . . . . . . . . 2610.1 Changes between versions 3 and 2 . . . . . . . . . . . . . . 2610.2 Changes between versions 2 and 1 . . . . . . . . . . . . . . 2610.3 Changes between versions 1 and 0 . . . . . . . . . . . . . . 2611. Trademark Issues . . . . . . . . . . . . . . . . . . . . . . 27 References . . . . . . . . . . . . . . . . . . . . . . . . .28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . .28 Full Copyright Statement . . . . . . . . . . . . . . . . . .29 Ylonen & Lehtinen Expires April 1, 2002 [Page 2]

Internet-Draft         SSH File Transfer Protocol           October 2001


1. Introduction This protocol provides secure file transfer (and more generally file system access) functionality over a reliable data stream, such as a channel in the SSH2 protocol [3]. This protocol is designed so that it could be used to implement a secure remote file system service, as well as a secure file transfer service. This protocol assumes that it runs over a secure channel, and that the server has already authenticated the user at the client end, and that the identity of the client user is externally available to the server implementation. In general, this protocol follows a simple request-response model. Each request and response contains a sequence number and multiple requests may be pending simultaneously. There are a relatively large number of different request messages, but a small number of possible response messages. Each request has one or more response messages that may be returned in result (e.g., a read either returns data or reports error status). The packet format descriptions in this specification follow the notation presented in the secsh architecture draft.[3]. Even though this protocol is described in the context of the SSH2 protocol, this protocol is general and independent of the rest of the SSH2 protocol suite. It could be used in a number of different applications, such as secure file transfer over TLSRFC 2246 [1] and transfer of management information in VPN applications. Ylonen & Lehtinen Expires April 1, 2002 [Page 3]

Internet-Draft         SSH File Transfer Protocol           October 2001


2. Use with the SSH Connection Protocol When used with the SSH2 Protocol suite, this protocol is intended to be used from the SSH Connection Protocol [5] as a subsystem, as described in section ``Starting a Shell or a Command''. The subsystem name used with this protocol is "sftp". Ylonen & Lehtinen Expires April 1, 2002 [Page 4]

Internet-Draft         SSH File Transfer Protocol           October 2001


5. File Attributes A new compound data type is defined for encoding file attributes. It is basically just a combination of elementary types, but is defined once because of the non-trivial description of the fields and to ensure maintainability. The same encoding is used both when returning file attributes from the server and when sending file attributes to the server. When sending it to the server, the flags field specifies which attributes are included, and the server will use default values for the remaining attributes (or will not modify the values of remaining attributes). When receiving attributes from the server, the flags specify which attributes are included in the returned data. The server normally returns all attributes it knows about. uint32 flags uint64 size present only if flag SSH_FILEXFER_ATTR_SIZE uint32 uid present only if flag SSH_FILEXFER_ATTR_UIDGID uint32 gid present only if flag SSH_FILEXFER_ATTR_UIDGID uint32 permissions present only if flag SSH_FILEXFER_ATTR_PERMISSIONS uint32 atime present only if flag SSH_FILEXFER_ACMODTIME uint32 mtime present only if flag SSH_FILEXFER_ACMODTIME uint32 extended_count present only if flag SSH_FILEXFER_ATTR_EXTENDED string extended_type string extended_data ... more extended data (extended_type - extended_data pairs), so that number of pairs equals extended_count The `flags' specify which of the fields are present. Those fields for which the corresponding flag is not set are not present (not included in the packet). New flags can only be added by incrementing the protocol version number (or by using the extension mechanism described below). The `size' field specifies the size of the file in bytes. The `uid' and `gid' fields contain numeric Unix-like user and group identifiers, respectively. The `permissions' field contains a bit mask of file permissions as defined by posix [1]. The `atime' and `mtime' contain the access and modification times of the files, respectively. They are represented as seconds from Jan 1, 1970 in UTC. The SSH_FILEXFER_ATTR_EXTENDED flag provides a general extension Ylonen & Lehtinen Expires April 1, 2002 [Page 8]

Internet-Draft         SSH File Transfer Protocol           October 2001


7. Responses from the Server to the Client The server responds to the client using one of a few response packets. All requests can return a SSH_FXP_STATUS response upon failure. When the operation is successful, any of the responses may be returned (depending on the operation). If no data needs to be returned to the client, the SSH_FXP_STATUS response with SSH_FX_OK status is appropriate. Otherwise, the SSH_FXP_HANDLE message is used to return a file handle (for SSH_FXP_OPEN and SSH_FXP_OPENDIR requests), SSH_FXP_DATA is used to return data from SSH_FXP_READ, SSH_FXP_NAME is used to return one or more file names from a SSH_FXP_READDIR or SSH_FXP_REALPATH request, and SSH_FXP_ATTRS is used to return file attributes from SSH_FXP_STAT, SSH_FXP_LSTAT, and SSH_FXP_FSTAT requests. Exactly one response will be returned for each request. Each response packet contains a request identifier which can be used to match each response with the corresponding request. Note that it is legal to have several requests outstanding simultaneously, and the server is allowed to send responses to them in a different order from the order in which the requests were sent (the result of their execution, however, is guaranteed to be as if they had been processed one at a time in the order in which the requests were sent). Response packets are of the same general format as request packets. Each response packet begins with the request identifier. The format of the data portion of the SSH_FXP_STATUS response is as follows: uint32 id uint32 error/status code string error message (ISO-10646 UTF-8 [RFC-2279]) string language tag (as defined in [RFC-1766]) where `id' is the request identifier, and `error/status code' indicates the result of the requested operation. The value SSH_FX_OK indicates success, and all other values indicate failure. Ylonen & Lehtinen Expires April 1, 2002 [Page 20]

Internet-Draft         SSH File Transfer Protocol           October 2001


9. Security Considerations This protocol assumes that it is run over a secure channel and that the endpoints of the channel have been authenticated. Thus, this protocol assumes that it is externally protected from network-level attacks. This protocol provides file system access to arbitrary files on the server (only constrained by the server implementation). It is the responsibility of the server implementation to enforce any access controls that may be required to limit the access allowed for any particular user (the user being authenticated externally to this protocol, typically using the SSH User Authentication Protocol [6]. Care must be taken in the server implementation to check the validity of received file handle strings. The server should not rely on them directly; it MUST check the validity of each handle before relying on it. Ylonen & Lehtinen Expires April 1, 2002 [Page 25]

Internet-Draft         SSH File Transfer Protocol           October 2001


10. Changes from previous protocol versions The SSH File Transfer Protocol has changed over time, before it's standardization. The following is a description of the incompatible changes between different versions.10.1 Changes between versions 3 and 2 o The SSH_FXP_READLINK and SSH_FXP_SYMLINK messages were added. o The SSH_FXP_EXTENDED and SSH_FXP_EXTENDED_REPLY messages were added. o The SSH_FXP_STATUS message was changed to include fields `error message' and `language tag'.10.2 Changes between versions 2 and 1 o The SSH_FXP_RENAME message was added.10.3 Changes between versions 1 and 0 o Implementation changes, no actual protocol changes. Ylonen & Lehtinen Expires April 1, 2002 [Page 26]

Internet-Draft         SSH File Transfer Protocol           October 2001


References

   [1] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and P. Kocher, "The TLS Protocol Version 1.0",RFC 2246, January 1999. [2] Institute of Electrical and Electronics Engineers, "Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) [C Language]", IEEE Standard 1003.2, 1996. [3] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. Lehtinen, "SSH Protocol Architecture",draft-ietf-secsh-architecture-09 (work in progress), July 2001. [4] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. Lehtinen, "SSH Protocol Transport Protocol",draft-ietf-secsh-architecture-09 (work in progress), July 2001. [5] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. Lehtinen, "SSH Connection Protocol",draft-ietf-secsh-connect-11 (work in progress), July 2001. [6] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. Lehtinen, "SSH Authentication Protocol",draft-ietf-secsh-userauth-11 (work in progress), July 2001. Authors' Addresses Tatu Ylonen SSH Communications Security Corp Fredrikinkatu 42 HELSINKI FIN-00100 Finland EMail: ylo@ssh.com Sami Lehtinen SSH Communications Security Corp Fredrikinkatu 42 HELSINKI FIN-00100 Finland EMail: sjl@ssh.com Ylonen & Lehtinen Expires April 1, 2002 [Page 28]

Internet-Draft         SSH File Transfer Protocol           October 2001


Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Ylonen & Lehtinen         Expires April 1, 2002                [Page 29]

# data[].attributes.attachment_link.description
SSH File Transfer Protocol (Internet-Draft, 2001)