Resumo

  • O RFC 3529 transportava tanto o resultado normal quanto a falha XML-RPC dentro de BEEP RPY; uma falha da aplicação não era convertida em ERR.
  • Canal pronto, identidade protegida e resposta correlacionada eram evidências diferentes de autorização, execução correta e efeito persistente.

O detalhe histórico decisivo do RFC 3529 aparece quando o servidor tem uma notícia ruim. Em vez de transformar uma falha XML-RPC em erro BEEP, o perfil determinava que toda methodResponse fosse devolvida em RPY. A moldura dizia que a resposta chegou; o documento interno dizia se o procedimento deu certo.

Antes disso, o perfil percorria boot e ready. O iniciador enviava bootmsg com o recurso desejado. Um bootrpy confirmava que o servidor reconhecia esse recurso e permitia a mudança para ready. Mensagem malformada ou recurso desconhecido produzia error ou ERR, sem mudança de estado. Esse fracasso pertencia à ligação do perfil, não ao método remoto.

Em ready, methodCall seguia em MSG e methodResponse voltava em RPY. O significado positivo de RPY era limitado ao padrão um-para-um do BEEP. Para saber o resultado da aplicação, o cliente precisava interpretar os parâmetros normais ou a estrutura de falha do XML-RPC. Contar quadros sem ler o corpo criava uma taxa de sucesso fictícia.

A URL montava etapas anteriores. A autoridade de xmlrpc.beep virava serverName; o caminho virava recurso de inicialização. Sem porta explícita, a descoberta podia consultar _xmlrpc-beep._tcp por SRV e depois resolver o endereço, usando a porta atribuída na ausência de um SRV adequado. Descobrir um destino não provava que havia listener, perfil ou método funcional.

xmlrpc.beeps exigia que a sessão BEEP fosse ajustada para privacidade antes de iniciar o perfil. Com TLS, o cliente comparava a autoridade da URL com a identidade do certificado. Isso protegia o caminho e qualificava o par. Não concedia permissão ao método, não validava a regra de negócio e não confirmava que uma alteração havia sido gravada.

As escolhas mínimas de segurança registram 2003: DIGEST-MD5 e TLS com RSA/3DES. Documentos posteriores mudaram o quadro de SASL e depreciaram versões e práticas antigas de TLS. A leitura atual deve conservar o valor arquitetônico e rejeitar a configuração criptográfica como recomendação presente.

O mesmo limite vale para o registro. Perfil BEEP, esquemas xmlrpc.beep e xmlrpc.beeps, serviço xmlrpc-beep e porta TCP 602 eram símbolos coordenados. IANA pode provar que o nome foi registrado, não que a implementação existe, o serviço está ativo ou uma chamada produziu efeito.

BEEP pretendia reutilizar uma sessão para canais e perfis distintos. Seu mapeamento sobre TCP tratava transporte e fluxo; o perfil SOAP sobre BEEP mostrou uma alternativa vizinha; os tipos de mídia XML davam forma ao documento. O RFC 3529 acrescentou uma disciplina de evidência: a classe do quadro exterior não absorvia o resultado da linguagem de aplicação.

Uma trilha operacional completa ligaria autoridade, resultado de descoberta, endereço, identidade do par, canal, recurso, número da mensagem, RPY ou ERR e conteúdo normal ou fault. Para métodos com efeito, seria necessário registrar também um identificador estável, uma versão ou uma leitura posterior.

Repetir chamadas sem essa trilha era arriscado. Uma queda antes da resposta deixava incerto se houve execução. Um RPY com falha informava rejeição, mas não garantia ausência de efeito parcial sem um contrato específico. Reexecutar uma operação não idempotente podia duplicar o dano que a recuperação tentava evitar.

O RFC 3529 era Experimental. Sua permanência não depende de provar adoção. Ele captura uma regra geral de engenharia: uma camada pode cumprir perfeitamente sua função ao entregar o fracasso declarado por outra. O observador precisa guardar os dois veredictos.

Sources