Resumen

  • draft-ietf-regext-epp-https-04, fechado el 3 de septiembre de 2026, es trabajo activo del grupo REGEXT. No es una RFC, una aprobación de la IETF ni constancia de despliegue.
  • Si el servidor genera una respuesta EPP, la devuelve dentro de HTTP 200 (OK) tanto para éxito como para error de la orden. El estado HTTP no sustituye al resultado EPP.
  • Si la orden pudo llegar al procesamiento y no aparece una respuesta EPP válida, el resultado queda indeterminado. Los intermediarios no deben reintentar; solo el cliente que conoce la idempotencia de la orden completa puede decidirlo, conservando identificador y secuencia.

Imagine una consola con dos líneas. En la primera, el balanceador informa 200. En la segunda, el registro responde que la orden no puede usarse en esa sesión. Las dos son correctas. Borrar una no simplifica el incidente; borra la realidad que el otro sistema no puede observar.

El nuevo borrador de EPP sobre HTTPS define esa separación con especial precisión. EPP es un protocolo XML con estado para aprovisionar objetos en un repositorio compartido. RFC 5730 exige orden, sesiones persistentes y respuestas coordinadas. La propuesta no convierte EPP en REST. Usa POST y respuestas HTTP como transporte de la conversación existente.

La conexión nace con un POST vacío a una URL entregada fuera de banda. Una apertura válida devuelve el saludo EPP, el tipo application/epp+xml, no-store, nosniff y una cookie que identifica la conexión. Después, un <login> EPP correcto crea la sesión autenticada.

El 200 pertenece a la envoltura

Cada POST posterior transporta una sola orden y cada respuesta transporta una respuesta EPP. Cuando la solicitud alcanza la capa EPP y ésta produce una respuesta, el servidor usa HTTP 200 aunque el código EPP indique rechazo. El dato operativo está en ambos niveles.

Los 4xx y 5xx quedan para resultados HTTP: solicitud mal formada, tipo de contenido no admitido, límite de tamaño, tasa, sobrecarga o fallo de gateway. Esos códigos explican que no se recibió una respuesta EPP autoritativa. No demuestran por sí solos qué ocurrió en el repositorio.

Una cookie incorrecta ofrece el ejemplo más limpio. Si la solicitud llega al procesador EPP, éste devuelve el código EPP 2002, error de uso de orden, dentro de HTTP 200. Un gráfico que llame “operación correcta” a cada 200 contará un rechazo explícito como éxito.

Por eso hacen falta dos libros. El libro HTTP registra recepción, tránsito y entrega a la capa de aplicación. El libro EPP registra la decisión sobre el objeto. El identificador de transacción del cliente une ambos y permite reconocer que un intento posterior pertenece a la misma intención.

El tiempo agotado no deshace la orden

La respuesta perdida abre un tercer estado. Una orden de transformación puede atravesar el gateway, ejecutarse y cambiar el repositorio. Si la respuesta se pierde de vuelta, el cliente carece tanto de confirmación como de rechazo. El borrador no inventa una certeza: lo llama resultado indeterminado.

Una política genérica de reintento puede agravar el problema. HTTP no considera POST idempotente. EPP diseña sus órdenes para que puedan hacerse idempotentes, pero eso no garantiza que cada orden concreta, con todas sus extensiones, lo sea. La infraestructura web ve bytes y un timeout; el cliente EoH conoce la operación.

La revisión 04 exige que esa autoridad permanezca en el cliente. Reintentar solo es posible si la falla parece transitoria, el estado HTTP lo permite y la semántica completa es idempotente. La repetición conserva exactamente la orden y el identificador de transacción. El cliente no envía la siguiente hasta recibir una respuesta válida o abandonar la sesión. Los proxies, balanceadores y demás intermediarios bajo control del operador deben tener desactivado el reintento automático.

El orden es parte del resultado. Cambiar el identificador convierte una recuperación en una aparente segunda instrucción. Dejar adelantar otra orden obliga a interpretarla sobre un estado desconocido. Permitir que un proxy repita traslada autoridad desde el componente que entiende EPP al componente que solo vio una interrupción.

HTTP puede distribuir conexiones, no la causalidad

HTTP/2 y HTTP/3 ofrecen multiplexación. EoH, sin embargo, prohíbe más de una solicitud pendiente por sesión EPP. Un intermediario todavía puede producir concurrencia, por lo que el servidor debe serializarla o rechazarla de forma definida.

La cookie representa una conexión lógica aunque sus mensajes circulen por varias conexiones HTTP. En un clúster, el operador puede fijar la sesión a una instancia o guardar el estado en un almacén compartido. La afinidad pierde conexiones activas cuando cae la instancia, salvo que exista réplica. El almacén compartido mejora el failover, pero pasa a formar parte del perímetro de seguridad y disponibilidad.

Las órdenes de una conexión deben procesarse en secuencia y las mutaciones de estado deben ser atómicas. Además, la expiración del almacén, de la sesión HTTP y de la sesión EPP tiene que coincidir. Una página de salud del frontend no prueba que sobreviva la conversación registral.

El borrador cita un SDK de Verisign en desarrollo para HTTP/1.1 y HTTP/2, y una variante de Registro.it en producción desde 2009. También advierte que son declaraciones de contribuidores no verificadas por la IETF. Sirven como señal de experimentación, no como auditoría de conformidad ni medida de adopción.

La separación de capas de realidad propuesta por Heng Lu permite leer toda la cadena: transporte, decisión EPP, objeto almacenado, publicación DNS y observación del usuario. La primacía del código en ejecución indica dónde debe vivir la autoridad de recuperación: junto al componente que entiende la orden, conserva su identidad y puede consultar el estado autoritativo.

HTTPS aporta infraestructura conocida. No aporta permiso para confundir entrega con decisión.

Fuentes