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'ON
Un Identificador de Recursos Uniforme (URI) es una cadena de caracteres
corta que identifica un recurso abstracto o fisico (por ejemplo, una
pagina web). Localizador de Recursos Uniforme (URL) es un URI que
identifica un recurso por su mecanismo de acceso primario (por ejemplo,
su ubicacion de), antes que por su nombre o algun otro atributo del
recurso. Un Nombre de Recurso Uniforme (URN) es un URI que debe ser
globalmente unico y permanecer aun cuando el recurso deja de existir o
pasa a ser inaccesible.
Los URIs son la forma estandar de nombrar los destinos de los
hiperenlaces para herramientas tales como los navegadores web. La
cadena "http://www.kernelnotes.org" es un URL (y tambien un URI).
Algunas personas usan el termino URL unicamente como sinonimo de URI
(aunque tecnicamente 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 traves 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 jerarquico actual" y "el nivel superior a este nivel
jerarquico", respectivamente, Tal y como lo hacen los sistemas al
estilo Unix. Un segmento de ruta que contiene el caracter ":" no puede
ser usado como el primer segmento de ruta relativa URI (por ejemplo,
"esto:aquello"), porque seria erroneo 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 porcion
particular identificada (fragmento) de un recurso. El texto despues 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 aqui un servidor_ip (los corchetes
muestran que es opcional):
servidor_ip = [usuario [ : contrase~na ] @ ] host [ : puerto ]
Este formato te permite opcionalmente insertar un nombre de usuario,
una contrasena y/o un numero de puerto. El host es el nombre del
ordenador que hace de anfitrion, y su nombre se puede determinar
mediante su DNS o una direccion IP (numeros separados por puntos). Por
lo que el URI <http://fred:fredcontrasena@xyz.com:8080/> se introduce
en el servidor web del anfitrion xyz.com como fred (usando
fredcontrasena) usando el puerto 8080. Evite incluir contrasenas 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 contrasena, y el servidor remoto pide la
contrasena, el programa que interpreta el URL debe requerir una del
usuario.
Aqui hay algunos de los esquemas mas comunes usados por sistemas al
estilo Unix, los cuales son comprendidos por muchas aplicaciones.
Advierta que algunas aplicaciones usan URIs y tambien tienen esquemas
internos o esquemas especializados. Vea en esas aplicaciones la
documentacion 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
elegira que devolver. Normalmente, si existe un fichero llamado
"index.html" o "index.htm" sera 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 peticion
tambien se puede dar en un formato mas largo "GET", el cual tiene una o
mas peticiones de entrada para el formulario variable=valor separadas
por el caracter ampersand (&). Advierta que variable puede ser repetida
mas de una vez, piense que son el servidor web y sus aplicaciones los
encargados de determinar si tiene significado. Existe una interaccion
desafortunada entre HTML/XML/SGML y este formato. Cuando tales URIs con
mas 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 mas 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. Vease la especificacion del "Common Gateway Interface"
en <http://www.w3.org/CGI> para mas informacion.
ftp - Protocolo de Transferencia de Ficheros (FTP)
ftp://servidor_ip/ruta
Este es un URL de acceso a ficheros a traves 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
contrasena su direccion de correo electronico. 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 solo
caracter que indica el tipo de recurso Gopher al que se refiere el URL.
La ruta entera tambien puede estar vacia, y en tal caso el delimitador
"/" es tambien opcional, siendo el tipogopher por defecto "1" selector
es la cadena de seleccion Gopher. En el protocolo Gopher, las cadenas
de seleccion 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 caracter LF) y 0D (US-ASCII caracter CR).
mailto - direcci'on de correo
mailto:direcci'on_de_correo
Esto es una direccion de correo electronico, normalmente de la forma
nombre@nombrehost Vease mailaddr(7) para mas informacion acerca del
formato correcto de la direccion de correo electronico. Advierta que
cualquier caracter % 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 jerarquico 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
caracter "@".
telnet - sesi'on 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 traves del protocolo Telnet.
El caracter 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 vacia. Esto se interpreta como `la maquina
desde la que el URL esta siendo interpretado'. Si la ruta es hacia un
directorio, el visor deberia 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 traves 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
estandares mas antiguos no permitian este formato, y algunos programas
no reconocen esto como un URI. Una sintaxis mas portable es usar una
cadena vacia como nombre del servidor, por ejemplo,
<file:///etc/passwd>. Esto hace la misma cosa y es mas sencillo de
reconocer por los buscadores de patrones y programas mas antiguos como
un URI. Advierta que si lo que realmente quiere decir es "comienza
desde la posicion actual," no especificas todo el esquema. En cambio,
usa la direccion 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'aginas man de documentaci'on
man:nombre-orden
man:nombre-orden(secci'on)
Esto se refiere a las paginas de referencia en linea del manual local.
El nombre de la orden opcionalmente puede ir precedido por un
parentesis y un numero de seccion. Vease man(7) para mas informacion
sobre el significado de los numeros de seccion. Este modelo URI es
unico en los sistemas tipo Unix (como Linux) y actualmente no esta
registrado por la IETF. Un ejemplo es <man:ls(1)>.
info - Documentaci'on en p'aginas info
info:nombrefichero-virtual
info:nombrefichero-virtual#nombrenodo
info:(nombrefichero-virtual)
info:(nombrefichero-virtual)nombrenodo
Este esquema hace referencia a las paginas de referencia en linea del
sistema info (generadas a partir de ficheros texinfo), un formato de
documentacion usado por programas tales como las herramientas GNU.
Este modelo URI es unico en los sistemas tipo Unix (tales como Linux) y
actualmente no esta registrado por el IETF. En el momento de escribir
esto, GOME y KDE difieren en sus sintaxis URI y no aceptan la sistaxis
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 esta prohibido por
los estandares URI. Se espera que en un futuro la mayoria 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'usqueda de documentaci'on
whatis:cadena
Busca en la base de datos de descripciones cortas (una linea) de
ordenes y devuelve una lista con las descripciones que contienen esa
cadena. Solo se muestran coincidencias de palabras completas. Vease
whatis(1). Este esquema URI es unico en los sistemas al estilo Unix
(tales como Linux) y actualmente no esta registrado por el IETF.
ghelp - documentaci'on de ayuda de GNOME
ghelp:nombre-de-aplicaci'on
Carga la ayuda de GNOME para la aplicacion dada. Dese cuenta que
actualmente no existe mucha documentacion 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 informacion organizada jerarquicamente (como personas
y recursos de computacion). Puede encontrar mas informacion 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
anfitrion seguiro por dos puntos y un numero de puerto. El
puerto LDAP por omision es el puerto TCP 389. Si no se
indica, el cliente determina que servidor LDAP usar.
dn el Nombre LDAP Distinguido, que identifica el objeto base
de la busqueda LDAP (vea RFC 2253
<http://www.ietf.org/rfc/rfc2253.txt> seccion 3).
attributes una lista de atributos, separados por comas, a devolver.
Vea RFC 2251 seccion 4.1.5. Si se omite, se deberian
devolver todos los atributos.
scope especifica el ambito de la busqueda, que puede ser "base"
(para una busqueda de objetos base), "one" (para una
busqueda de un nivel) o "sub" (para una busqueda de
subarbol). Si se omite el ambito, se asume "base".
filter especifica el filtro de la busqueda (subconjunto de
entradas a devolver). Si se omite, se deberian devolver
todas las entradas. Vea RFC 2254
<http://www.ietf.org/rfc/rfc2254.txt> seccion 4.
extensions Una lista de parejas tipo=valor, separadas por comas, donde
la porcion =valor se puede omitir para opciones que no la
necesiten. Una extension prefijada con un '!' es critica
(debe estar soportada para ser valida), en otro caso no es
critica (opcional).
Las consultas LDAP son mas faciles de explicar mediante ejemplos. Aqui
tiene una consulta que pide a ldap.itd.umich.edu informacion 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 direccion postal, pregunte:
ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US?postalAddress
Para pedir informacion a host.com en el puerto 6666 sobre la persona de
nombre comun (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'on de 'Area
Amplia
wais://hostport/database
wais://hostport/database?search
wais://hostport/database/wtype/wpath
Este esquema designa a una base de datos, busqueda o documento WAIS
(vea IETF RFC 1625 <http://www.ietf.org/rfc/rfc1625.txt> para obtener
mas informacion sobre WAIS). Hostport es el nombre del anfitrion,
seguido opcionalmente por dos puntos y un numero de puerto (el numero
de puerto por omision es 210).
La primera forma designa a una base de datos WAIS en la que buscar. La
segunda forma designa una busqueda 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 designacion WAIS del
tipo del objeto y wpath es el identificador de documento WAIS.
Otros formatos
Existen muchos otros esquemas URI diferentes. La mayoria de las
herramientas que aceptan URIs, tambien soportan un conjunto de URIs
internos (por ejemplo, Mozilla tiene el esquema about: para informacion
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: esta en desuso en favor del
esquema news:. Las URNs van a ser soportadas por el esquema urn:, con
un espacio de nombres jerarquico (por ejemplo, urn:ietf:...
identificaria documentos IETF). En este momento, las URNs no estan
ampliamente implementadas. No todas las herramientas soportan todos
los esquemas.
CODIFICACI'ON DE CARACTERES
URIs usan un numero 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 esta limitado a su proposito especifico (los datos
conflictivos deben ser precedidos por una caracter 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 ingles en
mayusculas y minuscula, los digitos, y el siguiente conjunto de marcas
de puntuacion y simbolos:
- _ . ! ~ * ' ( )
Los demas caracteres se deben preceder con caracteres de escape. Un
octeto con escape se codifica como un caracter triple, constituido por
el caracter de porcentaje "%" seguido de dos digitos hexadecimales que
representan el codigo del octeto (puede usar letras mayusculas y
minusculas para los digitos hexadecimales). Por ejemplo, un espacio en
blanco se debe representar como "%20", el caracter tabulador como
"%09", y el "&" como "%26". Ya que el caracter de porcentaje siempre
tiene el proposito reservado de comenzar una secuencia de escape, se
debe representar como "%25". Es una practica comun indicar los
caracteres de espacio con el simbolo (+) en frases para consulta. Esta
practica no esta definida de forma concisa en los RFCs relevantes (los
cuales recomiendan %20 en su lugar) pero cualquier aplicacion que
reciba URIs deberia estar preparada para ellos. Un URI siempre se
muestra en su forma "de escape".
Los caracteres no reservados se pueden escapar sin cambiar la semantica
de la URI, pero esto no se deberia hacer a menos que la URI se este
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 especificacion HTML 4.01 (seccion B.2) y el IETF RFC 2718
(seccion 2.2.5) recomiendan la siguiente aproximacion:
1. traducir las secuencias de caracteres a UTF-8 (IETF RFC 2279) - vea
utf-8(7) - y despues
2. usar el mecanismo de escape URI, es decir, usar la codificacion %HH
para octetos problematicos.
ESCRIBIENDO UN URI
Cuando son escritos, los URIs deberian introducirse entre comillas (por
ejemplo, "http://www.kernelnotes.org"), encerrados entre <> (por
ejemplo , <http://lwn.net>), o situados en una linea ellos solos. Una
advertencia para aquellos que usan comillas dobles: nunca mueva
simbolos de puntuacion extranos (tales como el punto y final de una
frase o la coma en una lista) dentro de un URI, ya que esto cambiara el
valor del URI. En su lugar, use "<>", o cambie a un sistema de notacion
para no incluir nunca en el caracteres extranos. Este ultimo sistema,
llamado el 'nuevo' o 'logico' sistema de notacion por "Las reglas de
Hart" y el "Diccionario Oxford para Ecritores y Editores", es el
preferido en la practica en Gran Bretana y por hackers de todo el mundo
(vease los ficheros de Jargon, seccion del estilo de escritura de los
hackers <http://www.fwi.uva.nl/~mes/jargon/h/HackerWritingStyle.html>
para mas informacion).
La sintaxis URI se diseno para que no fuera ambigua. Ademas, como los
URIs se han convertido en un lugar comun, los medios tradicionales
(television, radio, periodicos, vallas publicitarias, etc.) han
incrementado el uso de referencias abreviadas URI formadas solo por la
autoridad y partes del camino del identificativo del recurso (por
ejemplo, <www.w3.org/Addressing>). Tales referencias son principalmente
entendidas por la interpretacion humana mas que por las maquinas,
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
tendran un prefijo "ftp://"). Algunas implementaciones de clientes
resuelven heuristicamente estas referncias. Tales heuristicas 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 solo se pueden usar cuando no hay una
base definida (como en cuadros de dialogo). No use URIs abreviados como
enlaces de hipertexto dentro de un documento. Use el formato estandar
como se describe aqui.
OBSERVACIONES
Algunas herramientas de un sistema Linux que aceptan URIs (por ejemplo,
un navegador) deberian ser capaces de manejar (directa o
indirectamente) todos los esquemas aqui descritos, incluyendo los
esquemas man: e info:. Manejarlos invocando otros programas esta 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, vease la documentacion 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 anadido 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 varian en los URIs
que aceptan, en particular en sus respectivos navegadores de ayuda.
Para listar las paginas del manual, GNOME usa <toc:man> mientras que
KDE usa <info:(dir)> (el autor de esta pagina prefiere el sistema KDE
mostrado aqui, aunque un formato mas regular seria mejor). En general,
KDE usa <file:/cgi-bin/> como prefijo para un conjunto de ficheros
generados. KDE prefiere la documentacion en formato HTML, siendo
accedida a traves de <file:/cgi-bin/helpindex>. GNOME prefiere el
esquema ghelp para almacenar y encontrar documentacion. Ningun
navegador maneja referencias de tipo file: a directorios en el momento
de crear este documento, haciendo dificil la referencia a entradas de
directorio con un navegador URI. Como se ha indicado antes, estos
entornos difieren sobre como 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 pagina describira el resultado de esa
convergencia. Los esfuerzos para ayudar a esta convergencia son
admirables.
SEGURIDAD
Un URI no posee por si mismo un tratamiento de seguridad. No hay
garantia general de que un URI, que en un tiempo localizo un recurso
dado, continue haciendolo. Ni hay ninguna garantia de que tal URL no
localizara un recurso diferente pasado un tiempo. Tal garantia solo se
puede obtener de la(s) persona(s) que mantiene(n) el nombre y el
recurso en cuestion.
A veces es posible construir un URL tal que al intentar realizar una
operacion aparentemente inofensiva, como la recuperacion de una entidad
asociada con el recurso, se produzca una posible operacion remota
peligrosa. El URL no seguro se construye tipicamente especificando un
numero de puerto distinto del reservado por el protocolo de red en
cuestion. El cliente, inconscientemente contacta con un sitio que de
hecho esta ejecutando un protocolo diferente. El contenido del URL
contiene instrucciones que, cuando son interpretadas de acuerdo con
este otro protocolo, causan una operacion inexperada. Un ejemplo ha
sido el uso de un URL gopher para enviar, a traves de un servidor SMTP,
un mensaje no intencionado o anonimo.
Se deberia llevar cuidado cuando se usa un URL que especifica un numero
de puerto diferente del que viene por defecto para el protocolo,
especialmente cuando se trata de un numero dentro del espacio
reservado.
Se deberia andar con precacucion 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 transmision. Esto puede violar el protocolo,
pero evita el peligro de que algunos caracteres sean usados para
simular una operacion o parametro extra en ese protocolo, el cual puede
que conduzca a que se lleve a caba una inesperada y posiblemente danina
operacion.
Es claramente indeseable usar un URI que contenga una contrasena, la
cual supuestamente es secreta. En particular, el uso de una contrasena
con el componente 'userinfo' de un URI esta fuertemente desaconsejada
excepto en aquellos casos raros donde la contrasena es publica.
CONFORME A
IETF RFC 2396, <http://www.ietf.org/rfc/rfc2396.txt> W3C REC-
html40-19980424 <http://www.w3.org>
FALLOS
La documentacion puede estar situada en variedad de lugares, por lo que
actualmente no es un buen esuqema URI para la documentacion en linea de
ambito general con diferentes formatos. Referencias de la forma
<file:///usr/doc/ZZZ> no funcionan porque distribuciones diferentes y
requisitos de instalacion 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). Ademas, el
directorio ZZZ normalmente cambia con la version. Por ultimo, usar el
esquema file: no es sencillo para las personas que cargan documentacion
dinamica de Internet (en lugar de cargar ficheros en un sistema de
archivos local). Un futuro URI puede ser anadido (por ejemplo
"userdoc:") para permitirle a los programas incluir referencias
cruzadas a documentacion con mas detalle sin tener que saber la
posicion exacta de dicha documentacion. Alternativamente, una version
futura de la especificacion del sistema de ficheros puede que
especifique suficientemente las localizaciones de los ficheros para que
el esquema file: sea capaz de encontrar la documentacion.
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. Deberia
haber un mecanismo estandar, para cargar un URI, que automaticamente
detectara el entorno del usuario (por ejemplo, texto o grafico, 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) escribio esta pagina.
V'EASE TAMBI'EN
lynx(1), netscape(1), mailaddr(7), utf-8(7), man2html(1).