Resumo

  • A RFC 3080 colocou várias trocas independentes na mesma sessão BEEP. O canal zero administrava a sessão; o perfil escolhido definia a sintaxe e o significado de cada canal de aplicação.
  • Transporte aberto, greeting válido, capacidade anunciada, canal criado, resposta recebida e efeito real eram evidências distintas.

A estrada existia antes do destino

Dois pares podem estabelecer transporte, trocar greetings corretos e rejeitar todos os perfis oferecidos para o primeiro canal. A estrada está aberta, mas nenhuma aplicação encontrou linguagem comum.

Publicada em março de 2001 na trilha de padrões, a RFC 3080 descreveu o núcleo do Blocks Extensible Exchange Protocol. O objetivo era sustentar interações assíncronas e orientadas a conexão, com trocas simultâneas e independentes sob uma identidade de usuário. A conexão não recebia um único significado obrigatório.

Até o mapeamento para o transporte ficava separado. A RFC 3081 colocou uma sessão BEEP em uma conexão TCP. Completar TCP provava alcance e estado do suporte; não escolhia perfil, não concedia acesso e não entregava resultado.

O canal zero administrava, não executava

No início, só o canal zero existia. Ele carregava greeting, perfis suportados, pedidos para iniciar e fechar canais e a liberação da sessão.

Anunciar uma URI não era vinculá-la. Para abrir uma via, um par enviava start com número e alternativas de perfil. O receptor selecionava uma em resposta positiva ou recusava todas. A escolha registrada naquela resposta dava identidade ao canal.

Os números dispensavam coordenador central. O iniciador usava ímpares positivos; o ouvinte, pares positivos. Cada lado decidia localmente seus próximos canais sem colisão. Era uma regra comum mínima para um problema comum específico.

O perfil carregava o vocabulário

O core oferecia formas de troca. MSG começava; RPY e ERR encerravam uma interação um-para-um; ANS produzia respostas múltiplas e NUL fechava a série. Números de mensagem separavam intercâmbios; números de sequência acompanhavam todos os octetos do canal.

Frames de canais diferentes podiam alternar. Fragmentos de uma mensagem continuavam ordenados em seu canal, enquanto várias respostas ANS podiam se intercalar e ser reunidas pelo answer number. A regra permitia concorrência, não prometia justiça nem sucesso.

Perfis posteriores mostraram onde o sentido ficava. A RFC 3195 definiu syslog confiável sobre BEEP. A RFC 4227 criou para SOAP um caminho próprio entre boot e ready. A RFC 4744 manteve manager/agent de NETCONF separados de initiator/listener de BEEP. Quem abriu o transporte não se tornava automaticamente autoridade da aplicação.

Segurança nova não validava memória antiga

Havia canais de ajuste inicial e canais contínuos. TLS e SASL podiam mudar privacidade e identidade antes do fluxo duradouro, com apenas um canal de ajuste ativo por vez.

Depois de TLS, informações guardadas antes da proteção precisavam ser descartadas. Um atacante poderia tê-las alterado. A confidencialidade presente não autenticava o passado.

Também era necessário autorizar por canal. A RFC recomendava controle de acesso adequado à identidade autenticada e ao nível de privacidade antes de executar tarefa. Autenticar uma pessoa não autorizava todos os perfis nem todas as operações.

Uma conexão compartilhada exigia limites locais

TCP fazia controle de fluxo por conexão. A RFC 3081 acrescentou janelas por canal para evitar fome e bloqueio entre conversas. Cada canal começava com 4096 octetos; SEQ informava a próxima sequência esperada e o espaço aceito.

Não era retransmissão — TCP já entregava com confiabilidade. Era governança de buffer no interior da sessão. Para ser independente, cada conversa precisava de conta própria de capacidade e progresso.

O registro do porto também mudou

BEEP recebeu perfis para syslog, SOAP e NETCONF. Mais tarde, a RFC 9900 liberou os portos de NETCONF sobre BEEP e NETCONF sobre SOAP, preservando nomes de serviço.

Isso separa arquitetura de adoção. Publicar uma RFC não demonstrava uso permanente. Liberar um número não apagava a utilidade da distinção entre conexão, perfil e efeito. Texto, registro, software e operação envelhecem em ritmos diferentes.

O legado de RFC 3080 é essa recusa de atalhos. Greeting era anúncio. start aceito era vínculo. RPY era resposta de protocolo. Persistência, entrega e mudança externa precisavam de observação própria.

Fontes

  1. https://www.rfc-editor.org/info/rfc3080
  2. https://www.rfc-editor.org/rfc/rfc3080.html
  3. https://datatracker.ietf.org/doc/rfc3080/
  4. https://www.rfc-editor.org/rfc/rfc3081.html
  5. https://www.rfc-editor.org/rfc/rfc3117.html
  6. https://www.rfc-editor.org/rfc/rfc3195.html
  7. https://www.rfc-editor.org/rfc/rfc4227.html
  8. https://www.rfc-editor.org/rfc/rfc4744.html
  9. https://www.rfc-editor.org/rfc/rfc9900.html
  10. https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
  11. https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
  12. https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/