Resumo

  • O RFC 3404 tratou resolução como pedido tipado: I2L, I2R, I2C e I2N buscavam local, instância do recurso, descrição e nome persistente; formas no plural preservavam também a cardinalidade.
  • S, A e U indicavam a representação para a próxima etapa. P saía do DDDS para processamento da aplicação. Descobrir o resolvedor não autenticava o interlocutor nem o conteúdo devolvido.

Um sistema pode responder com sucesso à pergunta errada. Quem solicita uma descrição e recebe uma URL de download obteve informação relacionada, mas não equivalente. Quem pede o recurso e recebe seus metadados vê uma transação tecnicamente íntegra com sentido incorreto.

Publicado na trilha de padrões em outubro de 2002, o RFC 3404 definiu as aplicações DDDS de resolução de URI e URN. A arquitetura estava distribuída: o RFC 3401 apresentava a família; o RFC 3402, o algoritmo; o RFC 3403, as regras NAPTR no DNS; o RFC 3404, as aplicações; e o RFC 3405, a administração de uri.arpa. e urn.arpa..

O processo partia de uma cadeia exclusiva da aplicação. Na resolução genérica, o URI absoluto era canonizado e codificado; seu esquema fornecia a primeira chave conhecida, acrescida de uri.arpa. na consulta DNS. Para URN, o identificador do namespace conduzia a urn.arpa.. Regras NAPTR reescreviam ou delegavam até uma saída terminal ou uma entrega a outro sistema.

As aplicações de URI e URN eram tecnicamente idênticas, mas foram separadas na operação. A resolução de URN já dispunha de um atalho e não deveria depender da adoção de um resolvedor genérico por todos os esquemas URI. Assim, um namespace podia implantar valor próprio sem esperar uma decisão universal.

Services carregava o tipo da resposta. I2L devolvia um URI de local; I2Ls, um ou mais. I2R e I2Rs devolviam instâncias do recurso. I2C produzia uma descrição e I2N, um URN. Neste último caso, o texto alertava que decidir igualdade entre URNs podia exigir regras específicas do namespace.

Local e recurso não eram sinônimos. O primeiro diz onde tentar obtê-lo; o segundo é o objeto entregue. A descrição afirma algo sobre esse objeto; o nome persistente busca manter sua identidade quando os locais mudam. O mesmo identificador podia oferecer todas as operações, mas a evidência de uma não satisfazia as outras.

A cardinalidade integrava o contrato. O s de I2Ls e I2Rs permitia conjunto. Se o consumidor conservasse apenas o primeiro valor, inventaria sua própria política de seleção. O recibo deveria guardar serviço solicitado, singular ou plural, conjunto completo e escolha efetiva.

Um protocolo opcional podia anteceder os serviços. Seu nome, sozinho, era insuficiente. O RFC exigia especificação da codificação do pedido e da semântica da resposta. Dizer “HTTP” não informava como pedir descrição em vez de recurso, qual mídia representava cada resposta ou como serializar vários resultados.

Descoberta de capacidade não cria um protocolo de aplicação. A capacidade anunciada, o pedido observável e a classe da resposta precisam concordar. Sem esse vínculo, dois programas reconhecem a mesma palavra e continuam tratando de objetos diferentes.

Flags tratava de outra dimensão. S, A e U eram flags terminais do DDDS. S encaminhava um domínio para consulta SRV; A, para busca de endereços; U produzia um URI. Terminal significava fim do laço DDDS, não término da rede, da autenticação ou da validação do conteúdo.

P era de natureza diferente. Declarava que o restante seria específico da aplicação e estaria fora dos conceitos DDDS. Não era o quarto formato terminal, e sim uma fronteira de controle. Registrá-lo como terminal interno esconderia que outro sistema de regras assumiu autoridade.

As quatro flags eram mutuamente exclusivas em 2002, mas implementações não deveriam supor que o campo teria para sempre zero ou um caractere. Versões futuras poderiam combinar valores. Flag desconhecida fazia o registro ser ignorado e o processamento continuar. Essa verificação precedia a ordenação comum, pois a nova flag podia alterar a leitura dos demais campos.

Services vazio também era permitido numa delegação inicial. O publicador talvez ainda não soubesse protocolo e serviço finais. Vazio não queria dizer inválido nem universal: apenas adiava a escolha.

O RFC permitia otimização restrita dentro do mesmo ORDER. O cliente podia buscar um serviço mais aplicável do que sua primeira preferência, desde que preservasse entrada e saída do algoritmo básico. Não podia atravessar caminhos de delegação nem consultar um ORDER superior depois de uma correspondência.

Essa barreira separava capacidade local de autoridade publicada. O cliente escolhe entre opções equivalentes que sabe usar; não promove um destino conveniente de outra camada. Caso contrário, otimização vira reescrita silenciosa da delegação.

Registros SRV ou de endereço na seção Additional podiam economizar consultas, mas eram apenas otimização. A aplicação precisava funcionar sem eles. Descobrir o próximo nome, receber dados auxiliares e completar a conexão eram evidências distintas.

A segurança seguia a mesma divisão. Encontrar um resolvedor não definia comunicação segura; cada protocolo deveria especificá-la. uri.arpa. e urn.arpa. traziam riscos de disponibilidade, falsificação e administração. DNS validado não autenticava automaticamente a resposta da aplicação, o recurso ou a atualidade da descrição.

Expressões regulares deveriam passar por verificação antes da execução. Uma regra autêntica ainda podia ser perigosa num ambiente poderoso. Origem correta e interpretação segura não eram a mesma prova.

O RFC Editor lista três erratas editoriais. As verificadas 282 e 787 corrigem referências sobre Additional Information de RFC 3404 para RFC 3403. A 2923, mantida para atualização do documento, corrige números de referências na Seção 4. Nenhuma muda flags, tipos de serviço ou cardinalidade.

Um recibo operacional precisa conservar entrada canônica, esquema ou namespace, primeira chave, consulta DNS, conjunto NAPTR, decisão sobre flags, protocolo, serviço e cardinalidade, seleção no mesmo ORDER, regra escolhida, transição S/A/U/P, próxima consulta ou URI, pedido do protocolo, par autenticado, tipo de conteúdo, classe do objeto e resultado consumido.

O princípio da especificação inicial mínima de Lu Heng explica o desenho: padronizar as fronteiras compartilhadas e permitir evolução local dos protocolos. A primazia do código em funcionamento fornece o teste: pedir local, recurso e descrição do mesmo identificador; retirar Additional; inserir flag desconhecida; variar capacidades no mesmo ORDER. Só deve mudar aquilo que o contrato permite.

O RFC 3404 não prometeu toda resposta para todo identificador. Exigiu que o sistema dissesse o que buscava e por qual fronteira avançava. “Resolvido” deixou de ser um sinal verde vazio e passou a ser uma afirmação verificável.

Fontes