Network Working Group T. Berners-Lee Request for Comments: 1738 CERN Category: Seguimiento de Estándares L. Masinter Xerox Corporation M. McCahill University of Minnesota Editors Diciembre 1994 Localizadores Uniformes de Recursos (URL) Status de este Memorándum Este documento especifica un protocolo de seguimiento de estándares para la comunidad de Internet, y solicita debate y sugerencias para mejorarlo. Por favor, consulte la edición actual de los "Estándares de Protocolos Oficiales de Internet" (STD1) para conocer el estado de estandarización y status de este protocolo. La distribución de este memorándum tiene carácter ilimitado. Resumen Este documento especifica un Localizador Uniforme de Recursos (URL), la sintaxis y semántica de información formalizada para la localización y acceso de recursos a través de Internet. 1. Introducción Este documento describe la sintaxis y semántica para la representación mediante una cadena de caracteres compacta de un recurso disponible en Internet. Estas cadenas se denominan "Localizadores Uniformes de Recursos" (URLs). La especificación deriva de conceptos introducidos por la iniciativa de información global de la World Wide Web, cuyo uso de tales objetos data de 1990 y está descrito en "Identificadores Universales de Recursos en la WWW", RFC 1630. La especificación de los URLs está diseñada para cumplir los requisitos expuestos en "Requerimientos Funcionales para Localizadores de Recursos" [12] Este documento ha sido escrito por el grupo de trabajo URI de el IETF (Grupo de Tareas sobre Ingeniería de Internet). Se pueden enviar comentarios a los editores, o al grupo de trabajo URI . Los debates del grupo están archivados en 2. Sintaxis General de los URLs Berners-Lee, Masinter & McCahill [Pág. 1] RFC 1738 Localizadores Uniformes de Recursos Diciembre 1994 Del mismo modo que hay muchas formas distintas de acceder a recursos, hay también muchos esquemas para describir la localización de tales recursos. La sintaxis genérica de los URLs proporciona un marco para el establecimiento de nuevos esquemas utilizando otros protocolos distintos a los que se definen en este documento. Los URLs se usan para `localizar' recursos, proporcionando una identificación abstracta de la localización del recurso. Habiendo localizado un recurso, un sistema puede realizar una gran variedad de operaciones sobre ese recurso, como podrían ser las caracterizadas por palabras como `acceder', `actualizar', `reemplazar' o `encontrar atributos'. En general, solo se necesita especificar el método `acceso' para cualquier esquema de URLs. 2.1. Las principales partes de los URLs En la sección 5 puede encontrarse una descripción BNF completa de la sintaxis de los URLs. En general, los URLs se escriben como sigue: : Un URL contiene el nombre del esquema que se está usando () seguido de dos puntos y después una cadena (la ) cuya interpretación depende del esquema. Los nombres de esquema consisten en una secuencia de caracteres. Están permitidas las letras minúsculas "a"--"z", lo dígitos, el signo de suma ("+"), el punto (".") y el guión ("-"). Para evitar errores, los programas que interpreten URLs deberían tratar las letras mayúsculas como equivalentes a las minúsculas en los nombres de esquema (por ejemplo, permitir "HTTP" y "http"). 2.2. Aspectos de la Codificación de Caracteres en los URLs Los URLs son secuencias de caracteres, es decir, letras, dígitos, y caracteres especiales. Un URL puede representarse de varias formas: Por ejemplo, tinta sobre papel, o una secuencia de octetos en un conjunto de caracteres codificado. La interpretación de un URL depende únicamente de la identidad de los caracteres utilizados. En la mayoría de los esquemas de URL, las secuencias de caracteres se utilizan en distintas partes del URL para representar una secuencia de octetos utilizada por protocolos de Internet. Por ejemplo, en el esquema ftp, el nombre del servidor, el nombre del directorio y los Berners-Lee, Masinter & McCahill [Pág. 2] RFC 1738 Localizadores Uniformes de Recursos Diciembre 1994 nombres de fichero son tales secuencias de octetos, representadas por partes del URL. En esas partes, un octeto puede ser representado por el carácter que tiene ese octeto como código en el conjunto codificado de caracteres US-ASCII [20]. De forma adicional, los octetos pueden ser codificados con una terna de caracteres consistente en el carácter "%" seguido por los dos dígitos hexadecimales (de "0123456789ABCDEF") que forman el valor hexadecimal del octeto. (Se pueden usar también los caracteres "abcdef" para las codificaciones hexadecimales). Los octetos deben ser codificados si no tiene un carácter gráfico correspondiente en el conjunto codificado de caracteres US-ASCII, si el uso del correspondiente carácter es inseguro, o si el carácter correspondiente está reservado para alguna otra interpretación en ese esquema de URL en particular. Gráficos que no corresponden al conjunto US-ASCII: Los URLs se escriben solo con los gráficos imprimibles del conjunto codificado de caracteres US-ASCII. Los octetos 80-FF en hexadecimal no se usan en US-ASCII, y los octetos 00-1F y 7F en hexadecimal representan caracteres de control; todos estos deben ser codificados. Inseguros: Los caracteres pueden ser inseguros por un gran número de razones. El carácter de espacio es inseguro porque pueden desaparecer espacios significativos e introducir espacios no significativos cuando se transcriben URLs o se tratan en imprenta o con programas procesadores de textos. Los caracteres "<" y ">" son inseguros porque se usan como delimitadores alrededor de los URLs en texto libre; las comillas (""") se usan en algunos sistemas para delimitar URLs. El carácter "#" es inseguro y debería codificarse siempre porque es utilizado en la World Wide Web y en otros sistemas para delimitar un URL de un identificador de fragmento/enlace que podría seguirlo. El carácter "%" es inseguro porque se utiliza para la codificación de otros caracteres. Otros caracteres son inseguros porque es conocido que las pasarelas y otros agentes de transporte a veces modifican tales caracteres. Estos caracteres son "{", "}", "|", "\", "^", "~", "[", "]", y "`". Todos los caracteres inseguros deben codificarse siempre en un URL. Por ejemplo, el carácter "#" debe codificarse en un URL incluso en sistemas que normalmente no tratan con fragmentos o enlaces, para que si el URL se copia en otro sistema que sí que los usa, no sea necesario cambiar la codificación del URL. Berners-Lee, Masinter & McCahill [Pág. 3] RFC 1738 Localizadores Uniformes de Recursos Diciembre 1994 Reservados: En muchos esquemas de URL se reservan ciertos caracteres para que tengan un significado especial: su aparición en la parte del URL específica del esquema tiene una semántica designada. Si el carácter correspondiente a un octeto está reservado en el esquema, el octeto debe ser codificado. Los caracteres ";", "/", "?", ":", "@", "=", y "&" son los caracteres que pueden estar reservados para que tengan un significado especial dentro de un esquema. Ningún otro carácter puede estar codificado dentro de un esquema. Normalmente un URL tiene la misma interpretación cuando un octeto está representado con un carácter y cuando es codificado. Sin embargo, esto no es cierto para los caracteres reservados: codificar un carácter reservado para un esquema en particular puede cambiar la semántica de un URL. Así pues, solo los caracteres alfanuméricos, los caracteres especiales "$-_.+!*'(),", y los caracteres reservados usados para los propósitos para los que se han reservado pueden ser utilizados sin codificar en un URL. Por otra parte, los caracteres que no requieren ser codificados (incluyendo los alfanuméricos) pueden ser codificados dentro de la parte específica del esquema de un URL, ya que no se usarán para ningún propósito reservado. 2.3 Esquemas jerárquicos y enlaces relativos En algunos casos, los URLs se utilizan para localizar recursos que contienen apuntadores a otros recursos. En algunos casos, estos apuntadores se representan como enlaces relativos donde la expresión de la localización del segundo recurso se hace en términos de "en el mismo sitio que este pero con la siguiente ruta relativa". Los enlaces relativos no se describen en este documento. Sin embargo, la utilización de enlaces relativos depende de que el URL original contenga una estructura jerárquica en la que se pueda basar el enlace relativo. Algunos esquemas de URL (tales como el ftp, http, y esquemas de ficheros) contienen nombres que pueden ser considerados jerárquicos; los componentes de la jerarquía se separan con "/". 3. Esquemas específicos La correspondencia entre algunos protocolos estándar y experimentales existentes está descrita en la definición BNF de la sintaxis. A continuación, se presentan unas notas sobre algunos protocolos. Los Berners-Lee, Masinter & McCahill [Pág. 4] RFC 1738 Localizadores Uniformes de Recursos Diciembre 1994 esquemas cubiertos son: ftp Protocolo de Transferencia de ficheros http Protocolo de Transferencia de hipertexto gopher El protocolo Gopher mailto Dirección de correo electrónico news Noticias USENET nntp Noticias USENET utilizando acceso NNTP telnet Referencia a sesiones interactivas wais Servidores de Información de Área Extensa file Nombres de fichero específicos del sistema prospero Servicio de directorio Prospero Otros esquemas pueden ser especificados en futuras especificaciones. La sección 4 de este documento describe como se pueden registrar nuevos esquemas, y muestra una lista con algunos nombres de esquemas que están en desarrollo. 3.1. Sintaxis común del esquema Internet Aunque la sintaxis del resto de los URLs puede variar dependiendo del esquema particular elegido, los esquemas de URL que utilizan directamente protocolos basados en IP para acceder a una máquina determinada de Internet tienen una sintaxis común para los datos específicos del esquema: //:@:/ Se pueden excluir algunas de las siguientes partes, o todas ellas: ":@", ":", ":", y "/". Los datos específicos del esquema comienza con con una doble barra "//" para indicar que cumplen con la sintaxis común del esquema Internet. Los diferentes componentes siguen las siguientes reglas: usuario Un nombre de usuario opcional. Algunos esquemas (por ejemplo, ftp) permiten especificar un nombre de usuario. contraseña Una contraseña opcional. Si está presente, sigue al nombre de usuario separada de él por dos puntos. El nombre de usuario (y la contraseña), si están presentes, van seguidas por el signo de la arroba "@". Dentro de los campos de usuario y contraseña, cualquier signo ":", "@" o "/" debe ir codificado. Berners-Lee, Masinter & McCahill [Pág. 5] RFC 1738 Localizadores Uniformes de Recursos Diciembre 1994 Nótese que un nombre de usuario o contraseña vacíos es distinto de no poner nombre de usuario o contraseña; no hay ninguna forma de especificar una contraseña sin especificar un nombre de usuario. Por ejemplo, tiene el nombre de usuario vacío y ninguna contraseña, no tiene ningún nombre de usuario, mientras que tiene el nombre de usuario "fulanito" y una contraseña vacía. máquina El nombre completo con dominio de una máquina de una red, o su dirección IP como conjunto de cuatro grupos de números decimales separados por ".". Los nombres completos con dominio son de la forma descrita en la Sección 3.5 del RFC 1034 [13] y la Sección 2.1 del RFC 1123 [5]: una secuencia de etiquetas de dominio separadas por ".", cada una de ellas comienza y termina con un carácter alfanumérico y con la posibilidad de contener los caracteres "-". La etiqueta de dominio de más a la derecha nunca comenzará con un dígito, lo cual distingue sintácticamente todos los nombres de dominio de las direcciones IP. puerto El número de puerto al que se conecta. La mayoría de los esquemas designan protocolos que tienen un número de puerto por defecto. Opcionalmente se puede proporcionar otro número de puerto, en decimal, separado de la máquina por un signo de dos puntos. Si el puerto es omitido, también lo son los dos puntos. ruta-del-url El resto del localizador consiste en datos específicos del esquema y se conoce como la "ruta-del-url". Suministra los detalles de cómo el recurso especificado puede ser accedido. Nótese que la barra "/" entre la máquina (o el puerto) y la ruta-del-url NO es parte de la ruta-del-url. La sintaxis de la ruta-del-url depende del esquema que se esté usando, que determina la manera en que es interpretado. 3.2. FTP El esquema de URL de FTP se utiliza para designar archivos y directorios en servidores de Internet accesibles usando el protocolo FTP (RFC959). Un URL FTP sigue la sintaxis descrita en la Sección 3.1. Si el : es omitido, el puerto por defecto es 21. 3.2.1. Nombre y Contraseña FTP Berners-Lee, Masinter & McCahill [Pág. 6] RFC 1738 Localizadores Uniformes de Recursos Diciembre 1994 Deben suministrarse un nombre de usuario y una contraseña; se usan en los comandos ftp "USER" y "PASS" después de que primero se haya hecho la conexión al servidor de FTP. Si no se suministra el nombre de usuario o la contraseña y se pide uno por parte del servidor de FTP, se usan las convenciones para el FTP "anónimo", como sigue: El nombre de usuario que se suministra es "anonymous". La contraseña suministrada es la dirección de e-mail del usuario final que accede al recurso. Si el URL proporciona un nombre de usuario, pero no una contraseña, y el servidor remoto pide una contraseña, el programa que interpreta el URL FTP debería pedir una al usuario. 3.2.2. Ruta-del-url FTP La ruta-del-url de un URL FTP tiene la siguiente sintaxis: //...//;tipo= Donde desde hasta y son cadenas de caracteres (posiblemente codificadas) y es uno de los caracteres "a", "i", o "d". La parte ";tipo=" puede omitirse. Las partes y pueden estar vacías. Toda la ruta-del-url entera puede omitirse, incluyendo la barra "/" que lo delimita del prefijo que contiene el usuario, la contraseña, el servidor y el puerto. La ruta-del-url se interpreta como una serie de comandos FTP como sigue: Cada uno de los elementos se pasa, secuencialmente, como argumento a un comando CWD (cambiar directorio de trabajo). Si el código-tipo es "d", lanza un comando NLST (lista de nombres) con como argumento, e interpreta los resultados como el listado de archivos de un directorio. En cualquier otro caso, ejecuta un comando TYPE con como argumento, y accede al archivo cuyo nombre es (por ejemplo, usando el comando RETR.) Dentro de un nombre o componente CWD, los caracteres "/" y ";" están reservados y deben ser codificados. Los componentes se decodifican antes de ser utilizados en el protocolo FTP. En particular, si la secuencia FTP apropiada para acceder a un archivo particular requiere suministrar una cadena que contiene una "/" como argumento Berners-Lee, Masinter & McCahill [Pág. 7] RFC 1738 Localizadores Uniformes de Recursos Diciembre 1994 de un comando CWD o RETR, es necesario codificar cada "/". Por ejemplo, el URL se interpreta como conectar por FTP a "servidor.dom", validarse en él como "minombre" (dando una contraseña si se le solicita), y después ejecutar "CWD /etc" y después "RETR motd". Esto tiene un significado diferente de que sería "CWD etc" y después "RETR motd"; el "CWD" inicial podría ejecutarse relativo al directorio por defecto de "minombre". Por otro lado, , haría "CWD " con el argumento nulo, después "CWD etc", y después "RETR motd". Los URLs FTP pueden utilizarse también para otras operaciones, por ejemplo, es posible actualizar un fichero en un servidor de ficheros remoto, o averiguar información sobre él de un listado del directorio. El mecanismo para hacer eso no se describe aquí. 3.2.3. El Código de Tipo FTP es Opcional Toda la parte ;tipo= de un URL FTP es opcional. Si se omite, el programa cliente que interpreta el URL debe deducir el modo más apropiado a usar. En general, el tipo de los datos contenidos en un fichero, puede deducirse solo de su nombre, es decir, del sufijo del nombre; el código de tipo apropiado para ser usado para transferir un fichero puede ser entonces deducido de los datos que contiene el fichero. 3.2.4. Jerarquía Para algunos sistemas de archivo, la "/" utilizada para denotar la estructura jerárquica del URL corresponde al delimitador usado para construir una jerarquía de nombres de fichero, y así, el nombre de fichero parecerá similar a la ruta del URL. Esto NO significa que el URL sea un nombre de fichero de Unix. 3.2.5. Optimización Los clientes que acceden a recursos a través de FTP pueden emplear heurísticas adicionales para optimizar la interacción. Para algunos servidores FTP, por ejemplo, podría ser razonable mantener abierta la conexión de control mientras se accede a múltiples URLs del mismo servidor. Sin embargo, no hay un modelo jerárquico común para el protocolo FTP, así que si se da un comando de cambio de directorio, en general es imposible decidir qué secuencia debería darse para navegar a otro directorio para un segundo acceso, si las rutas son diferentes. El único algoritmo fiable es desconectar y restablecer la conexión de control. Berners-Lee, Masinter & McCahill [Pág. 8] RFC 1738 Localizadores Uniformes de Recursos Diciembre 1994 3.3. HTTP El esquema de URL HTTP se utiliza para designar recursos de Internet accesibles usando HTTP (Protocolo de Transferencia de Hipertexto). El protocolo HTTP se encuentra especificado en otro sitio. Esta especificación describe únicamente la sintaxis de los URLs HTTP. Un URL HTTP tiene la forma: http://:/? donde y son como se ha descrito en la Sección 3.1. Si : es omitido, el puerto por defecto es 80. No se permite nombre de usuario ni contraseña. es un selector HTTP, y es una cadena de petición. La es opcional, al igual que la y su "?" precedente. Si no están presentes ni ni , la "/" puede omitirse también. Dentro de la y la , los caracteres "/", ";", "?" están reservados. El carácter "/" puede usarse en HTTP para designar una estructura jerárquica. 3.4. GOPHER El esquema de URL Gopher se utiliza para designar recursos de Internet accesibles usando el protocolo Gopher. El protocolo Gopher base se describe en el RFC 1436 y contempla elementos y colecciones de elementos (directorios). El protocolo Gopher+ es un conjunto de extensiones compatibles hacia arriba del protocolo Gopher base y se describe en [2]. Gopher+ contempla la asociación de conjuntos arbitrarios de atributos y representaciones de datos alternativas con elementos Gopher. Los URLs Gopher sirven para los elementos y atributos de elementos tanto de Gopher como de Gopher+. 3.4.1. Sintaxis de los URLs Gopher Un URL Gopher tiene la forma: gopher://:/ donde es una de: %09 %09%09 Berners-Lee, Masinter & McCahill [Pág. 9] RFC 1738 Localizadores Uniformes de Recursos Diciembre 1994 Si se omite :, el puerto por defecto es 70. es un campo de un solo carácter para denotar el tipo Gopher del recurso al que se refiere el URL. La puede estar también vacía, en cuyo caso la "/" delimitadora es también opcional y el toma el valor por defecto "1". es la cadena de selector Gopher. En el protocolo Gopher, las cadenas de selectores Gopher son una secuencia de octetos que pueden contener cualquier octeto excepto el 09 en hexadecimal (HT en US-ASCII o tabulador) 0A en hexadecimal (carácter LF en US-ASCII), y 0D (carácter CR en US-ASCII). Los clientes Gopher especifican qué elemento hay que recuperar enviando la cadena de selector Gopher a un servidor Gopher. Dentro de la , no hay ningún carácter reservado. Nótese que algunas cadenas de Gopher comienzan con una copia del carácter , en cuyo caso ese carácter aparecerá dos veces consecutivas. La cadena de selector Gopher puede ser una cadena vacía; así es como los clientes de Gopher se refieren al directorio de más alto nivel de un servidor Gopher. 3.4.2. Especificando URLs para Motores de Búsqueda Gopher Si el URL se refiere a una búsqueda que se va someter a un motor de búsqueda Gopher, el selector va seguido por un tabulador codificado (%09) y la cadena de búsqueda. Para someter una búsqueda a un motor de búsqueda Gopher, el cliente Gopher envía la cadena del (tras decodificarla), un tabulador, y la cadena de búsqueda al servidor Gopher. 3.4.3. Sintaxis de URL para elementos de Gopher+ Los URLs para elementos de Gopher+ tienen un segundo tabulador codificado (%09) y una cadena de Gopher+. Nótese que en este caso, debe suministrarse la cadena %09, aunque el elemento de puede ser una cadena vacía. La se usa para representar la información requerida para recuperar un elemento Gopher+. Los elementos Gopher+ pueden tener vistas alternativas, conjuntos arbitrarios de atributos, y pueden tener formularios electrónicos asociados a ellos. Para recuperar los datos asociados con un URL Gopher+, un cliente se conectará al servidor y enviará el selector Gopher, seguido de un tabulador y la cadena de búsqueda (que puede estar vacía), seguido de un tabulador y los comandos Gopher+. Berners-Lee, Masinter & McCahill [Pág. 10] RFC 1738 Localizadores Uniformes de Recursos Diciembre 1994 3.4.4. Representación de datos Gopher+ por defecto Cuando un servidor Gopher devuelve un listado de directorio a un cliente, los elementos Gopher+ están marcados o con un "+" (que denota elementos Gopher+) o un "?" (que denota elementos Gopher+ que tienen un formulario +ASK asociado a ellos). Un URL Gopher con una cadena Gopher+ formada solo por un "+" se refiere a un vista por defecto (representación de datos) del elemento, mientras que una cadena Gopher+ que contiene solo un "?" se refiere a un elemento con un formulario electrónico Gopher asociado a él. 3.4.5. Elementos Gopher+ con formularios electrónicos Los elementos Gopher+ que tienen un +ASK asociados a ellos (es decir, elementos Gopher+ marcados con una "?") requieren que el cliente busque el atributo +ASK del elemento para obtener la definición del formulario, y a continuación consulte al usuario para que rellene el formulario y devuelva la respuesta del usuario al mismo tiempo que la cadena del selector para recuperar el elemento. Los clientes Gopher+ saben como hacer esto, pero dependen de la marca "?" en la descripción del elemento Gopher+ para conocer cuándo tratar este caso. La "?" se usa en la cadena Gopher+ para ser consistente con el uso de este símbolo del protocolo Gopher+. 3.4.6. Colecciones de atributos de elementos Gopher+ Para referirse a los atributos Gopher+ de un elemento, las cadenas Gopher+ de los URLs de Gopher consisten en "!" o "$". "!" hace referencia a todos los atributos de un elemento Gopher+. "$" hace referencia todos los atributos de todos los elementos de un directorio Gopher. 3.4.7. Referencias a atributos Gopher+ específicos Para hacer referencia a un atributo específico, la parte del URL es "!" o "$". Por ejemplo, para referirse al atributo que contiene el resumen (abstract) de un elemento, la cadena_gopher+ sería "!+ABSTRACT". Para hacer referencia a varios atributos, la cadena_gopher+ está formada por los nombres de los atributos separados por espacios codificados. Por ejemplo, "!+ABSTRACT%20+SMELL" se refiere a los atributos +ABSTRACT y +SMELL de un elemento. 3.4.8. Sintaxis de URL para vistas alternativas de Gopher+ Gopher+ permite opcionalmente la representación alternativa de los Berners-Lee, Masinter & McCahill [Pág. 11] RFC 1738 Localizadores Uniformes de Recursos Diciembre 1994 datos de los elementos (vistas alternativas): Para recuperar una vista alternativa de Gopher+, el cliente manda la vista y el identificador de lenguaje apropiados (que se encuentran en el atributo +VIEW del elemento). Para referirse a una vista alternativa de Gopher+ específica, la cadena del URL Gopher+ tendría la forma: +%20 Por ejemplo, la cadena Gopher+ "+application/postscript%20Es_ES" se refiere al vista alternativa postscript en español de un elemento Gopher+. 3.4.9. Sintaxis de URL para formularios electrónicos de Gopher+ La cadena_gopher+ para un URL que se refiere a un elemento al que hace referencia un formulario electrónico de Gopher+ (un bloque ASK) rellenado con valores específicos es una versión codificada de lo que el cliente envía al servidor. La cadena_gopher+ es de la forma: +%091%0D%0A+-1%0D%0A%0D%0A%0D%0A.%0D%0A Para recuperar este elemento, el cliente Gopher envía: +1 +-1 . al servidor Gopher. 3.5. MAILTO El esquema de URL mailto se utiliza para designar la dirección de correo de Internet de un individuo o servicio. A parte de la dirección de correo de Internet, no hay información adicional presente o implicada. Un URL mailto tiene la forma: mailto: donde es (la codificación de) una especificación de dirección, como se define en el RFC 822 [6]. Dentro de los URLs mailto, no hay caracteres reservados. Nótese que el signo de porcentaje ("%") es de uso común en las direcciones RFC 822 y debe ser codificado. Berners-Lee, Masinter & McCahill [Pág. 12] RFC 1738 Localizadores Uniformes de Recursos Diciembre 1994 Al contrario que muchos URLs, el esquema mailto no representa ningún objeto de datos para ser accedido directamente; no tiene sentido en lo de que designa un objeto. Tiene un uso diferente del tipo message/external-body de MIME. 3.6. NEWS El esquema NEWS se utiliza para referirse o a grupos de noticias o a artículos individuales de las noticias de USENET, tal como se especifica en el RFC 1036. Un URL de news tiene una de estas dos formas: news: news: Un es un nombre jerárquico delimitado por puntos, tal como "comp.infosystems.www.misc". Un corresponde al Message-ID de la sección 2.1.5 del RFC 1036, sin los delimitadores "<" y ">"; tiene la forma <único>@. Un identificador de mensaje puede distinguirse de un nombre de grupo de noticias por la presencia del carácter de la arroba "@". No hay más caracteres reservados dentro de los componentes de un URL de news. Si es "*" (como en ), se usa para referirse a "todos los grupos de noticias disponibles". Los URLs de news son inútiles en sí mismos, no contienen suficiente información para localizar un solo recurso, sino más bien al contrario, son independientes de la localización. 3.7. NNTP El esquema de URL nntp es un método alternativo de hacer referencia a artículos de noticias, útil para especificar artículos de noticias de servidores NNTP (RFC 977). Un URL nntp tiene la forma: nntp://:// donde y son como los descritos en la Sección 3.1. Si : se omite, el puerto por defecto es 119. El es el nombre del grupo, mientras que el es el identificador numérico del artículo dentro de ese grupo de noticias. Berners-Lee, Masinter & McCahill [Pág. 13] RFC 1738 Localizadores Uniformes de Recursos Diciembre 1994 Nótese que, aunque los URLs nntp: especifican una localización única para el recurso que es el artículo, la mayoría de los servidores NNTP que hay hoy día en Internet están configurados para permitir el acceso únicamente a clientes locales, y por eso los URLs nntp no designan recursos accesibles globalmente. Por ello, se prefiere la forma de URL news: como forma de identificar artículos de grupos de noticias. 3.8. TELNET El esquema de URL Telnet se usa para designar servicios interactivos a los que se puede acceder con el protocolo Telnet. Un URL telnet es de la forma: telnet://:@:/ tal como lo especificado en la Sección 3.1. El carácter "/" del final puede omitirse. Si : se omite, el puerto por defecto es 23. La : puede omitirse, así como toda la parte completa de :. Este URL no designa un objeto de datos, sino un servicio interactivo. Los servicios interactivos remotos varían enormemente en la forma en que permiten inicios de sesión remotos; en la práctica, el y la que se suministran son solo sugerencias: los clientes que acceden a un URL telnet solo aconsejan al usuario del nombre de usuario y contraseña propuestos. 3.9. WAIS El esquema de URL WAIS se usa para designar bases de datos WAIS, búsquedas, o documentos individuales disponibles en una base de datos WAIS. La descripción de WAIS se hace en [7]. El protocolo WAIS está descrito en el RFC 1625 [17]; Aunque el protocolo WAIS está basado en Z39.50-1988, el esquema de URL WAIS no está pensado para su uso con servicios arbitrarios de Z39.50. Un URL WAIS tiene cualquiera de las siguientes formas: wais://:/ wais://:/? wais://:/// donde y son como los descritos en la Sección 3.1. Si se omite, el puerto por defecto es 210. La primera forma designa una base de datos WAIS que está disponible para realizar búsquedas en ella. La segunda forma designa una búsqueda en Berners-Lee, Masinter & McCahill [Pág. 14] RFC 1738 Localizadores Uniformes de Recursos Diciembre 1994 particular. es el nombre de la base de datos WAIS que es interrogada. La tercera forma designa un documento particular dentro de una base de datos WAIS para su recuperación. En esta forma es la designación WAIS del tipo del objeto. Muchas implementaciones de WAIS requieren que el cliente sepa el "tipo" de un objeto antes de su recuperación, el tipo que devuelto junto con el identificador interno del objeto en el resultado de la búsqueda. El se incluye en el URL con el fin de permitir al cliente interpretar la información adecuada del URL para recuperar el documento. La de un URL WAIS consiste en el identificador de documento WAIS, codificado si es necesario usando el método descrito en la Sección 2.2. El identificador de documento WAIS debería ser tratado de forma opaca; que solo pueda ser descompuesto por el servidor que lo generó. 3.10. FILES El esquema de URL file se usa para designar ficheros accesibles en un computador en particular. Este esquema, al contrario que la mayoría de otros esquemas de URL, no designa un recurso que es universalmente accesible por Internet. Un URL file tiene la forma: file:/// donde es el nombre completo con dominio del sistema en el que la es accesible, y es una ruta jerárquica de directorios de la forma //.../. Por ejemplo, un fichero VMS DISK$USER:[MIS.NOTAS]NOTA123456.TXT podría convertirse en Como caso especial, puede ser la cadena "localhost" o la cadena vacía; esto se interpreta como 'la máquina desde la que se interpreta el URL'. El esquema de URL file es poco corriente porque no define un protocolo de Internet o método de acceso a tales ficheros; como tal, su utilidad en protocolos de red entre servidores es limitada. Berners-Lee, Masinter & McCahill [Pág. 15] RFC 1738 Localizadores Uniformes de Recursos Diciembre 1994 3.11. PROSPERO El esquema de URL Prospero se utiliza para designar recursos a los que se accede a través del Servicio de Directorio Prospero. El protocolo Prospero se encuentra descrito en [14]. Un URL Prospero tiene la forma: prospero://:/;= donde y son como se ha descrito en la Sección 3.1. Si se omite :, el puerto por defecto es 1525. No se permite nombre de usuario o contraseña. El es el nombre del objeto específico del servidor en el protocolo Prospero, convenientemente codificado. Este nombre es opaco y lo interpreta el servidor Prospero. El punto y coma ";" está reservado y no puede aparecer sin comillas en . Los URLs de Prospero se interpretan conectándose a un servidor de directorio Prospero en la máquina y puerto especificados para determinar el método de acceso adecuado para un recurso, los cuales podrían representarse como varios URLs diferentes. Los enlaces Prospero externos se representan como URLs del método de acceso subyacente y no se representan como URLs de Prospero. Nótese que puede aparecer una barra "/" en sin comillas, y la aplicación puede asumir que no es significativa. Aunque las barras pueden indicar una estructura jerárquica en el servidor, tal estructura no está garantizada. Nótese que muchos comienzan con una barra, en cuyo caso la máquina o el puerto irán seguidos por una doble barra: la barra de la sintaxis del URL, seguida por la barra inicial del . (Por ejemplo, designa un de "/pros/nombre".) De manera adicional, después del , se pueden especificar campos y valores opcionales asociados con el enlace Prospero como parte del URL. Cuando está presente, cada par campo/valor se separa uno de otro y del resto del URL con un ";" (punto y coma). El nombre del campo y su valor se separan con un "=" (signo de igualdad). Si están presentes, estos campos sirven para identificar el objetivo del URL. Por ejemplo, el campo OBJECT-VERSION puede especificarse para identificar la versión de un objeto. 4. REGISTRO DE NUEVOS ESQUEMAS Se puede introducir un nuevo esquema definiendo una relación con una Berners-Lee, Masinter & McCahill [Pág. 16] RFC 1738 Localizadores Uniformes de Recursos Diciembre 1994 sintaxis de URL que se ajuste, usando un nuevo prefijo. Se pueden utilizar URLs para esquemas experimentales con un acuerdo entre las partes. Los nombres de esquema que comienzan con los caracteres "x-" están reservados con propósitos experimentales. La Autoridad de Números Asignados de Internet (IANA) mantendrá un registro de esquemas de URL. Cualquier nuevo esquema de URL que se proponga debe incluir una definición de un algoritmo para acceder a los recursos de ese esquema, y la sintaxis para representar tal esquema. Los esquemas de URL deben tener utilidad y operabilidad demostrables. Una forma de proporcionar tal demostración es a través de una pasarela que proporcione objetos del nuevo esquema para clientes que usen un protocolo ya existente. Si el nuevo esquema no localiza recursos que son objetos de datos, las propiedades de los nombres en el nuevo espacio deben ser definidas claramente. Los esquemas nuevos deberían tratar de seguir las mismas convenciones sintácticas que los esquemas existentes, cuando sea apropiado. Se recomienda igualmente que, cuando un protocolo permite el acceso por URL, el software del cliente esté previsto para ser configurado para usar localizadores específicos de pasarelas para acceder indirectamente al nuevo esquema de nombres. Los siguientes esquemas han sido propuestos varias veces, pero este documento no define su sintaxis o uso por el momento. Se ha sugerido que el IANA reserve sus nombres de esquema para definiciones futuras: afs Nombres globales de ficheros Andrew File System. mid Identificadores de mensaje para correo electrónico. cid Identificadores de contenido para partes de cuerpo MIME. nfs Nombres de fichero del Sistema de Ficheros en Red (NFS). tn3270 Sesiones interactivas de emulación 3270. mailserver Acceso a datos disponibles en servidores de correo. z39.50 Acceso a servicios ANSI z39.50. 5. BNF para esquemas de URL específicos Esta es una descripción tipo BNF de la sintaxis del Localizador Uniforme de Recursos, utilizando las convenciones del RFC822, excepto por que "|" se utiliza para designar alternativas, y los corchetes [] se usan alrededor de elementos repetidos u opcionales. Brevemente, los literales se entrecomillan con "", los elementos opcionales se encierran en [corchetes], y los elementos pueden ir precedidos con * para designar n o más repeticiones del elemento siguiente; el valor por defecto de n es 0. Berners-Lee, Masinter & McCahill [Pág. 17] RFC 1738 Localizadores Uniformes de Recursos Diciembre 1994 ; La forma genérica de un URL es: urlgenerico = esquema ":" parteesquema ; Aquí se encuentran definidos algunos esquemas predefinidos ; Se pueden registrar otros esquemas nuevos en IANA url = urlhttp | urlftp | urlnews | urlnntp | urltelnet | urlgopher | urlwais | urlmailto | urlfile | urlprospero | otrourl ; los nuevos esquemas siguen la sintaxis general otrourl = urlgenerico ; el esquema está en minúsculas; los interpretes deberían ignorar ; las mayúsculas/minúsculas esquema = 1*[ minúscula | dígito | "+" | "-" | "." ] parteesquema = *xchar | parteesquema-ip ; partes de esquemas de URL para protocolos basados en ip: parteesquema-ip = "//" login [ "/" rutaurl ] login = [ usuario [ ":" contraseña ] "@" ] puertomáquina puertomáquina = máquina [ ":" puerto ] máquina = nombremáquina | númeromáquina nombremáquina = *[ etiquetadominio "." ] etiquetasup etiquetadominio = letradígito | letradígito *[ letradígito | "-" ] letradígito etiquetasup = letra | letra *[ letradígito | "-" ] letradígito letradígito = letra | dígito númeromáquina = dígitos "." dígitos "." dígitos "." dígitos puerto = dígitos usuario = *[ uchar | ";" | "?" | "&" | "=" ] contraseña = *[ uchar | ";" | "?" | "&" | "=" ] rutaurl = *xchar ; depende del protocolo ver sección 3.1 ; Esquemas predefinidos: ; FTP (ver también RFC959) urlftp = "ftp://" login [ "/" rutaf [ ";type=" tipoftp ]] rutaf = fsegmento *[ "/" segmentof ] segmentof = *[ uchar | "?" | ":" | "@" | "&" | "=" ] tipoftp = "A" | "I" | "D" | "a" | "i" | "d" Berners-Lee, Masinter & McCahill [Pág. 18] RFC 1738 Localizadores Uniformes de Recursos Diciembre 1994 ; FILE urlfile = "file://" [ máquina | "localhost" ] "/" rutaf ; HTTP urlhttp = "http://" puertomáquina [ "/" rutah [ "?" búsqueda ]] rutah = segmentoh *[ "/" segmentoh ] segmentoh = *[ uchar | ";" | ":" | "@" | "&" | "=" ] búsqueda = *[ uchar | ";" | ":" | "@" | "&" | "=" ] ; GOPHER (ver también RFC1436) urlgopher = "gopher://" puertomáquina [ / [ tipog [ selector [ "%09" búsqueda [ "%09" cadena_gopher+ ] ] ] ] ] tipog = xchar selector = *xchar cadena_gopher+ = *xchar ; MAILTO (ver también RFC822) urlmailto = "mailto:" dircodif822 dircodif822 = 1*xchar ; definida con detalle en RFC822 ; NEWS (ver también RFC1036) urlnew = "news:" partegrupo partegrupo = "*" | grupo | artículo grupo = letra *[ letra | dígito | "-" | "." | "+" | "_" ] artículo = 1*[ uchar | ";" | "/" | "?" | ":" | "&" | "=" ] "@" máquina ; NNTP (ver también RFC977) urlnntp = "nntp://" puertomáquina "/" grupo [ "/" dígitos ] ; TELNET urltelnet = "telnet://" login [ "/" ] ; WAIS (ver también RFC1625) urlwais = basedatoswais | índicewais | docwais basedatoswais = "wais://" puertomáquina "/" basedatos índicewais = "wais://" puertomáquina "/" basedatos "?" búsqueda docwais = "wais://" puertomáquina "/" basedatos "/" tipow "/" rutaw Berners-Lee, Masinter & McCahill [Pág. 19] RFC 1738 Localizadores Uniformes de Recursos Diciembre 1994 basedatos = *uchar tipow = *uchar rutaw = *uchar ; PROSPERO urlprospero = "prospero://" puertomáquina "/" rutap *[ especcampo ] rutap = segmentop *[ "/" segmentop ] segmentop = *[ uchar | "?" | ":" | "@" | "&" | "=" ] especcampo = ";" nombrecampo "=" valorcampo nombrecampo = *[ uchar | "?" | ":" | "@" | "&" ] valorcampo = *[ uchar | "?" | ":" | "@" | "&" ] ; Definiciones varias minúscula = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z" mayúscula = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z" letra = minúscula | mayúscula dígito = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" seguro = "$" | "-" | "_" | "." | "+" extra = "!" | "*" | "'" | "(" | ")" | "," nacional = "{" | "}" | "|" | "\" | "^" | "~" | "[" | "]" | "`" puntuación = "<" | ">" | "#" | "%" | <"> reservado = ";" | "/" | "?" | ":" | "@" | "&" | "=" hexadecimal = dígito | "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" | "e" | "f" escape = "%" hexadecimal hexadecimal noreservado = letra | dígito | seguro | extra uchar = noreservado | escape xchar = noreservado | reservado | escape dígitos = 1*dígito 6. Consideraciones de Seguridad El esquema de URL no supone en sí mismo un riesgo de seguridad. Los usuarios deberían estar advertidos de que en general, no hay garantía de que un URL que una vez apunta a un objeto dado continúe Berners-Lee, Masinter & McCahill [Pág. 20] RFC 1738 Localizadores Uniformes de Recursos Diciembre 1994 haciéndolo, y que incluso al cabo de algún tiempo apunte a un objeto diferente debido al movimiento de objetos entre servidores. Un riesgo de seguridad relacionado con los URLs es que a veces es posible construir un URL tal que al tratar de realizar una operación idempotente inofensiva, tal como la recuperación de un objeto, causará que se produzca una operación remota posiblemente dañina. Un URL inseguro se construye típicamente especificando un número de puerto distinto al que está reservado para el protocolo de red en cuestión. El cliente inconscientemente contacta con un servidor que de hecho está ejecutando un protocolo diferente. El contenido del URL tiene instrucciones que cuando son interpretadas según este otro protocolo causa una operación inesperada. Un ejemplo fue el uso de URLs gopher para hacer que un mensaje ofensivo sea enviado a través de un servidor SMTP. Se debería tener precaución cuando se utilice cualquier URL que especifique un número de puerto distinto al puerto por defecto del protocolo, especialmente cuando es un número dentro del espacio reservado. Debería tenerse cuidado cuando los URLs contengan embebidos delimitadores codificados para un protocolo dado (por ejemplo, los caracteres CR y LF para protocolos telnet) y que estos no sean descodificados antes de la transmisión. Esto violaría el protocolo pero podría utilizarse para simular una operación o parámetro extra, y de nuevo causar que se ejecute una operación inesperada y posiblemente dañina. La utilización de URLs que contengan contraseñas que deberían ser secretas, está totalmente desaconsejado. Agradecimientos Este documento se basa en el diseño básico de la WWW (RFC 1630) y en el debate de estos temas por muchas personas de la red. El debate fue estimulado particularmente por los artículos de Clifford Lynch, Brewster Kahle [10] y Wengyk Yeong [18]. Se incorporaron contribuciones de John Curran, Clifford Neuman, Ed Vielmetti y posteriormente el IETF URL BOF y el grupo de trabajo URI. Más recientemente, las cuidadosas lecturas y comentarios de Dan Connolly, Ned Freed, Roy Fielding, Guido van Rossum, Michael Dolan, Bert Bos, John Kunze, Olle Jarnefors, Peter Svanberg y muchos otros que han ayudado a refinar este RFC. APÉNDICE: Recomendaciones para URLs en Contexto. Los URIs, incluyendo los URLs, están pensados para ser transmitidos a través de protocolos que proporcionan un contexto para su Berners-Lee, Masinter & McCahill [Pág. 21] RFC 1738 Localizadores Uniformes de Recursos Diciembre 1994 interpretación. En algunos casos, será necesario distinguir los URLs de otras posibles estructuras de datos en una estructura sintáctica. En este caso, se recomienda que los URLs vayan precedidos de un prefijo consistente en los caracteres "URL:". Por ejemplo, este prefijo puede se usado para distinguir URLs de otras clases de URIs. De forma adicional, hay muchas ocasiones en las que los URLs se incluyen en otros tipos de texto; ejemplos sobre esto incluyen el correo electrónico, mensajes de noticias USENET, o impresos sobre papel. En tales casos, es conveniente tener un delimitador sintáctico que haga lo propio con el URL y lo separe del resto de texto, y en particular de los signos de puntuación que podrían ser confundidos con parte del URL. Para este propósito, se recomienda usar los signos de menor y mayor que ("<" y ">"), junto con el prefijo "URL:" para marcar los límites del URL. Estos delimitadores no forman parte del URL y no deberían usarse en contextos en los que ya esté especificado algún tipo de delimitador. En el caso en que un identificador de fragmento/enlace esté asociado con un URL (a continuación de un "#"), el identificador debería estar también situado entre los signos de menor y mayor que. En algunos casos, puede ser necesario añadir espacios en blanco adicionales (espacios, retornos de línea, tabuladores, etc.) para partir URLs muy largos en varias líneas. Estos espacios en blanco deberían ser ignorados cuando se extraiga el URL. No debería introducirse ningún espacio en blanco después de un carácter de guión ("-"). Como algunas imprentas e impresoras pueden (erróneamente) introducir un guión al final de una línea cuando se salta de línea, el intérprete de un URL que contenga un salto de línea inmediatamente después de un guión debería ignorar todo espacio en blanco no codificado alrededor del salto de línea, y debería tener en cuenta que el guión puede ser o no parte del URL. Ejemplos: Sí, Jim, lo he encontrado en pero seguramente lo puedes obtener también de . Fíjate en el aviso en . Referencias Berners-Lee, Masinter & McCahill [Pág. 22] RFC 1738 Localizadores Uniformes de Recursos Diciembre 1994 [1] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey, D., and B. Alberti, "The Internet Gopher Protocol (a distributed document search and retrieval protocol)", RFC 1436, University of Minnesota, March 1993. [2] Anklesaria, F., Lindner, P., McCahill, M., Torrey, D., Johnson, D., and B. Alberti, "Gopher+: Upward compatible enhancements to the Internet Gopher protocol", University of Minnesota, July 1993. [3] Berners-Lee, T., "Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web", RFC 1630, CERN, June 1994. [4] Berners-Lee, T., "Hypertext Transfer Protocol (HTTP)", CERN, November 1993. [5] Braden, R., Editor, "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, IETF, October 1989. [6] Crocker, D. "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, April 1982. [7] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., Wang, R., Sui, J., and M. Grinbaum, "WAIS Interface Protocol Prototype Functional Specification", (v1.5), Thinking Machines Corporation, April 1990. [8] Horton, M. and R. Adams, "Standard For Interchange of USENET Messages", RFC 1036, AT&T Bell Laboratories, Center for Seismic Studies, December 1987. [9] Huitema, C., "Naming: Strategies and Techniques", Computer Networks and ISDN Systems 23 (1991) 107-110. [10] Kahle, B., "Document Identifiers, or International Standard Book Numbers for the Electronic Age", 1991. Berners-Lee, Masinter & McCahill [Pág. 23] RFC 1738 Localizadores Uniformes de Recursos Diciembre 1994 [11] Kantor, B. and P. Lapsley, "Network News Transfer Protocol: A Proposed Standard for the Stream-Based Transmission of News", RFC 977, UC San Diego & UC Berkeley, February 1986. [12] Kunze, J., "Functional Requirements for Internet Resource Locators", Work in Progress, December 1994. [13] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, USC/Information Sciences Institute, November 1987. [14] Neuman, B., and S. Augart, "The Prospero Protocol", USC/Information Sciences Institute, June 1993. [15] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, USC/Information Sciences Institute, October 1985. [16] Sollins, K. and L. Masinter, "Functional Requirements for Uniform Resource Names", RFC 1737, MIT/LCS, Xerox Corporation, December 1994. [17] St. Pierre, M, Fullton, J., Gamiel, K., Goldman, J., Kahle, B., Kunze, J., Morris, H., and F. Schiettecatte, "WAIS over Z39.50-1988", RFC 1625, WAIS, Inc., CNIDR, Thinking Machines Corp., UC Berkeley, FS Consulting, June 1994. [18] Yeong, W. "Towards Networked Information Retrieval", Technical report 91-06-25-01, Performance Systems International, Inc. , June 1991. [19] Yeong, W., "Representing Public Archives in the Directory", Work in Progress, November 1991. [20] "Coded Character Set -- 7-bit American Standard Code for Information Interchange", ANSI X3.4-1986. Direcciones de los Editores Berners-Lee, Masinter & McCahill [Pág. 24] RFC 1738 Localizadores Uniformes de Recursos Diciembre 1994 Tim Berners-Lee World-Wide Web project CERN, 1211 Geneva 23, Switzerland Phone: +41 (22)767 3755 Fax: +41 (22)767 7155 EMail: timbl@info.cern.ch Larry Masinter Xerox PARC 3333 Coyote Hill Road Palo Alto, CA 94034 Phone: (415) 812-4365 Fax: (415) 812-4333 EMail: masinter@parc.xerox.com Mark McCahill Computer and Information Services, University of Minnesota Room 152 Shepherd Labs 100 Union Street SE Minneapolis, MN 55455 Phone: (612) 625 1300 EMail: mpm@boombox.micro.umn.edu Traducción al castellano: Oscar Urra Cuairán EMail: oscaruc@teleline.es Berners-Lee, Masinter & McCahill [Pág. 25]