Resumen

  • El miembro redacted puede nombrar el campo que el servidor ocultó, indicar el método y señalar la forma anterior o posterior de la respuesta. Es una afirmación sobre la salida observada, no una copia ni una verificación del dato protegido.
  • El motivo es opcional, la política queda fuera del estándar y el servidor puede callar incluso la existencia del campo si reconocerla filtra información. Una auditoría necesita conservar por separado consulta, servidor, credencial, nivel de acceso, hora, JSON bruto, rutas y política vigente.

El inventario que contó mal los ausentes

Supongamos que un analista reúne respuestas públicas de miles de dominios y calcula cuántos carecen de correo del registrante. El porcentaje parece preciso. Sin embargo, la misma ausencia visual puede representar datos nunca facilitados, datos retirados de esa vista, un objeto entero eliminado o una dirección reemplazada por un formulario. Sumar esos estados bajo la palabra “faltante” convierte el formato en una historia que el servidor no contó.

La RFC 9537 se publicó en marzo de 2024 como estándar del IETF para reducir esa ambigüedad. Define una extensión de RDAP que identifica campos eliminados, vaciados, parcialmente ocultos o sustituidos. Sus autores son James Gould, David Smith, Jody Kolker y Roger Carney. El perfil del IETF consultado el 7 de septiembre de 2026 enumera trece RFC asociados a Gould. La biografía del comité Registration Operations Workshop lo presenta como fellow de Verisign dedicado a la dirección técnica de servicios de registro. Son referencias de trayectoria y autoría compartida; no prueban invención individual ni control sobre sistemas ajenos.

El resultado del estándar es deliberadamente modesto. Hace explícita una declaración del servidor. No convierte el protocolo en árbitro del contenido secreto ni de la legitimidad de ocultarlo.

Anatomía de una declaración estructurada

Cuando usa la extensión, la respuesta incluye redacted en rdapConformance. El objeto con campos ocultos contiene normalmente un arreglo de descripciones. Cada entrada exige un name, expresado con un tipo registrado o con una descripción libre.

La ubicación se conserva mediante rutas. prePath apunta a la posición anterior a la ocultación; por eso puede no resolverse en el documento que llegó al cliente. postPath apunta a un valor vacío, parcial o sustituido que sí permanece. No se permiten ambos a la vez. replacementPath puede identificar el campo que cumple la función de sustituto. JSONPath es el lenguaje predeterminado y aporta una sintaxis común para esa relación.

Esta estructura permite decir que el servidor calificó un campo concreto con un método concreto. No contiene los bytes anteriores. Tampoco acredita que el registro interno fuera correcto, que la persona presumida fuera el titular o que el nivel de acceso del cliente estuviera bien calculado. Una ruta ubica una afirmación en el JSON; no certifica el mundo detrás del JSON.

Los registros de IANA asignan significados compartidos al identificador de extensión y a familias de nombres, motivos y lenguajes de expresión. Su valor es la interoperabilidad. Un valor registrado no certifica la respuesta particular que lo emplea.

No hay una sola forma de no mostrar

En la eliminación desaparece el campo u objeto. Es el método predeterminado si falta method, salvo cuando quitar una posición rompería un arreglo semántico. En esos arreglos jCard se puede conservar la posición mediante una cadena vacía o null. La ocultación parcial deja visible un fragmento de una cadena con formato. La sustitución entrega otro valor o campo, como un correo anonimizado o una URI de contacto.

Las consecuencias son distintas. Un objeto eliminado no puede verificarse como un elemento vacío. Una dirección parcial todavía revela zona o formato. Un formulario permite contactar sin ser el correo original. Si un repositorio de evidencias guarda solo la palabra “oculto”, destruye la diferencia que la RFC quería hacer legible.

La especificación también rechaza los rellenos hechos con una letra repetida. Un texto arbitrario puede incumplir el formato exigido para el campo y engañar a clientes que lo interpretan como dato. La prueba debe conservar la forma real: ausencia, vacío, fragmento o reemplazo.

El motivo no resuelve el derecho

Una entrada puede incluir reason, ya sea como tipo registrado o como descripción para personas. Esa descripción no debe ser una dependencia de procesamiento. La frase “política del servidor” no es una clave estable para aprobar o rechazar una petición.

El documento permite publicar una política de ocultación, pero deja su contenido fuera del estándar. No decide si hubo consentimiento, qué exige una ley, quién acredita un interés legítimo ni si una orden alcanza ese dato. La RFC 7481 ofrece autenticación y acceso por niveles bajo políticas locales. Por eso dos clientes pueden recibir legítimamente vistas distintas del mismo objeto.

El perfil RDAP de ICANN de 2024 muestra cómo un ámbito concreto agrega reglas. Para determinados servicios gTLD vincula elementos de datos y métodos de la RFC 9537, incluida la sustitución del correo. Es una capa operativa aplicable dentro de su alcance, no una política global de RDAP ni una sentencia sobre cada solicitud.

Además, revelar que existe un campo protegido puede ser una filtración. La RFC autoriza omitir la descripción de ocultación cuando la propia señal de existencia plantea un problema de privacidad. Por eso la falta de redacted no demuestra que la respuesta sea íntegra. También puede significar que la extensión no se usa o que el servidor evitó confirmar el campo.

Un recibo que resiste la comparación

La captura útil comienza con la URI exacta y el tipo de consulta. Debe registrar servidor autoritativo, redirecciones, hora, identidad de transporte, mecanismo de autenticación y clase de autorización. La misma consulta pública y autenticada no produce observaciones equivalentes.

Luego se conservan los bytes de respuesta o una huella verificable, rdapConformance, la identidad del objeto y cada nombre, ruta, lenguaje, método y motivo. El informe indica qué postPath se resolvió, cómo se trató un prePath ausente y qué versiones del decodificador y de JSONPath se emplearon. Una URL de política se archiva con fecha y versión: la página actual no demuestra automáticamente lo que regía meses atrás.

La RFC 9082 separa consultas directas de búsquedas. En una búsqueda, las descripciones pertenecen a objetos individuales. Un límite global del conjunto de resultados no es la ocultación de un campo. Las notices y remarks de la RFC 9083 pueden explicar condiciones generales, pero no reemplazan la entrada estructurada ligada al campo.

Ese conjunto permite una frase defendible: este servidor describió este campo como oculto, de esta forma, para esta consulta y este acceso. Afirmar qué valor había, por qué debía protegerse o quién podía obtenerlo exige pruebas independientes.

Fuentes