bionic (7) url.7.gz

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