Résumé

  • La requête diffusée Who-Provides? sollicitait les fournisseurs inconnus, sans transformer leur silence en preuve d’absence.
  • La question adressée Do-You-Provide? exigeait au contraire une réponse, y compris une liste vide, tandis qu’une indication sur un tiers devait normalement être vérifiée auprès de celui-ci.
  • Le nom d’une ressource décrivait une chaîne de démultiplexage ; comprendre UDP ou le port 53 ne suffisait donc pas à accepter toute spécialisation placée au-dessus.

Le cas le plus révélateur de la RFC 887 ne s’arrête pas lorsqu’un serveur de noms est trouvé. Un hôte connu affirme que S fournit le service. La machine demande alors directement à S. S répond par une liste vide. Il faut exclure S, reprendre la recherche, recevoir le nom de T et interroger T à son tour.

Ce détour n’est pas une faiblesse du protocole. C’est sa discipline épistémique : celui qui se souvient d’un fournisseur et celui qui exécute le service ne témoignent ni depuis le même endroit, ni au même moment.

Le nom suivait les étages du traitement

RLP nommait une ressource à partir du numéro du protocole Internet le plus bas qui permettait de l’atteindre. Suivaient une longueur et un identifiant composé des valeurs qui démultiplexaient les niveaux supérieurs. Pour un serveur DNS sur UDP, l’exemple associait 17 et le port 53.

Le champ de longueur permettait de sauter un identifiant inconnu sans perdre le début de la ressource suivante. L’hôte examinait ensuite les composantes successives. Un protocole inférieur absent entraînait un refus. L’épuisement exact du nom après des contrôles réussis autorisait une réponse positive. Des composantes restantes que l’hôte ne savait pas interpréter signifiaient que la spécialisation entière n’était pas fournie.

Cette grammaire empêchait un oui trop large. Offrir TFTP n’obligeait pas à offrir un format particulier de vidage mémoire sur TFTP. Le transport, le service et sa variante conservaient chacun leur frontière.

Demander à tous ne produisait que les oui

Who-Provides? était destiné à la diffusion. Les hôtes qui reconnaissaient au moins une ressource répondaient par I-Provide. Les autres pouvaient se taire.

Le coût collectif restait contenu, mais le silence gardait plusieurs causes : absence réelle, paquet perdu, réponse perdue, hôte sans RLP ou refus de participer. La RFC 919 rappellera qu’une diffusion IP n’est ni fiable, ni ordonnée, ni exempte de duplications. Elle consomme en outre du travail sur chaque hôte qui la reçoit.

Le mécanisme remplaçait une liste d’adresses câblée par une sollicitation partagée. Il ne donnait pas au requérant le pouvoir de conclure « personne » à partir d’un réseau silencieux.

Interroger un hôte précis donnait un non explicite

Do-You-Provide? changeait de contrat. La question visait une seule adresse et le destinataire devait répondre, même s’il ne fournissait aucune ressource demandée. Une liste vide devenait donc un non explicite, borné à cet hôte et à cette requête.

La RFC 887 interdisait de diffuser ce message. Exiger un accusé négatif de chaque machine aurait transformé une demande en tempête de réponses. Le protocole associait ainsi deux politiques : seuls les positifs parlent devant la foule ; l’interlocuteur nommé doit répondre dans les deux cas.

Un non direct ne disait toujours rien des autres hôtes, d’un autre instant ou d’une variante différente du service. Il levait une incertitude plus étroite, mais plus solide, que le silence collectif.

Le tiers indiquait une piste, pas un verdict

Who-Anywhere-Provides? et Does-Anyone-Provide? permettaient de consulter un hôte « intelligent » connaissant d’autres réseaux. La réponse They-Provide pouvait citer le répondant ou des machines tierces.

Le texte refusait d’élever cette connaissance indirecte au rang de confirmation. Le client n’était pas tenu de lui faire confiance sans examen et devait, dans la plupart des cas, adresser un Do-You-Provide? au candidat.

Cette distinction donnait une place normale à l’information périmée. L’annuaire pouvait avoir observé S hier, alors que S niait aujourd’hui. La correction ne nécessitait pas d’accuser l’un des deux de mensonge ; il fallait conserver l’auteur et l’heure implicite de chaque affirmation.

Le drapeau Local-Only ajoutait la portée à la question. Les adresses retournées devaient appartenir au réseau IP du requérant, et un hôte multirésident devait répondre avec sa bonne adresse locale. La localité n’était pas une présentation : elle modifiait les candidats admissibles.

Corréler une réponse ne suffisait pas à identifier son auteur

Le Message-ID de seize bits servait simplement à rapprocher demande et réponse. Il n’authentifiait pas l’émetteur. Le checksum UDP détectait certaines altérations accidentelles ; il ne constituait ni signature, ni autorisation.

Même une réponse directe I-Provide restait une déclaration du serveur. Elle ne garantissait pas la réussite de la transaction suivante, la conformité complète, la disponibilité durable ou le droit du client à utiliser le service.

D’autres systèmes ont déplacé les questions

Les standards ultérieurs offrent une comparaison, sans prouver une filiation. La RFC 2608 organisait SLPv2 autour de types, d’attributs, d’agents utilisateur, service et annuaire, ainsi que de portées administratives. Elle prévoyait l’authentification des URL et attributs, tout en excluant la confidentialité.

La RFC 6762 a défini des opérations de type DNS sur le lien local sans serveur DNS classique. La RFC 6763 a structuré la découverte d’instances nommées selon un type de service et un domaine. Le vocabulaire s’est enrichi ; la nécessité d’identifier la source, la portée et l’âge d’une annonce est restée.

Le numéro enregistré n’attestait aucun serveur vivant

La RFC 887 attribuait le port UDP 39. Le registre IANA des noms de service et ports conserve aujourd’hui rlp au port 39 pour TCP et UDP. C’est la continuité d’une attribution, non un recensement des déploiements.

La RFC 6335 précise qu’une attribution n’est pas une approbation et que le trafic observé sur un port peut ne pas appartenir au service enregistré. Le registre coordonne un nom ; seule une observation datée peut parler d’un système vivant.

Sources et limites

L’analyse repose sur les RFC 887, 919, 2608, 6762, 6763 et 6335, ainsi que sur le registre IANA. Elles établissent des règles et un état administratif. Elles ne prouvent ni l’ampleur du déploiement de RLP, ni une descendance directe vers les protocoles ultérieurs, ni le comportement actuel d’un produit.