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'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 &amp;. 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).