uri

URI(7)                   Manual del Programador de Linux                  URI(7)



NOMBRE
       uri, url, urn - identificador de recursos uniforme(URI), incluido un URL
       o URN

SINOPSIS
       URI = [ absolutaURI | relativaURI ] [ "#" fragmento ]

       absolutoURI = esquema ":" ( parte_jerarquica | parte_opaca )

       relativoURI = ( camino_red | camino_absoluto | camino_relativo ) [ "?" pregunta ]

       esquema = "http" | "ftp" | "gopher" | "mailto" | "news" | "telnet" |
                  "file" | "man" | "info" | "whatis" | "ldap" | "wais" | ...

       parte_jerarquica = ( camino_red | camino_absoluto ) [ "?" pregunta ]

       camino_red = "//" autoridad [ camino_absoluto ]

       camino_absoluto = "/"  segmentos_camino

       camino_relativo = segmento_relativo [ camino_absoluto ]

DESCRIPCIÓN
       Un Identificador de Recursos Uniforme (URI) es una cadena de caracteres
       corta que identifica un recurso abstracto o físico (por ejemplo, una
       página web). Localizador de Recursos Uniforme (URL) es un URI que
       identifica un recurso por su mecanismo de acceso primario (por ejemplo,
       su ubicación de), antes que por su nombre o algún otro atributo del
       recurso. Un Nombre de Recurso Uniforme (URN) es un URI que debe ser
       globalmente único y permanecer aun cuando el recurso deja de existir o
       pasa a ser inaccesible.

       Los URIs son la forma estándar de nombrar los destinos de los
       hiperenlaces para herramientas tales como los navegadores web. La cadena
       "http://www.kernel.org" es un URL (y también un URI). Algunas personas
       usan el término URL únicamente como sinónimo de URI (aunque técnicamente
       URLs son parte de los URIs).

       Los URIs pueden ser absolutos o relativos. Un identificador absoluto se
       refiere a un recurso independiente del contexto, mientras que un
       identificador relativo apunta a un recurso a través de las diferencias
       del contexto actual. Dentro de una referencia a una ruta relativa, los
       segmentos de ruta completos "." y ".." tienen significados especiales:
       "el nivel jerárquico actual" y "el nivel superior a este nivel
       jerárquico", respectivamente, Tal y como lo hacen los sistemas al estilo
       UNIX. Un segmento de ruta que contiene el carácter ":" no puede ser usado
       como el primer segmento de ruta relativa URI (por ejemplo,
       "esto:aquello"), porque sería erróneo para el esquema de nombres. Preceda
       tales segmentos con ./ ((por ejemplo "./esto:aquello"). Advierta que los
       descendientes de MS-DOS (por ejemplo, Microsoft Windows) reemplazan los
       dos puntos de los nombres de dispositivo con la barra vertical ("|") en
       URIs, por lo que "C:" se convierten en "C|".

       Un identificador de fragmento, si es incluido, se refiere a una porción
       particular identificada (fragmento) de un recurso. El texto después de un
       '#' identifica al fragmento. Un URI que comience con '#' se refiere al
       fragmento del recurso actual.

   Modo de empleo
       Hay diferentes esquemas URI, cada uno con reglas y significados
       adicionales, pero intencionadamente se hacen tan similares como sea
       posible. Por ejemplo, muchos esquemas URL permiten que la autoridad tenga
       el siguiente formato, llamado aquí un servidor_ip (los corchetes muestran
       qué es opcional):

       servidor_ip = [usuario [ : contraseña ] @ ] host [ : puerto]

       Este formato te permite opcionalmente insertar un nombre de usuario, una
       contraseña y/o un número de puerto. El host es el nombre del ordenador
       que hace de anfitrión, y su nombre se puede determinar mediante su DNS o
       una dirección IP (números separados por puntos). Por lo que el URI
       <http://fred:fredcontraseña@example.com:8080/> se introduce en el
       servidor web del anfitrión example.com como fred (usando fredcontraseña)
       usando el puerto 8080. Evite incluir contraseñas en un URI si es posible
       debido a los muchos riesgos para la seguridad que supone tener un
       password escrito. Si el URL facilita el nombre de usuario, pero no la
       contraseña, y el servidor remoto pide la contraseña, el programa que
       interpreta el URL debe requerir una del usuario.

       Aquí hay algunos de los esquemas más comunes usados por sistemas al
       estilo UNIX, los cuales son comprendidos por muchas aplicaciones.
       Advierta que algunas aplicaciones usan URIs y también tienen esquemas
       internos o esquemas especializados. Vea en esas aplicaciones la
       documentación para informarse sobre esos esquemas.

       http - Servidor (HTTP) Web

       http://servidor_ip/ruta
       http://servidor_ip/ruta?cuestion

       Esto es un URL accediendo a un servidor (HTTP) Web. El puerto por defecto
       es 80. Si el camino se refiere a un directorio, el servidor web elegirá
       que devolver. Normalmente, si existe un fichero llamado "index.html" o
       "index.htm" será mostrado, en otro caso, se devuelve una lista de los
       ficheros del directorio actual (con los enlaces apropiados). Un ejemplo
       es <http://lwn.net>.

       Una pregunta se puede dar en el formato obsoleto "isindex", constituido
       por una palabra o frase y no incluyendo un signo igual(=). Una petición
       también se puede dar en un formato más largo "GET", el cual tiene una o
       más peticiones de entrada para el formulario variable=valor separadas por
       el carácter ampersand (&). Advierta que variable puede ser repetida más
       de una vez, piense que son el servidor web y sus aplicaciones los
       encargados de determinar si tiene  significado. Existe una interacción
       desafortunada entre HTML/XML/SGML y este formato. Cuando tales URIs con
       más de una variable se insertan en un documento SGML/XML (incluyendo
       HTML), el ampersand (&) es reescrito como &amp;. Advierta que no todas
       las preguntas tienen este formato. Formatos más largos puede que sean
       demasiado largos para ser almacenados como una URI, por lo que usan un
       mecanismo interactivo diferente llamado POST, el cual no incluye los
       datos en el URI. Véase la especificación del "Common Gateway Interface"
       en ⟨http://www.w3.org/CGI⟩ para más información.

       ftp - Protocolo de Transferencia de Ficheros (FTP)

       ftp://servidor_ip/ruta

       Este es un URL de acceso a ficheros a través del protocolo de
       transferencia de ficheros (FTP). El puerto por defecto (para control) es
       el 21. Si no se incluye un nombre de usuario, se introduce el usuario
       llamado "anonymous", y en ese caso algunos clientes dan como contraseña
       su dirección de correo electrónico. Un ejemplo es
       <ftp://ftp.is.co.za/rfc/rfc1808.txt>.

       gopher - servidor Gopher

       gopher://servidor_ip/selector tipogopher
       gopher://servidor_ip/selector tipogopher%09search
       gopher://servidor_ip/selector tipogopher%09search%09gopher+_cadena

       El puerto por defecto es el 70. tipogopher es un campo de un sólo
       carácter que indica el tipo de recurso Gopher al que se refiere el URL.
       La ruta entera también puede estar vacía, y en tal caso el delimitador
       "/" es también opcional, siendo el tipogopher por defecto "1".

       selector es la cadena de selección Gopher. En el protocolo Gopher, las
       cadenas de selección Gopher son una secuencia de octetos que pueden
       contener cualquier octeto excepto el 09 en hexadecimal (US-ASCII HT o
       tab), 0A en hexadecimal (US-ASCII carácter LF) y 0D (US-ASCII carácter
       CR).

       mailto - dirección de correo

       mailto:dirección_de_correo

       Esto es una dirección de correo electrónico, normalmente de la forma
       nombre@nombrehost. Véase mailaddr(7) para más información acerca del
       formato correcto de la dirección de correo electrónico. Advierta que
       cualquier carácter % debe ser reescrito como %25. Un ejemplo es
       <mailto:dwheeler@dwheeler.com>.

       news - Grupo de noticias o Mensaje de noticias

       news:nombre-gruponoticias
       news:identificador-mensaje

       Un nombre-gruponoticias es un nombre jerárquico delimitado por puntos,
       tal como "comp.infosystems.www.misc". Si <newsgroup-name> es "*" (como
       <news:*>), se usa para referirse a "todos los grupos de noticias
       disponibles". Un ejemplo es <news:comp.lang.ada>.

       Un identificador-mensaje corresponde a Message-ID de IETF RFC 1036,
       ⟨http://www.ietf.org/rfc/rfc1036.txt⟩ sin encerrarlo entre "<" y ">".
       Toma la forma unico@nombre_completo_dominio. Un identificador de mensaje
       puede ser distinguido de un nombre de grupo de noticias por la presencia
       del carácter "@".

       telnet - sesión Telnet

       telnet://servidor_ip/

       El esquema de una URL de telnet se usa para designar servicios de texto
       interactivos a los que se puede acceder a través del protocolo Telnet. El
       carácter final "/" se puede omitir. El puerto por defecto es el 23. Un
       ejemplo es <telnet://melvyl.ucop.edu/>.

       file - Fichero normal

       file://servidor_ip/ruta
       file:ruta

       Esto representa un fichero o directorio que se puede acceder localmente.
       Como caso especial, servidor_ip puede ser la cadena "localhost" o una
       cadena vacía. Esto se interpreta como `la máquina desde la que el URL
       está siendo interpretado'. Si la ruta es hacia un directorio, el visor
       debería mostrar el contenido del directorio con enlaces a cada uno de los
       contenidos. Actualmente, no todos los visores hacen esto. KDE suporta
       ficheros generados a través del URL <file:/cgi-bin>. Si no se encuentra
       el fichero indicado, los escritores de visualizadores pueden querer el
       intentar expandir el nombre del fichero mediante comodines (vea glob(7) y
       glob(3)).

       El segundo formato (por ejemplo, <file:/etc/passwd>) es un formato
       correcto para referirse a ficheros locales. Sin embargo, los estándares
       más antiguos no permitían este formato, y algunos programas no reconocen
       esto como un URI. Una sintaxis más portable es usar una cadena vacía como
       nombre del servidor, por ejemplo, <file:///etc/passwd>. Esto hace la
       misma cosa y es más sencillo de reconocer por los buscadores de patrones
       y programas más antiguos como un URI. Advierta que si lo que realmente
       quiere decir es "comienza desde la posición actual," no especificas todo
       el esquema. En cambio, usa la dirección relativa como <../test.txt> que
       tiene el efecto colateral de ser independiente del esquema. Un ejemplo de
       este esquema es <file:///etc/passwd>.

       man - páginas man de documentación

       man:nombre-orden
       man:nombre-orden(sección)

       Esto se refiere a las páginas de referencia en línea del manual local. El
       nombre de la orden opcionalmente puede ir precedido por un paréntesis y
       un número de sección. Véase man(7) para más información sobre el
       significado de los números de sección. Este modelo URI es único en los
       sistemas tipo UNIX (como Linux) y actualmente no está registrado por la
       IETF. Un ejemplo es <man:ls(1)>.

       info - Documentación en páginas info

       info:nombrefichero-virtual
       info:nombrefichero-virtual#nombrenodo
       info:(nombrefichero-virtual)
       info:(nombrefichero-virtual)nombrenodo

       Este esquema hace referencia a las páginas de referencia en línea del
       sistema info (generadas a partir de ficheros texinfo), un formato de
       documentación usado por programas tales como las herramientas GNU. Este
       modelo URI es único en los sistemas tipo UNIX (tales como Linux) y
       actualmente no está registrado por el IETF. En el momento de escribir
       esto, GOME y KDE difieren en sus sintáxis URI y no aceptan la sistáxis
       del otro. Los primeros dos formatos son el formato de GNOME. Todos los
       espacios en los nombres de los nodos se escriben como subrayados. Los
       otros dos formatos son el formato de KDE. Los espacios en los nombres de
       los nodos se escriben como espacios, aunque esto está prohibido por los
       estándares URI. Se espera que en un futuro la mayoría de las herramientas
       comprendan ambos formatos y que acepten subrayados para los espacios en
       los nombres de los nodos. Tanto en GNOME como en KDE, si se usa la forma
       sin el nombre de nodo, se asume "Top" como nombre de nodo. Ejemplos del
       formato de GNOME son <info:gcc> y <info:gcc#G++_and_GCC>.Ejemplos del
       formato de KDE son <info:(gcc)> y <info:(gcc)G++ and GCC>.

       whatis - búsqueda de documentación

       whatis:cadena

       Busca en la base de datos de descripciones cortas (una línea) de órdenes
       y devuelve una lista con las descripciones que contienen esa cadena. Sólo
       se muestran coincidencias de palabras completas. Véase whatis(1). Este
       esquema URI es único en los sistemas al estilo UNIX (tales como Linux) y
       actualmente no está registrado por el IETF.

       ghelp - documentación de ayuda de GNOME

       ghelp:ghelp: nombre-de-aplicación

       Carga la ayuda de GNOME para la aplicación dada. Dese cuenta que
       actualmente no existe mucha documentación en este formato.

       ldap - Protocolo Ligero de Acceso a Directorios

       ldap://hostport
       ldap://hostport/
       ldap://hostport/dn
       ldap://hostport/dn?attributes
       ldap://hostport/dn?attributes?scope
       ldap://hostport/dn?attributes?scope?filter
       ldap://hostport/dn?attributes?scope?filter?extensions

       This scheme supports queries to the Lightweight Directory Access Protocol
       (LDAP), a protocol for querying a set of servers for hierarchically
       organized information (such as people and computing resources).  See
       RFC 2255 ⟨http://www.ietf.org/rfc/rfc2255.txt⟩ for more information on
       the LDAP URL scheme.  The components of this URL are:

       hostport    el servidor LDAP a consultar, escrito como un nombre de
                   anfitrión seguiro por dos puntos y un número de puerto. El
                   puerto LDAP por omisión es el puerto TCP 389. Si no se
                   indica, el cliente determina qué servidor LDAP usar.

       dn          el Nombre LDAP Distinguido, que identifica el objeto base de
                   la búsqueda LDAP (vea RFC 2253 ⟨http://www.ietf.org/rfc
                   /rfc2253.txt⟩ sección 3).

       attributes  una lista de atributos, separados por comas, a devolver. Vea
                   RFC 2251 sección 4.1.5. Si se omite, se deberían devolver
                   todos los atributos.

       scope       especifica el ámbito de la búsqueda, que puede ser "base"
                   (para una búsqueda de objetos base), "one" (para una búsqueda
                   de un nivel) o "sub" (para una búsqueda de subárbol). Si se
                   omite el ámbito, se asume "base".

       filter      especifica el filtro de la búsqueda (subconjunto de entradas
                   a devolver). Si se omite, se deberían devolver todas las
                   entradas. Vea RFC 2254 ⟨http://www.ietf.org/rfc/rfc2254.txt⟩
                   sección 4.

       extensions  Una lista de parejas tipo=valor, separadas por comas, donde
                   la porción =valor se puede omitir para opciones que no la
                   necesiten. Una extensión prefijada con un '!' es crítica
                   (debe estar soportada para ser válida), en otro caso no es
                   crítica (opcional).

       Las consultas LDAP son más fáciles de explicar mediante ejemplos. Aquí
       tiene una consulta que pide a ldap.itd.umich.edu información sobre la
       Universidad de Michigan en los EE.UU.:

       ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US

       Para obtener simplemente su atributo de dirección postal, pregunte:

       ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US?postalAddress

       Para pedir información a host.com en el puerto 6666 sobre la persona de
       nombre común (common name, cn) "Babs Jensen" de la Universidad de
       Michigan, pregunte:

       ldap://host.com:6666/o=University%20of%20Michigan,c=US??sub?(cn=Babs%20Jensen)

       wais - Wide Area Information Servers (Servidores de Información de Área
       Amplia)

       wais://hostport/database
       wais://hostport/database?search
       wais://hostport/database/wtype/wpath

       Este esquema designa a una base de datos, búsqueda o documento WAIS (vea
       IETF RFC 1625 ⟨http://www.ietf.org/rfc/rfc1625.txt⟩ para obtener más
       información sobre WAIS). Hostport es el nombre del anfitrión, seguido
       opcionalmente por dos puntos y un número de puerto (el número de puerto
       por omisión es 210).

       La primera forma designa a una base de datos WAIS en la que buscar. La
       segunda forma designa una búsqueda particular en la base de datos WAIS
       database. La tercer forma designa un documento particular a recuperar
       dentro de una base de datos WAIS. wtype es una designación WAIS del tipo
       del objeto y wpath es el identificador de documento WAIS.

       Otros formatos

       Existen muchos otros esquemas URI diferentes. La mayoría de las
       herramientas que aceptan URIs, también soportan un conjunto de URIs
       internos (por ejemplo, Mozilla tiene el esquema about: para información
       interna, y el navegador de ayuda de GNOME tiene el formato toc: para
       diversas localizaciones de comienzo. Hay muchos esquemas que han sido
       definidos, pero que actualmente no se usan de forma amplia. (por ejemplo,
       prospero). El esquema nntp: está en desuso en favor del esquema news:.
       Las URNs van a ser soportadas por el esquema urn:, con un espacio de
       nombres jerárquico (por ejemplo, urn:ietf:... identificaría documentos
       IETF). En este momento, las URNs no están ampliamente implementadas. No
       todas las herramientas soportan todos los esquemas.

   Character encoding
       URIs usan un número limitado de caracteres que pueden ser tecleados y
       usados en variedad de situaciones.

       Los siguientes caracteres son reservados, es decir, pueden aparecer en un
       URI, pero su uso está limitado a su propósito específico (los datos
       conflictivos deben ser precedidos por una carácter de escape antes de
       formar el URI):

                 ; / ? : @ & = + $ ,

       Los caracteres no reservados se pueden incluir en un URI. Los caracteres
       no reservados incluyen las letras del alfabeto inglés en mayúsculas y
       minúscula, los dígitos, y el siguiente conjunto de marcas de puntuación y
       símbolos:

               - _ . ! ~ * ' ( )

       Los demás caracteres se deben preceder con carácteres de escape. Un
       octeto con escape se codifica como un carácter triple, constituido por el
       carácter de porcentaje "%" seguido de dos dígitos hexadecimales que
       representan el código del octeto (puede usar letras mayúsculas y
       minúsculas para los dígitos hexadecimales). Por ejemplo, un espacio en
       blanco se debe representar como "%20", el carácter tabulador como "%09",
       y el "&" como "%26". Ya que el carácter de porcentaje siempre tiene el
       propósito reservado de comenzar una secuencia de escape, se debe
       representar como "%25". Es una práctica común indicar los caracteres de
       espacio con el símbolo (+) en frases para consulta. Esta práctica no está
       definida de forma concisa en los RFCs relevantes (los cuales recomiendan
       %20 en su lugar) pero cualquier aplicación que reciba URIs debería estar
       preparada para ellos. Un URI siempre se muestra en su forma "de escape".

       Los caracteres no reservados se pueden escapar sin cambiar la semántica
       de la URI, pero esto no se debería hacer a menos que la URI se esté
       usando en un contexto que no permite que aparezcan caracteres sin
       escapar. Por ejemplo, se usa "%7e" en lugar de "~" en una ruta HTTP URL
       pero las dos son equivalentes para una URL HTTP.

       Para URIs que deban manejar caracteres fuera del conjunto de caracteres
       US ASCII, la especificación HTML 4.01 (sección B.2) y el IETF RFC 2718
       (sección 2.2.5) recomiendan la siguiente aproximación:

       1.  traducir las secuencias de caracteres a UTF-8 (IETF RFC 2279) - vea
           utf-8(7) - y después

       2.  usar el mecanismo de escape URI, es decir, usar la codificación %HH
           para octetos problemáticos.

   Writing a URI
       When written, URIs should be placed inside double quotes (e.g.,
       "http://www.kernel.org"), enclosed in angle brackets (e.g.,
       <http://lwn.net>), or placed on a line by themselves.  A warning for
       those who use double-quotes: never move extraneous punctuation (such as
       the period ending a sentence or the comma in a list)  inside a URI, since
       this will change the value of the URI.  Instead, use angle brackets
       instead, or switch to a quoting system that never includes extraneous
       characters inside quotation marks.  This latter system, called the 'new'
       or 'logical' quoting system by "Hart's Rules" and the "Oxford Dictionary
       for Writers and Editors", is preferred practice in Great Britain and
       hackers worldwide (see the Jargon File's section on Hacker Writing Style,
       ⟨http://www.fwi.uva.nl/~mes/jargon/h/HackerWritingStyle.html⟩, for more
       information).  Older documents suggested inserting the prefix "URL:" just
       before the URI, but this form has never caught on.

       La sintáxis URI se diseñó para que no fuera ambigua. Además, como los
       URIs se han convertido en un lugar común, los medios tradicionales
       (televisión, radio, periódicos, vallas publicitarias, etc.) han
       incrementado el uso de referencias abreviadas URI formadas sólo por la
       autoridad y partes del camino del identificativo del recurso (por
       ejemplo, <www.w3.org/Addressing>). Tales referencias son principalmente
       entendidas por la interpretación humana más que por las máquinas,
       asumiendo que el estudio del contexto es suficiente para completar el URI
       (es decir, nombres de host que comiencen por "www" son como tener un
       prefijo URI "http://" y los host que comiencen con "ftp" usualmente
       tendrán un prefijo "ftp://"). Algunas implementaciones de clientes
       resuelven heurísticamente estas referncias. Tales heurísticas pueden
       cambiar con el tiempo, particularmente cuando se introduzcan nuevos
       esquemas. Ya que un URI abreviado tiene la misma sintaxis que una ruta
       URL relativa, la referencia URI relativa no se puede usar donde lor URIs
       relativos son permitidos, y sólo se pueden usar cuando no hay una base
       definida (como en cuadros de diálogo). No use URIs abreviados como
       enlaces de hipertexto dentro de un documento. Use el formato estándar
       como se describe aquí.

CONFORME A
       (IETF RFC 2396) ⟨http://www.ietf.org/rfc/rfc2396.txt⟩, (HTML 4.0)
       ⟨http://www.w3.org/TR/REC-html40⟩.

NOTAS
       Algunas herramientas de un sistema Linux que aceptan URIs (por ejemplo,
       un navegador) deberían ser capaces de manejar (directa o indirectamente)
       todos los esquemas aquí descritos, incluyendo los esquemas man: e info:.
       Manejarlos invocando otros programas está bien, y de hecho es lo
       apropiado.

       Tecnicamente el fragmento no es parte del URI.

       Para informarse sobre como incrustar URIs (incluidos URLs) en formato de
       datos, véase la documentación sobre ese formato. HTML usa el formato <A
       HREF="uri"> texto </A>. Los archivos Textinfo usan el formato @uref{uri}.
       Man y mdoc han añadido recientemente la macro UR, o simplemente
       incluyendo el URI en el texto (los visores deben ser capaces de detectar
       :// como parte de un URI).

       Los gestores de escritorio KDE y GNOME actualmente varían en los URIs que
       aceptan, en particular en sus respectivos navegadores de ayuda. Para
       listar las páginas del manual, GNOME usa <toc:man> mientras que KDE usa
       <info:(dir)> (el autor de esta página prefiere el sistema KDE mostrado
       aquí, aunque un formato más regular sería mejor). En general, KDE usa
       <file:/cgi-bin/> como prefijo para un conjunto de ficheros generados. KDE
       prefiere la documentación en formato HTML, siendo accedida a través de
       <file:/cgi-bin/helpindex>. GNOME prefiere el esquema ghelp para almacenar
       y encontrar documentación. Ningún navegador maneja referencias de tipo
       file: a directorios en el momento de crear este documento, haciendo
       difícil la referencia a entradas de directorio con un navegador URI. Como
       se ha indicado antes, estos entornos difieren sobre cómo manejar el
       esquema info:, probablemente es la mayor diferencia. Se espera que GNOME
       y KDE converjan a un mismo formato URI, y en el futuro esta página
       describirá el resultado de esa convergencia. Los esfuerzos para ayudar a
       esta convergencia son admirables.

   Seguridad
       Un URI no posee por sí mismo un tratamiento de seguridad. No hay garantía
       general de que un URI, que en un tiempo localizó un recurso dado,
       continue haciéndolo. Ni hay ninguna garantía de que tal URL no localizará
       un recurso diferente pasado un tiempo. Tal garantía sólo se puede obtener
       de la(s) persona(s) que mantiene(n) el nombre y el recurso en cuestión.

       A veces es posible construir un URL tal que al intentar realizar una
       operación aparentemente inofensiva, como la recuperación de una entidad
       asociada con el recurso, se produzca una posible operación remota
       peligrosa. El URL no seguro se construye típicamente especificando un
       número de puerto distinto del reservado por el protocolo de red en
       cuestión. El cliente, inconscientemente contacta con un sitio que de
       hecho está ejecutando un protocolo diferente. El contenido del URL
       contiene instrucciones que, cuando son interpretadas de acuerdo con este
       otro protocolo, causan una operación inexperada. Un ejemplo ha sido el
       uso de un URL gopher para enviar, a través de un servidor SMTP, un
       mensaje no intencionado o anónimo.

       Se debería llevar cuidado cuando se usa un URL que especifica un número
       de puerto diferente del que viene por defecto para el protocolo,
       especialmente cuando se trata de un número dentro del espacio reservado.

       Se debería andar con precacución cuando se usa un URI que contiene
       delimitadores de escape para un protocolo dado (por ejemplo, los
       caracteres CR y LF para protocolos de telnet) ya que no son decodificados
       antes de la transmisión. Esto puede violar el protocolo, pero evita el
       peligro de que algunos caracteres sean usados para simular una operación
       o parámetro extra en ese protocolo, el cual puede que conduzca a que se
       lleve a caba una inesperada y posiblemente dañina operación.

       It is clearly unwise to use a URI that contains a password which is
       intended to be secret.  In particular, the use of a password within the
       "userinfo" component of a URI is strongly recommended against except in
       those rare cases where the "password" parameter is intended to be public.

ERRORES
       La documentación puede estar situada en variedad de lugares, por lo que
       actualmente no es un buen esuqema URI para la documentación en linea de
       ámbito general con diferentes formatos. Referencias de la forma
       <file:///usr/doc/ZZZ> no funcionan porque distribuciones diferentes y
       requisitos de instalación locales diferentes puede que situen los
       archivos en directorios diferentes (puede ser en /usr/doc, o
       /usr/local/doc, o /usr/share, o cualquier otro sitio). Además, el
       directorio ZZZ normalmente cambia con la versión. Por último, usar el
       esquema file: no es sencillo para las personas que cargan documentación
       dinámica de Internet (en lugar de cargar ficheros en un sistema de
       archivos local). Un futuro URI puede ser añadido (por ejemplo "userdoc:")
       para permitirle a los programas incluir referencias cruzadas a
       documentación con más detalle sin tener que saber la posición exacta de
       dicha documentación. Alternativamente, una versión futura de la
       especificación del sistema de ficheros puede que especifique
       suficientemente las localizaciones de los ficheros para que el esquema
       file: sea capaz de encontrar la documentación.

       Muchos programas y formatos de ficheros no incluyen una forma de
       incorporar o implementar enlaces usando URIs.

       Algunos programas no pueden manejar todos los formatos URI. Debería haber
       un mecanismo estándar, para cargar un URI, que automáticamente detectara
       el entorno del usuario (por ejemplo, texto o gráfico, entorno de
       escritorio, preferencias de usuario local, y herramientas que se ejecutan
       actualmente) y que invocara la herramienta adecuada para cualquier URI.

VÉASE TAMBIÉN
       lynx(1), man2html(1), mailaddr(7), utf-8(7)

       IETF RFC 2255 ⟨http://www.ietf.org/rfc/rfc2255.txtCOLOFÓN
       Esta página es parte de la versión 5.10 del proyecto Linux man-pages.
       Puede encontrar una descripción del proyecto, información sobre cómo
       informar errores y la última versión de esta página en
       https://www.kernel.org/doc/man-pages/.


TRADUCCIÓN
       La traducción al español de esta página del manual fue creada por Angel
       Bueno Pardo <buenpar@teleline.es>, Juan Piernas <piernas@ditec.um.es> y
       Miguel Pérez Ibars <mpi79470@alu.um.es>

       Esta traducción es documentación libre; lea la GNU General Public License
       Version 3 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ o posterior con
       respecto a las condiciones de copyright.  No existe NINGUNA
       RESPONSABILIDAD.

       Si encuentra algún error en la traducción de esta página del manual,
       envíe un correo electrónico a debian-l10n-spanish@lists.debian.org>.  ⟨⟩.



Linux                            13 Agosto 2020                           URI(7)