Resumen

  • En la revisión 04 del borrador EPP sobre HTTPS, una respuesta HTTP 200 puede envolver tanto el éxito como el fracaso de la orden EPP; el código web no expresa el veredicto del registro.
  • Si no llega una respuesta EPP válida y la orden pudo alcanzar la capa de procesamiento, el resultado es indeterminado. Un reintento sólo corresponde al cliente que conoce la semántica idempotente de la orden completa y sus extensiones.
  • Un recibo de disposición debe unir las trazas HTTP y EPP, mantener el bloqueo de orden y dejar constancia de quién decidió reintentar, abandonar o conciliar.

Hay indicadores que, por costumbre, parecen hablar por sí solos. Un 200 aparece verde, suma disponibilidad y cierra una alarma. Esa lectura puede ser razonable para saber si una aplicación web respondió. Es insuficiente para saber qué hizo un registro con una orden EPP transportada dentro de esa respuesta.

draft-ietf-regext-epp-https-04, publicado el 3 de septiembre de 2026, formaliza la separación. Una vez que la solicitud alcanza la capa de procesamiento EPP y el servidor genera una respuesta EPP, la envoltura HTTP debe usar 200 sin importar si la operación EPP terminó bien o mal. El éxito del transporte significa que hay un mensaje aplicativo que leer; no sustituye su contenido.

También puede ocurrir lo contrario. Una respuesta de un intermediario por saturación, límite de solicitudes, tipo de medio no admitido o fallo de pasarela describe un resultado HTTP. Si la orden pudo llegar al procesamiento EPP pero el cliente no recibió una respuesta EPP válida, no existe un fracaso autoritativo. El borrador lo llama resultado indeterminado.

Ese tercer estado es el centro de la cuestión. Un registro y un registrador pueden no saber todavía si una creación, renovación, transferencia, modificación o eliminación cambió el objeto compartido. Si la automatización convierte ese desconocimiento en «falló» y vuelve a enviar, ya ha tomado una decisión que pertenece a la semántica EPP, no a la recuperación genérica de HTTP.

Una sesión estatal dentro de una infraestructura que espera solicitudes sueltas

RFC 5730 define EPP como un protocolo XML con estado y orden. El cliente inicia cada intercambio y el servidor devuelve una respuesta coordinada. Las órdenes son atómicas y se diseñaron para que puedan hacerse idempotentes. El transporte debe preservar el orden, explicar la relación entre sesión y conexión y declarar si permite canalización.

La propuesta HTTPS comienza con un POST vacío. Sólo un HTTP 200 que contenga el saludo EPP y establezca la sesión mediante cookie crea la conexión EoH. El login satisfactorio abre después la sesión EPP autenticada. Cada solicitud posterior lleva una única orden; cada respuesta procesada contiene una única respuesta EPP.

Usar el puerto 443 y componentes web comunes reduce fricción operativa. No convierte EPP en una API sin estado. El propio borrador describe el mapeo como un túnel y limita deliberadamente caché, multiplexación, autenticación de infraestructura, registro y reintentos automáticos. La plataforma presta transporte; no adquiere autoridad para interpretar la operación de registro.

La regla del identificador de sesión lo demuestra. Si una orden con cookie vacía o inválida llega al procesamiento EPP, el servidor debe devolver el error EPP 2002 dentro de HTTP 200. Mirar sólo el estado exterior invertiría el resultado.

«Indeterminado» es una conclusión, no una carencia de disciplina

Un parte de incidente suele exigir una casilla binaria. La operación tuvo éxito o fracasó. Sin embargo, cuando falta la respuesta EPP, ninguna de esas etiquetas está respaldada si no puede descartarse que el servidor procesara la solicitud. Forzar una etiqueta no añade información; sólo oculta la incertidumbre.

Mantener el estado indeterminado impone tres obligaciones. Primero, no atribuir al servidor un rechazo que no consta. Segundo, no confirmar al usuario una transformación sin una respuesta o conciliación suficiente. Tercero, impedir que órdenes posteriores vuelvan imposible reconstruir la secuencia.

No se trata de dramatizar una pérdida de paquetes. La incertidumbre puede resolverse pronto con una traza del servidor, una consulta del objeto, una respuesta recuperada o un procedimiento bilateral. Pero la consulta del estado actual no siempre identifica la causa: el objeto pudo existir antes, haber sido cambiado por otra orden o reflejar un proceso pendiente. La prueba de estado y la prueba de disposición no son necesariamente la misma cosa.

Idempotencia de la orden completa

RFC 9110 no define POST como método idempotente. Aconseja no repetirlo automáticamente salvo que el cliente sepa que la semántica real es idempotente o pueda demostrar que la primera solicitud no se aplicó. Además, un proxy no debe reintentar automáticamente solicitudes no idempotentes.

La revisión 04 añade una prueba específica. El cliente EoH puede reintentar cuando la causa sea posiblemente transitoria, el significado del estado HTTP lo permita y conozca la idempotencia aplicativa de toda la orden EPP, incluidas las extensiones. Debe enviar la misma orden y conservar el clTRID si estaba presente. Hasta obtener una respuesta válida o abandonar la sesión, no puede enviar la orden siguiente.

La palabra «completa» evita una atajo frecuente. Clasificar el verbo base no basta. Una extensión puede imponer condiciones, añadir datos o alterar efectos. La idempotencia debe pertenecer al mensaje realmente emitido bajo la versión de servicio realmente activa. Si esa evidencia no existe, la abstención no es pasividad: es la única política compatible con lo que se sabe.

