Resumen

  • Whois 1.124 incorporó respuestas text/plain y unformatted a la Versions API. RIPE NCC fecha el despliegue en producción el 27 de agosto de 2026; este examen del cambio se realiza en septiembre.
  • El objeto histórico se filtra antes de la salida. El cuerpo en texto plano no ejecuta el paso que añade la revisión a la respuesta estructurada. Un archivo aislado no equivale al archivo de la petición original de actualización.

Al guardar una versión histórica como texto, es fácil creer que se ha guardado todo. Se ve la clave del objeto, los atributos resultan legibles y un compañero puede compararlos sin procesar JSON o XML. Pero el número de revisión puede haber quedado en la consulta que produjo el archivo.

Es un problema hipotético de conservación, no un error observado en un usuario de RIPE Database. Sirve para separar dos ventajas que no son idénticas: poder leer una respuesta y poder identificar qué respuesta se conservó.

Whois 1.124 introdujo texto plano y respuestas sin formato en la Versions API. La documentación oficial sitúa su despliegue de prueba el 13 de agosto y el de producción el 27 de agosto. La URI de una versión concreta incluye fuente, tipo de objeto, clave y número solicitado. Esta investigación sigue el código publicado bajo 9095208c158c9d6630e6b1eac33e845d2c537d3d, no el comportamiento de todas las instalaciones actuales.

El historial se filtra antes de representarlo

En el servicio revisado, la consulta selecciona el tipo de objeto y utiliza SHOW_VERSION con el número pedido. El recorrido de origen REST devuelve un VersionWithRpslResponseObject.

No es una copia archivada de la solicitud HTTP o del correo original. El ejecutor histórico aplica primero sus funciones de filtrado de correo electrónico, autenticación, atributos changed y datos personales al RpslObject. Después asocia ese objeto procesado con la revisión solicitada.

Elegir otra representación no retrocede hasta una transacción original sin filtrar. Aplicar filtros tampoco significa que todos los atributos de todos los objetos cambien. Un texto RPSL visible podría coincidir con uno que se presentó anteriormente; la API no garantiza por ello su identidad con la petición original.

Esta separación tiene una justificación práctica. Consultar el pasado no obliga a volver a publicar material de autenticación o datos personales que el servicio filtra. Una prueba más fácil de leer no justifica eliminar esas protecciones.

La revisión pertenece a la envoltura estructurada

El servicio examina Accept. Si contiene text/plain, devuelve la representación textual del RpslObject histórico y termina ese recorrido.

La otra rama llega al mapeador. Interpreta unformatted para elegir cómo representar los atributos, añade expresamente la revisión al WhoisObject y lo incorpora a WhoisResources. La envoltura incluye también información de errores, condiciones y versión del software.

El cuerpo plano no ejecuta esa asignación de revisión ni la llamada posterior al mapeador. Por tanto, unformatted no debe presentarse como un interruptor que recupera el mensaje original en cualquier tipo de respuesta.

La conclusión se limita al código que produce el cuerpo. No se han auditado todos los encabezados, intermediarios o interceptores HTTP. La URI conserva la identidad de la revisión pedida, y el objeto puede contener fechas o comentarios ordinarios. Eso no permite dar por supuesto que el campo de revisión de la envoltura aparece en un archivo de texto separado de su consulta.

También son distintos el número de versión del software y la revisión histórica. El primero identifica el código del servicio; el segundo, una posición solicitada en la historia de un objeto. Conservar uno no sustituye al otro.

Qué guardar junto al texto

El texto plano es una opción útil: se abre fácilmente, encaja en herramientas existentes y permite comparaciones sencillas. La respuesta estructurada aporta una envoltura que algunas tareas no necesitan procesar. Ninguna de las dos es, por definición, incorrecta.

La decisión relevante es conservar el contexto. Guardar la URI exacta, fuente, tipo, clave y revisión; anotar la representación y la hora de captura; preservar encabezados y revisión estructurada cuando estén disponibles. La huella debe corresponder a los bytes realmente recibidos y al formato indicado.

Una huella demuestra integridad de esos bytes. No recupera una consulta perdida, no restaura campos filtrados y no acredita quién autorizó la transacción original. Dos formatos pueden generar bytes distintos sin demostrar un cambio del recurso.

Contenido histórico, identidad de revisión y evidencia transaccional son aspectos relacionados. No constituyen una única prueba intercambiable.

Fuentes