Resumo

  • RFC 5264 incorpora cada atualização parcial aceita a uma publicação completa. Sem refresh, a expiração limpa esse estado completo; não desfaz somente o delta mais recente nem recompõe uma versão anterior.
  • A cadeia de evidência precisa reunir entity-tags, precondição, corpo, hashes completos antes e depois, prazo, refresh, commit e efeito na composição.

O relógio silencioso era maior que a mensagem

O painel mostrava uma sequência normal de PUBLISH bem-sucedidos. O último corpo tinha poucos bytes: uma troca de prioridade em um contato. Nada indicava uma mudança ampla.

O evento decisivo não apareceu como um corpo grande. Foi a ausência do refresh. Ao vencer a publicação, o compositor removeu todo o documento daquele publicador, incluindo as alterações acumuladas desde a base completa.

O tamanho do último delta descrevia custo de transporte. Não descrevia o tamanho do estado sujeito ao relógio.

A base nasce completa

Para começar uma publicação parcial, o PUA envia pidf-full sob o tipo application/pidf-diff+xml. A partir dessa base, pedidos de modificação podem levar pidf-diff ou um novo estado completo.

Essa sequência mostra a unidade real. O sistema não cria um objeto permanente para cada add, replace ou remove. Ele mantém a publicação completa atual e aceita maneiras diferentes de atualizá-la.

Se o conjunto de diferenças ficar maior que o documento completo, o PUA deve preferir o estado completo quando puder comparar os tamanhos. A escolha continua sendo eficiência, não uma mudança de autoridade sobre o estado.

Uma linhagem de etiquetas, não duas versões concorrentes

RFC 3903 identifica uma publicação existente por meio de SIP-ETag. O cliente devolve a etiqueta em SIP-If-Match quando deseja renovar, modificar ou remover o estado. Cada sucesso entrega uma nova etiqueta.

O PIDF parcial possui seu próprio atributo de versão, mas RFC 5264 evita empregá-lo como outra ordem de publicação. Se número e etiqueta discordassem, surgiria uma ambiguidade sem regra clara. A precondição SIP é a autoridade sequencial escolhida.

Por isso, o arquivo de um delta sem as etiquetas anterior e posterior é evidência incompleta. Ele mostra conteúdo pretendido, não a transição condicional que o compositor reconheceu.

O compositor consolida, não arquiva patches

Ao receber um pidf-diff válido, o compositor executa as operações em ordem sobre o documento local. O resultado completo segue para a lógica de composição como qualquer publicação cheia.

A especificação não exige que o compositor guarde a série de patches. Não existe promessa de voltar automaticamente a uma versão anterior. Uma restauração precisa chegar como nova publicação completa.

Esse detalhe separa um protocolo de atualização de um sistema de versionamento. O primeiro produz o próximo estado. O segundo, se contratado, também preserva ancestrais e caminhos de retorno. RFC 5264 não promete a segunda função.

Expiração remove a contribuição completa

O prazo vale para a publicação completa já modificada. Se o publicador não renovar, o compositor deve limpar todo esse estado. Não há semântica que permita concluir que apenas a última alteração era temporária.

Um refresh sem corpo pode, portanto, proteger uma grande quantidade de informação. Sua ausência pode produzir impacto maior do que qualquer mensagem recente. Operar apenas por métricas de bytes e respostas de patch deixa o maior risco fora do painel.

Também não se deve calcular a vida de uma mudança a partir do momento em que seu delta foi enviado. Depois de consolidada, ela dura enquanto a publicação atual durar.

A remoção é limitada à publicação

Vários dispositivos podem publicar para o mesmo presentity. O compositor combina contribuições ativas e ainda pode dispor de hard state que não expira.

Logo, limpar a publicação vencida não significa necessariamente apagar todo o estado do recurso. Outras publicações e o hard state podem permanecer. O resultado público depende da política de composição.

Um registro preciso precisa nomear a contribuição removida e mostrar o composto antes e depois. “Tudo sumiu” só é verdadeiro dentro da fronteira daquela publicação.

Falhar antes do commit preserva o estado antigo

Um diff sem publicação inicial completa deve ser rejeitado. Erros no documento geram 400, com diagnóstico opcional. Outros erros antes do processamento integral geram 500 e exigem restauração do estado local original.

Esse rollback protege uma operação ainda não aceita. A expiração ocorre sobre estado já aceito e produz remoção, não rejeição retroativa.

Para responder a um incidente, é essencial distinguir precondição inválida, erro de patch, commit bem-sucedido, remoção explícita e expiração natural. O rótulo genérico “falha de publicação” não conserva causalidade.

Recibo da publicação

Para usos consequentes, registre:

  • Request-URI, evento, publicador, presentity e identidade da publicação;
  • etiqueta anterior, SIP-If-Match e nova SIP-ETag;
  • tipo, bytes, hash e horário do corpo completo ou parcial;
  • ordem e resultado das operações de patch;
  • hashes do documento completo antes e depois;
  • prazo pedido, concedido e efetivo;
  • deadline, pedido, resposta e commit do refresh;
  • remoção explícita ou expiração e o estado eliminado;
  • outras publicações e hard state ainda ativos;
  • hash composto, versão da política e notificação posterior; e
  • exibição, decisão automática ou resultado humano.

Esse recibo evita que uma resposta 2xx receba autoridade indevida. Ela demonstra a aceitação da transição correspondente. Persistência, composição, entrega e ação pertencem a etapas que precisam de observação própria.

Sources