Provided by: manpages-es_1.55-10_all bug

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  &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  <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).