Resumo

  • No RFC 5257, .priv e .shared delimitam quem pode ver e alterar uma anotação; não dizem que o remetente a escreveu, que a organização a endossou ou que o valor nunca mudou.
  • Em uma operação COPY, os dados compartilhados elegíveis seguem a mensagem, mas só as anotações privadas do usuário atual podem segui-la; a mensagem pode chegar intacta com um perímetro de contexto diferente.

O arquivo parecia completo porque a mensagem estava completa

Uma equipe encerrou uma investigação e copiou a mensagem central para o arquivo definitivo. O corpo, os cabeçalhos e o anexo chegaram sem alteração. Também chegou uma etiqueta compartilhada de “liberado”. O que não chegou foi a nota privada de outra analista, que registrava uma dúvida ainda sem resposta. Para quem abriu o arquivo depois, a ausência da dúvida parecia evidência de que ela nunca existira.

O servidor pode ter executado exatamente o que o RFC 5257 exige. A assimetria protege a esfera privada de cada usuário. O erro aconteceu na governança: o recibo da cópia da mensagem foi tratado como recibo de transferência de todo o contexto decisório.

Esse é o limite central. Uma anotação pode ser persistente, pesquisável e visualmente colada ao e-mail sem integrar a declaração original. Proximidade não cria autoria. Transporte não cria mandato. Persistência não cria uma história imutável.

Privado e compartilhado descrevem alcance, não verdade

Cada atributo de anotação possui, de forma implícita, variantes .priv e .shared. Uma consulta pode omitir o sufixo para buscar ambas; uma gravação por STORE ou APPEND, assim como uma ordenação por anotação, precisa escolher uma delas. O cliente declara, portanto, se o valor pertence ao espaço individual ou ao espaço comum.

A separação é útil. Um profissional pode manter um lembrete pessoal em uma caixa compartilhada, enquanto o grupo mantém uma atribuição comum. Mas os nomes convidam a inferências perigosas. .priv não significa criptografado, protegido por sigilo jurídico ou invisível a toda administração. .shared não significa revisado, correto ou aprovado pela pessoa jurídica.

Uma informação sensível no lado compartilhado pode se espalhar a colegas autorizados. Um estado operacional necessário no lado privado pode nunca chegar à equipe. O protocolo fornece a alavanca de visibilidade; a organização continua responsável por classificar o significado e a consequência do valor.

A ACL concede uma ação, não uma voz

Sem a extensão de ACL, o acesso acompanha o estado de seleção da caixa: somente leitura ou leitura e escrita. Com ACL, o direito r controla leitura e escrita das anotações privadas e leitura das compartilhadas. O RFC 5257 acrescenta o direito n para criar e alterar valores compartilhados.

É uma separação operacional importante. Um agente pode atualizar o estado comum sem receber poderes mais amplos sobre a caixa. Ainda assim, a permissão para escrever “aprovado” não prova que o agente representa o remetente, possui a mensagem, obteve consentimento do cliente ou pode vincular a organização fora daquele sistema.

Um registro de auditoria precisa preservar o autor da escrita, a credencial e a fotografia da ACL. “A conta de automação gravou um valor compartilhado sob o direito n” é um fato. “O remetente aprovou” é outra proposição, que exige uma cadeia de autoridade até o remetente.

Permanente não quer dizer inviolável

O RFC exige que a anotação seja armazenada permanentemente, em vez de desaparecer ao fim da sessão. Isso sustenta sincronização e uso desconectado. Não cria um diário somente de acréscimos.

STORE pode criar ou substituir um valor. Gravar NIL o exclui. A leitura de um valor inexistente retorna NIL, e seu tamanho é zero. Sem um histórico separado, a mesma ausência final pode significar que nada foi criado, que alguém apagou o valor ou que a caixa de destino não conseguiu armazená-lo.

Para clientes desconectados, o texto recomenda Conditional STORE, de modo que uma mudança concorrente seja detectada antes de uma sobrescrita silenciosa. Detectar o conflito não resolve qual anotação é correta, quem tinha legitimidade de negócio ou se o valor pode acionar uma decisão. Controle de concorrência não é revisão semântica.

