URI (en el Tesauro)

Localizador uniforme de recursos o localizador universal de recursos

Partición de URI

Existe cierta confusión en la comunidad web sobre la partición del espacio URI, concretamente, sobre la relación entre los conceptos de URL, URN y URI. La confusión se debe a la incompatibilidad entre dos puntos de vista diferentes de la partición de URI, que llamamos los puntos de vista “clásico” y “contemporáneo”.

Visión clásica

Durante los primeros años de debate sobre los identificadores web (de principios a mediados de los 90), se asumía que un tipo de identificador se clasificaría en una de las dos (o posiblemente más) clases. Un identificador puede especificar la ubicación de un recurso (una URL) o su nombre (un URN) independientemente de la ubicación. Así, un URI puede ser una URL o un URN. Se debatió la posibilidad de generalizar esto añadiendo un número discreto de clases adicionales; por ejemplo, un URI podría apuntar a metadatos en lugar de al propio recurso, en cuyo caso el URI sería un URC (cita). Así, el espacio URI se consideró dividido en subespacios: URL y URN, y otros subespacios adicionales, por definir. El único espacio adicional que se propuso fue el URC y nunca se aceptó; así que, sin pérdida de generalidad, es razonable decir que el espacio URI se consideraba dividido en dos clases: URL y URN. Así, por ejemplo, “http:” era un esquema URL y “isbn:” sería (algún día) un esquema URN. Cualquier esquema nuevo se incluiría en una u otra de estas dos clases.

Visión contemporánea

Con el paso del tiempo, la importancia de este nivel adicional de jerarquía pareció disminuir; se llegó a la conclusión de que un esquema individual no tiene que ser incluido en uno de un conjunto discreto de tipos de URI como “URL”, “URN”, “URC”, etc. Los esquemas de identificación web son, en general, esquemas URI; un esquema URI determinado puede definir subespacios. Así, “http:” es un esquema URI. “urn:” también es un esquema URI; define subespacios, llamados “namespaces”. Por ejemplo, el conjunto de URNs de la forma “urn:isbn:n-nn-nnnn-n” es un espacio de nombres URN. (“isbn” es un identificador de espacio de nombres URN. No es un “esquema URN” ni un “esquema URI”).

Además, según la visión contemporánea, el término “URL” no se refiere a una partición formal del espacio URI; más bien, URL es un concepto útil pero informal: una URL es un tipo de URI que identifica un recurso a través de una representación de su mecanismo de acceso primario (por ejemplo, su “ubicación” en la red), en lugar de por otros atributos que pueda tener. Así, como hemos señalado, “http:” es un esquema URI. Un URI http es una URL. La frase “esquema URL” se utiliza ahora con poca frecuencia, normalmente para referirse a alguna subclase de esquemas URI que excluye los URN.

Confusión

El conjunto de documentos (RFCs, etc.) que cubren la arquitectura, la sintaxis, el registro, etc. de las URI, abarca tanto la época clásica como la contemporánea. Las personas versadas en temas de URI tienden a utilizar “URL” y “URI” de forma que parecen ser intercambiables. Entre estos expertos, esto no es un problema. Pero entre la comunidad de Internet en general, sí lo es. La gente no está convencida de que URI y URL signifiquen lo mismo, en documentos en los que (aparentemente) sí lo hacen. Cuando uno ve una RFC que habla de esquemas URI (por ejemplo, [RFC 2396]), otra que habla de esquemas URL (por ejemplo, [RFC 2717]), y otra que habla de esquemas URN ([RFC 2276]) es natural preguntarse cuál es la diferencia, y cómo se relacionan entre sí. Aunque el RFC 2396 1.2 intenta abordar la distinción entre URIs, URLs y URNs, no ha conseguido aclarar la confusión.

Registro

Esta sección examina el estado del registro de los esquemas URI y de los espacios de nombres URN, así como los mecanismos por los que se realiza actualmente el registro.

Esquemas URI

Cabe distinguir entre:

