Provided by: manpages-es_1.55-10_all 
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 ] .sp
esquema = "http" | "ftp" | "gopher" | "mailto" | "news" | "telnet" |
"file" | "man" | "info" | "whatis" | ...
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.kernelnotes.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 fragmento del recurso
actual.
USO
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@xyz.com:8080/> se introduce en el servidor web del
anfitrión xyz.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 &. 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 <nombre-gruponoticias> 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, 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: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
Este esquema soporta consultas al protocolo LDAP (Lightweight Directory Access Protocol,
LDAP), un protocolo para consultar a un conjunto de servidores sobre información
organizada jerárquicamente (como personas y recursos de computación). Puede encontrar más
información sobre el esquema URL para LDAP en RFC 2255.
⟨http://www.ietf.org/rfc/rfc2255.txt⟩ Los componentes de esta URL son:
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.
CODIFICACIÓN DE CARACTERES
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.
ESCRIBIENDO UN URI
Cuando son escritos, los URIs deberían introducirse entre comillas (por ejemplo,
"http://www.kernelnotes.org"), encerrados entre <> (por ejemplo , <http://lwn.net>), o
situados en una línea ellos solos. Una advertencia para aquellos que usan comillas
dobles: nunca mueva símbolos de puntuación extraños (tales como el punto y final de una
frase o la coma en una lista) dentro de un URI, ya que esto cambiará el valor del URI. En
su lugar, use "<>", o cambie a un sistema de notación para no incluir nunca en él
caracteres extraños. Este último sistema, llamado el 'nuevo' o 'lógico' sistema de
notación por "Las reglas de Hart" y el "Diccionario Oxford para Ecritores y Editores", es
el preferido en la práctica en Gran Bretaña y por hackers de todo el mundo (véase los
ficheros de Jargon, sección del estilo de escritura de los hackers
⟨http://www.fwi.uva.nl/~mes/jargon/h/HackerWritingStyle.html⟩ para más información).
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í.
OBSERVACIONES
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="/fluri/fp"> texto </A>.
Los archivos Textinfo usan el formato @uref{/fluri/fp}. 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.
Es claramente indeseable usar un URI que contenga una contraseña, la cual supuestamente es
secreta. En particular, el uso de una contraseña con el componente 'userinfo' de un URI
está fuertemente desaconsejada excepto en aquellos casos raros donde la contraseña es
pública.
CONFORME A
IETF RFC 2396, ⟨http://www.ietf.org/rfc/rfc2396.txt⟩ W3C REC-html40-19980424
⟨http://www.w3.org⟩
FALLOS
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.
AUTOR
David A. Wheeler (dwheeler@dwheeler.com) escribió esta página.
VÉASE TAMBIÉN
lynx(1), netscape(1), mailaddr(7), utf-8(7), man2html(1).