Résumé

  • z39.50s fait entrer l’utilisateur dans une recherche Z39.50 avec état : le client ouvre ou réutilise une session vers le même point de connexion et doit la laisser ouverte pour la suite de l’interaction.
  • z39.50r encadre une récupération plus stricte : un docid opaque devient le terme unique d’une requête Type-1 et Search doit trouver exactement un enregistrement, sans rapprochement approximatif ni choix arbitraire.
  • RFC 2056 distingue adresse, base, identifiant, recherche, sélection des éléments, syntaxe d’enregistrement et livraison. Son statut documentaire et les inscriptions IANA ne mesurent ni déploiement, ni trafic, ni prise en charge actuelle.

Lorsque RFC 2056 paraît en novembre 1996, son problème n’est pas simplement de donner une nouvelle forme d’adresse à des documents. Z39.50 est un protocole de recherche documentaire dont une interrogation générale peut conserver un état et se dérouler en plusieurs étapes. Une recherche peut créer, côté serveur, des pointeurs vers des enregistrements d’une base ; le client peut ensuite poursuivre l’échange et, selon son interface, demander à l’utilisateur des paramètres supplémentaires. Faire entrer cette interaction dans une URL oblige donc à préserver davantage qu’un lieu.

La RFC, publiée sur le Standards Track avec le statut Proposed Standard, répond par deux schémas. z39.50s et z39.50r permettent à l’interface de reconnaître l’intention avant d’interpréter les parties opaques de l’URL. Dans les métadonnées actuelles capturées, RFC 2056 figure dans le flux Legacy et aucune relation explicite de mise à jour ou d’obsolescence n’est indiquée. Ce sont des renseignements sur le document, non sur son déploiement présent.

Le premier schéma, z39.50s, conserve le caractère interactif de la recherche. L’hôte est obligatoire ; le port est facultatif et prend la valeur 210 par défaut. Tous les autres éléments sont optionnels. Le client ouvre une session vers le couple hôte-port ou réutilise une session déjà ouverte vers le même point de connexion. L’URL peut ainsi rejoindre une interaction qui possède déjà un état.

Si un docid est présent, une base de données doit également être indiquée et le client effectue une recherche de forme « retrieval ». Lorsque docid est absent, les autres paramètres peuvent, selon le client, devenir des exigences, des préférences ou des indications ignorées. Le logiciel qui reçoit l’URL conserve donc une part de décision.

Une fois le traitement de z39.50s effectué, la session doit rester ouverte pour l’utilisateur. L’URL sert ainsi de point d’entrée dans une interaction Z39.50 avec état plutôt que de désigner seulement une transaction autonome. La participation effective de l’utilisateur dépend de l’interface du client, mais la possibilité de poursuivre appartient au comportement prescrit.

z39.50r resserre ce modèle. L’hôte et la base de données sont obligatoires ; le port reste facultatif avec 210 par défaut. Sans docid, la signification est indéfinie. Avec lui, le client dispose d’un terme opaque défini par le serveur, et non d’un identifiant universel dont il pourrait reconstruire le sens.

Le docid devient le terme unique d’une requête Type-1 au format général, avec le tag 45, l’attribut Bib-1 Use=docid et Structure=URx. Search doit produire exactement un résultat. Si le compte n’est pas égal à 1, la récupération échoue et le comportement de l’application n’est pas défini. Aucun rapprochement approximatif ni choix arbitraire parmi plusieurs enregistrements n’est autorisé.

Si l’unique enregistrement est déjà inclus dans la Search Response, le client peut le recevoir immédiatement. Sinon, il emploie Present. Après réception, il peut fermer la session ou la conserver. z39.50r organise donc une récupération déterminée par une recherche à résultat unique, tandis que z39.50s maintient la session ouverte afin que l’utilisateur puisse poursuivre.

La notion d’enregistrement recouvre plusieurs niveaux. L’enregistrement local d’une base, l’enregistrement abstrait partagé par le modèle Z39.50 et l’enregistrement exporté pour la récupération sont distincts. elementset sélectionne les éléments logiques ; recordsyntax détermine comment ils sont empaquetés pour la livraison. Une sélection d’éléments n’est pas une syntaxe d’enregistrement, et une syntaxe ne définit pas à elle seule l’étendue logique du contenu.

Lorsque esn est absent, le client choisit. Lorsqu’il est fourni, il doit être utilisé dans les noms d’ensemble d’éléments pour les petits ou moyens ensembles de Search, ou plus tard dans Present. Si rs est absent, le client choisit également. Lorsqu’une liste est fournie, il devrait de préférence proposer d’abord la première syntaxe qu’il prend en charge comme PreferredRecordSyntax.

