Resumo

  • O RFC 1295 foi um documento Informational do North American Directory Forum, publicado em janeiro de 1992, e não um Internet Standard. Para registros e listagens no Public Directory, ele declarou sete direitos: não ser listado; ser avisado quando uma entrada é criada; examiná-la; corrigir informação inexata; remover informação específica; esperar conformidade com leis norte-americanas ou canadenses aplicáveis sobre privacidade ou acesso à informação; e esperar atendimento tempestivo.
  • O texto não criou um protocolo de exclusão nem prometeu segurança. Ele separou porções públicas e privadas e aceitou uma escolha pública, privada ou combinada pelo usuário ou seu agente. O RFC 1417, de 1993, descreveu depois provedores concorrentes, um espaço público de nomes e espaços privados administrados separadamente.

O ponto decisivo de RFC 1295, User Bill of Rights for entries and listings in the Public Directory não era a capacidade de um diretório inspirado em X.500 guardar atributos. A questão era de outra ordem: o fato de um sistema conseguir armazenar, indexar e devolver um atributo autoriza por si só que ele o apresente a um público? A resposta do fórum foi uma fronteira de precedência. A posição de recusar a listagem vem antes da condição técnica de estar visível.

Isso importa porque a descoberta pública altera o efeito de uma informação. Um telefone, um endereço de correio eletrônico ou um vínculo organizacional pode ser dado de trabalho dentro de uma relação limitada e se tornar uma pista de acesso quando aparece em uma busca aberta. O RFC diz que o usuário ou seu agente pode optar por listar informação no Public Directory, em um diretório privado ou em uma combinação dos dois. Seu exemplo não é uma classificação moral de campos: um telefone ou um endereço eletrônico pode ser público, enquanto outras informações são reservadas a uso privado específico. O que importa é a escolha de audiência.

Corrigir uma afirmação não é apagar um campo

O RFC distribui três direitos que hoje seriam tentadoramente reduzidos a uma única função de edição: examinar a entrada, corrigir informação inexata e remover informação específica. A divisão é mais útil do que parece. O exame responde à pergunta “o que o diretório afirma sobre mim?”. A correção responde “qual afirmação é falsa ou ficou ultrapassada?”. A retirada específica responde outra pergunta: “qual informação pode até ser verdadeira, mas não deve continuar disponível para este público?”.

Cada resposta exige evidência distinta. Para uma correção, é preciso conseguir apontar a afirmação inexata e a revisão que a substituiu. Para uma retirada seletiva, é preciso identificar o atributo, a audiência e a instrução de não o exibir, sem fingir que a identidade inteira, todas as relações ou todos os serviços associados ao registro deixaram de existir. O RFC 1295 não define uma operação distribuída de apagar nem uma prova de que réplicas foram limpas. Ele torna visível uma distinção que um simples botão “editar” esconderia: precisão e exposição são superfícies de controle diferentes.

Também não basta transformar a solicitação em resultado. Uma pessoa pode pedir correção e o provedor pode abrir um caso; isso não mostra qual versão foi mudada. Um provedor pode remover o campo em sua cópia autoritativa; isso não mostra que cada índice, cache, parceiro ou leitor posterior deixou de ver uma versão anterior. A ausência de uma resposta pública não prova que a entrada nunca existiu. A lista de direitos é um vocabulário para ordenar a investigação, não um atalho que preenche todas essas lacunas.

Aviso é um evento, não um consentimento

O direito seguinte é receber aviso quando a entrada é criada. Aviso e consentimento não são intercambiáveis. Um aviso pode registrar que o operador enviou uma comunicação sobre uma criação já praticada. Não prova que o sujeito autorizou a inclusão, leu a mensagem, entendeu o alcance da publicação ou obteve uma oportunidade efetiva de contestá-la.

Mesmo assim, o aviso muda a qualidade do registro. Quando uma entrada nasce sem aviso, o sujeito pode só descobrir a exposição depois que um terceiro já a encontrou. Quando há aviso, a criação pode ser tratada como evento identificável: houve uma ação, um destinatário pretendido, um momento, uma entrada a examinar. Os direitos de exame, correção e retirada passam então a ter um objeto e uma cronologia verificáveis.

