Resumo

  • O RFC 5344 descreve casos de peering para presença e mensagens instantâneas; não define um protocolo novo nem transforma respostas de rede em prova de leitura humana.
  • Pager-mode SIP MESSAGE e sessões MSRP têm estados e recibos diferentes. “Aceito pelo peer”, “entregue a um cliente” e “lido pela pessoa” são eventos separados.
  • A mesma separação vale para presença: publicação, aceitação de subscription, geração da visão autorizada, NOTIFY e exibição não são um único sucesso.

O verbo “entregar” ficou grande demais

Operações distribuídas funcionam melhor quando cada componente declara apenas o que observou. Um proxy pode afirmar que encaminhou. O peer remoto pode afirmar que aceitou. Um servidor de mensagens pode afirmar que armazenou. Um cliente pode afirmar que processou. Um usuário pode ou não responder. O problema começa quando todos esses eventos recebem a mesma etiqueta verde.

O RFC 5344 inclui dois modos de IM. No pager mode, uma mensagem é transportada por SIP MESSAGE como uma solicitação discreta. No session mode, o MSRP estabelece uma sessão e possui suas próprias transações e relatórios. A existência de peering entre os domínios permite que esses fluxos atravessem uma fronteira administrativa; não homogeneíza suas semânticas.

Uma resposta SIP é evidência útil. Ela vincula uma disposição a uma transação, a um componente e a um horário. Mas o seu alcance termina ali. O usuário pode estar offline, o armazenamento pode falhar depois, uma gateway pode recusar um formato, o cliente pode descartar o conteúdo ou a pessoa pode nunca abrir a conversa.

Um indicador honesto usa uma escada: enviado pelo domínio de origem; recebido pelo hub, se houver; aceito pelo domínio remoto; disponibilizado a um cliente; processado ou exibido; reconhecido; respondido. Estados desconhecidos permanecem desconhecidos.

Presença tem uma escada diferente

Presença não é uma mensagem comum enviada uma vez. Um presentity publica estado. Um watcher solicita uma subscription. O servidor decide se aceita e qual visão aquele watcher pode receber. Mudanças produzem notificações. A política pode mudar enquanto a subscription existe.

Assim, “subscription ativa” não prova que a última visão chegou. “NOTIFY enviado” não prova que o cliente o aplicou. “Documento PIDF válido” não prova que o estado estava atual nem que uma tradução preservou o significado. O RFC 6271 lembra que gateways podem mapear “Do Not Disturb” para “Busy”; formatos interoperáveis ainda podem carregar semântica degradada.

Uma operação conjunta precisa distinguir publicação, versão do documento, versão da política, decisão do watcher, transformação, NOTIFY e estado do cliente. Se o painel reutiliza a métrica de MESSAGE para Presence, perde exatamente a informação necessária para explicar falhas.

O peer confiável ainda não é o destinatário

No caso simples do RFC 5344, a rede de Bob aceita subscriptions e IM apenas de seus usuários ou de Peer Networks confiáveis. A rede de Alice encaminha o pedido e recebe as atualizações. Isso resolve uma parte da admissão interdomínios.

Autenticar a rede de Alice não autentica automaticamente a pessoa Alice. Um certificado identifica um endpoint sob uma cadeia de confiança. Uma federação identifica um participante administrativo. Uma identidade de usuário requer sua própria asserção e validação. E mesmo uma identidade correta precisa satisfazer a política de Bob.

Os modelos dos RFCs 4745 e 5025 deixam isso explícito. Uma regra combina condições, ações e transformações. A identidade do requestor pode participar da condição. As transformações controlam visibilidade de pessoa, aparelho, serviço, atividade, humor, lugar, relacionamento e nota. Autorizar a subscription não libera todos os atributos.

Portanto, o recibo de admissão do peer deve ser armazenado separado da decisão de autorização do watcher. Para mensagens, a identidade do remetente e os cabeçalhos de privacidade também precisam atravessar serviços de múltiplos destinatários com regras específicas, como discute o RFC 5365.

A otimização de privacidade muda quem deve provar

