Resumo

  • O RFC 2056 definiu dois esquemas de URL para Z39.50 porque iniciar ou reutilizar uma sessão e recuperar um registro específico eram intenções diferentes, embora compartilhassem partes da mesma sintaxe.
  • No caminho de recuperação, um identificador opaco não bastava sozinho: banco de dados, construção da consulta, contagem única, conjunto de elementos e sintaxe de registro participavam de etapas distintas da operação.
  • Os registros documentais atuais preservam esses esquemas, mas isso não demonstra uso presente, suporte operacional, continuidade de autorização nem identidade permanente do objeto apontado.

Em novembro de 1996, o RFC 2056 foi publicado no fluxo Standards Track como Proposed Standard para definir formatos de URL destinados ao protocolo de recuperação de informações Z39.50. A proposta colocava diante da sintaxe opaca da URL uma escolha explícita entre dois esquemas: z39.50s e z39.50r. Essa bifurcação era pequena na superfície, mas importante no mecanismo. Ela permitia que uma interface soubesse, antes de interpretar os demais componentes, se deveria estabelecer ou reutilizar uma sessão de consulta ou executar uma recuperação com semântica mais restrita.

O Z39.50 geral não era uma simples leitura sem contexto. Uma consulta podia envolver várias etapas, conservar estado e interromper o fluxo para obter parâmetros adicionais. A participação do usuário dependia do cliente. Uma operação Search criava, no servidor, ponteiros para registros do banco de dados; operações posteriores podiam trabalhar sobre esse resultado. Assim, transformar uma URL em ação significava representar apenas uma parte de uma conversa protocolar potencialmente mais longa.

Dois esquemas, duas intenções

No esquema z39.50s, o host era obrigatório e a porta era opcional, com 210 como valor padrão. Todo o restante podia ser omitido. Ao receber a URL, o cliente deveria iniciar uma sessão com aquele host e porta ou reutilizar uma sessão já existente para a mesma combinação. Quando havia docid, também era necessário indicar o banco de dados, e o cliente realizava uma busca em forma de recuperação. Sem docid, os demais parâmetros podiam funcionar como requisitos, preferências ou indicações ignoráveis, conforme as capacidades e decisões do cliente. A sessão permanecia aberta para que o usuário pudesse continuar interagindo.

Essa última característica separava z39.50s de uma noção simplificada de “URL que devolve um documento”. A URL podia conduzir a um ambiente de consulta cujo próximo passo ainda dependeria do usuário, do cliente ou de parâmetros obtidos durante a interação. O endereço indicava como entrar em uma relação protocolar; não codificava necessariamente todo o desfecho.

O esquema z39.50r era mais estreito. Host e banco de dados eram obrigatórios, a porta 210 continuava sendo o padrão e o significado de uma URL sem docid ficava indefinido. O docid era opaco e definido pelo servidor. Para recuperar o item, o cliente o colocava como termo único em uma consulta Type-1 de formato geral, com tag 45, Bib-1 Use=docid e Structure=URx. A operação Search precisava produzir contagem exatamente igual a 1. Qualquer outro resultado tornava a recuperação malsucedida, e o comportamento posterior da aplicação não era definido pelo RFC.

Quando havia exatamente um resultado, o próprio Search Response podia conter o registro. Caso contrário, o cliente usava Present para recebê-lo. Depois disso, a sessão podia ser encerrada ou mantida. O texto, portanto, não autorizava uma escolha aproximada quando vários registros aparecessem, nem uma seleção arbitrária do “mais provável”. A unicidade era parte da condição de sucesso, não uma preferência de apresentação.

Identificador, registro e forma de entrega

A arquitetura também distinguia coisas que facilmente se confundem quando uma URL parece apontar para “um registro”. Havia o registro local no banco de dados, a noção abstrata de registro compartilhada entre as partes e o registro exportado efetivamente entregue ao cliente. Esses níveis não eram equivalentes.

O parâmetro esn, referente ao conjunto de elementos, selecionava quais elementos lógicos do registro deveriam ser retornados. Se ausente, a escolha cabia ao cliente. Se presente, podia ser usado nos nomes de conjuntos de elementos para resultados pequenos ou médios durante Search, ou posteriormente em Present. Já rs, referente à sintaxe de registro, tratava do empacotamento desses elementos para transmissão. Sem rs, o cliente escolhia. Quando uma lista era fornecida, a preferência era usar como PreferredRecordSyntax a primeira sintaxe da lista que o cliente suportasse.

Essa separação importa porque a seleção de campos e a representação de transporte respondem a perguntas diferentes. Escolher elementos não estabelece a identidade do objeto; escolher uma sintaxe não prova que duas representações sejam bibliograficamente equivalentes. O RFC 1729, citado no contexto de interoperabilidade de representações, documentava justamente os riscos de transportar informação entre formatos e sistemas que não compartilham perfeitamente as mesmas estruturas e capacidades.

