Resumo

  • Depois de processar terminate e responder, o serviço do RFC 3343 não enviava novas atualizações, mas as anteriores podiam continuar em trânsito e chegar depois.
  • O código 250 provava o corte no serviço, não o esvaziamento dos relays; correlação, geração da assinatura, atualidade e decisão do consumidor eram estados diferentes.

O serviço APEX de presença usava o endpoint conhecido apex=presence. Aplicações publicavam entradas, assinavam a presença de um endpoint e observavam quem assinava esse sujeito. Essas operações podiam durar, gerar vários eventos e sobreviver no armazenamento persistente do serviço.

Uma assinatura entregava imediatamente a entrada atual. Com duração positiva, novas mudanças produziam publish até o término; com duração zero, havia apenas uma consulta. watch respondia 250, enumerava assinantes atuais e depois enviava notify para novas assinaturas e encerramentos.

O fechamento tinha escopo

Consumidor ou serviço podiam terminar subscribe ou watch. Um identificador que não apontasse para operação ativa daquele originador recebia erro 550. Um identificador válido removia a operação e recebia 250.

Ainda assim, a especificação dizia que o originador poderia receber atualizações depois do término. O serviço não enviaria outras após processar terminate e a resposta, porém mensagens anteriores poderiam estar no caminho.

O recibo, portanto, descrevia a persistência do serviço e sua conduta futura. Não certificava buffers vazios, conexões drenadas nem a fila do consumidor. Uma barreira real precisaria contabilizar todas as mensagens anteriores. O protocolo não alegava essa força.

Correlacionado não era atual

publish e notify iniciados pelo serviço preservavam o transID da operação causadora. Uma atualização tardia continuava atribuível à assinatura antiga. Essa precisão não obrigava o consumidor a aplicá-la.

Era necessário conservar uma geração ou lápide. A política poderia descartar, arquivar, colocar em quarentena ou comparar com uma consulta nova. Coincidir o identificador provava origem, não vigência.

Ao criar nova assinatura para o mesmo originador e sujeito, o RFC encerrava silenciosamente a anterior. A relação aparente permanecia, mas a geração mudava. Sem essa dimensão, um publish antigo podia parecer o início do fluxo novo.

Presença armazenada não era conexão viva

O domínio mantinha entrada para cada endpoint mesmo quando ele não estava anexado. Ela continha lastUpdate, URI de informação e tuplas com destino, availableUntil e capacidades. Existência da entrada não provava ligação atual ou entrega real.

Uma publicação exigia que o lastUpdate enviado coincidisse semanticamente com o armazenado; divergência retornava 555. A resposta 250 confirmava a mutação no serviço, não a chegada a todos os assinantes. Uma atualização atrasada podia ser autêntica e obsoleta ao mesmo tempo.

Limite histórico

O RFC 3343 foi publicado em abril de 2003 como Experimental e hoje está Historic. O histórico do IETF de 29 de julho de 2012 afirma, até onde o IETF sabia, que não havia implementações implantadas dos RFCs 3340–3343 e que a funcionalidade era oferecida pelo XMPP amplamente implantado, nos RFCs 6120 e 6121.

Isso não atribui a trajetória à corrida de cancelamento e não documenta incidente. O texto também alertava que fusos de timestamps podiam revelar localização, permitindo conversão e uso de -00:00.

A disciplina permanece: registrar geração, entrega ao transporte, término, corte de emissão, drenagem, chegada e ação separadamente. Sem recibo de drenagem, o passado pode continuar vindo mesmo depois de a assinatura ter terminado.

Fontes