Resumo

  • Quando reportAfter chegava a zero, o RFC 3342 gerava um relatório transitório e ainda assim enviava os dados ao relay seguinte.
  • noLaterThan podia encerrar a entrega, e returnTrip limitava a volta do relatório final; alerta, bloqueio, recebimento do recibo e resultado eram fatos separados.

O APEX básico era um serviço de datagrama de aplicação imediato e de melhor esforço. Sem opções, a indisponibilidade de um relay podia levar ao descarte silencioso. O pacote do RFC 3342 adicionava espera, limites e observação, mas evitava o atalho de chamar todos os eventos temporais de falha.

Esse cuidado é relevante porque painéis e orquestradores gostam de um único estado. Um alerta acende, o trabalho vira falha e uma segunda tentativa começa. No desenho do RFC, porém, o primeiro trabalho podia continuar perfeitamente conforme a especificação.

O limite de observação não cancelava

dataTiming era processado a cada salto; por isso o originador precisava usar targetHop="all" e mustUnderstand="true". Antes do encaminhamento, o relay descontava de reportAfter o tempo local gasto em escolher o próximo relay, concluir o vínculo e preparar a transmissão.

Se o saldo chegasse a zero ou menos, o valor era zerado e o serviço de relatório era acionado. Independentemente disso, os dados seguiam para o próximo relay. No salto final, a ausência de ok do endpoint durante o mesmo intervalo também gerava relatório transitório.

O statusResponse ligava o relatório ao identificador da opção e marcava o destinatário original com o código 350, sucesso transitório. Não significava descarte. Afirmava que o limiar de aviso havia sido ultrapassado. Uma entrega posterior não anulava o atraso, e o atraso não provava o resultado final.

O orçamento rígido mudava o fluxo

noLaterThan também diminuía com o processamento local, mas tinha poder operacional. Se acabasse antes do próximo salto, o relay não encaminhava os dados. Com reportErrors, produzia ainda um relatório de erro de tempo. No endpoint, o saldo restante limitava a espera pelo ok.

A diferença era precisa: reportAfter avisava e deixava continuar; noLaterThan podia parar. Gravar ambos como simples timeout perde a informação necessária para saber se a primeira execução ainda pode chegar.

O corte não explicava sozinho a causa. Processamento, lentidão, indisponibilidade, congestionamento ou endpoint desconectado podiam consumir o prazo. O recibo provava o ponto do protocolo, não um defeito universal nem o efeito percebido pelo usuário.

O relatório fazia outra entrega

Depois de transmitir ao destinatário, um returnTrip não nulo solicitava um relatório de salto final. Esse relatório voltava como outra operação de dados APEX. Seu novo dataTiming.noLaterThan recebia o valor do returnTrip original.

Assim, a carga podia chegar, o relatório podia ser criado e apenas o relatório podia se perder na volta. Após o prazo, o remetente podia presumir a perda do relatório; não podia concluir que a carga também falhara. A ausência de prova não apagava o evento que a prova deveria descrever.

Um registro fiel separaria aceitação inicial, saldo de aviso, geração do relatório transitório, continuação da carga, saldo rígido, ponto de interrupção ou ok, geração do relatório final, prazo de retorno, recebimento e resultado da aplicação.

Fila e contagem de saltos não eram relógios iguais

hold4Endpoint permitia manter dados em fila enquanto o endpoint não estivesse anexado. Sem limite superior, a espera podia ser indefinida. O RFC alertava para negação de serviço e sugeria limites administrativos, inclusive exigir noLaterThan curto. Estar armazenado não era estar entregue.

dataHopping usava uma contagem semelhante ao TTL IP para detectar loops. O contador media relays, não milissegundos. Uma mensagem podia cumprir a contagem e estourar o tempo, ou o contrário. Cada limite protegia uma superfície.

attachOverride permitia que uma nova aplicação substituísse a anterior no mesmo endpoint. A propriedade dos dados tardios pertence ao mecanismo do RFC 3340 e a cobertura separada. Um relatório de tempo não resolve essa sucessão.

O alcance do registro histórico

O RFC 3342 foi publicado em julho de 2002 na trilha de padrões. Hoje está Historic e a busca do RFC Editor não lista errata correspondente. O histórico do IETF de 29 de julho de 2012 registra que, até onde o IETF sabia, não havia implementações implantadas dos RFCs 3340–3343 e que a funcionalidade era fornecida pelo XMPP amplamente implantado, nos RFCs 6120 e 6121.

Isso não prova que os temporizadores causaram a trajetória. Não documenta implantação, medição, vulnerabilidade ou incidente. O próprio RFC advertia que dataTiming poderia expor topologia privada e permitia restringi-lo às bordas do domínio administrativo.

A lição atual é distinguir qual relógio observa, qual relógio muda a execução e qual relógio governa a volta da evidência. Quando o alerta dispara, ainda é preciso perguntar se o trabalho parou. Quando o recibo chega, ainda é preciso perguntar exatamente qual fronteira ele confirma.

Fontes