Resumo
- A RFC 9171 mantém recepção, encaminhamento, entrega local, exclusão e relatórios de status como estados distintos do Bundle Protocol; um relatório descreve o estado afirmado pelo nó que o emitiu.
- O BPv7 não assegura sozinho a entrega fim a fim, e custody transfer deixou o protocolo-base. Uma recepção não prova custódia, processamento aplicacional, autoridade ou resultado externo.
Uma rede que pode passar longos períodos sem contato não permite a linguagem confortável de uma conversa contínua. O enlace pode desaparecer, os atrasos podem mudar e o próximo vizinho pode não estar presente quando o emissor age. O Bundle Protocol Version 7 transporta uma unidade de dados de aplicação junto com informações que podem torná-la utilizável quando houver entrega. Nesse cenário, “enviado” e “concluído” não formam, por si, uma trilha de evidência.
A RFC 9171 fornece uma gramática mais precisa. Transmission é a tentativa do Bundle Protocol Agent, ou BPA, de fazer cópias chegarem a nós de um endpoint. Forwarding é o uso sustentado de um ou mais adaptadores de camada de convergência para que uma cópia seja recebida por outro nó. Delivery é mais restrito e local: carga útil e metadados relevantes foram apresentados ao application agent de um nó de acordo com um registro local. Exclusão, descarte e retention constraints também são estados próprios.
Essa separação não é detalhe terminológico. Ela define a extensão de cada alegação. Um bundle encaminhado não é necessariamente recebido. Um bundle recebido não é necessariamente entregável localmente. Uma carga apresentada ao application agent não é necessariamente processada por ele. E o relatório que descreve qualquer uma dessas etapas não é necessariamente recebido por quem precisa tomar uma decisão. Resumir tudo em “entregue” deixa a interface simples e destrói a rastreabilidade de onde a responsabilidade mudou.
O procedimento de recepção mostra a primeira fronteira. Ao receber um bundle de outro nó, o BPA adiciona a retention constraint “Dispatch pending”. Se houve pedido de relatório de recepção e os relatórios estão habilitados, o BPA deve gerar um relatório de recepção para o endpoint report-to. A afirmação legítima é específica: aquele nó iniciou o processamento que a RFC prevê para um bundle recebido.
Isso não garante a preservação posterior. O BPA verifica CRCs anexados. Um bundle malformado, ou um bundle cujo CRC não corresponde ao valor calculado na recepção, deve ser excluído e os demais passos de recepção são pulados. Um bloco de extensão que o BPA não consegue processar também pode causar um relatório e, conforme seus controles, a exclusão do bundle ou a remoção do bloco. Logo, a existência de um relatório de recepção não se transforma em prova de que o objeto era válido, foi guardado, encaminhado ou entregue à aplicação.
O encaminhamento tem outra abrangência. O BPA escolhe nós e adaptadores e solicita o envio. A conclusão de que os procedimentos de envio resultaram em forwarding bem-sucedido é específica da implementação; se não resultar, o BPA pode tentar novamente conforme sua configuração. Um relatório de encaminhamento fala desse estado. Não é um recibo do próximo nó, não garante que a rota permanecerá disponível e não demonstra chegada ao endpoint final.
No destino, a fronteira é ainda mais explícita. A entrega local depende do registro associado ao endpoint de destino. Fragmentos podem precisar de remontagem; um registro passivo ou uma falha específica da implementação pode adiar ou abandonar a entrega. Mesmo quando existe relatório de entrega, a RFC declara que ele só afirma que a carga foi entregue ao application agent, não que o agente a processou.
Essa ressalva é essencial em fluxos automatizados. A aplicação pode validar, colocar em fila, recusar, adiar, transformar ou ignorar os dados sob regras próprias. O estado do BP não informa qual ocorreu. Ele não identifica o responsável por uma decisão, não prova que alguém autorizado examinou um resultado e não demonstra que uma instrução irreversível foi executada. Quando tais fatos importam, devem nascer e permanecer registrados na aplicação e no sistema de decisão que lhes dá sentido.
Relatórios de status ajudam, mas não são um livro-caixa completo do caminho. A RFC manda deixá-los desabilitados por padrão, pois pedidos numerosos podem gerar tráfego excessivo. Mesmo habilitados, a decisão de emitir um relatório solicitado fica a critério do BPA. Caso traga tempo, esse tempo é informado pelo relógio local do nó e é assunto de implementação. O relatório é, portanto, uma afirmação limitada de um nó, transportada como outro bundle até report-to; não é uma cronologia global sem perdas nem prova de que o leitor pretendido a recebeu.
O contraste histórico com custody importa. A RFC 5050 experimental definiu aceitação de custody e custody signals. A tabela da RFC 9171 mantém as flags correspondentes como valores da versão 6, e o Apêndice A afirma que custody transfer migrou para Bundle-in-Bundle Encapsulation. O BPv7 básico preserva mecanismos úteis de retenção, encaminhamento, entrega, relatório e extensão, mas não converte recepção em aceitação de guarda. Quem precisa de um compromisso durável deve nomear o mecanismo, as condições e a falha; não deve extraí-los de um indicador de recepção.
A maior limitação é declarada sem ambiguidade: o Bundle Protocol, sozinho, não assegura a entrega ao destino. Protocolos de camada de convergência confiáveis podem reduzir perdas entre vizinhos; a garantia fim a fim requer extensões de BP e/ou mecanismos de camada de aplicação. Não se trata de uma promessa esquecida, mas de uma distribuição honesta de responsabilidades. O protocolo registra o que o BPA fez com um bundle em um ponto; não finge comprovar o que aplicações, pessoas ou instituições escolheram depois.
Para uma liderança, a questão não é se um relatório de recepção merece desconfiança automática. É se o registro declara somente o que sabe. Recepção, encaminhamento, entrega local, processamento, reconhecimento, aprovação e execução externa devem ficar separados. Cada um deve dizer quem afirma, qual regra autoriza a afirmação, para onde ela foi enviada, qual relógio vale e como o estado falha. Fatos estreitos e verdadeiros podem ser combinados. Um único sinal verde que alegue cobrir tudo não se torna auditável por insistência.
A separação de Lu Heng entre representação, decisão local e realidade em execução é uma disciplina editorial útil. Um relatório BP representa um estado técnico delimitado. Deve ser aceito por esse estado, não elevado a declaração de autoridade ou sucesso. Sistemas em produção tornam-se mais resistentes quando separam o evento observado da consequência que outro ator ainda precisa escolher e realizar.
Fontes
- RFC 9171 — Bundle Protocol Version 7
- RFC 5050 — Bundle Protocol Specification
- RFC 8174 — Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
- Lu Heng — Running-Code Primacy
- Lu Heng — Minimum Initial Specification, Localized Future Decision
- Lu Heng — Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance

