Resumen

  • En RFC 3982, private explicaba que un valor ausente podía no publicarse nunca; denied explicaba que la política lo ocultaba al nivel de acceso actual.
  • Los valores visibles podían llevar specialAccess y doNotRedistribute, de modo que recibir un dato con privilegios no equivalía a adquirir libertad para volver a difundirlo.

Una operadora compara dos respuestas de un registro de dominios. En ambas, el correo del contacto aparece vacío. Si trata los resultados como equivalentes, puede abandonar una investigación que sí admitiría una solicitud autorizada, o insistir ante un dato que la política considera no publicable. La diferencia no está en el contenido: está en la razón de su ausencia.

RFC 3982 convirtió esa razón en parte del resultado. La ficha del RFC Editor, los errata y el expediente del Datatracker documentan la especificación de enero de 2005. Era el tipo de registro de dominios de IRIS y modelaba dominios, hosts, contactos, registradores y autoridades de registro mediante consultas y objetos estructurados.

La decisión venía de los requisitos de CRISP. RFC 3707, su estado, sus errata y su historial IETF exigían acceso granular según la política del operador. También exigían que un valor no entregado pudiera representarse como omisión sin explicación, denegación por autorización insuficiente o restricción de privacidad independiente de la autorización. Para un valor entregado, el protocolo debía permitir las marcas «no redistribuir» y «acceso especial concedido» al mismo tiempo.

El contraste histórico era WHOIS. RFC 3912, junto con su estado, sus errata y el Datatracker, describía una petición de texto en el puerto TCP 43 y una respuesta también textual. El propio documento reconocía que WHOIS carecía de seguridad fuerte, control de acceso, integridad y confidencialidad. Una implementación podía incluir explicaciones para lectores humanos, pero el protocolo no ofrecía una estructura común para que un cliente conservara el motivo de una celda vacía.

RFC 3982 aplicó etiquetas de privacidad a tipos concretos del esquema. Cuando un elemento aparecía sin contenido, debía incluir al menos uno de dos atributos booleanos. private significaba que el contenido estaba ausente porque quizá nunca pudiera publicarse. denied significaba que la política no permitía entregarlo al nivel de acceso actual.

La palabra «actual» evita una confusión decisiva. Una denegación no afirma que nadie pueda obtener el dato; describe este contexto de acceso. La marca privada tampoco afirma que el registro carezca del dato; describe un límite de publicación. Y si el elemento simplemente se omite, el cliente no recibe una explicación normalizada. Ausencia, privacidad y falta de privilegio siguen siendo tres estados distintos.

La mitad más original aparece cuando el valor sí está presente. specialAccess indicaba que se había entregado por derechos especiales. doNotRedistribute indicaba que no debía volver a circular. La primera marca explicaba la vía de acceso; la segunda imponía una responsabilidad posterior. Podían coexistir, porque autorizar la lectura no resuelve el destino de una copia.

Una canalización de datos puede borrar esa distinción sin perder un solo carácter del valor. Basta con extraer el texto y descartar los atributos, o convertir los valores nulos en cadenas vacías. También puede copiar un contacto obtenido con acceso especial a un índice público. El fallo no parece corrupción: los campos siguen alineados. Sin embargo, la semántica que controlaba su uso ha desaparecido.

RFC 3982 no pretendía ejecutar la política por sí sola. RFC 3981 y su registro de estado situaban los errores de permiso y la comprobación previa de permisos en el núcleo de IRIS, pero dejaban autenticación y privacidad al transporte de aplicación. RFC 3983 y su ficha definían el transporte sobre BEEP. Una etiqueta no cifraba el dato, no autenticaba al usuario y no impedía una copia. Hacía visible una decisión que otros controles debían aplicar.

La misma ambigüedad reapareció en el ecosistema RDAP. RFC 9083, con su estado, sus errata y su historial, define el modelo JSON de respuestas. RFC 9537, su estado, sus errata y su expediente IETF añaden una extensión para señalar campos censurados.

RFC 9537 distingue supresión, valor vacío, valor parcial y valor sustituido. Puede identificar el campo, el método y una razón. Rechaza marcadores genéricos como XXXX porque no constituyen una señal fiable. También reconoce una paradoja: informar de que hubo censura puede revelar que existe un dato sensible. Por eso un servidor puede omitir el propio indicador cuando la existencia debe permanecer oculta.

No hay evidencia en estas fuentes para afirmar una descendencia directa desde IRIS hasta esa extensión; la historia no necesita esa exageración. La continuidad está en el problema operativo. Si un sistema reduce todos los casos a vacío o no vacío, pierde tanto la procedencia de la ausencia como los límites de la divulgación. RFC 3982 mostró que una respuesta útil no solo entrega datos. También preserva qué decisión hizo que esos datos aparecieran —o no aparecieran— ante ese receptor.

Fuentes