É importante não comprimir essa sequência em uma promessa genérica de privacidade. O recebimento de uma instrução de não listar não prova que nenhuma entrada pública foi criada. A criação de uma entrada não prova autorização. O envio de aviso não prova consentimento. A possibilidade de examinar não prova correção. Um pedido de correção não prova que a tela pública mudou. A atualização de um registro pelo provedor não prova que todas as cópias mudaram. Em cada elo há um ator, uma versão, uma hora e uma evidência que não podem ser emprestados do elo vizinho.

Um mapa público não possuía os registros para os quais apontava

O RFC 1295 fala de um serviço cooperativo de diretórios eletrônicos na América do Norte, orientado pelos padrões CCITT X.500. O Directory é descrito como uma coleção de diretórios eletrônicos operados por provedores de serviços e operadores privados. A informação de uma entrada pode ser acessada salvo quando controles de segurança e privacidade a restringem; a parcela destinada à divulgação pública forma o Public Directory, enquanto outras parcelas podem não ter sido feitas para acesso público.

Nada disso faz da arquitetura de nomes uma resposta sobre autoridade. Uma hierarquia, uma rota de consulta ou uma relação de réplica informa como um cliente pode chegar a uma resposta. Não decide quem selecionou a audiência, se o dado é exato, se um agente tinha mandato, se o aviso foi recebido ou se uma solicitação foi cumprida. Visibilidade é uma propriedade de uma superfície observada. Autorização é uma relação que requer prova própria.

RFC 1417, NADF Standing Documents: A Brief Overview, publicado em 1993 e que tornou RFC 1295 obsoleto, explicita o problema institucional. Ele descreve provedores concorrentes tentando oferecer cooperativamente um Public Directory Service, um espaço público de nomes ao lado de espaços privados administrados separadamente e um registro que ocorria fora do Directory. Uma entidade podia optar por aparecer onde outros provavelmente procurariam. O espaço comum era um mapa de descoberta, não um título de propriedade sobre cada registro privado por trás do mapa.

O mesmo RFC observa que X.500(88) não possuía procedimentos de manutenção de conhecimento e que provedores concorrentes tornavam impossível administrar com exclusividade o espaço público de nomes. A solução descrita era criar ligações cooperativas entre o espaço público e espaços privados, com pouca carga de dados nesses vínculos. Isso não prova o comportamento de toda implementação e não demonstra que uma retirada tenha eliminado todos os duplicados. Demonstra por que a responsabilidade precisava ser pensada: nenhum provedor isolado podia falar honestamente em nome de todos os dados privados.

O direito enumera obrigações, mas não garante o mecanismo

O sexto direito associa a listagem ao cumprimento de leis aplicáveis dos Estados Unidos ou do Canadá sobre privacidade ou acesso à informação, e o sétimo fala em atendimento tempestivo. Essas frases não oferecem um teste jurídico atual, não definem prazo universal e não resolvem uma disputa concreta. Elas impedem, contudo, que o operador trate a publicação como simples armazenamento. Uma entrada pública inclui uma relação de serviço: a solicitação deve ser recebida e tratada por alguém responsável.

O próprio status do texto recomenda cautela. RFC 1295 é Informational, não Internet Standard, e se apresenta como cópia quase literal de NADF-265. Em suas considerações de segurança, declara que assuntos de segurança não são discutidos. Não há base no texto para concluir que cada pedido era criptografado, que todo agente era autenticado, que cópias eram impedidas, que exclusões eram garantidas ou que se criou uma norma mundialmente vinculante.

Por isso, uma busca pública não prova consentimento, conformidade legal ou resultado operacional. A falta de um resultado não prova não-listagem anterior, ausência de réplicas ou retirada integral. Um protocolo de recebimento não é prova de correção. Uma cópia atual do provedor não é prova de que todos os consumidores veem essa cópia. O valor histórico do RFC está em exigir que esses passos sejam separados, e não em declarar que foram automaticamente resolvidos.

Fontes e limites da evidência

As fontes são RFC 1295 e RFC 1417. Elas sustentam o status Informational de janeiro de 1992, a relação quase literal com NADF-265, o contexto cooperativo orientado a X.500, os sete direitos, a distinção público/privado e a descrição posterior de provedores concorrentes e espaços de nomes conectados. Não provam um diretório atual, uma solicitação individual, o recebimento real de um aviso, uma correção concreta, a remoção de uma cópia, o estado de replicação, conformidade jurídica ou garantia de segurança.