Resumen
- Mark Nottingham propuso «HTTP/3» para que el mapeo de la semántica HTTP sobre QUIC se entendiera como una función de HTTP distinta del transporte QUIC.
- Su mensaje unió el nombre con una propuesta institucional: tras la publicación, el grupo HTTP mantendría HTTP/3 y QPACK. Las cartas de la IETF documentan después esa asignación.
- La frontera hizo más visible quién decide y mantiene cada parte, pero no convirtió el nombre en una garantía técnica, una decisión personal de Nottingham ni una prueba de despliegue.
Al final de 2018, «QUIC» podía referirse tanto al protocolo de transporte como al mapeo que permitía ejecutar HTTP sobre él. Para quienes no seguían el trabajo de cerca, ambos asuntos empezaban a confundirse. La dificultad no era meramente editorial: si transporte y protocolo de aplicación parecían un solo producto, también resultaba menos claro qué grupo debía decidir su futuro.
El 28 de octubre, Mark Nottingham escribió a la lista del grupo de trabajo QUIC. Propuso llamar «HTTP/3» al documento HTTP y usar h3 como identificador ALPN final. Su argumento era que el nombre mostraría otra forma de vincular la semántica HTTP con un protocolo en el cable, igual que había hecho HTTP/2, sin confundir esa capa con QUIC. El razonamiento aparece en su mensaje, no depende de una reconstrucción posterior.
La propuesta incluía una segunda parte. Una vez publicado el mapeo, planteó trasladar al grupo HTTP el mantenimiento de HTTP/3 y QPACK. No es lo mismo redactar un documento en el grupo que está desarrollando un transporte que asumir todas las decisiones sobre el protocolo de aplicación a largo plazo. El cambio de nombre aclaraba qué se estaba definiendo; la transferencia de mantenimiento decía dónde quedaría la responsabilidad futura.
La sala separó el apoyo del derecho a decidir
En IETF 103, el grupo QUIC debatió el nombre. Las actas registran desacuerdos: para algunos, HTTP/3 sonaba a sucesor de HTTP/2; otros temían que sugiriera una bifurcación. Nottingham recordó que HTTP/2 no había desaprobado ni reemplazado HTTP/1.1. Lo esencial, dijo en la discusión, era separar la semántica de HTTP del protocolo que la transportaba.
Las actas no describen una votación formal. Registran un «hum» informal, aproximadamente 70 a 30, a favor del nuevo nombre y un apoyo cercano a la unanimidad para dejar que HTTPbis decidiera. Esta segunda señal es la más reveladora. El trabajo había surgido en el grupo QUIC, pero nombrar una versión de HTTP correspondía a la comunidad HTTP. Nottingham lo expresó de forma directa: la denominación de HTTP debía permanecer en esa comunidad.
Su nota de octubre llevaba la marca «Chair hat». Pedía limitar la conversación en Bangkok y evitar una discusión interminable sobre nombres. Los desarrolladores y usuarios necesitaban una descripción comprensible, pero el grupo también debía avanzar en el trabajo técnico. La presidencia podía encuadrar la pregunta y cuidar el tiempo; no podía reemplazar el consenso con una instrucción propia.
El nombre solo funciona si las capas siguen a la vista
La especificación publicada mantiene esa distinción. RFC 9114 define HTTP/3 como un mapeo de la semántica HTTP sobre QUIC. RFC 9110 define esa semántica; RFC 9000 define el transporte QUIC. HTTP/3 aprovecha la entrega fiable y ordenada por flujo y las propiedades de seguridad de QUIC, pero conserva el significado de los mensajes y las decisiones de aplicación de HTTP. El nombre identifica el mapeo; no fusiona las capas.
El token ALPN h3 tampoco es un sinónimo intercambiable del nombre público. Es un identificador transmitido durante la negociación del protocolo. «HTTP/3» ayuda a clasificar la especificación y el trabajo; h3 permite que dos extremos negocien qué protocolo usar. Nottingham escribió que el nombre no quedaría formalizado ni se usaría en el cable hasta que se publicara la RFC. La comunidad conservaba así margen para cambiar de opinión antes de que el token condicionara la compatibilidad.
La transferencia de mantenimiento tampoco quedó en una consigna. La carta HTTPbis de 2018 decía que, una vez publicado HTTP/3 por el grupo QUIC, HTTPbis mantendría el protocolo y desarrollaría extensiones cuando fuera necesario, incluido QPACK. La carta vigente de HTTP incluye HTTP/3 y QPACK entre sus especificaciones centrales. La carta actual de QUIC dice que ese grupo originó el mapeo y QPACK, y que ahora se mantienen en el grupo HTTP.
La frontera no es una pared. El grupo QUIC todavía enumera trabajo sobre eventos qlog para HTTP/3, un punto donde la observabilidad del transporte y de la aplicación se cruzan. La distinción útil es quién mantiene el mapeo central y quién resuelve los mecanismos que pertenecen a QUIC. Los sistemas desplegados obligan a ambas comunidades a coordinarse donde esas capas se encuentran.
La publicación todavía necesita operadores
El nombre HTTP/3 no hace que un cliente lo ofrezca, que un servidor lo acepte ni que una ruta de red lo transporte correctamente. Una RFC publicada y un identificador ALPN registrado dan una referencia común. Las implementaciones todavía deben negociar, interoperar, gestionar alternativas y decidir si despliegan el protocolo. El nombre reduce una confusión de categorías; no mide adopción ni rendimiento.
El alcance de la propuesta es acotado, pero práctico. Una especificación puede fijar el significado de los mensajes HTTP y su mapeo sobre QUIC. Otra puede definir entrega, control de congestión y seguridad del transporte. Las cartas pueden indicar quién mantiene esos textos. Después, operadores e implementadores deciden cómo los usan. Cada registro responde a una pregunta distinta.
La contribución de Nottingham no fue que él bautizara HTTP/3 por sí solo ni que transfiriera personalmente su mantenimiento. Conectó el nombre público con una responsabilidad futura y defendió que el grupo HTTP decidiera el nombre. Las actas y las cartas muestran cómo se procesaron esas decisiones. La prueba para una nueva especificación es sencilla: ¿puede un lector identificar qué permanece común, qué cambia, quién mantiene cada parte y qué falta comprobar en las implementaciones?
Fuentes
- Mark Nottingham — “Identifying our deliverables” (28 de octubre de 2018)
- Actas del grupo QUIC en IETF 103
- Diapositivas de HTTPbis en IETF 103: responsabilidad de HTTP/QUIC
- Carta de HTTPbis, versión 08
- Carta vigente del grupo HTTP
- Carta vigente del grupo QUIC
- RFC 9114 — HTTP/3
- RFC 9110 — Semántica de HTTP
- RFC 9000 — QUIC, transporte multiplexado y seguro sobre UDP
- Borrador de trabajo QUIC-HTTP -16
- Borrador de trabajo QUIC-HTTP -18
- Documentos del grupo QUIC
- Datatracker de la IETF — Mark Nottingham
- Heng Lu — Especificación inicial mínima, decisión futura localizada y adopción voluntaria (marco editorial)
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
