Resumo

  • O RFC 5262 ordena estados completos e deltas e torna uma atualização perdida observável; essa garantia pertence a uma alimentação específica para um watcher específico.
  • Um recibo defensável vincula base, versões, diffs, observador, política, reconstrução e expiração, mantendo a tentativa de contato e seu resultado como fatos separados.

O servidor trocou delta por estado completo

Uma presença acumulou tantas mudanças que enviar pequenas diferenças deixou de ser eficiente. O servidor entregou um novo pidf-full no lugar de outro pidf-diff. O número continuou a mesma sequência, e o cliente passou a usar o novo estado completo.

Essa troca é prevista pelo RFC 5262. Ela resolve o custo de transporte. Não demonstra que o novo documento contém toda a realidade do presentity, apenas que ele substitui a composição local dentro daquele fluxo.

A decisão entre full e diff é uma decisão de representação. Transformá-la em selo de completude institucional confunde economia de bytes com autoridade sobre os fatos.

Um contador atravessa os dois formatos

application/pidf-diff+xml pode carregar pidf-full ou pidf-diff. O documento parcial aplica add, replace e remove do XML Patch. Quando o atributo opcional version é usado, ele cresce de um em um e continua único mesmo quando o formato alterna.

O receptor consegue ordenar entregas e notar que esperava 569, mas recebeu 570. Isso é evidência concreta de continuidade ou perda. Não valida a origem de cada afirmação, não revela campos omitidos por política e não mede quanto tempo a realidade levou para chegar ao servidor.

A base precisa de identidade própria

Uma série perfeita pode começar na cópia errada. A versão 568 só é sucessora útil de 567 quando ambas pertencem ao mesmo presentity, watcher, diálogo, política de autorização, tipo de conteúdo e charset.

O recibo deve guardar os bytes e o hash da base completa, além do número. Sem isso, uma base antiga ou tomada de outra assinatura pode receber deltas válidos e produzir uma reconstrução coerente do contexto errado.

Cada watcher recebe uma projeção autorizada

Presença pode conter informações sensíveis. O protocolo envolvente deve determinar quais dados podem ser mostrados a qual observador e em qual momento. Assim, a ausência de um contato pode significar que ele não existe ou que não foi autorizado para aquele watcher.

O contador ordena somente o que entrou na projeção permitida. Ele não atravessa a política. Duas sequências contínuas podem divergir legitimamente, e o mesmo número aparente não prova o mesmo escopo.

Por isso a decisão de autorização, sua versão e o conjunto de campos permitido devem acompanhar a cadeia de conteúdo.

Detectar uma lacuna não é recuperar o estado

Uma lacuna aciona uma pergunta, não uma correção. A aplicação ainda precisa suspender a vista, buscar uma nova base, descartar intermediários ou declarar funcionamento degradado.

O registro de recuperação deve mostrar o primeiro número inesperado, a faixa ausente, o último hash confiável, o pidf-full substituto e o instante em que ele se tornou visível. Um alarme encerrado sem essa cadeia não prova reparo.

Compatibilidade não é aplicação nem publicação

Em sistemas SIMPLE, o uso do tipo parcial é negociado. A negociação comprova capacidade de formato. Um diff específico ainda pode não chegar, falhar no seletor, produzir apenas um estado em memória ou nunca alcançar o consumidor.

Recepção, aplicação XML, persistência e exposição são limites separados. O recibo precisa ligar a ordem recebida ao resultado de cada operação, aos hashes intermediários, à confirmação de armazenamento e à vista efetivamente consumida.

XML correto não é disponibilidade humana

O documento deve ser bem formado e deveria ser válido. Ainda assim, um aparelho pode desligar logo depois, uma pessoa pode não querer responder e uma sessão subsequente pode falhar.

A frase comprovável é: “este watcher reconstruiu o estado mais recente recebido neste fluxo”. A frase “a pessoa estava disponível” exige o recibo posterior de convite, negociação, entrega e resposta.

O recibo de presença parcial

Preserve:

  • presentity, watcher, assinatura, diálogo e identidade do fluxo;
  • política de autorização, versão, decisão e escopo permitido;
  • tipo de mídia e charset aceitos;
  • bytes, hash, versão, recebimento e validade da base completa;
  • bytes, hash, versão, ordem e tempo de cada diff;
  • versão esperada, recebida e lacunas;
  • operação, seletor, pré-imagem e resultado da aplicação;
  • hashes intermediários e documento reconstruído;
  • pedido de recuperação, nova base e estados descartados;
  • confirmação de armazenamento e exposição a jusante;
  • tentativa de contato, negociação, entrega e resultado humano ou do serviço.

O recibo não transforma presença em certeza. Ele impede que uma sequência íntegra fale em nome de toda a realidade institucional.

Sources