La grammaire rend cette organisation visible. Les bases de données sont séparées par +. Le ?docid est optionnel. Peuvent ensuite apparaître ;esn= et un seul paramètre ;rs=. Lorsque plusieurs syntaxes d’enregistrement sont proposées, leurs valeurs sont séparées par + à l’intérieur de cet unique paramètre. La forme définie n’est donc pas une répétition de ;rs=.

Cette syntaxe s’appuie sur la grammaire commune de RFC 1738. RFC 1729 avait par ailleurs documenté les risques d’interopérabilité liés aux représentations. Ce contexte éclaire la séparation entre l’enregistrement abstrait, les éléments choisis et leur forme exportée : recevoir une représentation acceptée n’abolit pas les transformations qui ont conduit de la base locale à l’enregistrement livré.

RFC 1625 fournit un voisin historique qu’il ne faut pas confondre avec ce mécanisme. Dans son contexte WAIS, la recherche utilisait une requête texte Type-3, les résultats étaient supprimés pour permettre un traitement sans état et Present n’était pas utilisé. RFC 2056 rend au contraire visibles l’état possible de la session, les résultats détenus côté serveur et la succession entre Search et Present.

La sécurité ajoute une limite plus grave. RFC 2056 avertit qu’un localisateur peut, avec le temps, ne plus viser l’élément initialement voulu. Une URL peut conserver la même forme tandis que ce qui se trouve derrière le point de connexion, la base ou l’identifiant opaque a changé. Le document avertit aussi qu’une opération ressemblant à une récupération inoffensive et idempotente peut déclencher une opération distante dommageable. La forme de la demande ne garantit donc ni la permanence de sa cible ni l’innocuité de ses effets.

Le registre IANA actuel inscrit z39.50s et z39.50r comme Permanent et z39.50 comme Historical. Ces mentions décrivent l’état des inscriptions. Elles ne mesurent pas le trafic, ne démontrent pas une prise en charge logicielle contemporaine et ne constituent pas une approbation opérationnelle. De même, le statut documentaire de RFC 2056 décrit une spécification, pas son déploiement actuel.

Pris ensemble, ces mécanismes racontent une architecture de responsabilités distribuées. Le schéma annonce l’intention générale. Le point de connexion conduit au serveur. La base délimite l’espace de recherche. Le serveur attribue le sens local du docid opaque. Le client construit la recherche requise, choisit certains paramètres lorsqu’ils manquent et négocie la représentation qu’il sait recevoir. Search établit un ensemble de résultats ; Present peut ensuite assurer la livraison. Enfin, la session peut demeurer disponible pour la continuation de l’interaction.

Cette succession explique les limites de ce qu’une observation établit. Atteindre le même point de connexion ne rend pas immuable le contenu d’une base. Le même docid peut rester textuellement stable sans constituer une preuve indépendante de l’identité durable de l’objet que le serveur lui associe. Un compte de Search égal à 1 établit un résultat unique pour la recherche prescrite à cet instant, non que l’enregistrement n’a jamais été remplacé. elementset renseigne sur les éléments demandés et recordsyntax sur leur forme de livraison ; aucun des deux ne certifie à lui seul la correction bibliographique ou la complétude conceptuelle de l’enregistrement.

La même séparation vaut pour l’autorisation, l’analyse des données et l’issue humaine. Une récupération qui fonctionne à un instant n’emporte pas une autorisation perpétuelle. Recevoir un enregistrement dans une syntaxe déterminée n’établit pas que toute analyse ultérieure sera sûre. Une session encore ouverte décrit un état protocolaire ; elle ne dit pas si l’utilisateur a finalement obtenu ce qu’il recherchait. Ces limites découlent de la mécanique et des avertissements documentés, sans ajouter d’intentions aux auteurs de RFC 2056.

Les trois essais de Heng Lu cités ci-dessous interviennent uniquement à ce niveau interprétatif. L’idée d’une spécification commune minimale aide à lire la place laissée aux décisions locales futures et à l’adoption volontaire. La distinction entre couches de réalité aide à ne pas confondre l’existence symbolique d’une inscription ou d’une norme avec l’état d’un système concret. La primauté du code en fonctionnement rappelle qu’une réalité opérationnelle ne se déduit pas entièrement du texte normatif. Ces essais n’établissent ni l’intention des auteurs de RFC 2056, ni une pratique moderne préférable, ni un niveau d’utilisation présent.

Sources