Provided by: manpages-es_1.55-7_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 [ : 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 &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: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).