Resumen

  • El RFC 1295, documento Informational de enero de 1992 del North American Directory Forum, enumeró siete derechos para las entradas del Public Directory: no figurar, recibir aviso al crearse una entrada, examinarla, corregirla, retirar información concreta, esperar cumplimiento de la normativa estadounidense o canadiense aplicable y recibir una respuesta oportuna.
  • La lista no era un mecanismo de borrado ni una garantía de seguridad. Separaba el directorio público de partes privadas y permitía a una persona o a su agente elegir una presencia pública, privada o mixta; RFC 1417 describió después una red de proveedores competidores y espacios de nombres privados enlazados.

La pregunta de fondo de RFC 1295, User Bill of Rights for entries and listings in the Public Directory no era si una infraestructura inspirada en X.500 podía conservar atributos. Era si la capacidad de conservarlos, indexarlos y devolverlos en una consulta podía convertirse, sin otro examen, en autorización para exponerlos. La respuesta del foro norteamericano fue un orden de operaciones: primero está la posibilidad de no entrar en la lista; sólo después viene la existencia de una entrada pública.

Ese orden evita una confusión muy práctica. Un número de teléfono, una dirección de correo o una afiliación institucional pueden ser datos ordinarios dentro de una relación limitada y, al mismo tiempo, convertirse en una señal de disponibilidad cuando aparecen en un índice abierto. El RFC admite que un usuario o su agente elija colocar información en el Public Directory, en un directorio privado o en una combinación de ambos. Su ejemplo es deliberadamente concreto: puede hacerse público un teléfono o una dirección de correo, mientras otros datos quedan reservados para un uso privado determinado.

No se trata de clasificar un campo como seguro o peligroso de una vez para siempre. Se trata de decidir quién puede verlo y bajo qué relación.

Un aviso no sustituye al consentimiento

Después del derecho a no figurar, el documento exige que se avise cuando se cree una entrada. La proximidad de ambas frases puede inducir a tratarlas como una sola garantía. No lo son. El aviso acredita, en el mejor de los casos, que el operador produjo una comunicación acerca de un acto ya realizado. No demuestra que la persona lo autorizara, que leyera el mensaje, que entendiera su alcance ni que tuviera una vía efectiva para objetarlo.

Su utilidad histórica está en otra parte. Una creación silenciosa deja al sujeto ante una ficha que puede descubrir un tercero antes que él. Una creación acompañada de aviso convierte la aparición de la ficha en un hecho identificable: hay una acción, un destinatario previsto, una fecha posible y un objeto que examinar. A partir de ahí cobran sentido los derechos siguientes. La persona puede inspeccionar la entrada, señalar una inexactitud o pedir que se retire una información específica. Sin ese punto de referencia, la discusión empieza tarde y con pruebas más débiles.

Por eso conviene conservar cada verbo de la lista. Que el proveedor reciba una instrucción de no publicar no demuestra que nunca haya creado una entrada. Que exista una entrada no demuestra que el sujeto la haya aprobado. Que se emita un aviso no demuestra consentimiento. Que el sujeto pueda ver la ficha no demuestra que la información sea correcta. Que solicite una corrección no demuestra que se haya cambiado la versión visible. Que el operador cambie una copia bajo su control no demuestra que ninguna otra copia siga circulando. Son afirmaciones relacionadas, pero cada una necesita actor, momento, versión y evidencia propios.

Corregir no es retirar un atributo

El RFC distingue con cuidado entre examen, corrección y eliminación de información específica. Esa precisión resulta más interesante que una promesa genérica de “editar el perfil”. Examinar permite saber qué se afirma en una entrada. Corregir ataca la exactitud de una afirmación: una dirección equivocada, una afiliación desactualizada, un dato atribuido al sujeto de forma errónea. Retirar información concreta plantea otro problema: el dato puede ser exacto y, sin embargo, no ser apropiado para el público al que llega.

La diferencia cambia el tipo de prueba que importa. Una corrección exige identificar qué afirmación era inexacta y qué revisión la reemplaza. Una retirada selectiva exige identificar el atributo, el público y la instrucción de dejar de mostrarlo sin convertir automáticamente toda la identidad del sujeto en un vacío. Ninguna de las dos peticiones autoriza a suponer que toda relación, toda copia o toda ruta de búsqueda desapareció. El texto no define un protocolo de borrado distribuido ni un mecanismo de comprobación de réplicas. Su contribución es más elemental: reconoce que exactitud y exposición son problemas distintos.