A capacidade do servidor não resolve a capacidade da caixa

O servidor anuncia ANNOTATE-EXPERIMENT-1, mas cada caixa selecionada informa o que realmente aceita. NONE impede anotações; READ-ONLY permite observar, não alterar; NOPRIVATE admite apenas valores compartilhados. Um número informa o limite de tamanho, e o servidor também pode limitar a quantidade por mensagem.

Logo, uma migração não pode validar apenas o banner de capacidade. O destino pode aceitar a mensagem e rejeitar uma anotação privada, um valor grande ou uma gravação incompatível com suas permissões. “Mensagem copiada” e “contexto entregue” são resultados diferentes.

Falhas de tamanho ou contagem devem aparecer como falhas de entrega de metadados. Escondê-las dentro de um sucesso geral produz um arquivo enganoso: o registro chegou, mas parte das razões usadas para interpretá-lo ficou na origem.

COPY monta um pacote deliberadamente desigual

Em uma COPY no mesmo servidor, uma implementação com ANNOTATE copia todas as anotações compartilhadas e apenas as anotações privadas pertencentes ao usuário que executa a operação. As notas privadas dos demais usuários não podem ser copiadas. Permissões, modo somente leitura, falta de suporte e limites do destino podem reduzir ainda mais o conjunto transferido.

É uma boa propriedade de privacidade e uma advertência de evidência. A cópia não é um envelope fechado contendo “mensagem mais todo o conhecimento sobre ela”. Uma investigação privada acompanha seu autor; outra fica. Rótulos compartilhados seguem quando aceitos. Um valor grande demais pode ser omitido. Os mesmos bytes passam a viver dentro de outra fronteira informacional.

O valor compartilhado que chega também não recebe autoridade retroativa. Ele pode ter sido escrito dias depois da mensagem, por outra conta, sob outra ACL, e levado por sucessivas cópias. O evento preserva um valor; não preserva automaticamente motivo, procedência e mandato.

Pesquisa e ordenação transformam contexto em controle

O RFC 5257 permite procurar valores de anotação e ordenar mensagens por valores privados ou compartilhados. O que parecia uma nota lateral pode definir fila, prioridade, retenção e automação. Quanto maior sua influência, maior a necessidade de procedência verificável.

Um valor pode ser sintaticamente válido, legível pela ACL e corretamente copiado, mas estar desatualizado ou errado. O registro de um nome de entrada padrão ou de um espaço de nomes do fornecedor organiza a interpretação; não atesta cada instância armazenada.

O RFC 5464, publicado depois, trata metadados de servidor e de caixa, não anotações por mensagem. A distinção mostra por que “metadado” não é uma classe única de autoridade. Escopo, escritor, regra de movimento e consumidor determinam o que o valor pode provar.

O recibo precisa envolver a anotação

Para todo valor capaz de afetar uma decisão, preserve caixa e UID, escopo da mensagem ou parte, nome da entrada, classe .priv ou .shared, identidade e credencial do escritor, instantâneo de ACL e capacidade, hashes anterior e posterior, token de estado, resposta do servidor, evento de exclusão, decisão de tamanho ou cota e ação posterior.

Na cópia, acrescente origem, destino, ator, modos de anotação suportados, inventário de atributos copiados ou ignorados e o motivo. Na interface, mostre escritor, horário e classe de visibilidade. A nota não deve parecer trecho do corpo enviado.

A linguagem do relatório precisa respeitar essa fronteira. “Depois desta escrita, a anotação compartilhada continha ‘aprovado’” é testável. “O remetente aprovou” pede prova externa da autoridade do remetente. “Todo o contexto dos revisores foi preservado” exige um recibo atributo por atributo.

O RFC 5257 tornou o contexto durável e útil. A tarefa da liderança é impedir que a conveniência desse contexto permita que ele fale com a autoridade do registro que apenas acompanha.

Fontes