Resumo

  • No RFC 3340, o identificador de uma operação no canal BEEP valia apenas enquanto o canal existia, mas o identificador inserido nos dados de um serviço APEX podia atravessar a desconexão.
  • Um segundo aplicativo no mesmo endpoint podia receber a resposta do primeiro; nome, correlação, geração conectada e autoridade para agir continuavam sendo fatos separados.

A seção 6.1.1 descreve uma sucessão sem esconder a ambiguidade. Um aplicativo se conecta como endpoint, envia dados com um identificador de transação para um serviço e, mais tarde, sai da malha de relés. Outro aplicativo assume o mesmo endpoint e também envia requisições. Depois disso, o segundo pode receber do serviço uma resposta à solicitação do primeiro, contendo o identificador criado pelo primeiro.

O encaminhamento pode estar certo e a correlação também. A falha de interpretação aparece quando essas duas correções são tratadas como prova de continuidade. O endpoint é um nome durável; a conexão BEEP, o processo e a intenção têm vidas próprias. Quem ocupa o nome agora não herdou necessariamente a operação iniciada antes.

O limite do canal

O APEX utilizava o BEEP. Em operações endpoint-relé e relé-relé, o identificador fazia sentido só durante a vida do canal. Liberada a conexão BEEP, o canal deixava de existir e o aplicativo já não permanecia conectado à malha. Um identificador de attach pertencia a esse contexto fechado.

Nas conversas com serviços APEX, porém, o identificador podia ficar embutido nos dados. A execução no serviço e sua resposta não precisavam terminar antes da desconexão. Por isso o RFC chamou esses valores de potencialmente duradouros e aconselhou que parecessem imprevisíveis, reduzindo ambiguidades.

Ser imprevisível não significa provar origem. A propriedade não cabe em um número difícil de adivinhar. O valor não revela qual processo o emitiu, se a intenção foi cancelada, se o novo aplicativo aceitou trabalho pendente nem se a política atual permite executar a resposta. Um ledger deve guardar separadamente endpoint, par autenticado, geração de conexão, solicitante e recebedor.

O ok que chega cedo

O processamento do relé mostra outra divisão de recibos. Primeiro ele verifica se o cliente BEEP pode transmitir em nome do originador e trata opções aplicáveis aos dados. Em seguida devolve ok. Só depois processa opções do originador e cada destinatário.

Quando o destino está em outro domínio administrativo, considera-se o destinatário processado depois de abrir uma sessão com o relé apropriado, mandar os novos dados e receber o ok desse relé. Para destino local, a política precisa autorizar a comunicação, o endpoint deve estar conectado e o aplicativo precisa devolver ok após seu processamento. São marcos diferentes. Nenhum autoriza chamar o primeiro aceite de resultado final do serviço ou de efeito para o usuário.

Com statusRequest, relés aplicáveis podiam enviar statusResponse posteriormente por meio do serviço de relatórios. O valor all em targetHop permitia acompanhar a passagem pela malha. A trilha acrescentava observações sem ampliar retroativamente o significado do primeiro ok. Também expunha topologia; o RFC 3342 sugeria a possibilidade de desativar recursos de temporização fora das fronteiras administrativas.

Autenticação com escopo

O DNS SRV indicava onde encontrar relés. O RFC 3340 reconhecia que a integridade do encaminhamento dependia do DNS e do uso que os aplicativos faziam dele, com garantia adicional se o iniciador BEEP exigisse autenticação do listener. Um par autenticado podia receber autorização para atuar como endpoint. Para autenticação ponta a ponta, o conteúdo podia ser assinado.

Essas provas não tornam o aplicativo eterno. Elas sustentam o relé alcançado, o par presente, a permissão de usar um nome ou a integridade do conteúdo. Não sustentam a afirmação de que o processo conectado agora fez a requisição antiga. Até uma resposta assinada pode exigir quarentena se faltar o recibo que transfere o trabalho à nova geração.

O conjunto mínimo inclui identidade lógica, par, canal, geração, workload, identificador e método de criação, hash da solicitação, recibo persistente do serviço, aceites e relatórios, evento de saída, nova conexão, hash da resposta, geração receptora, decisão de consumir ou descartar, estado de idempotência e resultado observado. Chaves em comum ligam esses documentos; não substituem o seu conteúdo.

Quando o APEX virou história

O RFC 3340 foi publicado em julho de 2002 na trilha de padrões, ao lado do serviço de acesso, do pacote de opções e do serviço de presença dos RFCs 3341 a 3343. Em 29 de julho de 2012, o histórico do IETF registrou a reclassificação dos quatro como Historic. Segundo o conhecimento do IETF, nenhuma implementação havia sido implantada; as funções de APEX eram então oferecidas pelo XMPP, amplamente implantado e definido nos RFCs 6120 e 6121.

Essa nota não explica a decisão de cada implementador nem atribui o resultado ao identificador duradouro. Não prova defeito, incidente ou fracasso operacional. O cuidado histórico exige manter separados o destino comercial de uma arquitetura e os limites que sua especificação descreveu. Filas de tarefas, callbacks e identidades de serviço atuais ainda trocam processos sob um nome estável.

Uma resposta atrasada pode continuar válida. O ponto decisivo é obter uma prova adicional de que a geração presente a adotou. A correlação responde “a que pedido isso se refere”; a governança ainda deve responder “quem pode agir com isso agora”.

Fontes