rfc0959 Es

Network Working Group J.
Postel
Request for Comments: 959 J. Reynolds
ISI
Obsoletes RFC: 765 (IEN 149) Octubre 1985
Traduccin al castellano: Febrero 2000
Gonzalo Paniagua Javier <gpanjav@jazzfree.com>
PROTOCOLO DE TRANSFERENCIA DE FICHEROS (FTP)
Estado de este Documento
Este documento es la especificacin 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 edicin

de la especificacin:
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 especificacin 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
implcito (a travs 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 diseado principalmete para ser usado
por programas.
Con esta especificacin se intentan satisfacer las diversas

necesidades de los usuarios de maxi-hosts, mini-hosts, estaciones de
trabajo personales y TAC's con un diseo de protocolo simple y fcil
de programar.
En este documento se asumen conocimientos del Protocolo de Contol de

Transmisin (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 seccin se tratan la historia, la terminologa y el modelo
Postel & Reynolds Estndar [Pg. 1]

RFC 959 Protocolo de transferencia de ficheros Octubre 1985
FTP. Los trminos que se definen en esta seccin son slo aquellos
que tienen un significado especial en el FTP. Parte de la
terminologa es muy especfica al modelo FTP; algunos lectores pueden
encontrar conveniente consultar la seccin sobre el modelo FTP
mientras revisan la terminologa.
2.1. HISTORIA
El FTP ha pasado por un larga evolucin a travs de los aos. El

apndice III es una recopilacin cronolgica 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), ms 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 revisin de este plasmada en el RFC 265, inici
una revisin adicional, mientras que el RFC 281 sugiri ms
cambios. El uso de una transaccin 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, sealando como funcin principal del
FTP la transferencia de ficheros fiable y eficiente entre
ordenadores y permitiendo el uso adecuado de las caractersticas
de almacenamiento remotas. El RFC 385 sigui comentando errores,
enfatiz algunos puntos y aadi caractersticas 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 ms 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 espcificacin
"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 ms cambios en el diseo y pequeas
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 pequea

revisin del RFC 686, referente al tema de ficheros para imprimir.
Motivado por la transicin del NCP al TCP como protocolo

subyacente, naci un fnix de todos los anteriores esfuerzos en el
RFC 765 como la especificacin de FTP para uso sobre TCP.
Esta edicin de la especificacin FTP est dirigida a la

correccin de pequeos errores en la documentacin, a mejorar la
explicacin de algunas caractersticas del protocolo, y a aadir
algunas nuevas rdenes opcionales.
En particular, se incluyen las siguientes nuevas rdenes

opcionales en esta edicin de la especificacin:
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 especificacin es compatible con la anterior edicin. Un

programa implementado conforme a la especificacin anterior
debera estar automticamente en conformidad con esta
especificacin.
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
cdigo de 8 bits (i.e., el bit ms 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

servidor FTP utilizar los controles de acceso.
tamao de byte
Hay dos tamaos de byte interesantes en el FTP: el tamao

lgico de byte del fichero y el tamao de byte usado para la
transmisin de los datos. El tamao de byte utilizado para la
transmisin es siempre de 8 bits. Este tamao no es
necesariamente el tamao de byte con el que se guardan los
datos en un sistema ni el tamao lgico de byte para la
interpretacin de la estructura de los datos.
conexin de control
La ruta de comunicacin entre el USER-PI y el SERVER-PI para el

intercambio de rdenes y respuestas. Esta conexin sigue el
Protocolo Telnet.
conexin de datos
Una conexin 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 conexin 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 conexin del proceso de
transferencia activa para abrir la conexin de datos.
DTP
El proceso de transferencia de datos (DTP, Data Transfer

Process) establece y maneja la conexin de datos. Puede ser
activo o pasivo.
Fin-de-linea (EOL, end-of-line)
La secuencia fin-de-linea define la separacin entre lneas. La

secuencia consiste en un retorno de carro seguido de un
carcter de nueva lnea.
EOF (fin-de-fichero, end-of-file)
La condicin fin-de-fichero que define el final de un fichero

en proceso de transmisin.

EOR (end-of-record, fin-de-registro)
La condicin fin-de-registro que define el final de un registro

en proceso de transferencia.
recuperacin 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
recuperacin 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 informacin 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 conexin 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 seccin Modos de
Transmisin.
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
estndar con rdenes estndar y convenciones sobre los nombres
de ruta [pathname].
pgina
Un fichero se puede estructurar como un conjunto de partes

independientes llamadas pginas. El FTP soporta la transmisin

de ficheros discontinuos como pginas 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
an un estndar 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 Intrprete 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 nmero 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 travs de la conexin de control
en respuesta a una orden FTP. La forma general de una respuesta
es un cdigo de terminacin seguido de una cadena de texto. Los
cdigos 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 conexin de
datos con el puerto de datos que est a la espera. Prepara los
parmetros para transferir y almacenar y transfiere los datos
cuando as se requiere a travs de su PI. El DTP se puede poner
en estado "pasivo" para esperar una conexin, en lugar de
iniciarla.
proceso server-FTP
Un proceso o un conjunto de ellos que realizan la funcin de

transferencia de ficheros en conjuncin con el proceso user-FTP

y, posiblemente, otro servidor. Las funciones consisten en un

intrprete de protocolo (PI) y un proceso de transferencia de
datos (DTP).
server-PI (server Protocol Interpreter)
El intrprete de protocolo del servidor "escucha" en el puerto

L hasta que recibe una conexin de un user-PI y establece una
conexin de comunicaciones para control. Recibe rdenes FTP
estndar desde el user-PI, enva respuestas y controla el
server-DTP.
tipo
El tipo de representacin 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
representacin definidos en el FTP se describen en la seccin
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 diseo del
protocolo est orientado a su utilizacin por autmatas.
user-DTP (user Data Transfer Process)
El Proceso de Transferencia de Datos espera a recibir una

conexin en el puerto de datos desde el proceso server-FTP. Si
dos servidores estn transfiriendo datos entre ellos, el user-
DTP permanece inactivo.
proceso user-FTP
Un conjunto de funciones incluyendo un intrprete de protocolo,

un proceso de transferencia de datos y una interfaz de usuario
que juntos realizan la funcin de transferir ficheros en en
cooperacin con un proceso server-FTP. La interfaz de usuario
permite usar un lenguaje local en el dilogo orden-respuesta
con el usuario.
user-PI (user Protocol Interpreter)
El intrprete de protocolo de usuario inicia la conexin de

control desde su puerto U hasta el proceso server-FTP, enva

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---\| Conexin |/----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 conexin de datos es bidireccional.

2. La conexin de datos no tiene por qu existir todo el
tiempo.
En el modelo descrito en la Figura 1, el intrprete de

protocolo de usuario (user-PI), inicia la conexin de control.
La conexin de control sigue el Protocolo Telnet. Las rdenes
FTP estndar las genera el user-PI y se transmiten al proceso
servidor a travs de la conexin de control. (El usuario puede
establecer una conexin de control directa con el server-FTP,
desde un terminal TAC por ejemplo, y enviar rdenes FTP
estndar, obviando as el proceso user-FTP.) Las respuestas
estndar se envan desde el server-PI al user-PI por la
conexin de control como contestacin a las rdenes.
Las rdenes FTP especifican parmetros para la conexin de

datos (puerto de datos, modo de transferencia, tipo de
representacin y estructura) y la naturaleza de la operacin

sobre el sistema de ficheros (almacenar, recuperar, aadir,

borrar, etc.). El user-DTP u otro proceso en su lugar, debe
esperar a que el servidor inicie la conexin al puerto de datos
especificado y transferir los datos en funcin de los
parmetros que se hayan especificado. Se debe resear que el
puerto de datos no tiene por qu estar en el mismo ordenador
que enva las rdenes FTP a travs de la conexin de control,
pero el usuario o el proceso user-FTP debe asegurarse de que se
espera la conexin en el puerto de datos indicado. Tambin hay
que destacar que la conexin de datos se puede usar
simultneamente para enviar y para recibir.
En otra situacin, 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 conexin de datos entre
ellos. De esta forma, la informacin de control se enva al
user-PI pero los datos se transfieren entre los procesos de
transferencia de datos de los servidores. A continuacin se
muestra un modelo de esta interaccin 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 relacin entre FTP y Telnet:
El FTP usa el protocolo Telnet en la conexin 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

el mdulo Telnet que exista en el sistema.
La facilidad de implementacin, compartir cdigo y la

programacin modular, estn a favor de la segunda aproximacin.
La eficiencia y la independencia abogan por la primera
aproximacin. En la prctica, el FTP no depende mucho del
protocolo Telnet, por ello la primera aproximacin no
necesariamente implica gran cantidad de cdigo.
3. FUNCIONES DE TRANSFERENCIA DE DATOS
Los ficheros slo se transmiten por la conexin de datos. La conexin

de control se usa para enviar rdenes, que describen la funcin a
realizar, y las repuestas a estas rdenes (ver la seccin "Respuestas
FTP"). Varias rdenes se refieren a la transferencia de datos entre
ordenadores. Estas rdenes incluyen MODE (modo) que especifica cmo
se transmiten los bits de datos y las rdenes STRU (STRUcture,
estructura) y TYPE, que se usan para definir la forma de
representacin de los datos. La transmisin y la representacin son
bsicamente independientes, pero el modo de transmisin flujo depende
de la estructura del fichero y si se especifica el modo de
transmisin "comprimido", la naturaleza del byte de relleno depende
del tipo de representacin.
3.1. REPRESENTACION DE DATOS Y ALMACENAMIENTO
Los datos se tranfieren desde un dispositivo de almacenamiento en

el ordenador que enva los datos a otro en el ordenador que los
recibe. A menudo es necesario realizar ciertas transformaciones en
los datos porque la representacin de los datos almacenados vara
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
representacin estndar NVT-ASCII cuando se transmite texto entre
sistemas diferentes. Los ordenadores que intervienen en la
transferencia deberan realizar las transformaciones necesarias
entre la representacin estndar y su representacin interna.
Nos encontramos con un problema diferente cuando se transmiten

datos en forma binaria (no caracteres) entre ordenadores con
distinto tamao de palabra. No siempre est claro cmo 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 tamao de palabra de 32 bits a un sistema con tamao de
palabra de 36 bits, sera conveniente (por razones de eficiencia y

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 debera tener la opcin de especificar la
representacin de los datos y las transformaciones realizadas en
ellos. Hay que sealar que el FTP proporciona muy limitados tipos
de representacin. Las transformaciones necesarias ms 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

manejarn en el FTP. Este tipo puede definir implcita (como es
el caso de ASCII y EBCDIC) o explcitamente (como en un tamao
de byte local) un tamao de byte para la interpretacin
denominado "tamao de byte lgico". Hay que tener en cuenta que
esto no tiene nada que ver con el tamao de byte usado para la
transmisin a travs de la conexin de datos, llamado "tamao
de byte de transferencia", y no debera haber confusin entre
ambos. Por ejemplo, NVT-ASCII tiene un tamao de byte lgico de
8 bits. Si el tipo es tamao de byte local entonces la orden
TYPE tiene un segundo parmetro obligatorio especificando el
tamao de byte lgico. El tamao 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 propsito es
transferir ficheros de texto, excepto cuando ambos
ordenadores encuentran el tipo EBCDIC ms conveniente.
El ordenador que enva los datos, los convierte de una

representacin de caracteres interna a la representacin
estndar NVT-ASCII de 8 bits (ver la especificacin de
Telnet). El receptor convertir los datos del tipo estndar
a su propia forma interna.
De acuerdo con el estndar NVT, la secuencia <CRLF> se debe

usar donde sea necesario para indicar el final de una lnea
de texto. (Ver el tratamiento de la estructura del fichero
al final de la seccin sobre Almacenamiento y Representacin
de los Datos.)
Usar la representacin estndar NVT-ASCII implica que los

datos se deben interpretar como bytes de 8 bits.
El parmetro de formato para los tipos ASCII y EBCDIC se

expone ms adelante.
3.1.1.2. TIPO EBCDIC
El propsito de este tipo es la transferencia eficaz entre

ordenadores que usan EBCDIC como su representacin de
carcter interna.
Para la transmisin, los datos estn en forma de caracteres

EBCDIC de 8 bits. El cdigo de carcter es la nica
diferencia entre la especificacin funcional de los tipos
EBCDIC y ASCII.
Fin-de-linea (en contraposicin 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 carcter <NL>.
3.1.1.3. TIPO IMAGEN
Los datos se envan como bits contiguos que, para la

transferencia, estn 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 lmite pertinente (byte, palabra o bloque). Este
rellenado, que debe ser todo ceros, slo 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 transformacin de
relleno debe ser conocida por el usuario para procesar el
fichero en el lugar de recepcin.
El tipo imagen est indicado para el almacenamiento y

obtencin 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 lgicos del tamao

especificado por el segundo parmetro obligatorio, tamao de
byte. El valor del tamao de byte debe ser un entero
decimal; no hay valor por defecto. El tamao de byte lgico
no es necesariamente el mismo que el tamao de byte de
transferencia. Si hay diferencia entre los tamaos de byte,
entonces los bytes lgicos se deben empaquetar

contiguamente, a pesar de los lmites del byte de

transferencia y con el relleno necesario al final.
Cuando los datos llegan al receptor, se transformarn de una

manera independiente del tamao de byte lgico y del
ordenador en cuestin. Esta transformacin debe ser
inversible (i.e., se obtendr el mismo fichero si se usan
los mismos parmetros) y los desarrolladores de la
implementacin deben hacerla pblica.
Por ejemplo, un usuario enviando nmeros en coma flotante de

36 bits a un ordenador con tamao de palabra de 32 bits
puede enviar esos datos como byte local con un tamao lgico
de 36. El receptor debera almacenar los bytes lgicos de
forma que sea fcil su manipulacin; en este ejemplo, poner
los bytes lgicos de 36 bits en palabras dobles de 64 bits
sera suficiente.
En otro ejemplo, un par de ordenadores con tamao de palabra

de 36 bits, pueden enviarse datos en palabras usando "TYPE L
36". Los datos se enviaran en los bytes de transmisin de
8 bits y empaquetados para que 9 bytes de transmisin lleven
dos palabras de 36 bits.
3.1.1.5. CONTROL DE FORMATO
Los tipos ASCII y EBCDIC llevan un segundo parmetro

(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 representacin de datos se
definen en el FTP:
Un fichero de texto se enva a un ordenador por uno de estos

tres propsitos: para su impresin, para almacenarlo y
posteriormente recuperarlo, o para procesarlo. Si se enva
un fichero para imprimirlo, el receptor debe saber cmo est
representado el control de formato vertical. En el segundo
caso, debe ser posible almacenar el fichero y despus
recuperarlo exactamente igual. Por ltimo, debera 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
parmetro 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

parmetro (formato). Se debe admitir en todas las

implementaciones del FTP.
El fichero no necesita ninguna informacin de formato

vertical. Si se pasa a un proceso para imprimir, este
proceso puede asumir valores estndar para espaciado y
mrgenes.
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, tambin indica
fin-de-lnea.
3.1.1.5.3. CONTROL DE CARRO (ASA)
El fichero contiene caracteres de control de formato

vertical ASA (FORTRAN). (Vea el apndice C RFC 740; y
Comunicaciones de la ACM, Vol. 7, No. 10, p. 606, octubre
1964). En una lnea o registro formateado de acuerdo con
en estndar ASA, el primer carcter no se imprime. En su
lugar, se usa para determinar el movimiento vertical del
papel que debera tener lugar antes de que se imprima el
resto del registro.
El estndar ASA especifica los siguientes caracteres de

control:
Carcter Espaciado vertical
espacio Mueve el papel una lnea arriba
0 Mueve el papel dos lneas arriba
1 Mueve hasta el comienzo de la sig. pgina
+ 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 ms
abajo) no hay problema; los registros se marcan
explcitamente durante la transferencia y el

almacenamiento. Si el fichero no tiene estructura de

registro, la secuencia fin-de-linea <CRLF> se usa para
separar lneas al imprimir, pero los controles ASA tienen
prioridad sobre estos especificadores de formato.
3.1.2. ESTRUCTURAS DE DATOS
Adems de los diferentes tipos de representacin, 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 pgina, donde el fichero est compuesto de

pginas 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 interpretacin y almacenamiento del
fichero (vea la seccin Modos de Transmisin).
La estructura "natural" de un fichero depende del ordenador que

almacena el fichero. Un fichero con cdigo fuente se guardar
en un Mainframe de IBM, normalmente, en registros de tamao
fijo pero en un TOPS-20 de DEC se guardar como un flujo de
caracteres particionados en lneas, 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 enva
un fichero con una estructura a un ordenador orientado a la
otra. Si un fichero de texto se enva con estructura de
registros a un ordenador que est orientado a ficheros,
entonces ste ltimo debera aplicar internamente una
transformacin basada en la estructura de registros.
Obviamente, esta transformacin debera ser adecuada, pero,
adems, debe ser inversible para que se pueda obtener un
fichero identico usando estructura de registro.

En el caso de enviar un fichero con estructura de fichero a un

ordenador orientado a registro, surge la cuestin de qu
criterio debe usar el ordenador para dividir el fichero en
registros que se puedan procesar localmente. Si es necesaria
esta divisin, la implementacin del FTP debera usar la
secuencia <CRLF> para ficheros de texto ASCII o <NL> para
ficheros de texto EBCDIC como separador de registro. Si una
implementacin del FTP adopta esta tcnica, debe estar
preparada para hacer la transformacin 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 discontnuos, el FTP define una

estructura de pgina. Los fichero de este tipo tambin se
conocen como ficheros de acceso aleatorio o como ficheros
con huecos. En estos ficheros hay a veces otra informacin
asociada con el fichero como un todo (por ejemplo, un
descriptor de fichero), o con una seccin del fichero (por
ejemplo, controles de acceso a pgina) o ambos. En el FTP
las secciones del fichero se llaman pginas.
Para tratar con varios tamaos de pgina y con la

informacin asociada, cada pgina se enva con una cabecera
de pgina. Esta cabecera tiene definidos los siguientes
campos:
Longitud de la cabecera
El nmero de bytes lgicos en la cabecera incluyendo

este. El tamao mnimo de la cabecera es de 4.
Indice de pgina
El nmero lgico de pgina de esta seccin del

fichero. Esto no es el nmero de secuencia de
transmisin de esta pgina, sino el ndice usado para
identifiar esta pgina del fichero.
Tamao de datos
El nmero de bytes lgicos que hay en los datos de la

pgina. El mnimo es 0.
Tipo de pgina
Existen los siguientes tipos de pgina:
0 = Ultima pgina
Se usa para indicar el final de una transmisin

con estructura de pgina. El tamao de cabecera
debe ser 4 y el tamao de datos debe ser 0.
1 = Pgina normal
Este es el tipo usado para ficheros paginados

simples sin informacin de control de acceso
asociada a nivel de pgina. El tamao de la
cabecera debe ser 4.
2 = Pgina de descriptor
Este tipo se utiliza para transmitir la

informacin descriptiva del fichero considerado
como un todo.
3 = Pgina con control de acceso
Este tipo incluye un campo adicional en la

cabecera para ficheros paginados con informacin
de control de acceso a nivel de pgina. El
tamao de la cabecera debe ser 5.
Campos opcionales
Se pueden usar ms campos en la cabecera para

proporcionar, por ejemplo, informacin de control por

pgina.
Todos los campos miden un byte lgico. El tamao de

byte lgico se especifica por la orden TYPE. Vea el
apndice I para ms detalles y un caso especfico de
estructura de pgina.
Una nota de atencin sobre los parmetros: un fichero debe ser

almacenado y recuperado con los mismos parmetros si la versin
recuperada debe ser idntica a la versin originalmente
transmitida. Por tanto, las implementaciones del FTP deben
devolver un fichero idntico al original si los parmetros usados
para almacenar y recuperar el fichero son los mismos.
3.2. ESTABLECIENDO CONEXIONES DE DATOS
La mecnica de transferir datos consiste en preparar la conexin

de datos en los puertos apropiados y elegir los parmetros 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 conexin de control (i.e., U). El puerto
por defecto del proceso servidor es el puerto adyacente al puerto
de la conexin de control (i.e., L-1).
El tamao de byte para la transferencia es de 8 bits. Este tamao

slo es relevante para la transferencia de datos; no tiene nada
que ver con la representacin 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 peticin de transferencia.
Esta orden determina el sentido de la transferencia de los datos.
El servidor, una vez recibida la peticin de transferencia,
iniciar la conexin de datos al puerto indicado. Una vez
establecida la conexin, la transferencia de datos comienza entre
los DTPs y el server-PI enva una respuesta de confirmacin al
user-PI.
Todas las implementaciones del FTP deben soportar el uso de los

puertos de datos por defecto y slo 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 lneas 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

servidor (mediante una orden FTP) que "escuche" hasta recibir una
conexin que el otro iniciar. El user-PI enva aun server-PI una
orden PORT indicando el puerto de datos del otro. Finalmente, se
envan a ambos las rdenes apropiadas de transferencia. La
secuencia exacta de rdenes y respuestas entre el usuario y los
servidores est en la seccin sobre Respuestas FTP.
En genera, es responsabilidad del servidor mantener la conexin de

datos (abrirla y cerrarla). La excepcin a esto se produce cuando
el user-DTP enva los datos en un modo de transferencia que
requiere cerrar la conexin para indicar EOF. El servidor DEBE
cerrar la conexin 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 conexin de control se cierra correctamente o de

cualquier otro modo.
5. Se produce una condicin de error irrecuperable.
En cualquier caso, el cierre es una opcin del servidor que se

debe indicar al proceso de usuario slo mediante una respuesta 250
226.
3.3. MANEJO DE LA CONEXION DE DATOS
Puertos de la conexin de datos por defecto: Todas las

implementaciones del FTP deben soportar el uso de los puertos de
datos por defecto y slo 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
localizacin de un puerto en el propio servidor con la orden PASV.
Como una conexin est definida por el par de direcciones,
cualquiera de estas acciones es suficiente para tener una conexin
de datos diferente, pero se permite usar ambas rdenes para
utilizar nuevos puertos en los dos lados de la conexin.
Reutilizacin de la conexin de datos: Cuando se usa el modo flujo

para transferencia de datos el final de fichero se indica cerrando
la conexin. Esta causa un problema si se van a transferir varios

ficheros en la sesin, debido a la necesidad que tiene el TCP de

mantener el registro de la conexin por un tiempo de espera para
garantizar una comunicacin fiable. Por eso la conexin 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 transmisin.
Un comentario sobre los modos de transmisin. El modo flujo de

transferencia es implcitamente poco fiable porque no se puede
determinar si la conexin se ha cerrado prematuramente o no.
Los otros modos de transferencia (de bloque, comprimido) no
cierran la conexin para indicar el final de fichero. Los datos
que enva el FTP a travs de ellos hacen que se pueda
determinar el final de fichero. Por eso, usando estos modos, se
puede dejar la conexin de datos abierta para transferir ms de
un fichero.
3.4. MODOS DE TRANSMISION
Otro aspecto a considerar en la transferencia de datos es la

eleccin apropiada del modo de transmisin. Hay tres modos: uno
que formatea los datos y permite reiniciar la transmisin; otro
que adems comprime los datos para una transferencia eficaz; y
otro que pasa los datos sin apenas procesarlos. En este ltimo
caso, el modo interacta con el atributo de estructura para
determinar el tipo de proceso. En el modo comprimido, el tipo de
representacin 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 explcita o
implcitamente cerrando la conexin de datos. Para ficheros con
estructura de registro, todos los indicadores de fin-de-registro
(EOR) son explcitos, incluyendo el ltimo. Para ficheros
transmitidos con estructura de pgina, se usa una pgina con el
indicador de ltima pgina activado.
NOTA: en el resto de esta seccin, byte significa "byte de

transferencia" excepto donde se indique explcitamente.
Para estandarizar la transferencia, el ordenador que enva los

datos trasladar sus caracteres de fin de lnea o de fin de
registro a la representacin indicada por el modo de transferencia
y la estructura del fichero y el receptor realizar la traduccin
inversa a su representacin interna. Un campo de contador de
registro de un Mainframe de IBM puede no ser reconocido por otro
ordenador, por eso, la informacin de fin-de-registro se puede

transferir como un cdigo de control de dos bytes en modo flujo o

como un bit activado en un descriptor de modo bloque o comprimido.
El fin-de-lnea en un fichero ASCII o EBCDIC no estructurado en
registros se debera indicar con <CRLF> o <NL> respectivamente.
Debido a que estas transformaciones implican un trabajo extra para
algunos sistemas, sistemas idnticos que transfieren entre ellos
un fichero de texto no estructurado en registros pueden preferir
usar una representacin binaria y modo flujo para la
transferencia.
Se definen los siguientes modos de transmisin en el FTP:
3.4.1. MODO FLUJO
Los datos se transmiten como un flujo de bytes. No hay ninguna

restriccin en el tipo de representacin usado; se permiten
estructuras de registro.
En un fichero estructurado en registros, EOR y EOF se indicarn

por un cdigo de control de dos bytes. El primer byte del
cdigo de control consistir en todo unos, el carcter de
escape. El segundo tendr el bit de orden ms bajo activado y
ceros en el resto para EOR y el segundo bit de orden ms 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 ms bajos (i.e., el
valor 3). Si se pretende transmitir un byte con todo unos como
dato, se debera repetir em el segundo byte del cdigo de
control.
Si la estructura es de fichero, se indica el EOF cuando el

ordenador que enva los datos cierra la conexin 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 ms bytes cabecera. Los bytes de la
cabecera contienen un campo contador y un cdigo 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 cdigo descriptor define: ltimo
bloque del fichero (EOF), ltimo bloque del registro (EOR),
indicador de reinicio (vea la seccin sobre Recuperacin de
Errores y Reinicio) o datos sospechosos (i.e., los datos
tranferidos pueden contener errores y no son fiables). Este
ltimo cdigo NO es para controlar errores desde el propio FTP.
Su uso est motivado por el deseo de ciertos sitios que

intercambian cierto tipo de informacin (por ejemplo, datos

ssmicos o meteorolgicos) enviando y recibiendo todos los
datos a pesar de que pueda haber errores locales (como errores
leyendo una cinta magntica). Se permiten estructuras de
registro y se puede usar cualquier tipo de representacin.
La cabecera consiste en tres bytes. De los 24 bits de

informacin, los 16 ms bajos representan un contador de bytes
y los 8 ms altos representan cdigos de descripcin como se
muestra a continuacin.
Cabecera de Bloque
+----------------+----------------+----------------+
| Descriptor | Contador de Bytes |
| 8 bits | 16 bits |
+----------------+----------------+----------------+
Los cdigos de descripcin se indican mediante bits en el byte

de descripcin. Hay asignados 4 cdigos, donde cada nmero de
cdigo es el valor decimal del correspondiente bit en el byte.
Cdigo 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 codificacin, ms de una condicin codificada puede

ocurrir para un bloque en particular. Se pueden activar tantos
bits como sea necesario.
El indicador de reinicio est includo en el flujo de datos

como un nmero de 8 bits representando caracteres imprimibles
en el lenguaje usado en la conexin 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 debera enviar lo siguiente:

+----------+--------+--------+
|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 informacin a enviar: datos normales,

enviados en una cadena de bytes; datos comprimidos, formados
por repeticiones o relleno; e informacin de control, enviada
en una secuencia de escape de dos bytes. Si se enva n>0 bytes
(hasta 127) de datos normales, estos n bytes van precedidos de
un byte con el bit ms a la izquierda a cero y los 7 bits ms a
la derecha contienen el nmero 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 envan los 2 siguientes bytes:
Byte Repetido:
2 6 8
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|1 0| n | | d |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+

Una cadena de n bytes de relleno se puede comprimir en un slo

byte, donde el byte de relleno vara segn el tipo de
representacin. Si el tipo es ASCII o EBCDIC, el byte de
relleno es <SP> (espacio, cdigo ASCII 32, cdigo 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 cdigos de descripcin segn lo definido para el modo
bloque. Los cdigos 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 pequeo. Se puede usar de forma muy efectiva para
reducir el tamao 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).
Slo est definido el procedimiento de reinicio para los modos de

transferencia de bloque y comprimido. Requiere que el que enva
datos inserte un cdigo marcador especial en el flujo de datos con
informacin que indique por dnde vamos. Esta informacin slo
tiene significado para el ordenador que enva los datos, pero debe
consistir en caracteres imprimibles en el lenguaje negociado o por
defecto de la conexin de control (ASCII o EBCDIC). El indicador
puede representar una cuenta de los bits, los registros o
cualquier otra informacin por la que un sistema pueda identificar
un punto de control. El receptor de los datos, si implementa el
procedimiento de reinicio, debera guardar la correspondiente
posicin de este marcador en el sistema receptor y devolver esta

informacin 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 enva 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 informacin del ltimo marcador recibido, ya sea
directamente o por la conexin de control en una respuesta 110
(dependiendo de quin enve 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 conexin
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 comunicacin entre el user-PI y el server-PI se establece

como una conexin TCP desde el usuario al puerto estndar. El
intrprete de protocolo de usuario es responsable de enviar rdenes
FTP e interpretar las respuestas recibidas; el server-PI interpreta
las rdenes, enva respuestas y controla su DTP para establecer la
conexin de datos y transferirlos. Si el proceso de transferencia
pasiva es el user-DTP, entonces est controlado a travs del
protocolo interno del ordenador donde se ejecuta el user-DTP; si es
otro server-DTP, est controlado a travs de rdenes recibidas en su
PI desde el user-PI. Las respuestas FTP se tratan en la siguiente
seccin.
Al describir algunas de las rdenes en esta seccin, viene bien ser

explcito 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 cdigos de las rdenes estn entre parntesis).
NOMBRE DE USUARIO (USER)

El argumento es una cadena Telnet que identifica al usuario.
Esta identificacin 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 conexin

de control (algunos ordenadores lo pueden requerir). El

servidor puede requerir informacin adicional como una
contrasea y/o cuenta. Los servidores pueden permitir una
nueva orden USER en cualquier momento para cambiar el
control de acceso y/o la informacin de la cuenta. Esto
tiene el efecto de descartar cualquier informacin anterior
sobre usuario, contrasea y cuenta y comienza la secuencia
de acceso otra vez. Todos lo parmetros de la transferencia
permanecen sin cambios y cualquier transferencia de fichero
en curso se completa bajo los anteriores parmetros de
control de acceso.
CONTRASEA (PASS)
El argumento es una cadena Telnet especificando la
contrasea del usuario. Esta orden debe ir inmediatamente
precedida por la orden USER y, para algunos ordenadores,
completa la identificacin del usuario para el control de
acceso. Como la informacin de la contrasea 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
informacin sobre la contrasea.
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 slo para cierto
tipo de acceso, como almacenar ficheros. En este ltimo
caso, la orden se puede enviar en cualquier momento.
Hay cdigos de respuesta para diferenciar automticamente

estos casos: cuando se requiere informacin de la cuenta, la
respuesta a una orden PASS correcta es el cdigo 332. Por
otra parte, si NO se requiere esta informacin, la respuesta
a una orden PASS correcta es 230; y si la cuenta se requiere
para una orden enviada ms tarde, el servidor debera
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 informacin sin alterar su informacin de entrada
o de cuenta. Los parmetros de transferencia permanecen sin
cambios. El argumento es un nombre de ruta especificando el

directorio o alguna otra agrupacin de ficheros dependiente

del sistema.
CAMBIAR AL DIRECTORIO PADRE (CDUP)

Esta orden es un caso especial de CWD y se incluye para
simplificar la implementacin de programas para transferir
rboles de directorios entre sistemas operativos que tienen
diferentes formas de nombrar al directorio padre. Los
cdigos de respuestas debern ser idnticos a los de CWD.
Vea el Apndice II para ms detalles.
MONTAR ESTRUCTURA (SMNT)

Esta orden permite al usuario montar un sistema de ficheros
diferente sin alterar su informacin de entrada o de cuenta.
Los parmetros de transferencia permanecen sin cambios. El
argumento es un nombre de ruta especificando un directorio o
alguna otra agrupacin de ficheros dependiente del sistema.
REINICIALIZAR (REIN)
Esta orden termina una orden USER, descargando todos los
datos del entrada/salida y la informacin de cuenta, excepto
que si hay alguna transferencia en proceso permite que
termine. Todos los parmetros se inician con sus valores por
defecto y la conexin de control se deja abierta. El estado
alcanzado es idntico al que se tiene inmediatamente despus
de abrir la conexin de control. Posiblemente se espere una
orden USER a continuacin de esta.
DESCONECTAR (QUIT)
Esta orden termina una orden USER y si no hay en proceso
ninguna transferencia, cierra la conexin de control. Si hay
una transferencia de fichero en proceso, la conexin
permanecer abierta hasta que el servidor enve 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
conexin y reabrirla para cada usuario, se debera usar el
comndo REIN en lugar de QUIT. Un cierre inesperado de la
conexin de control provoca que el servidor acte como si
hubiera recibido las rdenes interrumpir (ABOR) y
desconectar (QUIT).
4.1.2. ORDENES DE PARAMETROS DE TRANSFERENCIA
Todos los parmetros de transferencia de datos tienen valores

por defecto y las rdenes que especifican valores para ellos
slo se deben utilizar si se van a cambiar los parmetros por
defecto. El valor por defecto es el ltimo valor especificado

o, si no se ha especificado ninguno, el valor por defecto

estndar 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 parmetros de
transferencia de datos:
PUERTO DE DATOS (PORT)

El argumento es una especificacin ordenador-puerto para el
puerto que ser usado en la conexin 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 concatenacin de una direccin IP (32 bits)
y un puerto TCP (16 bits). Esta informacin est repartida
en campos de 8 bits y el valor de cada campo se transmite
como un nmero decimal (representado como una cadena de
caracteres). Los campos estn separados por comas. Una orden
PORT podra ser algo as:
PORT h1,h2,h3,h4,p1,p2
donde h1 es el nmero decimal correspondiente a los 8 bits

ms altos de la direccin 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 conexin en lugar de iniciar una al recibir una
orden de transferencia. La respuesta a este comando incluye
la direccin IP y el puerto donde este servidor est
esperando a recibir la conexin.
TIPO DE REPRESENTACION (TYPE)

El argumento especifica un tipo de representacin tal y como
se describi en la seccin Representacin de Datos y
Almacenamiento. Algunos tipos requieren un segundo
parmetro. El primer parmetro es un nico carcter Telnet y
el segundo, para ASCII y EBCDIC, tambin; el segundo
parmetro para tamao de byte local es un entero decimal.
Los parmetros estn separados por un <SP> (espacio, cdigo
ASCII 32).
Se asignan los siguientes cdigos para tipos:

\ /
A - ASCII | | N - No para imprimir
|-><-| T - Formateo con caracteres Telnet
E - EBCDIC| | C - Control de carro (ASA)
/ \
I - Imagen
L <tamao de byte> - Tamao de byte local
La representacin por defecto es ASCII no para imprimir. Si

se cambia el parmetro de formato y ms tarde slo el primer
argumento, el formato vuelve a ser el inicial por defecto
(no para imprimir).
ESTRUCTURA DEL FICHERO (STRU)

El argumento es un nico carcter Telnet especificando una
estructura de fichero de las descritas en la seccin
Representacin de Datos y Almacenamiento.
Existen los siguientes cdigos para la estructura:
F - Fichero (sin estructurar en registros) R -

Estructurado en registros P - Estruturado en pginas
La estructura por defecto es Fichero.
MODO DE TRANSFERENCIA (MODE)

El argumento es un nico carcter Telnet especificando un
modo de transferencia de los descritos en la seccin Modos
de Transmisin.
Los posibles cdigos 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 funcin 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 estndar por defecto aplicables) y las

convenciones del lenguaje usado en la conexin 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 travs de
la conexin 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 conexin 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 conexin 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 exista ya.
ALMACENAR UNICO (STOU)

Esta orden se comporta igual que STOR slo 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.
AADIR (con creacin) (APPE)

Esta orden hace que el server-DTP reciba datos a travs de
la conexin de control y los guarde en un fichero en el
servidor. Si el fichero especificado en el nombre de ruta
existe, los datos se aaden 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 nmero de bytes (usando el tamao de byte
lgico) de almacenamiento que se deben reservar. Para
ficheros enviados con estructura en registros o pginas,
puede ser necesario enviar el tamao mximo de registro o

pgina; 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 continuecin de esta
orden se deber indicar una orden STOR o APPE. La orden ALLO
debera tratarse como la orden NOOP (no operacin) por los
servidores que no necesitan conocer de antemano el tamao
del fichero y aquellos servidores que slo interpreten el
tamao mximo de registro o pgina deberan 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 site a
continuacin del punto indicado. A continuacin de esta
orden se debe enviar la orden de servicio FTP apropiada que
har que contine 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 interrupcin puede requerir alguna
"accin especial", tratada ms 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 conexin
de control, pero puede que s cierre la conexin de datos.
Hay dos posibles casos para el servidor al recibir esta
orden: (1) la orden de servicio FTP est ya terminada, o (2)
an est en ejecucin.
En el primer caso, el servidor cierra la conexin 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 conexin de datos, devolviendo una

respuesta 426 para indicar que la solicitud de servicio

termin anormalmente. Luego, el servidor enva 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
proteccin (del tipo "Seguro qu quiere borrar el
fichero?"), la debera proporcionar el proceso user-FTP.
BORRAR DIRECTORIO (RMD)

Esta orden borra en el servidor el directorio indicado. Vea
el Apndice II.
CREAR DIRECTORIO (MKD)

Esta orden crea el directorio indicado en el servidor. Vea
el Apndice II.
MOSTRAR EL DIRECTORIO DE TRABAJO (PWD)

Esta orden hace que el servidor nos devuelva en la respuesta
el nombre del directorio actual. Vea Apndice II.
LISTAR (LIST)
Esta orden hace que el servidor enve una listado de los
ficheros a travs del proceso de transferencia de datos
pasivo. Si el nombre de ruta u otra agrupacin 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 debera enviar informacin 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 envan a traves de la conexin de
datos con tipo ASCII o EBCDIC. (El usuario se debe asegurar
del tipo con TYPE). Como la informacin sobre un fichero
puede variar mucho de un sistema a otro, es muy difcil que
sta pueda ser procesada automticamente, pero puede ser
til para una persona.
LISTAR NOMBRES (NLST)

Esta orden hace que se enve un listado de directorio desde
el servidor. El nombre de ruta indica un directorio u otra
agrupacin de ficheros especfica del sistema; si no hay
argumento, se asume el directorio actual. Los datos se
transfieren en formato ASCII o EBCDIC a travs de la
conexin de datos separados unos de otros por <CRLF> o <NL>.
(Una vez ms el usuario se debe asegurar con TYPE). La
funcin de esta orden es devolver informacin que pueda ser

usada por un programa para procesar posteriormente los

ficheros automticamente. Por ejemplo, implementando una
funcin que recupere varios ficheros.
PARAMETROS DEL SISTEMA (SITE)

Esta orden la usa el servidor para proporcionar servicios
especficos propios de su sistema que son fundamentales para
transferir ficheros pero no lo suficientemente universales
como para ser includos como rdenes en el protocolo. La
naturaleza de este servicio y la especificacin 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 versin actual del
documento Nmeros Asignados [4].
ESTADO (STAT)
Esta orden hace que el servidor nos enva una respuesta con
su estado a travs de la conexin de control. La orden se
puede enviar durante la transferencia de un fichero (junto
con las seales Telnet IP y Synch--vea la seccin Ordenes
FTP) en cuyo caso el servidor responder con el estado de la
operacin 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
devolvern por la conexin de control. Si no hay ningn
argumento, el servidor devolver informacin general del
estado del proceso servidor FTP. Esto debera incluir los
valores actuales de los parmetros de transferencia y el
estado de las conexiones.
AYUDA (HELP)
Esta orden hace que el servidor enve informacin sobre la
implementacin del FTP a travs de la conexin de control.
La orden puede tener un argumento que debe ser un nombre de
orden y as devuelve informacin ms especfica 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
parmetros dependientes del sistema, por ejemplo, en
respuesta a HELP SITE.
NO OPERACION (NOOP)
Esta orden no afecta a ningn parmetro ni orden introducida

previamente. No hace nada ms que provocar que el servidor

enve una respuesta OK.
El Protocolo de Transferencia de Ficheros sigue la especificacin

del Protocolo Telnet en todas las comunicaciones a travs de la
conexin de control. Como el lenguaje usado para comunicacin
Telnet puede ser una opcin negociada, todas las referencias en
las siguientes dos secciones se referirn al "lenguaje Telnet" y
el correspondiente "cdigo Telnet de fin-de-lnea". De momento,
podemos entender que esto significa NVT-ASCII y <CRLF>. No se har
mencin a ninguna otra especificacin del Protocolo Telnet.
Las rdenes FTP son "cadenas Telnet" terminadas con el "cdigo

Telnet de fin de lnea". Los cdigos de orden son caracteres
alfabticos terminados con el carcter <SP> (espacio) si tienen
parmetros o el carcter Telnet EOL (fin de lnea) si no los
tienen. En esta secin se han descrito los cdigos de orden y su
significado; la sintaxis detallada se encuentra en la seccin
sobre Ordenes, las secuencias de respuesta se explican en la
seccin Secuencia de Ordenes y Respuestas, y se muestran ejemplos
del uso de estos comandos en la seccin Escenario Tpico del FTP.
Las rdenes FTP se pueden dividir en aquellas que indican

identificadores de control de acceso, parmetros de transferencia
de datos y peticiones de servicio FTP. Algunas rdenes (como ABOR,
STAT y QUIT) se pueden enviar por la conexin de control cuando
hay una transferencia en proceso. Puede que algunos servidores no
sean capaces de gestionar las conexiones de control y de datos
simultneamente, en cuyo caso puede ser necesaria alguna accin
especial para captar la atencin del servidor. Se recomienda
insistentemente esta forma:
1. Se inserta la seal Telnet "Interrumpir Proceso" (IP) en la

conexin de control.
2. Se enva la seal Telnet "Synch".
3. Se enva el comando (p.e., ABOR) por la conexin de control.
4. El intrprete de protocolo del servidor, despus de recibir

la seal "IP", lee de la conexin de control UNICAMENTE UN
COMANDO. (Para otros servidores, puede que esto no sea
necesario, pero el hacerlo no tendr ninguna repercusin.)
4.2. RESPUESTAS FTP
Las respuestas a rdenes del FTP estn pensadas para asegurar la

sincronizacin entre peticiones y acciones en el proceso de

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 ms de una;
en este ltimo caso, las diferentes respuestas se deben distinguir
fcilmente. Adems, 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 ms abajo.
Una respuesta FTP consiste en un nmero de tres cifras

(transmitido como tres caracteres alfanumricos) seguidos de
texto. El nmero se proporciona para su uso por autmatas que
deben determinar el prximo estado; el texto va dirigido a las
personas. Se pretende que el nmero contenga suficiente
informacin codificada como para que el intrprete 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 cdigo de
respuesta.
Una respuesta debe contener el cdigo de 3 dgitos, seguidos de

espacio <SP>, seguido de una lnea de texto (en la que hay
definido una longitud mxima), y termina con el cdigo Telnet de
fin de lnea. Habr casos en los que el texto es mayor que una
lnea. 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 conexin de control) y haga otras cosas. Esto requiere
de un formato especial en la primera lnea para indicar que hay
ms y otro en la ltima lnea para indicar lo propio. Al menos una
de estas debe contener el cdigo de respuesta apropiado para
indicar el estado de la transaccin. Para satisfacer a todos, se
ha decidido que ambas, la primera y la ltima lnea, deben
contener el mismo cdigo.
Por tanto, el formato para respuestas multi-lnea consiste en que

la primera lnea empieza con el cdigo de respuesta requerido
seguido inmediatamente de un guin, "-" (tambin es el signo
menos), seguido de el texto. La ltima lnea empezar con el mismo
cdigo, seguido inmediatamente por un espacio <SP>, opcionalmente
texto, y el cdigo Telnet de fin de lnea.
Por ejemplo:

123-Primera linea
Segunda linea
234 Una linea que comienza con numeros
123 La ultima linea
El proceso de usuario slo necesita buscar la segunda ocurrencia

del mismo cdigo de respuesta, seguido de <SP> (espacio), al
principio de una lnea. Si una lnea intermedia comienza con un
nmero de tres dgitos, el servidor debe desplazar ese nmero para
evitar confusiones.
Este esquema permite permite que se usen los procedimientos

estndar del sistema para la informacin de respuesta (como, por
ejemplo, para STAT), con las lneas primera y ltima aadidas
"artificialmente". En casos raros en los que estos procedimientos
generen tres dgitos y un espacio al principio de cualquier lnea,
el principio de cada lnea de texto se debera desplazar con algn
texto neutral, como espacios.
Este esquema asume que las respuestas multilnea no pueden estar

anidadas.
Cada tres dgitos 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 dgito denota si
la respuesta es buena, mala o incompleta. (Refiriendonos al
diagrama de estado), un proceso de usuario poco sofisticado podr
determinar su prxima accin simplemente examinando el primer
dgito. 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 dgito,
reservando el tercero para una mayor precisin en la informacin
(por ejemplo, orden RNTO sin ser precedida por una RNFR).
Hay cinco valores para el primer dgito del cdigo de respuesta:
1yz Respuesta preliminar positiva

Se ha iniciado la accin requerida; se espera otra respuesta
antes de seguir con una nueva orden. (El proceso de usuario
que enva otra orden antes de que la respuesta de
finalizacin llegue, estar violando el protocolo, pero el
proceso servidor debera 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 debera ocuparse ahora de
la conexin de datos, en implementaciones donde controlar
ambas conexiones a la vez es difcil. El proceso servidor
puede enviar, a lo sumo, una respuesta 1yz por orden

recibida.
2yz Respuesta de finalizacin positiva

La accin 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
ms informacin para completarla. El usuario debera enviar
otra orden indicando esta informacin. Esta respuesta se
utiliza en rdenes que deben ir en secuencia.
4yz Repuesta de finalizacin negativa transitoria

La orden no se ha aceptado y la accin requerida no se ha
llevado a cabo, pero la condicin de error es temporal y se
puede solicitar la accin de nuevo. El usuario debera
volver al principio de la secuencia de comandos, si es que
la hay. Es difcil dar un significado a "transitoria",
particularmente cuando dos sistemas diferentes (el servidor
y el usuario) deben estar de acuerdo en la interpretacin.
Cada respuesta la categora 4yz puede tener un valor
diferente, pero se pretende con ella que el proceso de
usuario reintente la operacin. Una regla para determinar si
una respuesta pertenece a la categora 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 finalizacin negativa permanente

La orden no se ha aceptado y la accin requerida no ha
tenido lugar. El proceso de usuario no debera repetir la
misma peticin (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 dgito:
x0z Sintaxis
Estas respuestas se refieren a errores de sintaxis, rdenes
correctas sintcticamente pero que no encajan en ninguna
otra categora, rdenes no implementadas o superfluas.

x1z Informacin
Estas son respuestas a solicitudes de informacin como
STATUS o HELP.
x2z Conexiones
Respuestas referidas a las conexiones de control y de datos.
x3z Autenticacin y cuenta

Respuestas para el proceso de entrada al sistema y
procedimientos de cuenta.
x4z Sin especificar an.
x5z Sistema de ficheros

Estas respuestas indican el estado del sistema de ficheros
en el servidor segn se realizan transferencias u otras
acciones sobre el sistema de ficheros.
El tercer dgito afina ms en el significado de cada una de las

categoras indicadas por el segundo. La lista de respuestas de la
siguiente seccin mostrar esto. El texto asociado con cada
respuesta es slo una recomendacin, no una obligacin, y puede
incluso cambiar segn la orden asociada. Los cdigos de respuesta,
por otra parte, deben seguir estrictamente las especificaciones;
es decir, las implementaciones de servidores no deben inventarse
nuevos cdigos para situaciones que son ligeramente diferentes a
las descritas aqu, sino que deberan adaptarse a los cdigos ya
definidos.
Una orden como TYPE o ALLO cuya correcta ejecucin no proporciona

al usuario ninguna nueva informacin debera devolver un cdigo
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 finalizacin 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 especfica a ningn 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 Cdigos de respuesta por grupos funcionales
200 Orden correcta.
500 Error de sintaxis, comando no reconocido.

Esto puede incluir errores como lnea de orden demasiado

larga.
501 Error de sintaxis en parmetros 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 parmetro.
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 (atencin
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 estndar. Esta respuesta slo 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 Nmeros Asignados.
120 El servicio estar en funcionamiento en nnn minutos.
220 Servicio preparado para nuevo usuario.
221 Cerrando la conexin de control.

Desconectado si procede.
421 Servicio no disponible, cerrando la conexin de control.

Esta puede ser la respuesta a cualquier comando si el
servidor sabe que debe finalizar.
125 La conexin de datos ya est abierta; comenzando

transferencia.

225 Conexin de datos abierta; no hay transferencia en proceso.
425 No se puede abrir la conexin de datos.
226 Cerrando la conexin de datos.

La accin sobre fichero requerida ha sido correcta (por
ejemplo, una transferencia o interrupcin).
426 Conexin cerrada; transferencia interrumpida.
227 Iniciando modo pasivo (h1,h2,h3,h4,p1,p2).
230 Usuario conectado, contine.
530 No est conectado.
331 Usuario OK, necesita contrasea.
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 conexin de

datos.
250 La accin sobre fichero solicitado finaliz correctamente.
257 "NOMBRERUTA" creada.
350 La accin requiere ms informacin
450 Accin no realizada.

Fichero no disponible (por ejemplo, fichero bloqueado).
550 Accin no realizada,

Fichero no disponible (por ejemplo, fichero no existe, no se
tiene acceso al mismo).
451 Accin interrumpida. Error local.
551 Accin interrumpida. Tipo de pgina desconocido.

Falta de espacio en el sistema de ficheros.
552 Accin interrumpida.

Se ha sobrepasado el espacio disponible de almacenamiento

(para el directorio actual).

Nombre de fichero no permitido.
4.2.2 Cdigos de respuesta por nmero.
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 (atencin
a los espacios entre los marcadores y el "=").
120 El servicio estar en funcionamiento en nnn minutos.
125 La conexin de datos ya est abierta; comenzando

transferencia.
150 Estado del fichero correcto; va a abrirse la conexin 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 estndar. Esta respuesta slo 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 Nmeros Asignados.
220 Servicio preparado para nuevo usuario.
221 Cerrando la conexin de control.

Desconectado si procede.
225 Conexin de datos abierta; no hay transferencia en proceso.
226 Cerrando la conexin de datos.

La accin sobre fichero requerida ha sido correcta (por

ejemplo, una transferencia o interrupcin).
227 Iniciando modo pasivo (h1,h2,h3,h4,p1,p2).
230 Usuario conectado, contine.
250 La accin sobre fichero solicitado finaliz correctamente.
257 "NOMBRERUTA" creada.
331 Usuario OK, necesita contrasea.
332 Necesita una cuenta para entrar en el sistema.
532 Necesita una cuenta para almacenar ficheros.
350 La accin requiere ms informacin.
421 Servicio no disponible, cerrando la conexin de control.

Esta puede ser la respuesta a cualquier comando si el
servidor sabe que debe finalizar.
425 No se puede abrir la conexin de datos.
426 Conexin cerrada; transferencia interrumpida.

Fichero no disponible (por ejemplo, fichero bloqueado).
451 Accin interrumpida. Error local.

Falta de espacio en el sistema de ficheros.
500 Error de sintaxis, comando no reconocido.

Esto puede incluir errores como lnea de orden demasiado
larga.
501 Error de sintaxis en parmetros 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 parmetro.

530 No est conectado.
550 Accin no realizada,

Fichero no disponible (por ejemplo, fichero no existe, no se
tiene acceso al mismo).
551 Accin interrumpida. Tipo de pgina desconocido.
552 Accin interrumpida.

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

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 mnimo 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 parmetros de transferencia:
TYPE - ASCII No para imprimir MODE - Flujo STRU - Fichero
Todos los servidores deben aceptar los valores indicados como

estndar por defecto.
5.2. CONEXIONES

El intrprete de protocolo del servidor debe "escuchar" en el

puerto L. El usuario o el intrprete de protocolo de usuario
iniciar la conexin de control full-duplex (bidireccional). Los
procesos de servidor y de usuario deberan 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
obligacin de proporcionar facilidades para la edicin de la lnea
de comandos y pueden requerir que esto se haga en el ordenador del
usuario. El servidor deber cerrar la conexin a peticin del
usuario despus 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 determinarn por la orden de servicio
FTP.
Todas las implementaciones del FTP deben poder transferir datos

usando el puerto por defecto y slo 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 conexin de control entre
ambos server-PIs. A uno de los servidores, por ejemplo, A, se le
enva un comando PASV indicandole que "escuche" en su puerto de
datos en lugar de iniciar la conexin cuando reciba la peticin de
transferencia. Cuando el user-PI recibe la respuesta a la orden
PASV, que incluye la direccin del ordenador y el puerto donde
est escuchando, el user-PI enva 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 conexin y comienza la transferencia de datos. La secuencia
orden-respuesta se muestra aqu. Los mensajes se muestran en orden
verticalmente, pero no horizontalmente:

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

-------------------- --------------------
C->A : Conexin C->B : Conexin

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 : Conexin a HOST-A, PORT-a
Figura 3
El servidor cerrar la conexin de datos en las condiciones

descritas en la seccin Estableciendo Conexiones de Datos. Si se
va a cerrar la conexin 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 conexin de datos para ver si necesita "escuchar"
(recuerde que el usuario debe "escuchar" en un puerto cerrado
ANTES de enviar la peticin de transferencia. Para evitar fallos
de sincronizacin, el servidor enva una respuesta (226) despus
de cerrar la conexin de datos (o, si la conexin se deja abierta,
una respuesta "Transferencia completada." (250) y el user-PI
debera 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 conexin, debera leer inmediatamente
cualquier dato que permanezca encolado en la conexin y proceder
al cierre de la misma.
5.3. ORDENES
Las rdenes son cadenas de caracteres Telnet transmitidas por la

conexin de control tal y como se describe en la seccin Ordenes
FTP.
Las funciones y la semntica de las rdenes se describe en las

secciones Ordenes de Control de Acceso, Ordenes de Parmetros de
Transferencia, Ordenes de Sevicio FTP y Ordenes Varias. La
sintaxis de los comandos se detalla aqu.
Las rdenes comienzan con un cdigo de orden seguido de unos

argumentos. Los cdigos de orden tienen cuatro o menos carcteres
alfabticos. Las letras maysculas y las minsculas se tratan de
la misma manera. Por tanto, cualquiera de las siguientes puede
representar a la orden "recuperar":

RETR Retr retr ReTr rETr
Tambin se aplica esto a cualquier smbolo que represente valores

de los parmetros como la 'A' para el tipo ASCII. Los cdigos de
comando y el campo de argumentos estn separados por uno o ms
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 lnea) para la representacin NVT-
ASCII; para otros lenguajes negociados puede que se use otro
representacin para el fin de lnea. El servidor no realizar
ninguna accin hasta recibir el cdigo de fin de lnea.
La sintaxis se especifica ms abajo en NVT-ASCII. Todos los

caracteres del campo de argumentos son caracteres ASCII,
incluyendo los enteros decimales representados en ASCII. Los
parntesis 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> <contrasea> <CRLF>
ACCT <SP> <informacin-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> <cdigo-tipo> <CRLF>
STRU <SP> <cdigo-estructura> <CRLF>

MODE <SP> <cdigo-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 notacin BNF) es:

<nombre-usuario> ::= <cadena>
<contrasea> ::= <cadena>
<informacin-cuenta> ::= <cadena>
<cadena> ::= <carcter> | <carcter><cadena>
<carcter> ::= cualquier carcter ASCII excepto <CR> y <LF>
<marcador> ::= <pr-cadena>
<pr-cadena> ::= <pr-carcter> | <pr-carcter><pr-cadena>
<pr-carcter> ::= caracteres imprimibles, cualquier cdigo

ASCII desde 33 a 126.
<tamao-byte> ::= <nmero>
<dirIP-puerto> ::= <host-nmero>,<port-nmero>
<host-nmero> ::= <nmero>,<nmero>,<nmero>,<nmero>
<port-nmero> ::= <nmero>,<nmero>
<nmero> ::= cualquier entero decimal desde 1 a 255
<cdigo-formateo> ::= N | T | C
<cdigo-tipo> ::= A [<sp> <cdigo-formateo>]

| E [<sp> <cdigo-formateo>]
| I
| L <sp> <tamao-byte>
<cdigo-estructura> ::= F | R | P
<cdigo-modo> ::= S | B | C
<nombre-ruta> ::= <cadena>
<entero-decimal> ::= cualquier entero decimal
5.4. SECUENCIA DE ORDENES Y RESPUESTAS
La comunicacin entre el usuario y el servidor se lleva a cabo

mediante un dilogo. Como tal, el usuario enva una orden y el
servidor devuelve una respuesta. El usuario debera esperar a
recibir la respuesta antes de enviar ms ordenes.

Algunas rdenes requieren una segunda respuesta a la que el

usuario debera tambin esperar. Estas respuestas informan, por
ejemplo, del estado o la finalizacin de una transferencia o del
cierre de la conexin de datos. Son respuestas secundarias a
rdenes de transferencia de ficheros. Un grupo importante de
respuestas informativas son los mensajes al iniciar la conexin.
En circunstancias normales, un servidor enviar una respuesta 220,
"Esperando rdenes", cuando se completa la conexin. El usuario
debera esperar esta respuesta antes de enviar cualquier orden. Si
el servidor no puede aceptar rdenes en ese momento, se debera
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 espontneas
A veces "el sistema" tiene que enviar un mensaje al usuario

espontneamente (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 informacin se encole en el
server-PI y se enve en la siguiente respuesta (posiblemente en
una respuesta multilnea).
La tabla siguiente lista las respuestas indicando la

finalizacin 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 accin que
implica el nmero de cdigo y la secuencia de comandos no debe
alterarse.
Secuencias orden-respuesta
En esta seccin 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 ejecucin
correcta indentadas a continuacin), luego las respuestas de
finalizacin 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 vern ms tarde.
Establecimiento de conexin
120
220
220
421

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
Parmetros de transferencia
PORT
200
500, 501, 421, 530
PASV
227
500, 501, 502, 421, 530
MODE
200
500, 501, 504, 421, 530
TYPE
200

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

(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

200
500 421
6. DIAGRAMAS DE ESTADO
Aqu presentamos los diagramas de estado para una implementacin FTP

muy simple. Slo se tiene en cuenta el primer dgito de la respuesta.
Hay un diagrama de estado por cada grupo de rdenes FTP o secuencia
de las mismas.
La agrupacin de las rdenes se ha hecho construyendo un modelo para

cada una de ellas y juntando las que tienen modelos idnticos
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
smbolo B para "inicio" y el smbolo W para indicar "espera una
respuesta".
En primer lugar tenemos el diagrama que representa el grupo ms

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:

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 ms

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:

+---+ 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 slo en el tratamiento de las respuestas tipo
100 en la segunda parte, mientras que el segundo grupo espera (a
veces necesita) respuestas tipo 100. Slo se permite una respuesta
tipo 100 por cada orden.

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.

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

proceso user-FTP. El siguiente puede ser un escenario tpico. Lo que
muestra el user-FTP est entre parntesis, '---->' representa rdenes
de U a S y
'<----' representa respuestas de S a U.

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 contrasea<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 conexin
de datos<CRLF>.
El servidor crea la conexin de datos
al puerto U.
<---- 226 Cerrando conexin 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 conexin 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 transmisin 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

pginas. El sistema operativo es ms eficiente manipulando pginas
que ficheros. El sistema operativo proporciona una interfaz con el

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 pginas, un conjunto de pginas (posiblemente vaco) 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 extensin y el nmero de generacin.
La tabla de pginas contiene hasta 2**18 entradas. Cada una de ellas

puede estar vaca o apuntar a una pgina. Si no est vaca, hay unos
bits de acceso a la pgina; no todas las pginas de un fichero tienen
por qu tener los mismos permisos de acceso.
Una pgina es un conjunto contiguo de 512 palabras de 36 bits cada

una. Los atributos del fichero, que est en el Bloque de Descripcin
del Fichero (FDB), contienen datos como la hora de creacin, de
escritura, de lectura,...
Las entradas de la tabla de pginas NO tienen por qu ser contiguas.

Puede haber pginas vacas entre otras ocupadas. Adems, el puntero
de fin de fichero es simplemente un nmero. 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 despus 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 estn al final del fichero, ocurren con los
ficheros de datos NLS.
Los ficheros paginados del TOPS-20 se pueden enviar con los

siguientes parmetros FTP:
TYPE L 36, STRU P y MODE S (de hecho, se puede usar cualquier modo).
Cada pgina de informacin tiene una cabecera. Cada campo de la

cabecera, que es una byte lgico, 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.

Palabra 1: Indice de pgina.

Si los datos son de la pgina de un fichero, este es el nmero
de ellas que hay en el mapa de pginas del fichero. Las pginas
vacas (huecos) del fichero no se envan. Tener en cuenta que
un hueco NO es lo mismo que una pgina de ceros.
Palabra 2: Longitud de datos.

El nmero de palabras de datos de esta pgina que van a
continuacin de la cabecera. El nmero total de palabras
transmitidas es la longitud de la cabecera ms la longitud de
datos.
Palabra 3: Tipo de pgina.

Un cdigo para indicar el tipo de pgina. Un 3 indica una
pgina de datos; un 2 indica que es un FDB.
Palabra 4: Control de acceso a la pgina.

Los bits de control asociados a la pgina en el mapa de pginas
del fichero.
A continuacin de la cabecera van los datos. La longitud de los datos

es o 512 para una pgina 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 fcilemente como ficheros
normales, es conveniente ampliar los servidores FTP de estos sistemas
para tratar con la creacin de directorios. Como hay ms tipos de
servidores con un sistema similar, estas rdenes son tan generales
como es posible.
Se han aadido 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

directorio de trabajo actual a menos que "nombreruta" contenga

suficiente informacin 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 implementacin de programas para transferir rboles
de directorios completos entre sistemas que llaman de forma
diferente al directorio padre. Lo cdigos de respuesta a CDUP son
los mismos que para CWD.
Los cdigos de respuesta para RMD son los mismos que para su
anlogo con ficheros, DELE.
Los cdigos de respuesta para MKD, sin embargo, son un poco ms

complicados. Un directorio creado recientemente ser, lo ms
seguro, el objeto de una prxima 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 slo
el nombre de subdirectorio. Esto es, en un servidor FTP de un
TOPS-20, la secuencia
MKD DIRECTORIO
CWD DIRECTORIO
fallar. Slo podemos referirnos al nuevo directorio por su nombre

absoluto; por ejemplo, si se realiza el comando MKD cuando estamos
conectados al directorio <DFRANKLIN>, slo 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. Segn qu aplicacin, esto puede ser un
inconveniente. No es muy robusto en ningn caso.
Para solucionar estos problemas, una vez que finalice

correctamente una orden MKD, el servidor debera 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 carcter; si en el nombre hay comillas dobles,
se debera indicar usando dos veces ls comillas dobles.
Por ejemplo, un usuario se conecta al directorio /usr/dm y crea un

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 accin.
Las respuestas indicando error para MKD son anlogas a las de su

primo para crear ficheros, STOR. Tambin 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 debera
serlo en un TOPS-20).
Como el comando PWD devuelve el mismo tipo de informacin que un

MKD correcto, la respuesta a un comando PWD correcto usa tambin
el cdigo 257.
SUTILEZAS
Como estos comandos sern ms tiles a la hora de transferir

subrboles 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 informacin suficiente que
indique lo contrario. Un ejemplo hipottico 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>

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 tambin 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. Poda haber habido problemas
de ambigedad si existiera un directorio llamado
<sobreelarcoiris>, pero esto es una ambigedad inherente al
sistema TOPS-20. Estas consideraciones se aplican tambin 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 debera 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 aadir al protocolo FTP", RFC

281 (NIC 8163), BBN, 8 de diciembre de 1971.
Bhushan, Abhay, "El uso de la transaccin "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.

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, "Documentacin 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, "Interaccin 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, "Compresin 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 "Interaccin servidor-servidor en FTP -

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, "Cdigos 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 ms 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, Jon, "Especificacin 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 transicin de

protocolo en Internet",Network Information Center, SRI International,
marzo de 1982.
[2] Postel, Jon, "Protocolo de control de la transmisin -

Especificacin del protocolo del programa DARPA Internet", RFC 793,
DARPA, septiembre de 1981.
[3] Postel, Jon, and Joyce Reynolds, "Especificacin del Protocolo

Telnet", RFC 854, ISI, mayo de 1983.
[4] Reynolds, Joyce, and Jon Postel, "Nmeros asignados", RFC 943,
ISI, abril de 1985.

rfc0959 Es

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

rfc0959 Es

Загружено:

Авторское право:

Доступные форматы

Network Working Group J.

PROTOCOLO DE TRANSFERENCIA DE FICHEROS (FTP)

Estado de este Documento

Este documento es la especificacin oficial del Protocolo de

Las siguientes nuevas rdenes opcionales se incluyen en esta edicin

CDUP (cambiar al directorio padre), SMNT (montar estructura), STOU

Esta especificacin es compatible con ediciones anteriores.

Los objetivos del FTP son 1) promocionar el uso compartido de

Con esta especificacin se intentan satisfacer las diversas

En este documento se asumen conocimientos del Protocolo de Contol de

2. HISTORIA, TERMINOLOGIA Y MODELO FTP

En esta seccin se tratan la historia, la terminologa y el modelo

Postel & Reynolds Estndar [Pg. 1]

El FTP ha pasado por un larga evolucin a travs de los aos. El

El RFC 172 proporcion un protocolo orientado al nivel de usuario

El RFC 354 dej obsoletos los RFCs 264 y 265. El Protocolo de

Hacia julio de 1973, se hicieron considerables cambios a las

En 1974, los RFCs 607 y 614 continuaron los comentarios sobre el

Postel & Reynolds Estndar [Pg. 2]

revisin del RFC 686, referente al tema de ficheros para imprimir.

Motivado por la transicin del NCP al TCP como protocolo

Esta edicin de la especificacin FTP est dirigida a la

En particular, se incluyen las siguientes nuevas rdenes

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 especificacin es compatible con la anterior edicin. Un

El conjunto de caracteres ASCII se considera tal y como est

Los controles de acceso definen los privilegios de acceso del

Postel & Reynolds Estndar [Pg. 3]

servidor FTP utilizar los controles de acceso.

Hay dos tamaos de byte interesantes en el FTP: el tamao

La ruta de comunicacin entre el USER-PI y el SERVER-PI para el

Una conexin bidireccional sobre la que se transfieren los

El proceso de transferencia pasiva de datos "escucha" en el

El proceso de transferencia de datos (DTP, Data Transfer

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

La secuencia fin-de-linea define la separacin entre lneas. La

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

La condicin fin-de-fichero que define el final de un fichero

Postel & Reynolds Estndar [Pg. 4]

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

La condicin fin-de-registro que define el final de un registro

Un procedimiento que permite al usuario recuperar el control a

Un conjunto de rdenes que abarcan la informacin de control

Un conjunto ordenado de datos del ordenador (incluyendo

El modo en que se tranfieren datos por la conexin de datos.

El terminal virtual de red (Network Virtual Terminal) tal y

El sistema de ficheros virtual de red (Network Virtual File

Un fichero se puede estructurar como un conjunto de partes

Postel & Reynolds Estndar [Pg. 5]

de ficheros discontinuos como pginas indizadas independientes.

nombre de ruta [pathname]

El nombre de ruta se define como una cadena de caracteres que

El Intrprete del Protocolo (Protocol Interpreter). La parte

Un fichero secuencial se puede estructurar en un nmero de

Una respuesta es un asentimiento (positivo o negativo) enviada

server-DTP (server Data Transfer Process)

El proceso de transferencia de datos (Data Transfer Process),