|
En este documento se muestran los diferentes (pero confluyentes)
esfuerzos por dar a la Web un marco en el cual definir una
codificación para nombres y direcciones de recursos disponibles en
ella. En la Web existe un sinnúmero de objetos, a los que se puede
acceder mediante una variedad de protocolos, inventados, en desarrollo
o a ser ideados en el futuro. Para poder abstraer la idea de "objeto
genérico", se necesita disponer de conceptos que den sentido a nombres
y direcciones en la Web.
Un Identificador Universal de Recursos (URI) es un miembro de este
conjunto universal de nombres, en un cierto espacio de nombres y con
una dirección referida a un cierto protocolo, ambos previamente
registrados. un Localizador Uniforme de Recursos (URL), es báciamente
un caso particular de URI que expresa una dirección, mapeada a un
algoritmo de recuperación del objeto que sua protocolos de
comunicación a través de la red. Por último, un Nombre Uniforme de
Recursos (URN) es algo que aún está en debate y que pretende definir
un espacio de nombres para etiquetar objetos persistentes.
Un recurso es cualquier cosa distinguible. Por ejemplo, un documento
electrónico, una imagen, un servicio, etc. Cabe notar que no todos los
recursos son recuperables a través de la red (por ej.: seres humanos,
corporaciones y libros impresos, que también se consideran recursos).
Un recurso es, básicamente, un concepto que puede mapearse a una o a
varias entidades, y que puede permanecer constante a pesar de ver
alterados sus contenidos.
Diagrama correspondiente a la especificación de URI, URL y URN, según el RFC 23
96.
_______________________________________________________
| ________________ |
| | ftp: | |
| | gopher: | |
| | http: __|____________ |
| | etc | | urn: | |
| |_____________|__| | |
| URLs | | |
| |_______________| |
| URNs |
|_______________________________________________________|
La pregunta ahora es, ¿por qué es necesario uniformizar
identificadores, localizadores y nombres?
La respuesta está en la gran cantidad de protocolos usados hoy en día
para encontrar y recuperar recursos en la red, y en la cierta
aparición de muchos protocolos más debido al carácter explosivo de la
expansión de este campo.
Los sistemas en los que se distribuye toda la información alcanzable
utilizan una variedad de plataformas y formatos en constante
evolución, que de no ser por los protocolos y convertidores de formato
adecuados, no podrían ofrecer el acceso global que se da hoy en día.
Sin embargo, esto no es posible de realizar al nivel de direcciones y
nombres de los objetos, dado que son usados para identificarlos y
distinguirlos. Además, estos nombres y direcciones son "transmitidos"
de las más diversas maneras, desde memorándums hasta hipertextos, por
lo que debe suponerse que estos identificadores tendrán una larga
existencia.
De todas las ideas desarolladas en este aspecto, aparece una
característica común mapeable a la idea de un "objeto" y su
correspondiente nombre/etiqueta/identificador. De esta manera se puede
definir un conjunto de espacies de nombres en los que se dice que
existen los objetos.
En la práctica, estos sistemas deben tratar con una mezcla de objetos,
definidos por distintas propuestas. De aquí se desprende la necesidad
del concepto de conjunto universal de objetos, y por ende del conjunto
universal de espacios de nombres. con esto se permite tratar de una
manera similar a objetos pertenecientes a espacios de nombres
distintos, incluso entre los que tienen características totalmente
distintas.
Corresponden a una forma de encapsular un nombre en un espacio de
nombres registrados, y etiquetarlo con el espacio de nombres,
produciendo un miembro del conjunto universal.
La sintaxis universal permite el acceso a objetos disponibles
utilizando protocolos existentes, y es capaz de ser extendida con el
tiempo.
Es necesario decir que la especificación de la sintaxis URI no dice
nada acerca de las propiedades de los nombres y las direcciones de los
espacios de nombres que mapea. Las propiedades salen de la
especificación de protocolos y las convenciones de cada esquema.
Para los protocolos de acceso a Internet existentes, en la mayoría de
los casos se hace necesario definir la codificación del algortimo de
acceso en algo suficientemente conciso para llamarse "dirección". Las
URIs que referencias objetos a los que se accede mediante protocolos
existentes se conocen como URLs.
Aunque muchos esquemas de URLs son bautizados según el protocolo que
utilizan, esto no implica que la única forma de acceder al recurso de
la URL sea mediante ese único protocolo. En particular, los servicios
de gateway, proxy, cache y resolución de nombres pueden llegar a ser
usados para acceder a ciertos recursos, independientemente del
protocolo original, y la resolución de algunas URLs puede requerir el
uso de más de un protocolo (por ejemplo, HTTP y DNS típicamente son
usados para acceder un recurso de URL "http" cuando no se encuentre en
el cache local).
Un URN difiere de una URL en que su propósito principal es etiquetar
persistentemente un recurso con un identificador. Este identificador
es obtenido de un conjunto de espacios de nombres definidos, cada uno
de los cuales tiene establecida su propia estructura de nombres y
procedimientos de asignación. El esquema "urn" se encuentra reservado
para establecer una estandarización de los requerimientos del espacio
de nombres URN.
Criterios para el diseño
Dentro de los requerimientos críticos para la sintaxis del esquema
URI, se encuentran:
- Que sea extensible. En otras palabras, que pudiesen agregarse nuevos esquemas de nombres a medida que fuese necesario.
- Que sea completa. Que sea posible codificar cualquier esquema existente
- Que se pueda imprimir. Si es necesario, un URI debe poder ser "transmitida" usando papel y lápiz, por lo que debe ser posible expresarla usando sólo caracteres ASCII de 7 bits.
Además, hay varios aspectos del diseño relevantes al proceso de
transmisión de URIs:
- Un URI es una secuencia de caracteres, la cual no siempre es representada como una secuencia de bytes.
- Un URI puede ser obtenido desde una fuente desconectada de la red, y por lo tanto debe consistir de caracteres tipeables en un computador, con la restricciones impuestas por los dispositivos de entrada en cada idioma y configuración local.
- A menudo se necesita que un URI sea recordado por la gente, y para eso es conveniente que sus componentes tengan algún sentido.
Estos aspectos del diseño no siempre compatibilizan entre sí. Por
ejemplo, si se quisiera describir acabadamente una componente de URI
caeríamos en la utilización de caracteres prohibitivos para ciertos
sistemas. La necesidad de poder transcribir fácil y universalmente un
URI fue elegida como prioritaria.
Extensibilidad
Se resolvió permitiendo una cadena arbitraria (pero registrada)
como prefijo. La selección de los dos puntos (":") como
separador entre el prefijo y el resto de la URI fue totalmente
arbitraria.
Completitud
Fue satisfecho permitiendo que los nombres extraños (o incluso
binarios) se codificaran en base 16 o base 64 usando los
caracteres aceptables.
Imprimibilidad
Inicialmente, s pertendió establecer que debía codificarse
cualquier carácter que no perteneciese a un set básico; pero la
discusión se desvió a definir cuál sería el set básico,
considerando que, por ejemplo, los sistemas que manejaran
adecuadamente el set de caracteres ISO Latin-1 no tendrían
problemas en utilizar esos caracteres localmente, pero que el
problema se suscitaría al transportar dichos caracteres. La
solución fue especificar un conjunto de caracteres "seguro", y
un esquema general de escapado de caracteres que puede
utilizarse para escapar caracteres "peligrosos".
Sintaxis general y componentes principales de URLs
Así como hay diferentes métodos de acceder a los recursos, hay varios
esquemas para describir su ubicación.
La sintaxis genérica para URLs provee un marco de trabajo extensible,
que permite incorporar protocolos aún no considerados o incluso aún no
inventados
Las URL's, como su nombre lo indica, localizan recursos mediante una
identificación abstracta. Una vez identificado el recurso, un sistema
puede operar de diversas formas sobre él, como por ejemplo realizando
accesos, actualizándolo, reemplazándolo o recuperando sus atributos.
En general, sólo se necesita especificar el método de acceso para cada
esquema URL.
En general, las URLs son de la siguiente forma:
<esquema>:<sección_específica_al_esquema>
Una URL contiene el esquema al cual corresponde, seguido de dos puntos
y posteriormente la cadena que localiza al recurso en cuestión, y cuya
interpretación pasa a ser responsabilidad del esquema.
Los nombres de los esquemas son secuencias de caracteres, dentro de
los que se permiten los literales "a".."z", los dígitos, los símbolos
"+", "." y "-". Para evitar confusiones, las interpretaciones de URLs
debieran ignorar distinciones entre mayúsculas y minúsculas (por
ejemplo, "HTTP" debiera permitirse y significar lo mismo que "http").
Codificación y caracteres especiales
Las URIs están compuestas de letras, dígitos y caracteres con
significado especial. Las convenciones sobre los caracteres especiales
son las siguientes:
Escape (%)
El signo porcentaje (hexadecimal 25) se usa para anular el
significado especial de los caracteres especiales.
Jerarquización (/)
El slash (hexadecimal 2F) se reserva para delimitar substrings
de relación estrictamente jerárquica. Las subcadenas "." y ".."
son igualmete reserados. EL significado del salsh entre dos
segmentos es que el segmento de la izquierda es más
significativo que el de la derecha.
Identificador de fragmentos (#)
El carácter "#" (hexadecimal 23) se reserva como delimitador
para separar la URI de un objecto de un identificador de
fragmento (resuelto en el cliente).
Prefijo de consulta (?)
Delimita la URI de un objeto suscetpible de ser consultado, de
la subcadena que representa la consulta en sí misma. Cuando se
usa una URI con una consulta, la URI resultante referencia al
objeto que resulta de aplicar la consulta al objeto original.
Dentro de la cadena de consulta, el símbolo "+" se reserva como
una abreviación del espacio (" "). Por lo tanto, paa colocar un
signo "+" tal cual debe codificarse. Este método fue
establecido para facilitar el traspaso de URIs con consultas a
sistemas que no permiten espacios.
Otros (*, !)
EL asterisco ("*", hexadecimal 2A) y el signo de exclamación
("!", hexadecimal 21) se reservan para darles un significado
especial dentro de los esquemas específicos.
Además, la forma canónica de las URIs establece que algunos
caracteres, como el espacio (" "), caracteres de control, aquellos que
varián su codificación en ASCII de 7 bits al pasar de un set
nacionalizado a otro, y todos los caracteres de 8 bits más allá del 7F
hexadecimal (DEL) del set ISO Latin-1, nodebieran usarse sin
codificar. Esta codificación utiliza el símbolo de escape "%", seguido
por dos sígitos hexadecimales (0-9, A-F), que corresponden al código
del craácter en ISO Latin-1.
Jerarquizaciones y formas relativas de URIs
Cuando se referencia una URL absoluta desde el contexto de un
documento, se está incluyendo mucha información tal vez ya conocida, y
que podría extraerse del contexto del documento original (como por
ejemplo el esquema, la ubicación dentro de la red, y partes de la ruta
de acceso). En estos casos es cuando se justifica usar URL's
relativas. En ellas se identifica el recurso describiendo la
diferencia con un espacio de nombres jerárquico ente el contexto
actual y un identificador absoluto del recurso
Algunos esquemas URI soportan un sistema de nombres jerárquico, donde
la jerarquía del nombre se denota por el delimitador "/" ente
componentes del esquema. Esta forma de jerarquización es independiente
del esquema y puede ser usada junto con una URI "base" para producir
otra URI.
Algunos de los esquemas URL existentes hoy en día son:
ftp File Transfer protocol
http Hypertext Transfer Protocol
gopher The Gopher protocol
mailto Electronic mail address
news USENET news
nntp USENET news using NNTP access
telnet Reference to interactive sessions
wais Wide Area Information Servers
file Host-specific file names
prospero Prospero Directory Service
Sintaxis usual
Mientras que la sintaxis para el resto de la URL puede variar
dependiendo del esquema del que se trate, los esquemas URL que
incluyen el uso directo de un protocolo basado en IP a un host
específico en Internet usan una sintaxis común para la parte
específica al esquema:
//<user>:<password>@<host>:<port>/<url-path>
Algunas de o todas las partes (exceptuando <host>) pueden ser
omitidas. Se comienza con un doble slash para indicar que se ajusta a
la sintaxis común de Internet. Cada una de las partes se explica a
continuación:
user
Algunos esquemas (como el ftp) permiten especificar un username
(opcionalmente)
password
Si se presenta, debe estar separado del username por dos puntos
(":")
El username (o el password), de estar presente, debe ir seguido
de un símblo arroba "@" al final. Dentro del username y el
password, cualquier ":", "@" o "/" debe estar respectivamente
codificado.
host
Un nombre de dominio (completo) o host, o su dirección IP.
port
El número del puerto al cual conectarse. La mayoría de los
protocolos tienen ya un número de puerto asignado por defecto.
url-path
El resto corresponde a datos específicos del esquema, y
contiene detalles de cómo el recurso especificado debiera ser
accedido. El "/" entre el host (o número de puerto) y el
url-path noes parte del url-path.
Ejemplo: FTP
El esquema URL para FTP es usado para designar archivos y directorios
en hosts alcanzables por medio del protocolo FTP en Internet.
Una URL de FTP sigue la sintaxis usual descrita anteriormente. Si se
omite :<port>, se toma el valor por defecto, 21
Nombre y password
Si se especifican un username y password como se definió en el
punto anterior, éstos se utilizan en los comandos ftp "USER" y
"PASS" luego de realizar la conexión con del servidor FTP. Si no
se provee ninguno de los dos y el servidor los requiere, se
utilizan las convenciones de FTP anónimo, que son:
- Se suministra el usename "anonymous".
- El password entregado es la dirección e-mail del usuario accediendo al recurso.
Si la URL incluye un username pero no un password, y el servidor
remoto requiere un password, el programa que esté interpretando la
URL FTP debiera pedírselo al usuario.
url-path de FTP
El url-path de una URL FTP tiene la siguiente sintaxis:
<cwd1>/<cwd2>/.../<cwdN>/<name>;type=<typecode>
Donde <cwd1> hasta <cwdn> y <name> son cadenas (posiblemente
codificadas) y <typecode> es uno de los caracteres "a", "i" o "d".
Esta última parte puede además ser omitida, así como también toda
la parte del url-path (incluyendo el "/").
El url-path es interpretado de la siguiente forma:
- Cada uno de los elementos <cwd> es suministrado como argumento al comando CWD, secuencialmente.
- Si el <typecode> es "d", realizar un comando NLST (listar nombres) con <name> como argumento, e iterpretar los resultados como un listado de directorio.
- De otro modo, ejecutar un comando TYPE con <typecode> como argumento, y luego acceder al archivo cuyo nombre es <name> (usando, por ejemplo, el comando RETR)
Registro de nuevos esquemas
Se introduce un nuevo esquema, definiendo el mapeado correspondiente
según la sintaxis de URLs, y usando un prefijo nuevo. En particular,
los esquemas URL en experimentación son utilizables en común acuerdo
entre las partes involucaradas (los esquemas con nombres que comiencen
en "x-" se reservan para experimentación).
Se mantiene un registro de esquemas URL, a cargo de IANA (Internet
Assigned Numbers Authority). Cualquier proposición de esquema URL debe
incluir la definición de un algoritmo de acceso a recursos
localizables dentro de ese esquema, y la sintaxis para representarla.
Los esquemas deben ser (demostrablemente) útiles y operables. Deben
tratar, además, de seguir las mismas convenciones sintácticas de los
ya existentes.
Seguridad
Un esquema URL no es en sí una amenaza a la seguridad. Los usuarios
debieran estar al tanto de que no hay una garantía general de que una
el objeto referenciado por una URL sea siempre el mismo.
La amenaza de seguridad relativa a las URLs consiste en que algunas
veces es posible construir una URL tal que un intento por realizar
alguna operación inocua (como recuperar el objeto) cause en realidad
una operación remota peligrosa. Esta URL insegura aparece por lo
general cuando se especifica un puerto distinto del asignado por
defecto al protocolo en cuestión. El cliente desinformadamente
contacta a un servidor que está atendiendo oyto protocolo por ese
puerto; y los contenidos de la URL le proveen instrucciones le proveen
instrucciones a este protocolo, que pueden causar resultados
inesperados. (Por ejemplo, gonectar a un cliente gopher al pueto SMTP
de un servidor puede ocasionar que se distribuyan mensajes de
contenido "bizarro", por decir lo menos). Es por esto que se debe ser
muy cauteloso al usar una URL que especifique un puerto distinto de
asignado al protocolo, sobre todo cuando este nombre "choca" con
alguno también ya definido.
Otro riesgo se da cuando la url contiene (codificados) delimitadores
para un cierto protocolo (por ejemplo, CR y LF en el caso de telnet)
que no hayan sido decodificados antes de ser transmitidos. Esto
ocasionaría que se simulara un parámetro u operación extra, causando
tal vez que se ejecutara alguna operación dañina.
Por último, es obviamente no recomendable el utilizar URLs que
contenags passwords que no deban ser dadas a conocer
- Berners-Lee, T., "Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression Objects on the Network as used in the World-Wide Web", RFC 1630, CERN, June 1994.
- Berners-Lee, T., Masinter, L., and M. McCahill, Editors, "Uniform Resource Locators (URL)", RFC 1738, CERN, Xerox Corporation, University of Minnesota, December 1994.
- Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD 9,
- RFC 959, USC/Information Sciences Institute, October 1985.
La siguiente es la gramática en BNF que corresponde a la
especificación de URI.
URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ]
absoluteURI = scheme ":" ( hier_part | opaque_part )
relativeURI = ( net_path | abs_path | rel_path ) [ "?" query ]
hier_part = ( net_path | abs_path ) [ "?" query ]
opaque_part = uric_no_slash *uric
uric_no_slash = unreserved | escaped | ";" | "?" | ":" | "@" |
"&" | "=" | "+" | "$" | ","
net_path = "//" authority [ abs_path ]
abs_path = "/" path_segments
rel_path = rel_segment [ abs_path ]
rel_segment = 1*( unreserved | escaped |
";" | "@" | "&" | "=" | "+" | "$" | "," )
scheme = alpha *( alpha | digit | "+" | "-" | "." )
authority = server | reg_name
reg_name = 1*( unreserved | escaped | "$" | "," |
";" | ":" | "@" | "&" | "=" | "+" )
server = [ [ userinfo "@" ] hostport ]
userinfo = *( unreserved | escaped |
";" | ":" | "&" | "=" | "+" | "$" | "," )
hostport = host [ ":" port ]
host = hostname | IPv4address
hostname = *( domainlabel "." ) toplabel [ "." ]
domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum
toplabel = alpha | alpha *( alphanum | "-" ) alphanum
IPv4address = 1*digit "." 1*digit "." 1*digit "." 1*digit
port = *digit
path = [ abs_path | opaque_part ]
path_segments = segment *( "/" segment )
segment = *pchar *( ";" param )
param = *pchar
pchar = unreserved | escaped |
":" | "@" | "&" | "=" | "+" | "$" | ","
query = *uric
fragment = *uric
uric = reserved | unreserved | escaped
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
"$" | ","
unreserved = alphanum | mark
mark = "-" | "_" | "." | "!" | "~" | "*" | "'" |
"(" | ")"
escaped = "%" hex hex
hex = digit | "A" | "B" | "C" | "D" | "E" | "F" |
"a" | "b" | "c" | "d" | "e" | "f"
alphanum = alpha | digit
alpha = lowalpha | upalpha
lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" |
"j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" |
"s" | "t" | "u" | "v" | "w" | "x" | "y" | "z"
upalpha = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" |
"J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" |
"S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z"
digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
"8" | "9"
| 