A gramática do RFC 2056 herdava a base comum de URLs do RFC 1738. Na parte específica de Z39.50, bancos de dados múltiplos eram separados por +; ?docid era opcional onde a forma permitia; ;esn= carregava a seleção de elementos. Para sintaxes de registro, havia um único parâmetro ;rs=: quando mais de uma sintaxe era indicada, os valores eram separados por + dentro desse mesmo parâmetro. A distinção é estrutural: não se trata de repetir ;rs=, mas de fornecer uma lista em uma única ocorrência.

O que a URL observava — e o que não observava

Ler essa arquitetura historicamente ajuda a separar uma sequência de observações. O esquema indicava a intenção protocolar. Host e porta indicavam o ponto de conexão. O nome do banco selecionava um domínio de consulta. O docid fornecia um termo opaco definido pelo servidor. O cliente construía uma consulta específica. A contagem igual a um verificava unicidade naquele resultado. esn escolhia elementos lógicos; rs, a forma de representação; Search Response ou Present realizavam a entrega.

Nenhuma dessas etapas, isoladamente ou em conjunto, constituía por si só prova de que o objeto continuava autorizado, jamais fora substituído, mantinha identidade permanente em outro contexto, possuía descrição bibliográfica correta ou completa, seria analisado com segurança por qualquer software, preservaria a mesma sessão indefinidamente ou produziria o mesmo resultado para o usuário. Essas conclusões excederiam o que o mecanismo documenta.

A própria seção de segurança do RFC 2056 tornava essa cautela concreta. Um localizador poderia deixar de apontar para o item pretendido. Além disso, uma recuperação aparentemente inofensiva e idempotente poderia provocar uma operação remota danosa. A aparência de “buscar um registro” não bastava para inferir ausência de efeitos relevantes no sistema remoto.

Essa observação é especialmente importante porque URLs tendem a adquirir, socialmente, uma aparência de estabilidade. A sintaxe pode continuar válida enquanto o servidor, a base, a interpretação de um identificador ou as consequências de uma operação mudam. O RFC descrevia uma forma de executar uma intenção em determinadas condições; não criava uma garantia temporal sobre todas essas condições.

O contraste com WAIS sobre Z39.50-1988

O RFC 1625 não era uma especificação de URLs para WAIS. Ele documentava WAIS sobre Z39.50-1988 e oferece um contraste útil sem tornar os dois mecanismos equivalentes. Nesse contexto, a consulta usava Type-3 text query, os resultados eram descartados para permitir tratamento sem estado e não havia operação Present. No RFC 2056, em contraste, o comportamento Z39.50 podia preservar uma sessão e recorrer a Present para obter o registro.

A diferença mostra como aplicações construídas sobre a família Z39.50 podiam distribuir de maneira distinta a responsabilidade entre cliente e servidor, o tempo de vida dos resultados e a continuidade necessária entre uma busca e a entrega. O contraste é protocolar: ele não transforma o RFC 1625 em antecedente de uma sintaxe de URL para WAIS.

Situação documental atual

Nos metadados públicos consultados, o RFC 2056 aparece no fluxo Legacy e seu registro não apresenta uma relação explícita de atualização ou obsolescência. O registro de esquemas URI da IANA atualmente lista z39.50s e z39.50r como Permanent e z39.50 como Historical. Esses são fatos documentais sobre registros e classificação. Eles não demonstram volume de tráfego, disponibilidade de servidores, suporte em clientes atuais nem adoção operacional contemporânea.

A diferença entre registro e funcionamento é central para interpretar infraestrutura antiga. Uma entrada permanente em um registro administrativo preserva uma atribuição e evita colisões de nomes; não certifica que uma comunidade ainda use o mecanismo. Da mesma forma, a permanência de um RFC em acervos oficiais preserva uma especificação e sua história, não uma medição de implantação presente.

Os ensaios de Heng Lu sobre especificação comum mínima, decisões futuras localizadas e adoção voluntária, sobre camadas de realidade e sobre a primazia de código em execução oferecem uma lente interpretativa para esse episódio. Sob essa lente, o RFC 2056 pode ser visto como uma tentativa de especificar apenas o suficiente para interoperabilidade inicial enquanto deixava várias decisões posteriores para clientes, servidores e participantes locais. Essa é uma interpretação externa; não deve ser atribuída como intenção aos autores do RFC.

O valor histórico do RFC 2056 está justamente nessa separação de responsabilidades. Uma URL compacta não eliminava estado, negociação, representação ou escolha local. Ela conectava essas partes por uma gramática comum e definia pontos em que o comportamento precisava ser preciso — como a contagem de exatamente um resultado em z39.50r — enquanto deixava outros pontos deliberadamente dependentes do cliente ou do servidor. A URL era uma porta de entrada para um mecanismo distribuído, não uma prova condensada de tudo o que existia atrás dela.

Fontes