Resumo

  • A RFC 3983 chamava o canal BEEP de pronto depois da aceitação do perfil IRIS e da criação do canal. Esse estado habilitava mensagens dos tipos anunciados; não autenticava automaticamente servidor ou usuário.
  • O tipo de registro podia escolher autenticação própria do servidor, o método TLS básico ou declarar nenhuma autenticação. Criptografia, identidade do usuário, autorização da consulta e confiança no destino de uma referência ainda exigiam provas próprias.

Um painel recebe o evento “channel ready” e acende uma única luz verde. Daquele momento em diante, alertas, automação e auditoria passam a tratar o vínculo como confiável. RFC 3983 dava a esse evento um significado muito menor: perfil BEEP aceito, canal criado, capacidade de trocar mensagens IRIS. O protocolo não havia concluído todas as decisões que a tela resolveu condensar.

A ficha do RFC Editor, as erratas e o histórico no Datatracker documentam o texto Standards Track de janeiro de 2005. Ele mapeou o Internet Registry Information Service para o Blocks Extensible Exchange Protocol. Nada nesses registros mede adoção ou confirma um serviço ativo.

BEEP já oferecia enquadramento, autenticação, conexão e negociação, com ferramentas e experiência que implementadores podiam reutilizar. Um transporte exclusivo para IRIS precisaria reconstruir funções parecidas. Segundo o documento, HTTP arriscava confusão com aplicações Web e práticas divergentes de TLS; TCP direto não oferecia a negociação exigida por um cliente que, seguindo referências, encontrava servidores com parâmetros distintos. Essa justificativa não é uma comparação medida de desempenho.

O URI do perfil reunia a versão do esquema IRIS e o URN do tipo de registro. Na criação do canal, o cliente podia oferecer vários elementos profile, negociando versões por tipo servido. Quando um deles era aceito e o canal criado, o canal ficava pronto para mensagens IRIS. O servidor tinha de honrar consultas de todos os tipos que anunciara em qualquer canal aberto com aquele perfil.

Honrar não significava liberar dados. O padrão básico era uma troca um a um: MSG levava um XML IRIS válido; RPY trazia um XML IRIS; ERR carregava falhas BEEP. Um tipo podia definir outro padrão dentro de BEEP, mas precisava aceitar o padrão básico para lookupEntity. O núcleo IRIS e sua situação documental continuavam responsáveis por recusas, consultas não suportadas e outros resultados do registro. O transporte deixava a pergunta circular sem garantir uma resposta positiva.

A identidade do servidor precisava de convenção adicional. Ao usar o perfil de ajuste TLS de BEEP, o tipo de registro deveria definir seu método; sem definição, valia o básico. O cliente enviava a autoridade desejada pelo mecanismo serverName. O servidor apresentava um certificado X.509 com essa autoridade. O cliente verificava a criptografia de acordo com TLS e, em seguida, comparava o nome da autoridade com dNSName e as formas autorizadas de subjectDN.

Essas etapas não eram redundantes. Um certificado pode ter cadeia válida e pertencer a outro nome. Um nome igual em certificado não validado tampouco prova identidade. A ligação só funcionava quando a credencial era confiável e representava a autoridade solicitada.

O checklist de cada tipo tornava a política explícita. Sua especificação devia declarar um padrão de mensagens e definir autenticação TLS do servidor, escolher o método básico ou declarar que não usaria autenticação de servidor. Logo, um canal corretamente negociado podia estar pronto num tipo que, por decisão expressa, não autenticava o servidor.

O usuário ainda não aparecia dessa conclusão. RFC 3983 listava SASL DIGEST-MD5 e OTP para autenticação de usuário sem criptografia da sessão. Listava usos de TLS somente para cifrar e variantes com certificado do cliente para adicionar autenticação. Acesso anônimo podia ocorrer sem perfil de autenticação ou com SASL ANONYMOUS. Servidor autenticado, sessão cifrada, usuário identificado e resultado autorizado eram combinações, não uma sequência automática.

A composição vinha do próprio BEEP. RFC 3080, seu status, suas erratas e seu registro no Datatracker definiam perfis, canais, mensagens e ajustes. RFC 3081 e sua ficha levavam BEEP sobre TCP. Mudar uma propriedade da sessão não certificava as demais.

As referências da época estabelecem o contexto. RFC 2246 e seu status especificavam TLS 1.0; RFC 2222 e sua ficha, o SASL então citado. RFC 2817, com seu status, e RFC 2818, com o seu, registravam as abordagens HTTP/TLS discutidas. Um mecanismo disponível não é evidência de sua aplicação correta em uma sessão.

Referências entre servidores tornavam a custódia da credencial visível. RFC 3983 alertava para não entregar segredos a destinos não confiáveis, desaconselhava SASL PLAIN e proibia seu uso antes de cifrar a sessão TCP. A criptografia protegia o segredo em trânsito; não decidia se o novo destinatário tinha direito de recebê-lo.

Mais tarde, RFC 4992 e sua página de status acrescentaram XPC sobre TCP e atualizaram o núcleo. A sequência prova modularidade de transporte, não adoção nem motivo de substituição.

O registro de esquemas URI da IANA mantém iris.beep, e o registro de parâmetros BEEP da IANA mantém namespaces de perfis e ajustes. São registros protocolários, não recibos de canal, identidade, autorização ou resultado.

A contribuição histórica da RFC 3983 foi resistir à luz verde total. Pronto para trocar mensagens era uma condição útil e estreita. Transformá-la em prova de confiança apaga justamente os estados que permitem saber, depois, qual decisão falhou.

Sources