Resumo

  • No RFC 3402, o resultado de uma regra não terminal virava a chave da próxima busca, porém a regra seguinte ainda era aplicada à Application Unique String exata que iniciara o processo.
  • A separação impedia que uma cadeia de delegações acumulasse alterações de identidade: cada autoridade podia indicar onde procurar depois, não substituir aquilo que estava sendo procurado.

Uma sequência de reescritas costuma ser imaginada como uma oficina. A primeira regra altera o texto, a segunda recebe a alteração e a terceira trabalha sobre o que restou. Em descoberta distribuída, essa imagem é perigosa. Depois de algumas etapas, a última autoridade pode estar avaliando um artefato das transformações anteriores, não o objeto que o aplicativo apresentou no início.

Publicado na trilha de padrões em outubro de 2002, o RFC 3402 era a segunda parte do Dynamic Delegation Discovery System. Seu algoritmo implementava vinculação tardia. Um aplicativo fornecia uma Application Unique String, a AUS; o cliente recuperava regras quando necessário, atravessava bases declaradas e parava quando uma regra terminal produzisse o resultado previsto pelo aplicativo.

O ponto decisivo era o papel da saída intermediária. Uma substituição não terminal gerava a chave usada para recuperar outro conjunto ordenado de regras. Ela não se tornava uma nova AUS. Na etapa seguinte, a expressão era aplicada novamente à cadeia original. O documento proibia, em linguagem normativa, usar a saída anterior como sujeito da regra posterior e exigia que as especificações de aplicativo preservassem essa proibição.

O percurso começava com a First Well Known Rule. Definida pelo aplicativo e não buscada na base, ela transformava a AUS na primeira chave válida. Assim, o ponto de partida vinha de um contrato conhecido. O fato de uma base aceitar determinado formato não bastava para convertê-la em origem autorizada da delegação.

Cada busca devolvia uma lista ordenada. O cliente testava as substituições contra a AUS até achar um resultado não vazio e então avaliava Services, Flags e Priority. Correspondência textual, serviço aceitável, terminalidade e preferência eram decisões separadas. Se o serviço não servisse, o cliente retomava a mesma lista depois da regra rejeitada, preservando ordem, motivo e posição.

Ao aceitar uma regra não terminal, o cliente validava o resultado como chave da base seguinte. Uma expressão defeituosa poderia criar uma chave ilegal, mesmo com aparência plausível. A validação protegia o limite da base; jamais autorizava elevar a chave à condição de novo objeto.

O RFC chamou o modelo acumulativo, associado a cadeias do tipo sendmail, de frágil e sujeito a erro. Quando cada saída vira entrada, um desvio inicial altera o significado de todas as decisões posteriores. Mantendo a AUS fixa, é possível reproduzir cada regra isoladamente e examinar cada saída segundo sua função: chave de consulta ou resultado terminal.

Havia uma passagem explícita para outro contexto. Um Flags podia suspender o aplicativo DDDS e entregar o fluxo a outro aplicativo ou a uma etapa específica de protocolo; o p do RFC 3404 era o exemplo. Isso declarava uma troca de sistema. Não era permissão para as regras antigas continuarem enquanto uma chave intermediária fingia ser a AUS.

Uma regra terminal encerrava o algoritmo com uma saída no formato esperado, acompanhada de Flags e Services. Encerrar não provava disponibilidade posterior, autoridade de quem publicou a regra nem aceitação pelo consumidor. O valor final precisava permanecer distinto do sucesso do serviço.

Priority também tinha alcance restrito. Indicava preferência entre opções equivalentes, como uma alternativa melhor, mais rápida ou mais barata. O RFC afirmou que não era balanceamento de carga. Distribuição de tráfego pertencia a outro mecanismo, como SRV quando aplicável.

A validade temporal limitava atalhos. O cliente podia guardar chaves e regras anteriores, mas tinha de obedecer à expiração definida pela base. Se uma regra usada no caminho expirasse, o algoritmo recomeçava no primeiro passo. Misturar uma metade antiga com outra atual criaria uma delegação que talvez nunca tivesse existido de forma simultânea.

Por isso o algoritmo dependia de dois contratos. A especificação do aplicativo definia AUS, regra inicial, bases permitidas, caracteres e saída terminal. A especificação da base definia armazenamento, busca, formatos, inserção e prevenção de colisões. O RFC 3401 advertia que ler só uma parte da série levava a erros de interoperabilidade.

DDDS também reconhecia o que não podia decidir. Hora, pagamento, direitos ou transações eram fatos externos à AUS e às regras. Escondê-los em uma saída opaca faria o algoritmo parecer portador de uma autoridade que nunca recebeu. Segurança concreta só surgia ao combinar aplicativo e base específicos.

O RFC 3403 descreveu DNS e NAPTR; o RFC 3404, URI Resolution; o RFC 2916, um precursor de ENUM. Eram aplicações da arquitetura, não prova de suporte universal. O registro IANA ENUM Service Registrations mostra coordenação de identificadores em uma aplicação posterior, mas registro não comprova execução, atualidade, autoridade ou êxito do serviço.

O RFC Editor registra uma única errata editorial verificada para o RFC 3402, a 7049. Ela corrige de 4.4 para 4.3 a seção do RFC 3404 que discute o indicador p; o invariante do algoritmo permanece intacto.

Um recibo operacional deve preservar AUS, aplicativo e versão, First Well Known Rule, tipo de base, todas as chaves, conjuntos ordenados, identidade e validade das regras, correspondências, resultados, rejeições de serviço, posição de retomada, decisão de Priority, Flags terminal, validação da saída e ação do consumidor.

O princípio de especificação inicial mínima de Lu Heng explica a contenção: padronizar apenas a fronteira compartilhada por implementações independentes e deixar semântica e armazenamento para contratos próprios. A primazia do código em execução completa a exigência. É preciso reproduzir a AUS com as regras observadas e provar que nenhuma chave intermediária tomou o lugar do sujeito.

O legado do RFC 3402 é uma regra de continuidade. A autoridade podia mover a busca e trocar a chave quantas vezes fossem necessárias. Não podia mover, sem aviso, aquilo que todas as regras deveriam resolver.

Fontes