Quando muitos watchers no mesmo peer acompanham o mesmo presentity, enviar uma versão diferente a cada um custa tráfego. O RFC 5344 descreve a migração de autorização: o domínio de origem compartilha a política e um documento completo; o domínio receptor filtra localmente.

Esse arranjo pode reduzir bytes, mas transfere a função que decide a divulgação. O peer remoto precisa provar qual identidade avaliou, qual versão da política usou, quais regras combinaram e quais campos entregou. O consentimento continua pertencendo ao usuário. O RFC 6271 exige consentimento expresso para compartilhar suas configurações de privacidade.

O documento completo é um intermediário sensível. Pode revelar mais do que qualquer watcher individual teria direito a ver. TLS protege um caminho sob condições determinadas; não prova filtragem correta, retenção mínima ou exclusão posterior no ambiente remoto.

Uma alternativa envia visões diferentes com listas de watchers autorizados. Ela reduz o compartilhamento de regras, mas exige ligação atômica entre documento e lista. Se a lista mudar ou chegar fora de ordem, a visão pode ser entregue ao conjunto errado.

Um endereço de lista não é um recibo coletivo

Listas pessoais, públicas e ad hoc aparecem nos casos de uso. O RFC 5363 mostra que um serviço de URI-list transforma uma solicitação em muitas e cria risco de integridade, confidencialidade e amplificação. O RFC 5360 trata a tradução para vários recipients como uma questão de consentimento.

Uma lista pessoal mostra intenção do watcher, não consentimento de cada presentity. Uma lista pública tem administrador, mas o administrador não recebe automaticamente autoridade sobre a privacidade dos membros. Uma lista ad hoc muda durante a atividade.

O registro precisa conter versão ou hash da composição no momento da expansão, quem a alterou, os recipients produzidos e o resultado de cada um. Uma única resposta agregada pode esconder rejeições. Informar detalhadamente os recusados também pode vazar a composição; a interface deve equilibrar diagnóstico e privacidade.

O mesmo vale para MESSAGE com vários destinatários. O serviço cria solicitações novas e toma decisões sobre From, identidade afirmada e privacidade. O sucesso de entrada não é o sucesso de todas as saídas.

O Clearing House observa um trecho

O RFC 5344 admite uma federação central, chamada de Clearing House, que pode fornecer interconexão autorizada, identificação dos peers, logging, chat e interceptação legal. O hub simplifica acordos, mas também concentra conteúdo e metadados.

Seu log prova somente o evento que definiu e capturou. Pode registrar entrada no hub sem resposta do peer remoto; pode contar uma URI-list sem suas expansões; pode guardar o documento completo sem registrar a visão filtrada; pode deduplicar retries que importam para a cronologia.

Para usar o log como evidência, é preciso declarar cobertura, relógio, ordem, identificador, retenção, acesso e exclusões. Depois, reconciliar origem, hub e destino. Divergências podem vir de retry, expiração, deduplicação ou rejeição de política; não devem ser apagadas por uma fonte “central”.

Centralização também aumenta o custo de saída. Se políticas, listas e documentos completos ficam presos ao hub, trocar de provedor exige mover ou destruir material altamente sensível. Continuidade e exclusão precisam ser desenhadas antes da escala.

Semântica correta exige recibo de transformação

Um gateway pode entregar todos os bytes e ainda alterar o sentido. Além de “Não perturbe” versus “Ocupado”, atributos desconhecidos podem ser removidos, notas podem perder idioma e identidades podem ser normalizadas para o principal errado.

O registro de transformação deve preservar valor de entrada, versão do mapa, valor de saída e componente executor. Campo ausente, filtrado, desconhecido e desatualizado não podem virar o mesmo vazio. Caso contrário, uma auditoria vê sucesso sintático enquanto o usuário recebe uma realidade diferente.

Limite da evidência

Os documentos usados aqui estabelecem modelos, requisitos e mecanismos do IETF. Não demonstram comportamento atual de produto, federação, Clearing House, conta ou usuário específico. Os exemplos são cenários de teste, não incidentes observados. O RFC 5344 é Informational e deixa soluções de segurança fora de escopo.

A referência ao padrão ajuda a definir o recibo necessário; ela não substitui esse recibo.