Resumo

  • O espaço global da RFC 3650 era federado: uma autoridade de nomes única e um nome local único formavam um Handle único dentro do sistema, enquanto espaços locais podiam manter seus nomes e vínculos de valores.
  • O Global Handle Registry (GHR) fornecia sobretudo informações de serviço para localizar o serviço Handle responsável; os Local Handle Services (LHS) normalmente resolviam os Handles sob suas autoridades.

Um nome global não exigia um banco de dados global

A questão da RFC 3650 não era apenas como escrever um identificador persistente. Era como diferentes espaços de nomes e domínios administrativos poderiam compartilhar um namespace sem entregar todos os registros de recursos a um único operador. A resposta foi separar nome, autoridade e descoberta do serviço.

Um Handle combina uma autoridade de nomes — o prefixo — com um nome local, ou sufixo. A autoridade é única no Handle System; o nome local precisa ser único sob ela. Juntos, tornam o Handle único dentro desse sistema. Um namespace local já existente poderia aderir obtendo uma autoridade única, sem abrir mão de seus nomes locais e vínculos de valores. “Global”, portanto, descrevia o contexto compartilhado de unicidade, não um banco de dados sob administração única. RFC 3650

A arquitetura de serviços seguia a mesma separação. A RFC 3650 colocou o Global Handle Registry (GHR) no topo e os Local Handle Services (LHS) abaixo. O Handle de uma autoridade trazia informações de serviço — sites e interfaces dos servidores — para orientar o cliente até o serviço “de origem” responsável. Primeiro, o cliente consultava o GHR; depois, contatava o serviço responsável pelo Handle solicitado. O registro funcionava como mapa de responsabilidade do serviço, não necessariamente como repositório de todos os valores locais. RFC 3650 · RFC 3651

“Local” dizia respeito à responsabilidade sobre namespace e administração, não à proximidade geográfica. Um LHS poderia operar diversos sites espalhados pela Internet, cada um com vários servidores. A replicação entre sites é uma possibilidade da arquitetura, não evidência de disponibilidade medida em uma implantação específica.

Uma hierarquia de registro não era uma cadeia de comando

As autoridades podiam ser organizadas em árvore. O pai precisava ser registrado antes de cadastrar um filho, mas a RFC 3650 distingue essa ordem de qualquer relação administrativa: os namespaces pai e filho poderiam estar em serviços diferentes e não compartilhar privilégios. A árvore, por si só, não informa quem pode alterar os Handles do filho, arbitrar uma disputa ou garantir continuidade do serviço. RFC 3650

O GHR também não era um diretório proibido de lidar com Handles individuais. A RFC 3650 diz que ele poderia administrar qualquer namespace Handle, e a RFC 3651 admite que também gerencie, resolva ou administre alguns Handles que não sejam autoridades de nomes. O ponto mais preciso é que seu papel distintivo era administrar Handles de autoridade e suas informações de serviço; em geral, os serviços locais cuidariam dos namespaces atribuídos a eles. RFC 3651

O valor associado a um Handle poderia mudar sem alterar o identificador, permitindo atualizar a localização ou outras informações do recurso. Mas a sintaxe não garante permanência: a RFC 3650 diz que ela depende de cuidado administrativo. Uma sequência estável não obriga uma instituição a manter registros, um resolvedor ou um destino acessível. RFC 3650

Relacionado a outros identificadores, sem ser equivalente

A RFC compara o Handle a sistemas de nomes existentes sem confundi-los. O DNS organiza nomes e resolução por sua própria delegação de zonas. O trabalho sobre URNs especifica nomes destinados a identificar recursos independentemente de sua localização; descobrir e alcançar serviços de resolução é uma questão separada. Um Handle pode servir a aplicações que precisam de nomes persistentes ou resolução, mas não se torna automaticamente uma URN. Uma resposta Handle tampouco comprova que o recurso está acessível. RFC 1034 · RFC 1737 · RFC 2276 · RFC 3406 · RFC 8141

O status de publicação também importa. A RFC 3650 é Informational, não um padrão da Internet. A nota do IESG afirma que grupos do IETF e do IRTF haviam discutido o sistema, mas não alcançaram consenso no IETF sobre a arquitetura descrita nem sobre sua posição na arquitetura de identificadores do IETF. Isso não é endosso nem rejeição: delimita a diferença entre uma proposta publicada e consenso institucional. RFC 3650

A contribuição histórica foi distribuir funções: um registro-raiz indicava qual serviço atendia cada autoridade, enquanto serviços administrados separadamente podiam manter e resolver seus próprios namespaces. A promessa ainda dependia dos registros, operadores e caminhos de serviço que mantinham esse mapa funcionando. A RFC descreve como as fronteiras poderiam se encaixar; não prova resolução universal, permanência, adoção em escala ou acesso bem-sucedido a um recurso específico.

Fontes: RFC 3650; RFC 3651; RFC 3652; RFC 1737; RFC 2276; RFC 3406; RFC 8141; RFC 3986; RFC 1034.