Summary

  • El borrador RPP core, revisión 01, fechado el 2 de noviembre de 2026, lleva a HTTP la gestión de objetos compartidos como los dominios. El borrador de objetos de datos define el modelo por separado.
  • Transferir un dominio cambia el cliente que lo patrocina, pero RPP representa el traslado como un objeto de proceso. El registrador que lo inicia envía POST /domainNames/{name}/processes/transferProcesses; el ejemplo devuelve 201 Created y una URL del proceso en Location.
  • Quien inició la solicitud puede cancelar un proceso pendiente; el patrocinador actual puede rechazarlo o aprobarlo. Una cola duradera de mensajes permite avisar después de la terminación asíncrona. Leer el aviso y acusarlo son operaciones distintas.

En el lenguaje comercial, un dominio «pasa» de un registrador a otro. En el registro de RPP core de la IETF, ese verbo tiene etapas. Primero se solicita un proceso. Puede intervenir el patrocinador vigente. Después puede llegar un mensaje que informe el resultado. El primer Created del ejemplo se refiere al expediente de transferencia. No acredita por sí mismo que la ficha del dominio ya tenga otro patrocinador.

RPP está diseñado como protocolo propio. Un operador puede conectarlo a un sistema EPP, pero la correspondencia con EPP es trabajo separado. El borrador principal asigna operaciones a rutas, métodos, cabeceras y códigos HTTP; otro documento describe los objetos y sus datos, y otra especificación debe darles una representación concreta. Por eso, frente a una respuesta HTTP, conviene preguntar qué se creó y qué sigue pendiente, no solo si el código empieza por dos.

Una dirección para seguir el proceso

La sección 16.9.5 define la transferencia como cambio de cliente patrocinador y la modela con un ciclo de vida propio. Para iniciarla, el registrador entrante hace POST a transferProcesses bajo el dominio. La respuesta de ejemplo usa 201 Created, incluye un código de resultado RPP y apunta con Location a /transferProcesses/latest. Esa ruta señala el proceso más reciente. Es una forma de localizar el trámite; no es una lectura del patrocinador final.

El cliente puede consultar el estado por GET. Mientras la solicitud esté pendiente, el iniciador puede cancelarla con DELETE. El patrocinador actual dispone de las operaciones transferReject y transferApprove. El reparto de verbos muestra el reparto de poder. El registrador que quiere entrar puede abrir el expediente, pero no aprobarse a sí mismo en nombre de quien aún patrocina el objeto. Un registro operativo completo debe enlazar solicitud, estado, decisión y lectura posterior del dominio.

La URL tampoco promete permanencia universal. Si el servidor expone una instancia del proceso, debe ofrecer la más reciente mediante latest y puede asignarle un identificador persistente. Si decide no exponer recurso persistente alguno, el borrador exige 200 OK en vez de 201 Created. Una integración no puede basarse en que siempre habrá una URL duradera. Sí puede conservar identificadores de transacción y comprobar el estado final por los medios disponibles.

La bandeja de entrada conserva lo que solo se leyó

El borrador incluye una cola duradera de mensajes asíncronos para el cliente. Como ejemplo cita la finalización de una transferencia que necesitaba aprobación de otra parte. GET recupera mensajes. DELETE dirigido a un mensaje concreto lo acusa. Uno recuperado pero no acusado debe seguir en la cola. La separación impide que «lo mostramos en una pantalla» se convierta silenciosamente en «lo tratamos». También coloca el aviso de terminación en un momento distinto de la respuesta inicial al POST.

Si una operación corriente crea además un recurso de proceso, la sección 15 propone un enlace Link con rel="rpp-process". Su atributo process identifica el tipo; processId aparece si hay identificador persistente; latest designa la instancia más reciente. Son pistas útiles para seguir el trabajo. Ninguna equivale a una sentencia sobre el resultado.

Los documentos oficiales no muestran una transferencia de producción medida. Una prueba con un dominio controlado debería guardar la respuesta inicial, cada estado del proceso, la decisión del patrocinador vigente, el aviso de la cola, su acuse y la ficha final del dominio. Esa secuencia indica cuándo la web del registrador puede cambiar de «solicitada» a «terminada». La lección del borrador es concreta: tener una URL para la mudanza no significa que el dominio se haya mudado.

RPP core revisión 01 · Estado en Datatracker · Objetos de RPP · RFC 5730