Resumo

  • RFC 3151 normalizava a string pública e transcrevia espaços, separadores e caracteres reservados em urn:publicid:; conversão correta não validava proprietário nem recurso.
  • A equivalência era só lexical: depois da normalização, duas URNs eram equivalentes apenas se fossem idênticas. Nome igual ainda podia encontrar catálogos, bytes e efeitos diferentes.
  • Catálogo, caminho local, conhecimento embutido e cache continuavam opções de resolução; seleção, mapeamento, busca, parsing e resultado precisavam de comprovantes separados.

A ponte carregava um nome, não um endereço

Uma entidade externa XML tinha identificador de sistema e identificador público. O primeiro era URI por definição e historicamente tendia a ser local. O segundo era uma string herdada do SGML, usada como nome mais amplo e persistente.

Quando novas especificações exigiram URI para identificadores externos, abandonar nomes e catálogos instalados imporia ruptura. RFC 3151 registrou publicid para expressar a string como urn:publicid:{transcrição}.

A aparência de URI não aumentava autoridade. Unicidade e persistência continuavam sendo propriedades do identificador original. Dono não registrado e política fraca atravessavam a ponte sem reparo.

O RFC era Informational e dizia não definir padrão de Internet. Seus exemplos eram didáticos, não garantidamente reais. Eles comprovavam a regra, não implantação, registro ou recurso disponível.

Normalizar melhorava comparação e apagava uma diferença

Antes da transcrição, sequências de espaço, tab, retorno e nova linha viravam um espaço, e espaços nas pontas sumiam. Duas capturas com formatação distinta podiam então produzir o mesmo nome.

Essa perda era intencional. Guardar apenas a URN impedia reconstruir o texto original. Por isso fonte, codificação, string normalizada e versão da regra pertenciam ao recibo.

Espaço normalizado virava +. Como sequências já tinham sido reduzidas, plus adjacentes não deveriam nascer de espaços. Um + literal virava %2B. Um registrava espaço; outro, caractere.

Normalizar depois de escapar mudava a operação. A saída podia parecer plausível sem demonstrar o processo correto.

Estrutura visível não era estrutura validada

Formal Public Identifiers normalmente combinavam dono, classe, descrição, língua e, às vezes, versão. // separava campos e :: aparecia em componentes.

RFC 3151 fazia // virar : e :: virar ;, preservando a forma sem exigir um parser SGML completo. Reconhecer FPI válido estava fora do algoritmo.

Logo, dois-pontos na saída indicavam barras duplas na fonte normalizada. Não provavam registro do dono nem validade dos campos.

Caractere literal seguia outro caminho: : fora de :: virava %3A, / fora de // virava %2F, e ; virava %3B. Apóstrofo, interrogação, cerquilha e porcentagem também eram escapados. Ordem e posição das substituições importavam.

Round-trip podia provar preservação do nome normalizado, nunca atribuição ou resolução.

Identidade lexical parava no nome

Duas URNs eram equivalentes se e somente se fossem lexicalmente idênticas após a normalização da fonte. Não havia folding de caixa, alias de dono ou comparação semântica.

Um catálogo podia mandar dois nomes ao mesmo arquivo sem torná-los iguais no namespace. E uma URN igual podia passar por catálogos, bases, sistemas de arquivos e caches diferentes.

O RFC permitia vários identificadores públicos para um recurso. Igualdade de nome, mapa, bytes e comportamento eram testes diferentes. RFCs posteriores de URI e URN não reescreviam retroativamente essa regra.

A fragilidade do dono também persistia

FPIs com dono registrado deveriam ser únicos. Nomes informais e donos não registrados podiam ou não ser únicos, sem uma política geral de fiscalização.

Persistência vinha do mesmo lugar. Registro ajudava, mas não garantia catálogo ou conteúdo. O esquema IDN baseado em domínio herdava as fraquezas de persistência de domínios.

urn:publicid: não mantinha serviço, renovava domínio nem congelava representação. Um recurso sem identificador público precisava primeiro receber um segundo as regras originais; só então era transcrito.

Guarde dono, estado de registro, política, data e contexto. Não extraia autoridade do formato.

Resolver continuava contextual

O documento citava catálogos OASIS, mapeamento para caminhos locais, tabelas conhecidas pelo programa e caches. Não definiu resolvedor mundial único.

Ordem de catálogos, rewrite, base URI, mount, rede e idade do cache escolhiam o destino. Match de regra era recibo de seleção, não de leitura.

Depois vinham bytes e hash, parser e política de entidades, diagnósticos e resultado. resolved=true escondia todas essas etapas.

Não havia mecanismo de validação especificado. A ausência de novas considerações de segurança não autenticava dono, catálogo, cache ou alvo. Um encoder perfeito podia chegar a um arquivo velho ou substituído.

O código em execução corrigia a conclusão

Uma URN perfeita podia encontrar DTD antiga num arquivo local. Regra, abertura e parsing davam certo, mas o aplicativo usava versão errada. Outra máquina podia resolver o mesmo nome para bytes diferentes.

A tabela do RFC mandava na transcrição. A execução decidia qual resolvedor rodou, que regra venceu, que bytes chegaram e o que ocorreu. Cada camada tinha seu próprio recibo.

O feito histórico foi limitado com precisão: um nome antigo entrou na arquitetura URI sem fingir ser localização. Transportar identidade não completou a resolução.

Fontes