La séptima expectativa, el cumplimiento oportuno, añade una obligación de servicio. Una solicitud que no recibe respuesta en un plazo razonable no queda transformada en cumplimiento por el mero hecho de que exista un formulario o una política. Pero el RFC tampoco fija un reloj universal ni decide una controversia concreta. Pide que los proveedores traten los derechos como trabajo operativo: recibir, identificar, decidir, modificar cuando corresponda y responder. Ese trabajo no se reduce al almacenamiento de atributos.

El espacio público no era dueño de los registros privados

RFC 1295 sitúa el asunto en un proyecto de directorios electrónicos cooperativos de América del Norte, orientado a normas CCITT X.500. Describe el Directory como una colección de directorios electrónicos operados por proveedores de servicios y operadores privados. La información de una entrada puede ser accesible salvo que controles de seguridad o privacidad limiten el acceso; una parte destinada a la difusión pública forma el Public Directory y otras partes pueden no estar destinadas al acceso público.

La arquitectura de nombres puede sonar como una respuesta a la cuestión de autoridad, pero no lo es. Una jerarquía, una regla de encaminamiento de consultas o una relación de réplica informa de cómo un cliente puede alcanzar una respuesta. No decide quién eligió la audiencia, si la respuesta sigue siendo exacta, si un agente estaba autorizado a actuar, si el aviso llegó o si una solicitud fue atendida. La visibilidad es una propiedad de una superficie observada; la autorización es una relación que debe demostrarse.

RFC 1417, NADF Standing Documents: A Brief Overview, publicado en 1993 y obsoleto respecto de RFC 1295, hizo visible la razón institucional de esa separación. Describe proveedores competidores que intentaban ofrecer cooperativamente un servicio de directorio público, con un espacio de nombres público y espacios privados gestionados por separado. La inscripción ocurría fuera del Directory, y una entidad podía optar por aparecer allí donde fuera probable que otros buscaran. El mapa común ayudaba al descubrimiento; no convertía a un proveedor en propietario exclusivo de los registros situados detrás de cada enlace.

RFC 1417 también observa que X.500(88) no incorporaba procedimientos de mantenimiento de conocimiento y que la competencia entre proveedores impedía la gestión exclusiva del espacio público. La respuesta descrita son enlaces cooperativos desde el espacio público a espacios privados, con poca carga de datos en los propios enlaces. No es una prueba de que todas las implementaciones conservaran esa disciplina, ni de que una retirada eliminara cada duplicado.

Sí es evidencia de que un directorio compartido necesitaba reglas de responsabilidad precisamente porque la infraestructura no tenía un único dueño capaz de hablar por todos los datos privados.

Un derecho enumerado no es una garantía técnica

El estatus del RFC obliga a no exagerar su alcance. Es un documento Informational de enero de 1992, no un Internet Standard, y declara ser una copia casi literal de NADF-265. Sus consideraciones de seguridad dicen expresamente que los asuntos de seguridad no se tratan. No puede convertirse por ello en evidencia de cifrado, autenticación de cada agente, prevención de copias, borrado garantizado ni una regla jurídica globalmente vinculante.

La referencia a la legislación estadounidense o canadiense aplicable sobre privacidad o acceso tampoco ofrece una prueba de cumplimiento presente. No proporciona un criterio legal contemporáneo, no decide el derecho de otra jurisdicción y no convierte una respuesta de directorio en certificación jurídica. Lo que hace es impedir que el operador se describa como un simple intermediario neutral entre campos y búsquedas. Si publica una entrada, participa en una relación de acceso con responsabilidades de procedimiento.

Ese límite sigue siendo una buena disciplina de lectura. Un resultado visible no acredita que el sujeto consintió ni que se respetó la ley. La ausencia de un resultado no acredita que nunca existió, que no haya una réplica o que una retirada se haya completado. Un recibo de solicitud no acredita una corrección. Una versión actualizada en el proveedor no acredita que todos los lectores posteriores reciban esa versión. El RFC proporciona el vocabulario para preguntar; no borra los eslabones que faltan en la cadena de pruebas.

Fuentes y límites de la evidencia

Las fuentes son RFC 1295 y RFC 1417. Juntas respaldan la condición Informational de enero de 1992, la relación casi literal con NADF-265, el contexto cooperativo orientado a X.500, los siete derechos, la separación entre directorio público y privado, y la descripción posterior de proveedores competidores y espacios de nombres enlazados. No prueban un directorio actual, una solicitud individual, la recepción de un aviso, una corrección concreta, la desaparición de una copia, el estado de una réplica, el cumplimiento legal ni una garantía de seguridad.