Provided by:
manpages-es_1.55-9_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 [ : contrasea ] @ ] 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:direccin_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(seccin)
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-aplicacin
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. 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 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 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 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 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, W3C REC-html40-19980424
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).