Resumo

  • A RFC 3981 fez do núcleo IRIS uma peça deliberadamente insuficiente: esquemas de cada registro definiam consultas, resultados e classes de entidades, enquanto transportes separados cuidavam de autenticação e sessões.
  • A recusa de um cliente universal protegia diferenças de domínio e a operação de serviços públicos. Uma consulta bem formada ainda podia ser sem sentido, não suportada, limitada, não autorizada ou incapaz de chegar a um resultado.

O operador de um registro público vê uma linguagem de consulta de modo diferente do autor de uma interface. Para a interface, mais combinações parecem significar mais poder. Para quem mantém o serviço disponível, uma busca parcial cruzando vários índices pode ser uma conta sem teto — e uma ferramenta igualmente atraente para pesquisa legítima e abuso. Se o recurso ameaça o serviço, ele será desligado. A linguagem continuará “universal” apenas no papel.

Essa é uma das escolhas centrais de RFC 3981, publicada em janeiro de 2005 como o núcleo XML do Internet Registry Information Service, o IRIS. A página de situação, o registro de erratas e o histórico no Datatracker documentam o status Standards Track e a atualização posterior pela RFC 4992. Não medem adoção, servidores ativos ou sucesso comercial.

O sistema separava três camadas. A camada própria do tipo de registro declarava consultas, resultados e classes de entidades. A camada comum IRIS organizava conjuntos de busca e de resultados, referências, continuações e identificação dos tipos. A camada de transporte de aplicação assumia autenticação, passagem de mensagens, conexões, sessões e a sintaxe de URI associada. Dividir essas funções impedia que uma convenção de mensagem se transformasse, por acidente, em autoridade sobre dados ou acesso.

A própria especificação avisa que o esquema do núcleo tem um tipo básico de consulta, dois tipos autônomos de resultado e nenhuma estrutura de registro. Sozinho, é de utilidade limitada. Isso não é uma tarefa deixada pela metade. Cada tipo era identificado por um URN que também apontava para seu namespace XML e seu esquema; ali entravam as particularidades. Um serviço podia oferecer mais de um tipo sem que o núcleo inventasse uma árvore comum para todos.

Os documentos derivados mostram a fronteira em funcionamento. RFC 3982, com sua ficha oficial, definiu um tipo para registros de domínios. RFC 4698 definiu um tipo para registros de endereços. A presença de dois esquemas não fragmentava o padrão; preservava semânticas que não cabiam honestamente no mesmo molde.

O lookup comum era intencionalmente estreito. Ele confrontava um valor discreto com um índice, e lookupEntity informava o tipo de registro, a classe e o nome da entidade. Valores parciais, vários índices ou várias consultas sobre um índice formavam uma busca mais ampla. A RFC 3981 não criou uma linguagem única para toda busca possível. Cabia a cada tipo publicar as buscas que seus dados e sua operação podiam sustentar.

Daí o título da seção sobre “a ilusão de um cliente universal”. Um cliente genérico podia executar lookup e apresentar uma resposta rudimentar. Para formular uma busca útil ou explicar a resposta, precisava saber o que aqueles dados significavam. Acrescentar uma linguagem comum não removia o conhecimento do domínio; apenas obrigava o software a traduzir a intenção para o menor denominador comum.

A decisão vinha de requisitos anteriores. RFC 3707 e sua página de status registraram para o CRISP preocupações com busca, encaminhamento distribuído, versões e usuários abusivos. A RFC 3981 respondeu a esse ambiente de serviços voltados ao público. As fontes, porém, não quantificam carga maliciosa nem demonstram que toda linguagem genérica seja insegura.

Referências e continuações tampouco equivaliam a respostas finais. Uma referência de entidade carregava conhecimento específico de outra entidade. Uma continuação de busca dizia que outra autoridade talvez levasse ao que se procurava, talvez a outro material, talvez a nada. O cliente deveria seguir cada resposta apenas uma vez para evitar laços. Receber o próximo endereço não provava alcançabilidade, autoridade final ou resultado.

O vocabulário de erro separava outras condições que uma tela poderia juntar. invalidName tratava da sintaxe; invalidSearch, da semântica; queryNotSupported, da capacidade; limitExceeded, da política de recursos; nameNotFound, da ausência no índice; permissionDenied, da autorização. Validar XML não resolvia nenhuma das demais perguntas.

Até o transporte permaneceu modular. RFC 3983 e seu status mapearam o IRIS para BEEP. Depois, RFC 4992 atualizou a RFC 3981 com o XPC, um transporte TCP capaz de fragmentar e colocar XML em pipeline; sua ficha, suas erratas e seu registro no Datatracker documentam essa mudança. Trocar enquadramento, sessão ou autenticação não alterava o significado de uma consulta de domínio ou endereço.

O registro de esquemas URI da IANA ainda lista iris e esquemas relacionados, e o IETF XML Registry mantém o namespace iris1. São provas de registro protocolar, não de um serviço atual, de uma consulta bem-sucedida ou de ampla implantação.

Historicamente, a RFC 3981 valorizou o limite certo. Ela padronizou juntas, não apagou as peças que elas uniam. O núcleo incompleto permitia interoperar sem anunciar que uma sintaxe comum conhecia todos os registros — e sem obrigar operadores a sustentar uma promessa que precisariam desativar.

Sources