• Esquemas URI registrados. El registro oficial de nombres de esquemas URI lo mantiene IANA, en http://www.iana.org/assignments/uri-schemes . Para cada esquema, se enumera la RFC que lo define, por ejemplo, “http:” está definido por [RFC 2616]. La tabla contiene actualmente 30 esquemas. Además, hay algunos nombres de esquemas “reservados”; en un momento dado se pretendía que se convirtieran en esquemas registrados, pero desde entonces se han eliminado.
• Esquemas URI no registrados. Distinguimos entre regímenes públicos (no registrados) y privados. Un esquema público (registrado o no), es aquel para el que existe algún documento público que lo describe.
• Registro de esquemas URI. El [RFC 2717] especifica los procedimientos para el registro de los nombres de los esquemas, y apunta al [RFC 2718] que proporciona directrices. El RFC 2717 describe una organización de esquemas en “árboles”.

Respecto a los esquemas URI no registrados:

• Esquemas públicos no registrados. Existe mantiene una lista de esquemas URI públicos conocidos, tanto registrados como no registrados, un total de 84 esquemas. Unos 50 de ellos no están registrados (no figuran en el registro de la IANA). Algunos pueden ser obsoletos (por ejemplo, parece que “phone” es obsoleto, superado por “tel”). Algunos tienen una RFC, pero no están incluidos en la lista de IANA.
• Esquemas privados. Probablemente sea imposible determinar todos ellos, y no está claro que merezca la pena intentarlo, excepto quizás para tener una idea de su número. En las actas de la reunión del IETF de agosto de 1997 se señala que puede haber entre 20 y 40 en uso en Microsoft, con 2-3 añadidos al día, y que WebTV tiene 24, con 6 añadidos al año.

Respecto al registro de esquemas URI:

• Árbol IETF. El árbol del IETF está pensado para esquemas de interés general para la comunidad de Internet, y que requieren un proceso de revisión y aprobación sustantivo. El registro en el árbol del IETF requiere la publicación de la sintaxis y la semántica del esquema en una RFC.
• Otros árboles. Aunque el RFC 2717 describe “árboles alternativos”, hasta la fecha no se ha registrado ningún árbol alternativo, aunque está pendiente un árbol suministrado por un proveedor (“vnd”). Los esquemas URI en árboles alternativos se distinguirán porque tendrán un “.” en el nombre del esquema.

Espacios de nombres URN

Un espacio de nombres URN se identifica mediante un “ID de espacio de nombres”, NID, que se registra en la IANA.

NIDs URN pendientes

Hay una serie de solicitudes de registro de NIDs URN pendientes, pero no hay una forma fiable de descubrirlos, ni su estado. Por ejemplo, ‘isbn’ y ‘nbn’ han sido aprobados por el IESG y están en la cola del Editor de RFC. En particular, “isbn”, como potencial espacio de nombres URN (o esquema URI), ha sido una fuente de mucha especulación y confusión durante varios años. Sería útil que hubiera algún medio formal para seguir el estado de las solicitudes de NID como ‘isbn’.

NID no registrados

En la categoría de “no registrados” (además del caso experimental, que no se describe en este documento) hay NID de buena fe que simplemente no se han molestado en explorar el proceso de registro, y el más destacado que me viene a la mente es ‘hdl’. En el caso de “hdl”, se ha especulado que este esquema no se ha registrado porque los propietarios no tienen claro si debe registrarse como un esquema URI o como un espacio de nombres URN.

Procedimientos de registro para NIDs URN

Una solicitud de un NID debe describir características que incluyan: características estructurales de los identificadores (por ejemplo, características relevantes para los enfoques de almacenamiento en caché/acortados); reglas específicas de codificación de caracteres (por ejemplo, qué carácter debe utilizarse para las comillas simples); reglamentos, normas, etc., que expliquen la estructura del espacio de nombres; consideraciones sobre la unicidad de los identificadores; delegación de la autoridad de asignación, incluyendo cómo convertirse en asignador de identificadores; consideraciones sobre la persistencia de los identificadores; consideraciones sobre la calidad del servicio; proceso para la resolución de los identificadores; reglas de equivalencia léxica; cualquier consideración especial necesaria para ajustarse a la sintaxis del URN (particularmente aplicable en el caso de los sistemas de nomenclatura heredados); mecanismos de validación (para determinar si una cadena dada es actualmente un URN válidamente asignado; y alcance (por ejemplo, “números de la seguridad social de Estados Unidos”).