El intermediario queda fuera de esa decisión. Puede conocer el tiempo de espera, pero no el objeto, la extensión, el contrato de deduplicación ni la secuencia EPP. El borrador exige a los operadores desactivar los reintentos automáticos de POST EPP en los intermediarios bajo su control. Una regla genérica de resiliencia no debe convertirse en autora invisible de una segunda orden.

Un identificador no es un resultado

RFC 5730 permite que el cliente incluya un clTRID, único dentro del espacio que él administra. La respuesta combina ese valor con un svTRID asignado por el servidor. Sirven para sincronizar orden y respuesta; deben registrarse, conservarse y protegerse.

El borrador exige el mismo clTRID en un reintento permitido. Eso mantiene la correlación entre intentos. No hay en esas normas una afirmación de que todo servidor trate por sí solo el clTRID repetido como clave universal de deduplicación. Si un servicio ofrece tal promesa, hay que citar su contrato, alcance, versión y tratamiento de extensiones. Confiar en ella sin evidencia transforma una etiqueta de rastreo en una garantía imaginaria.

El svTRID, cuando existe, es igualmente importante: muestra que se produjo una respuesta concreta en el lado servidor. Cuando falta porque la respuesta nunca llegó, no debe inventarse ni sustituirse con el identificador de un proxy. El espacio vacío forma parte del expediente.

La prohibición de concurrencia conserva causalidad

HTTP/2 y HTTP/3 admiten multiplexación. La propuesta EoH no la traduce en ejecución concurrente de órdenes. Un cliente no puede tener más de una solicitud pendiente por sesión EPP. Si un intermediario genera concurrencia, el servidor debe definir si rechaza o serializa.

El beneficio principal no es sólo técnico. Las transformaciones pueden depender unas de otras. Una actualización puede presuponer una creación; una transferencia puede cambiar la autoridad de quien pide la siguiente modificación. Si la primera queda indeterminada y se acepta la segunda, varias historias pueden explicar el resultado final. Se pierde la capacidad de atribuir causa y responsabilidad.

Abandonar la sesión corta la cadena, pero no decide retroactivamente la orden. La conciliación continúa fuera de esa sesión hasta reunir una respuesta válida o evidencia acordada. Abrir una conexión nueva sin trasladar el caso pendiente crea continuidad de tráfico, no continuidad de conocimiento.

El recibo de disposición

La solución mínima es un objeto que una las dos capas. No necesita imponer una base de datos común, pero sí conservar campos que ningún log aislado contiene completos:

  1. tipo de orden, objeto afectado y huella del XML íntegro con extensiones;
  2. identidad de sesión, clTRID e identificador de cada intento HTTP;
  3. hora de envío y frontera a partir de la cual ya no puede probarse la no entrega;
  4. estado HTTP y componente que lo emitió;
  5. código EPP y svTRID, si llegó una respuesta válida;
  6. disposición explícita: éxito resuelto, fracaso resuelto o indeterminado;
  7. fuente y versión de la evaluación de idempotencia;
  8. bloqueo que impidió admitir una orden posterior;
  9. persona o política autorizada que decidió reintentar, abandonar o conciliar;
  10. prueba de cierre, momento, confianza y discrepancias residuales.

El enfoque de especificación inicial mínima de Lu Heng ofrece la proporción adecuada: estandarizar el núcleo que permite rendir cuentas y dejar que cada operador elija almacenamiento y flujo de soporte. El recibo puede ser un evento firmado, un caso compartido o una unión protegida de registros. No debe contener una ficción binaria para facilitar una gráfica.

The Policy Mirror hace visible el reparto de poder. ¿Quién obtiene la capacidad de repetir una transformación? ¿Quién soporta el coste si el intento inicial ya se aplicó? ¿Quién puede cuestionar la prueba? Si la capa web recibe el beneficio de una disponibilidad aparente y exporta el riesgo al registrador o al titular, un ajuste técnico está distribuyendo derechos y pérdidas.

Un borrador avanzado sigue siendo un borrador

La revisión 04 es un documento activo del grupo REGEXT con intención de Standards Track. No es un RFC ni ha terminado la evaluación del IESG; vence el 7 de marzo de 2027. El hito de septiembre de 2026 para enviarlo a publicación es una meta, no un hecho consumado.

La sección de implementaciones cita un SDK de Verisign y trabajo de IIT-CNR/Registro.it. El aviso basado en RFC 7942 dice que la información aportada por participantes no fue verificada por el IETF, no supone respaldo y no constituye catálogo. Es una señal de experimentación, no una auditoría de los despliegues ni de sus políticas de reintento.

La entrada de IANA descrita en el texto también es propuesta. Hasta que el proceso correspondiente la materialice, no se debe hablar de ella como registro activo. La disciplina semántica que pedimos al operador debe aplicarse primero al estado de la norma.

Fuentes

  1. IETF — EPP Transport over HTTPS, revisión 04
  2. Datatracker — ficha del documento
  3. Datatracker — historial
  4. Grupo de trabajo REGEXT
  5. RFC 5730 — Extensible Provisioning Protocol
  6. RFC 5731 — mapeo de nombres de dominio en EPP
  7. RFC 5734 — transporte EPP sobre TCP
  8. RFC 9110 — semántica HTTP
  9. RFC 7942 — conocimiento del código en ejecución
  10. IANA — Extensions for EPP
  11. Lu Heng — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  12. Lu Heng — The Policy Mirror