Resumen
- THTTP codificaba solicitudes y respuestas de servicios de resolución URN mediante HTTP 1.0 o HTTP 1.1.
- Alcanzar un servidor o recibir una URL no acredita quién asignó el nombre, quién autoriza la respuesta, si hay acceso permitido o si la recuperación fue correcta.
La palabra «trivial» del título de RFC 2169 describe una estrategia de despliegue. Un servidor HTTP existente podía añadir un manejador CGI, leer el URN y el servicio solicitado y devolver una respuesta normal. Así se podía experimentar con resolución sin exigir una nueva pila de protocolo.
El RFC distinguía N2L, que solicita una URL, de N2R, que solicita el recurso identificado. También dejaba vigentes los códigos de estado, la negociación de representación y el caché de HTTP. Esas piezas no son una cadena de autoridad: la elección del resolutor, la administración del espacio de nombres y la custodia del contenido pueden pertenecer a actores distintos.
RFC 2141 ayuda a ver el límite. Define la forma sintáctica y la equivalencia léxica de los URN; la equivalencia funcional corresponde a la práctica de cada namespace. RFC 2169 exigía respuestas iguales para formas léxicamente equivalentes, pero no designaba un resolutor universal ni declaraba que una cabecera Location validase el derecho sobre el nombre.
Por eso una observación HTTP tiene alcance reducido. Una respuesta 200 muestra una decisión temporal de un endpoint. Una redirección muestra una ubicación ofrecida. Una respuesta N2R puede entregar bytes. Ninguno de esos hechos prueba asignación por el namespace, vigencia del mandato, integridad del contenido, autorización del cliente o concordancia de otros resolutores.
RFC 3406 describió después la asignación de URN como proceso gestionado y la resolución global como un registro separado. El registro actual de namespaces URN de IANA, bajo RFC 8141, documenta namespaces reconocidos. No revive ni certifica por sí mismo un resolutor THTTP histórico.
La lección de RFC 2169 es operativa: una convención puede ser útil precisamente porque no finge resolver los problemas de autoridad que quedan fuera de su perímetro.
Fuentes y límites de evidencia
Este análisis usa RFC 2169, 2141, 1737, 3401, 3406, 8141 y el registro IANA. No aportan una medición completa de adopción de THTTP ni prueban la autoridad presente de un endpoint concreto.
- https://www.rfc-editor.org/rfc/rfc2169.html
- https://www.rfc-editor.org/rfc/rfc2141.html
- https://www.rfc-editor.org/rfc/rfc1737.html
- https://www.rfc-editor.org/rfc/rfc3401.html
- https://www.rfc-editor.org/rfc/rfc3406.html
- https://www.rfc-editor.org/rfc/rfc8141.html
- https://www.iana.org/assignments/urn-namespaces
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance
